Imprimer les évènements

Bonjour,

J’ai un problème que je n’arrive pas à résoudre et pour faciliter la recherche de la solution, j’aimerais bien imprimer la liste des évènements autrement que par des copies d’écran, un peu longues à faire.

Je n’ai pas vu d’action «Imprimer», est-elle bien cachée ?

Je suis pas sur que ce soit plus simple de retrouver tes problèmes via des feuilles :confused:

Tu imagines le nombres de feuilles que ça peut générer ?? Ré imprimer à chaque fois que tu modifie un évènement…

Mais je pense pas que ce soit possible a part via des captures d’écrans comme tu dis.

Structure bien tes évènements avec les commentaires et les groupes que tu peux créer ça te permet de t’y retrouver plus facilement :slight_smile: .

l’absence de codage pur et dur ne dispense quand même pas de travailler un minimum sur la logique et l’organisation sinon on en revient à la “programmation spaghetti” du siècle dernier :slight_smile:

un outil comme GD doit aussi servir à apprendre les bases strictement fondamentales afin de se donner davantage de chances de progresser voire de s’attaquer ensuite à du petit scripting (python ou javascript par ex) pour peut-être évoluer alors vers des langages plus évolués après, c’est selon…

Ce n’est que mon point de vue mais je trouve pas ça très logique et organisé d’imprimer son code ou ces évènement non ? :confused:

ah si tout à fait d’accord, la prépa logique doit se faire avant de commencer l’écriture des événements sinon après c’est galère…

vaut donc mieux pour la suite se donner dès le départ des pratiques les plus proches possibles de ce qu’on fait en programmation car même si GD ne nécessite pas de codage lourd grâce à son système d’événements, on perdra énormément de temps sur des développements plus complexes et on recommencera souvent les mêmes choses sur des développements différents si on n’a pas dès le départ organisé et structuré un peu sa manière de travailler…

en fait j’aurais peut-être du dire que le fait de ne pas devoir connaître un langage de programmation ne dispense pas de bonnes pratiques, la prépa logique et l’organisation du code (ici des événements) étant à la base…

Je suis bien d’accord qu’il faut réfléchir et organiser le travail avant de se lancer dans la réalisation. Mais pour cela il faut mieux connaître un minimum les particularités de Gdevlop, notamment la gestion des chronomètres, les différents niveaux de variables et les instances d’objet qui n’ont pas obligatoirement d’identifiant, or c’est mon premier projet avec Gdevlop.

Et puis même en s’organisant à l’avance, qui n’a jamais fait d’erreur ? le papier permet une lecture de deux endroits en même temps, ce qui n’est pas le cas à l’écran. Ceci dit j’ai trouvé l’erreur, en repartant d’une version antérieure et en réintroduisant progressivement, avec méthode donc :slight_smile:, les éléments qui ne fonctionnaient pas. (un problème de teste des clics gauches et droits successifs sur des instances d’un objet, et ça se mélangeait un peu.)

il faut en effet être confronté aux situations de la création pour voir comment progressivement améliorer les process…

ça prend du temps et ça passe par de nombreux travaux différents avant de commencer à voir comment on peut petit à petit s’orienter