« 1 (2) 3 4 »


Re: Python - l'instruction return
OverdOzed
Inscrit:
19/03/2016 16:30
De Belgique
Post(s): 1415
Elle ne me gêne pas à priori mais j'aime bien regrouper pour des raisons d'organisation. C'était juste une question.

Tu veux parler de cette ligne ?

if not 'init' in self.obj:


Si le mode toujours vraie du senseurs always n'est pas activé, alors oui, la condition est inutile.

Par contre, si le senseur est toujours vraie, alors le init se lance en boucle autant de fois que la fréquence définie.

Je suis donc obligé de faire cette condition pour éviter de remettre des variables interne à zéro, par exemple.

Contribution le : 23/03/2018 16:47
_________________
Mon projet jeu vidéo
Mes tutos
Créer un fichier PDF de la contribution Imprimer


Re: Python - l'instruction return
OverdOzed
Inscrit:
29/04/2007 20:11
De Nîmes...300 jours de soleil par an, inondations le reste du temps
Post(s): 3774
Alors là je vais te gronder : tous tes noms doivent être explicites. Toto, ça ne veut rien dire. On ne peut pas lire "toto" et savoir ce que c'est censé faire ou à quoi ça sert.

Il faut savoir qu'en réalité, quand on programme, on ne passe que 10% de son temps à écrire du code. Les 90% qui restent, on les passe à en (i]lire[/i]. Pour comprendre comment il marche, comment on l'utilise, ou pourquoi il ne marche pas. Donc, tous les raccourcis qui rendent l'écriture plus facile, plus rapide, au détriment de la clarté, de la lisibilité et de la compréhensibilité du code, sont à proscrire.
Et en plus, c'est gratuit, la longueur des noms n'a aucun impact sur les performances.

Pour la même raison, ta classe Text est mal nommée. Un objet de la classe Text a pour charge de stocker des morceaux de texte et de les afficher. Ce n'est donc pas un texte.
Tu devrais renommer toto en Text, comme c'était avant, et renommer cette classe principale en, je sais pas, TextWriter par exemple.

Ah, et un nom de classe commence, par convention, par une majuscule. Ce n'est pas "toto" mais "Toto"

Passées les questions de forme, attaquons-nous au fond. Un principe important en programmation en général, et tout particulièrement en POO, c'est la séparation des responsabilités. Globalement, chaque élément du code, que ce soit une classe, une méthode ou carrément une bibliothèque, doit s'occuper d'une seule tâche. Plus le code est découpé, plus il est modulaire, et plus il est facile à étendre, modifier, corriger et débugger.

En gardant cette idée en tête : dans son constructeur, un objet Text modifie une propriété de l'objet auquel le script est attaché. Non mais de quoi je me mêle ? C'est un double problème : 1/ ça déborde du rôle d'un constructeur, qui est là pour construire l'objet, pas plus, et 2/ ça outrepasse le rôle d'un Text, qui est là pour stocker des textes et les afficher, pas pour modifier son voisin. Cette modification d'un champ de l'objet parent doit dégager.

D'ailleurs, ça pose un autre gros problème : ton Text est une classe indépendante. Donc, on peut l'instancier un peu comme on veut, en principe. Sauf que nom, puisqu'il faut qu'on soit dans un contexte où getCurrentController() va renvoyer quelque chose de cohérent. Cette contrainte 1/ ne résulte pas de l'intention du code, pour afficher du texte normalement on se moque du contexte, et 2/ n'est pas explicite. On ne le sait pas à la lecture du code, aucune règle de syntaxe ne l'indique, il faut le deviner.

Ensuite, autre responsabilité que le Text ne devrait pas avoir, et son constructeur encore moins, c'est qu'il assigne une variable globale (bge.logic.getCurrentScene().post_draw), potentiellement utilisée par beaucoup de monde, et remplace sa valeur. Post_draw est censé être une liste de méthodes : on inscrit des méthodes pour qu'elles soient appelées au bon moment. Tel que tu le fais ici, tu écrases la liste, autrement dit tu désinscris toutes les méthodes inscrites précédemment. C'est un coup à tout casser. Et là encore, s'inscrire auprès de la scène, ce n'est pas son travail.

On pourrait aussi dire que stocker des tronçons de texte et les afficher, c'est trop. La responsabilité du stockage étant très simple, on peut la laisser où elle est, mais dans l'idéal il faudrait la virer.

Parlons maintenant du stockage. Pourquoi dans le dictionnaire ? Pourquoi est-ce que ce Text devrait stocker ses données dans une variable globale ? La liste des textes à afficher n'intéresse à priori que lui. Autant qu'il la garde pour lui plutôt que d'étaler ses affaires partout. C'est à ça que sert l'état d'un objet, donc ses champs. D'ailleurs, en l'état, ton code ne devrait pas marcher. Tu références dico['list_text'] pour y ajouter des éléments, mais à aucun moment cette variable n'est initialisée. Tu devrais avoir une erreur de type pointeur null. Est-ce que dico['list_text'] est initialisé ailleurs ?

Pour régler tout ça, il faut changer un peu l'architecture. On va découper Text en TextList et TextWriter ; Toto devient TextItem qui est un peu plus clair. Ces trois classes finissent dans un module, qu'on appellera textwriter.py. Toute mention du dictionnaire disparaît, et on n'importe même plus le module bge. Ce qu'on a à présent, c'est un ensemble autonome : un Writer stocke une List et en extrait des Items qu'il affiche. Le reste du monde, ces classes n'en ont rien à faire. Le code modifié est ici

Ensuite, tu vas avoir un scripts qui va initialiser les choses :
import bge
from dictionnary import dico # dictionary s'écrit avec un seul N ;-)
import textwriter

list = TextStorage()
writer = TextWriter()
dico['list_text'] = list
writer.list = list
bge.logic.getCurrentScene().post_draw.append(self.write)

À ce stade, la méthode post_draw() va bien, entre autres (donc sans écraser tout ce qu'elle aurait pu faire d'autre), appeler un TextWriter et lui demander d'afficher ses textes, qu'il ira chercher dans une TextList, qui est stockée dans le dico pour être accessible par le reste du code. Le TextWriter, lui, est caché : personne n'a besoin de savoir qu'il est là, personne ne peut interagir avec lui, il n'existe que parce que post_draw appelle une de ses méthodes.

Ce script est à placer à un endroit où il s'exécutera une seule fois.

Et pour finir, à chaque fois que tu veux ajouter quelque chose à ton affichage, ça se fait en une ligne : dico['list_text'].add("Hello, World !", 0.7, 0.42, [0.0, 1.0, 0.0, 1.0], "Arial")

La possibilité d'effacer un texte est laissée comme exercice pour le lecteur.

Et pour répondre à ta dernière question : on pourrait intégrer la classe TextItem à la classe TextStorage. Le résultat serait une classe à part entière, mais qui ne serait accessible et utilisable que depuis l'intérieur de TextStorage. Le TextStorage serait le seul à savoir que les TextItems existent.
Ça peut avoir du sens, mais dans ce cas précis non : le Writer utilise implicitement des TextItem, puisqu'il les extrait de son TextStorage. Ça fonctionnerait, mais ça ne serait pas très cohérent.

Contribution le : 23/03/2018 16:51
_________________
|C'est en forgeant qu'on devient forgeron, c'est en mouchant qu'on devient moucheron et c'est en sciant que Léonard devint scie.
Créer un fichier PDF de la contribution Imprimer


Re: Python - l'instruction return
OverdOzed
Inscrit:
19/07/2011 21:39
De Corsica !
Post(s): 1027
Citation :

RedStart a écrit:
Si le mode toujours vraie du senseurs always n'est pas activé, alors oui, la condition est inutile.

Par contre, si le senseur est toujours vraie, alors le init se lance en boucle autant de fois que la fréquence définie.

Je suis donc obligé de faire cette condition pour éviter de remettre des variables interne à zéro, par exemple.


Et juste pour rebondir la dessus, on est pas dans un script qui ce lance en boucle la. Tu va devoir instancier ta classe et la fonction init se lancera que lors de la création de l'objet. Donc à moins que tu crée 50 000 objets en boucle, cette fonction ne se lancera qu'une seule fois.

Contribution le : 23/03/2018 17:44
Créer un fichier PDF de la contribution Imprimer


Re: Python - l'instruction return
OverdOzed
Inscrit:
19/03/2016 16:30
De Belgique
Post(s): 1415
Oui, je suis d'accord avec toi. Mais là, je suis dans un essais, c'est pour tester avant de mettre ça dans mon vrai code. Mais en ayant la même architecture de mon projet pour être sûr que ça marchera comme prévu.

Citation :

...doit s'occuper d'une seule tâche. Plus le code est découpé...


Je l'ai bien compris, ça. C'est c'est pas toujours évident de pouvoir séparer certaines choses parce que tu as des dépendances par-ci et par-là.

Je t'invite à écumer en diagonale la version 0.3.2 de mon projet, comme ça, tu pourra me dire avec un cas concret sous la main, là où j'ai mal agencés mes affaires.

Citation :

....c'est qu'il assigne une variable globale bge.logic.getCurrentScene().post_draw....


'Pas d'accord: cette "chose" permet l'affichage du texte. D’où vois-tu que c'est une variable ?

Si je ne me trompe pas:
- BGE est un module
- Logic est... une classe ? une instance ? Je me suis pas posé la question.
- getCurrentScene() c'est une instruction, pour moi
- post_draw c'est une instruction, pour moi

Moi, je constates une action, pas un paramétrage.

Citation :
Pourquoi dans le dictionnaire ? Pourquoi est-ce que ce Text devrait stocker ses données dans une variable globale ?


Parce que, dans mon projet, mon dictionnaire communique avec toutes les scènes: le HUD, le personnage et l’environnement (le terrain, donc) ou devrais-je dire l'inverse. Je te renvoies au code de mon projet pour plus de détail.

Qui plus est que, si je ne me trompe pas, ce dictionnaire n'est pas renouvelé mais lié (enfin, je n'en sait rien en fait).

Le dictionnaire est crée dans un autre script, je n'ai pas d'erreur python.

Tien, voici un petit script de ma scène "barre chargement".

Encore une fois, c'est un test grandeur nature.

Donc, le fichier blend ou se trouve ce script est chargé dans ma scène principale (là ou je fais "play") et sert à donner l'état de chargement du jeu. Il est supprimé par la suite.

Comme tu le devinera mis en commentaire, des signaux partent de ma scène principale, communique via le dictionnaire et "barre chargement" pompe l'info depuis le dico pour se mettre à jour.

J'ai dû séparer cette scène du reste de mon jeu car, comme je passe de blend en blend, cette scène revient en début de partie, c'est pour éviter de modifier dans chaque blend un duplicata de celui-ci.

Vu que je peux lier "barre chargement" aux autres blends, les modifications dans l'un se répercute dans les autres blends.

Contribution le : 23/03/2018 18:13
_________________
Mon projet jeu vidéo
Mes tutos
Créer un fichier PDF de la contribution Imprimer


Re: Python - l'instruction return
OverdOzed
Inscrit:
19/03/2016 16:30
De Belgique
Post(s): 1415
Hook, si je lance une fois le script et que, entre temps, je change le texte (après être lancé). Ça ne se verra pas, puisque le script n'est pas renouvelé.

Contribution le : 23/03/2018 18:16
_________________
Mon projet jeu vidéo
Mes tutos
Créer un fichier PDF de la contribution Imprimer


Re: Python - l'instruction return
OverdOzed
Inscrit:
19/07/2011 21:39
De Corsica !
Post(s): 1027
Pour actualiser ton texte tu en ajoute un nouveau avec la fonction Add et tu appelle la fonction Write qui va écrire le texte.
La ce que tu dis c'est juste pas logique, ta TextList tu la crée une seule fois. Si tu commence à créer des objets à la chaîne on est pas sorti de l'auberge

Ton init tu le met dans ta fonction Main quand tu déclare tes instances pour les créer une fois.
Le truc que tu comprend pas peut être, c'est qu'une classe n'est pas obligé d'être rattachée à un GameObject.

Quand tu écris ça:
Citation :

Redstar a écrit:
self.cont = bge.logic.getCurrentController()
self.obj = self.cont.owner


Une instance de classe n'a pas besoin d'être rattachée à un objet dans ton cas présent.
C'est pas la peine, déjà de base cherche pas à comprendre ne met pas de condition dans la __init__ vu qu'elle ne sera exécuté QU'UNE SEULE FOIS (lors de la création d'un objet).

La condition par contre comme je disais, je la mettrais dans la fonction principale de ton script qui sera exécutée toute les frames. Pour créer une seule instance de chaque classe et stocker les références dans des variables.

Citation :

Redstar a écrit:
Je t'invite à écumer en diagonale la version 0.3.2 de mon projet, comme ça, tu pourra me dire avec un cas concret sous la main, là où j'ai mal agencés mes affaires.


Le travail titanesque, je suis pas sur qu'on est envie de se farcir des scripts qui à mon avis sont trèèèès long Non c'est un peu facile si tu veux faire de la POO dans ton projet alors continu de suivre des tutos de faire des exo pratiques ce genre de chose ...
Et puis je ne suis pas d'accord, on peut parfaitement apprendre sans avoir besoin de quelqu'un qui explique constamment en IRL (à condition de savoir se remettre en question).

Contribution le : 23/03/2018 23:31
Créer un fichier PDF de la contribution Imprimer


Re: Python - l'instruction return
OverdOzed
Inscrit:
29/04/2007 20:11
De Nîmes...300 jours de soleil par an, inondations le reste du temps
Post(s): 3774
Citation :
C'est c'est pas toujours évident de pouvoir séparer certaines choses parce que tu as des dépendances par-ci et par-là.

Des excuses, toujours des excuses . Si des dépendances nuisent à la séparation des responsabilités, en général, la solution est d'éliminer la dépendance. Note que dans le code que j'ai modifié, TextWriter ne dépend plus de rien, le module est autonome. Les dépendances, c'est le mal, de toute façon.

Citation :
Je t'invite à écumer en diagonale la version 0.3.2 de mon projet, comme ça, tu pourra me dire avec un cas concret sous la main, là où j'ai mal agencés mes affaires.

L'échelle du projet s'y prête mal. Sur un cas particulier je veux bien, sur l'ensemble ça fait plus de travail que je ne suis prêt à en fournir.

Citation :
'Pas d'accord: cette "chose" permet l'affichage du texte. D’où vois-tu que c'est une variable ?

Je me suis mal exprimé, mais j'ai raison sur le fond. D'où je le vois ? De la syntaxe du code. Et si ça ne te suffit pas, de la documentation officielle de Python.
BGE est un module. Logic, ça peut être une classe, un objet, on s'en moque en vrai. getCurrentScene() est une méthode, qui renvoie une KX_Scene si mes souvenirs sont bons. "Instruction" est juste, mais c'est un terme trop vaste pour être utile ici (ça couvre aussi bien un appel de méthode qu'une assignation ou une comparaison). Mais jusque-là, tu as bien compris.

C'est l'étape suivante qui pose problème. Post_draw est une variable. Pour paraphraser la documentation, c'est une collection de callables, donc d'objets qu'on peut appeler, par exemple des méthodes. L'idée est qu'après avoir dessiné la scène, on va appeler tous les éléments de la collection. Post_draw est en gros "la liste des trucs qu'on fera après le rendu". Ce n'est pas une instruction, c'est une collection d'instructions. Et ton code remplace cette collection par une nouvelle (via "... = [write]"), ce qui revient à désinscrire tout ce qu'il pouvait y avoir avant. C'est un aimant à bug.

Ce n'est donc pas une action. C'est une assignation. Comme l'indique le "="...

Citation :
Parce que, dans mon projet, mon dictionnaire communique avec toutes les scènes

Ce n'est pas ce que j'ai demandé. Le dictionnaire, OK, il a sa place dans ton système dans l'ensemble, pas de problème de ce côté-là, ce n'est pas la seule façon de faire mais ça marche.

Ce que je conteste, c'est ce que cette information en particulier fait dans le dictionnaire. La liste des textes à afficher n'a rien à faire là, c'est une information qui ne concerne que le TextWriter. Cf mon exemple modifié : le TextStorage s'y trouve, mais il encapsule ces données (en gros, il les cache aux yeux du reste du code, toute interaction avec la liste de textes passe par lui).

L'encapsulation est un autre principe important : ne doit avoir accès à une information que celui qui en a vraiment besoin.

@ Hook
Citation :
C'est pas la peine, déjà de base cherche pas à comprendre ne met pas de condition dans la __init__ vu qu'elle ne sera exécuté QU'UNE SEULE FOIS (lors de la création d'un objet).

Là pour le coup tu rates un détail. On vérifie si l'objet auquel le script est rattaché a été initialisé, ça ne concerne pas l'objet qu'on est en train de construire. Cette méthode est exécutée à chaque fois qu'on crée un objet de la classe Text. Et on ne sait pas à quelle fréquence ça se passe. Si ça se trouve, il instancie tout le temps des Texts pour rien, la vérification a du sens.
En gros : l'architecture est bancale, donc le scotch un peu partout se justifie

Contribution le : 24/03/2018 02:12
_________________
|C'est en forgeant qu'on devient forgeron, c'est en mouchant qu'on devient moucheron et c'est en sciant que Léonard devint scie.
Créer un fichier PDF de la contribution Imprimer


Re: Python - l'instruction return
OverdOzed
Inscrit:
19/03/2016 16:30
De Belgique
Post(s): 1415
Citation :

La ce que tu dis c'est juste pas logique, ta TextList tu la crée une seule fois. Si tu commence à créer des objets à la chaîne on est pas sorti de l'auberge


Si tu te cantonnes au code que j'ai donné là, on est d'accord. Mais là, moi, je parle de l'ensemble en y incluant le code "fantôme" de mon projet.

Voici un bout du début de mon code pour le terrain.

La classe mère contient des éléments qui sont censés se répéter un peu partout dans l'ensemble. J'ai estimé intéressant de mettre quelques fonctions là pour éviter de réécrire à chaque fois ces même lignes.

La classe HUD hérite de "mere" (mais ce n'est pas la seule). Donc, "mere" ne s'exécute pas sans appels.

Pour pouvoir appuyer sur un bouton et obtenir un effet, je dois pouvoir envoyer un signal grâce à ma souris. Mais si je suis ta réflexion, le script ne fonctionnera qu'une fois, par conséquent, je peux cliquer autant que je veux, je n'aurai pas mon effet si je ne le place pas dans "init".

Maintenant, supposons que l'on rajoute l'affichage du texte: le "post_draw" n'a besoin que d'être lancé qu'une fois, ok. Mais pour le reste ? Si mon script ne se lance qu'une fois globalement, mes autre textes s’afficheront ? Non.

Tout ça pour dire que, dans le BGE, on est dans le cas ou le script doit être appelé en boucle. Ce n'est pas un simple programme "pur python" que l'on lancerai comme un batch Windows.

Enfin, pourquoi devrai-je rappeler la fonction "write" alors que je peux simplement modifier un texte ? En plus, si je fais ça, ça va superposer l'ancien texte avec le nouveau, ce qui vas donner un effet gras sur le texte. C'est pas ça que je veux, moi.

C'est en faisant des essais que j'ai remarqué ça.

Citation :
Le travail titanesque, je suis pas sur qu'on est envie de se farcir des scripts qui à mon avis sont trèèèès long


Je respecte ton avis mais....

Beeenn, d'un côté, si tu n'as pas de cas concrets et que tu te contentes de faire des ateliers, je vois pas trop comment la personne extérieur peut apporter un jugement correct.

Non ? Le programmeur est censé savoir programmer comme un pro d’entrée de jeu ??? Ça, c'est "l'Allemand blond aux yeux bleu", si je puis me permettre. Et c'est la raison pour laquelle il y a du chômage au 21e siècle, en plus.

Citation :
...une nouvelle (via "... = [write]"), ce qui revient à désinscrire tout ce qu'il pouvait y avoir avant. C'est un aimant à bug...


Cette phrase me gêne. Si c'est un aimant à bug, comment faut-il rédiger le code pour que ce ne soit plus considéré comme tel ?

Citation :
...c'est ce que cette information en particulier fait dans le dictionnaire. La liste des textes à afficher n'a rien à faire là...


Si. Je l'ai expliqué plus haut: Dans mon projet, il y a 2 blends: le terrain et "barre chargement". Ils sont tous deux indépendants, par conséquent, ils n'ont aucun liens physique mais il faut lier l'un à l'autre pour l'avoir partiellement.

Ce qui veux dire que je dois réécrire le code pour afficher le texte dans le second blend qui ne l'a pas (le terrain, donc).

C'est la raison pour laquelle j'ai modifié le code de sorte à ce que cela ressemble à l'architecture du code de mon projet, pour m'assurer que cela fonctionnera pour la suite. Et la suite, c'est de séparer la scène HUD dans un blend séparé, où il y a du texte. Comme c'est déjà le cas pour "barre chargement".

Si je vous explique quelque chose sans support quelconque, vous comprenez bien que vous allez demander un cas concret ?

Contribution le : 24/03/2018 11:14
_________________
Mon projet jeu vidéo
Mes tutos
Créer un fichier PDF de la contribution Imprimer


Re: Python - l'instruction return
OverdOzed
Inscrit:
29/04/2007 20:11
De Nîmes...300 jours de soleil par an, inondations le reste du temps
Post(s): 3774
Citation :
Pour pouvoir appuyer sur un bouton et obtenir un effet, je dois pouvoir envoyer un signal grâce à ma souris. Mais si je suis ta réflexion, le script ne fonctionnera qu'une fois, par conséquent, je peux cliquer autant que je veux, je n'aurai pas mon effet si je ne le place pas dans "init".

J'entrevois que tu n'as pas compris ce qu'est la méthode __init__. Elle est appelée quand tu crées un objet. C'est un initialiseur (je disais constructeur, et dans la plupart des langages c'est la même chose, mais en Python les deux sont séparés), qui sert à (duh) initialiser l'objet qu'on vient de créer. C'est tout.

Quand tu cliques, tu lances un script de gestion du clic. Il fait sa tambouille. Cette tambouille peut impliquer la création d'objets. Si ton script crée deux objets, la méthode __init__ sera appelée une fois sur chacun. S'il n'en crée aucun, __init__ ne sera jamais appelée. Je ne vois pas ce que tu veux dire avec ton histoire de script qui ne s'exécute qu'une fois sauf si on le met dans une méthode qui n'a de raison d'être que si elle s'exécute une seule fois...

Citation :
Maintenant, supposons que l'on rajoute l'affichage du texte: le "post_draw" n'a besoin que d'être lancé qu'une fois, ok. Mais pour le reste ? Si mon script ne se lance qu'une fois globalement, mes autre textes s’afficheront ? Non.

J'ai décidément du mal à suivre ta logique. Tu as regardé le code modifié que je t'ai proposé ?

Citation :
Tout ça pour dire que, dans le BGE, on est dans le cas ou le script doit être appelé en boucle. Ce n'est pas un simple programme "pur python" que l'on lancerai comme un batch Windows.

... Si ?
Un script n'a pas à être exécuté en boucle. Ce n'est pas la seule option. À ce stade, lis la doc.
Et même si c'était la seule option... Ça n'a toujours aucun rapport avec la question. Hook et toi ne vous comprenez peut-être pas, mais c'est lui qui a raison.

Citation :
Enfin, pourquoi devrai-je rappeler la fonction "write" alors que je peux simplement modifier un texte ? En plus, si je fais ça, ça va superposer l'ancien texte avec le nouveau, ce qui vas donner un effet gras sur le texte. C'est pas ça que je veux, moi.

Mais on ne parle pas de rappeler la fonction write(). Nulle part. Ne commence pas à répondre à des choses qu'on ne t'a pas proposées, sinon on n'est pas sortis de l'auberge.

Quant à la modification du texte... Je vais me répéter, et je déteste ça pour information : tu as regardé mon code modifié ?
La méthode write écrit la liste de textes telle qu'elle est actuellement. SI tu modifies son contenu, ça modifie l'affichage.

Citation :
Beeenn, d'un côté, si tu n'as pas de cas concrets et que tu te contentes de faire des ateliers, je vois pas trop comment la personne extérieur peut apporter un jugement correct.

Non ? Le programmeur est censé savoir programmer comme un pro d’entrée de jeu ??? Ça, c'est "l'Allemand blond aux yeux bleu", si je puis me permettre. Et c'est la raison pour laquelle il y a du chômage au 21e siècle, en plus.

Vas-y, fais-toi passer pour une victime. Et sors un point Godwin. Ça va avoir un effet positif sur ma bonne volonté et me donner envie de t'aider, je t'assure.
Je t'invite à remarquer que ni moi ni Hook ne sommes payés pour te répondre ou pour passer ton code en revue. C'est du temps qu'on te consacre par pure bonté d'âme. Et il y a des limites au temps et à l'effort que je suis prêt à consacrer à un anonyme sur Internet. Surtout quand l'anonyme en question me donne l'impression de ne lire mes réponses qu'en diagonale.

Personne ici, à part ta parano ou ta stratégie de victimisation, ne prétend que tu es censé savoir programmer d'entrée de jeu. C'est pour ça que, comme tu as peut-être pu le constater, on consacre tous les deux un peu de temps à t'aider dans cet apprentissage. Alors ton guilt trip, tu le gardes pour toi bien sagement.

Citation :
Cette phrase me gêne. Si c'est un aimant à bug, comment faut-il rédiger le code pour que ce ne soit plus considéré comme tel ?

Cf le code que j'ai proposé.

Citation :
Si. Je l'ai expliqué plus haut: Dans mon projet, il y a 2 blends: le terrain et "barre chargement". Ils sont tous deux indépendants, par conséquent, ils n'ont aucun liens physique mais il faut lier l'un à l'autre pour l'avoir partiellement.

Là, tu es en train de me répéter pourquoi il y a un système pour faire passer des données dans tout le code. Ce n'est pas ce que j'ai demandé. J'ai demandé pourquoi chaque texte avait besoin d'y être, au lieu de les encapsuler quelque part. Et tu n'y réponds pas, parce qu'il n'y a pas de bonne raison. Encore une fois : cf le code que j'ai proposé.

Bon, attaquons ton cas concret maintenant.

Citation :
Voici un bout du début de mon code pour le terrain.

Remarque préliminaire : "mère", c'est aussi explicite et compréhensible que "toto".

Citation :
La classe mère contient des éléments qui sont censés se répéter un peu partout dans l'ensemble. J'ai estimé intéressant de mettre quelques fonctions là pour éviter de réécrire à chaque fois ces même lignes.

Pour le vocabulaire, on appelle le fait de regrouper des éléments communs à plusieurs classes dans une classe-mère factoriser. Sur le principe, c'est bien.
J'ai un problème avec cette classe : elle a deux responsabilités. Premièrement, initialiser les variables qu'on utilise tout le temps genre obj et scene. Deuxièmement, lire des sons. Quel est le rapport ?
Et c'est facile à corriger, en la divisant en deux : une classe SceneElement qui reprend la méthode __init__, une classe AudioPlayer qui hérite de SceneElement et reprend les deux autres.

Citation :
Donc, "mere" ne s'exécute pas sans appels.

Euh, ça, ça ne veut rien dire. Au point que je ne peux même pas essayer de corriger cette phrase.

Pour passer à game : un poil de chipotage, game devrait hériter de mere, et utiliser super(self) au lieu d'une référence directe à mere. Ce sera plus souple, plus facile à modifier par la suite.
Plus grave : ton indentation, c'est n'importe quoi. Tu définis des méthodes les unes dans les autres sans raison, la hiérarchie apparente n'a pas de sens.
Voici une version corrigée de ce fichier. Ici encore, il convient d'en faire un module, genre game.py. Tu auras ensuite un script, placé à un endroit où il ne s'exécutera qu'une fois, qui donnera quelque chose comme :
import game
from dictionary import dico
current_game = Game()
dico['current_game'] = current_game
current_game.spawn_mob('cube loup', 'loup')
current_game.spawn_mob('cube renard', 'renard')
current_game.spawn_mob('cube sanglier', 'sanglier')
current_game.spawn_mob('cube corbeau', 'corbeau')
current_game.spawn_mob('cube boomslang', 'booms')
current_game.spawn_mob('cube biche', 'biche')
current_game.spawn_mob('cube thon', 'thon')
current_game.spawn_mob('Cube_cheval_charette', 'cheval char')
current_game.spawn_mob('Cube_raptor', 'raptor')


Et si ailleurs un autre script a besoin de spawn quelque chose, il va chercher le Game dans le dico, et appelle une des méthodes de spawn qu'il appelle.

EDIT j'oubliais un truc, concernant ton projet d'ensemble. Tu dis que tu as compris le principe de séparation des responsabilités, mais tu as des scripts de plusieurs milliers de lignes qui font tout... 4 000 lignes, c'est minimum 40 scripts. Pas 1.

Le volume de l'ensemble serait déjà un obstacle pour une revue de code d'ensemble ; clairement, je n'ai pas que ça à faire. Mais j'aurais pu prendre un module en particulier, à la rigueur, si c'était un concept applicable...

Contribution le : 24/03/2018 16:39
_________________
|C'est en forgeant qu'on devient forgeron, c'est en mouchant qu'on devient moucheron et c'est en sciant que Léonard devint scie.
Créer un fichier PDF de la contribution Imprimer


Re: Python - l'instruction return
OverdOzed
Inscrit:
19/03/2016 16:30
De Belgique
Post(s): 1415
Citation :

Elle est appelée quand tu crées un objet. C'est un initialiseur...


Donc, tu veux dire que "init" n'est pas obligatoire quand on créer un classe ? Car moi, c'est ce que j'avais compris.

Si je comprends bien, ça veux dire que je pourrai très bien appeler une fonction de cette classe, tout en étant a l'extérieur (de la classe) ? (ex: ma_classe.ajouter_un_texte(arg1, arg2, arg3))

J'ai testé le script (j'ai rajouté un "self" à "append", dans la fonction "add"). Le script est passé sans erreurs. Tu as dis que le "post_draw" est un aimant à bug (ou est-ce l'ensemble ... = [write] ?), c'est bien juste ?

J'ai pas mon texte affiché dans le BGE. Comment est-ce possible d'avoir un aimant à bug si c'est lui qui permet l'affichage ? Je ne comprends pas.

Citation :

Un script n'a pas à être exécuté en boucle. Ce n'est pas la seule option. À ce stade, lis la doc.


Dans la doc python de blender ? C'est impossible. Ou as-tu trouvé cette phrase qui parle d'une telle hérésie ? Comment peux-tu, dans un environnement interactif, exécuter le script une seule fois ?

Comment peux-tu en une seule fois, virer un texte en vert si l'on place le pointeur dessus et le virer en rouge quand le pointeur est ailleurs (donc on suppose qu'il est rouge de base) ?

Citation :

Vas-y, fais-toi passer pour une victime...


Je pense que l'on à pas bien interpréter ce que j'ai dit, je laisse passer.

Citation :

...une classe SceneElement qui reprend la méthode __init__, une classe AudioPlayer qui hérite de SceneElement et reprend les deux autres...


Pourquoi suis-je obligé de séparer ça ? Point de vue éthique, on est d'accord, mais pourquoi créer juste une classe pour ça ? Pour le lecteur, peut-être ?

Citation :

super(game, self).__init__()


"Plus souple et plus facile à modifier par la suite"

"super" se réfère à "SceneElement" ? Mais enfin, comment est-ce possible ? Si je place "class audioplayer" en premier, c'est lui "super" alors ?

Citation :

current_game = Game()
dico['current_game'] = current_game


Seul game doit faire apparaitre des créatures. Il y a bien, dans le HUD, quand j'ouvre l'inventaire du joueur, à faire apparaitre les "items"... Donc, je pompe l'objet current_game (ou game, plutôt ?) du dico, pour pouvoir faire ça ? Mais il y a plus d'arguments pour ces plans de l'inventaire.

Citation :

...minimum 40 scripts. Pas 1.


Il me semblait que c'était dangereux d'avoir beaucoup de scripts... Outre la facilité de lire ceux-ci, pourquoi faire ça ?

Donc, pour résumer le cas d'application d'une classe:

- Pas de init sauf si variable il y a.

- classe est un objet, variable = objet, donc variable est un "label", un surnom donné à la classe.

- ne sert que pour exécuter un ensemble d'actions, d'effet, comme pour une fonction qui évite les répétitions de code. Donc le reste doit rester à l'indentation zéro

J'ai oublié ou mal interpréter quelque chose ?

Contribution le : 25/03/2018 13:34
_________________
Mon projet jeu vidéo
Mes tutos
Créer un fichier PDF de la contribution Imprimer



 Haut   Précédent   Suivant
« 1 (2) 3 4 »




Enregistrer votre réponse
Compte*
Nom   Mot de passe   Authentification
Message:*



[Recherche avancée]



Sujets récemment répondus
Forums Sujets Réponses Lus Dernières contributions
Questions & Réponses Besoin d'aide simulation de vent sur des plantes (système particules) 0 15 Aujourd'hui 17:50:55
B3nD 
Questions & Réponses Contrainte en édition 1 29 Aujourd'hui 13:57:05
naeco 
Python & Plugins [WIP] Tracer une courbe et obtenir son équation 0 21 Aujourd'hui 10:49:49
Jeanclaude25 
Questions & Réponses Impossible de faire un bevel regulier 8 178 Aujourd'hui 09:43:47
busanga 
Questions & Réponses [non résolu] Des conseils ? 5 150 Hier 22:21:41
tokoji 
Moteur de jeu GameBlender et alternatives [non résolu] Programmer un archer à cheval    [1][2][3][4] 32 835 Hier 22:12:53
Bibi09 
Questions & Réponses La video n'est pas lu dans l'editeur node 0 25 Hier 20:06:12
masje 
Questions & Réponses Question sur IvyGen 3 194 Hier 16:20:13
Muad 
Questions & Réponses Déplacement d'un personnage riggé sur courbe de Bézier 3 60 Hier 13:45:28
Rimpotche 
Questions & Réponses Choisir Rendu sur la carte graphique de l'ordinateur 4 134 Hier 11:13:26
masje 
Questions & Réponses Extrusion régulière sur plusieurs angles ?    [1][2] 12 214 12/11 15:37:27
Fracoris 
[WIP] et travaux terminés [WIP] Bataille Navale // Animation 3d    [1][2][3] 24 1903 11/11 22:02:15
Bibi09 
[WIP] et travaux terminés Teeny Tiny - Story 1 130 11/11 21:42:22
Bibi09 
Questions & Réponses des rayures bizzard ? 3 83 11/11 20:52:08
Eleonor-e 
Mes premières images sous Blender (débutants) Les trucs à Élé 6 199 11/11 18:53:11
Eleonor-e 
Questions & Réponses [non résolu] Impossible d'effectuer un boolean sur sculpt 3 98 11/11 15:04:53
busanga 
Questions & Réponses Longueur d'une courbe de béziers ? 3 219 11/11 01:23:27
Eleonor-e 
Questions & Réponses Viewer node ne fonctionne pas 1 105 11/11 01:21:41
Eleonor-e 
Mes premières images sous Blender (débutants) club Blender en collège/lycée    [1][2][3]...[6] 59 24475 10/11 21:05:52
Thewada 
Le coin des geeks config pour projet d'environ 30 000 000 de vertex 3 240 09/11 13:56:22
Bibi09 

Qui est en ligne
73 utilisateur(s) en ligne (dont 44 sur Forums)

Membre(s): 1
Invité(s): 72


ebrain, plus...
Nouveaux membres
B3nD 14/11/2019
Jothys 13/11/2019
21600883 11/11/2019
Eleonor-e 11/11/2019
DAOUDA 8/11/2019

AikonFR
8/11/2019
LouYa9 6/11/2019
nikita182 6/11/2019
parki 6/11/2019
papillon 5/11/2019
Dernier Ajout
2019-11-05 01.JPG

Evènements à venir
Nov 18
Anniversaire de RichDeg
Dec 29
Anniversaire d'ebrain
Jan 11
BUG de Lyon
plus 278 plus d'élément(s)
 Par Mickaël Guédon [ebrain] © 2003-2019 The Blender Clan - hébergé par TuxFamily - Site déclaré à la CNIL sous le numéro 1155445