Eviter que GD plante lors de situation impossible

Bonjour

Serait il possible de faire en sorte que GD mette un message comme quoi il a rencontré un problème et ne peux l’aperçut ? Car pour l’instant, GD s’éteint…
Cela m’a arrivé et redémarré/quitter à chaque fois Game Develop pour trouver le problème en désactivant/activant les évènements est un peu moyen…

jérémie 14
PS : dans mon cas, c’est que je n’avais pas précisé l’automatisme de l’objet que je voulais tester…

Ben, on y peut rien, c’est une erreur de code C++ parce que tu as fait une erreur d’événement, si en plus on demande GD de vérifier ce qu’il fait, mais tu peux acheter un grille pain, tu verra pas de différence avec ton PC pour ton jeu, ça va ramer a mort…
A toi de faire gaffe :wink:

Je fais un peu de python et quand il y a une erreur, il me dit qu’il y en a une et le script s’arrête mais la console ne s’atteint pas. Juste un exemple et je penses qu’on peut remplacé “python” par “GD”, “le script” par “les évènements”, “la console” par “aperçu” et “il y a une erreur” par “un message indiquant qu’il y a une erreur”.
Et si de plus c’est une erreur de C++…(t’imagines si tu es programmeur à chaque fois qu’il y a une parenthèse mal placé et que tu essai ton code le logiciel plante au lieu de t’indiquer où il y a l’exception (=erreur)?!

Donc je penses que c’est faisable que quand il y a une solution impossible, au moment où elle se produit, GD affiche un message et arrête l’aperçu au lieu de quitter…

jérémie 14

A ton avis, tu crois que c’est fait exprès que GD plante quand il y a une erreur ? :slight_smile:
Dans pratiquement tout les cas, si Game Develop plante, c’est un bug, et c’est bien en dehors de ma volonté. De même, les programmeurs des interpréteurs python font leur maximum pour éviter dans n’importe quel cas que ton programme plante, mais il peut leur arriver de laisser passer une situation où python plante, même si ça doit être rare : C’est pareil pour mon cas, je fais le maximum pour éviter que dans n’importe quel cas, votre programme plante.

Donc si tu repère un bug, tu créé un sujet dans le forum de bugs, tu me dis exactement commet le recréer, et de mon coté, je refais la manipulation que tu m’a indiqué, je trouve le bug et je le règle. :slight_smile:

Je pense qu’en plus 4ian tu gère déjà les exceptions (try … catch) ? Sinon ce serait une bonne solution. Là GD quitte tout seul comme il dit. C’est que GD n’a pas su gérer l’aperçu.

Evidemment que je les gère, mais que là où y en a besoin ( c’est à dire pas beaucoup ). Les exceptions ne peuvent rien contre une erreur de mémoire comme pointeur invalide par exemple.

Encore une fois, les bugs ça peut arriver ( je pense pas que GD soit forcément un nid à bug ), et j’aurai beau “gérer les exceptions”, “afficher un message d’erreur”, ou quoi que ce soit, si j’ai mal prévu quelque chose, bah le programme va pas fonctionner correctement : Ça peut aller du bouton qui marche pas jusqu’au plantage direct.

Comprenez bien que rien n’est magique : Les exceptions, ça ne marche que pour les fonctions qui en lancent, et si j’en oublie une, alors le programme plantera également, et les messages d’erreurs, soit ils sont prévus ( Genre “Vous avez oublié ceci” ) et dans ce cas c’est pas un bug, soit on essaie d’en mettre un fourre tout qui va dire “Game Develop va planter, désolé”, mais dans ce cas, ça veut dire que la situation est irrecupérable.

Salut jeremie14,
Recommence ta scène, et fais tout pour éviter l’erreur de nouveau. Ca peut te donner des surprises. Essaie, même si c’est long. Répond-moi si ça marche stp.

J’ai pas tout recommencé, c’était juste que j’avais oublié de dire ce qu’elle automatisme de l’objet était basé la condition. Et de toute façon , ce projet est mis en pause car je suis entrain d’améliorer Magicia.
Et de toute façon , la scène a une 50aine d’évènements…

jérémie14

Le bug dont souffrait jérémie14 a été corrigé hein ( pour la prochaine version ), il faut pas prendre pour habitude de tout recommencer à cause d’un petit oubli qui a, manque de bol, fait planter Game Develop. :wink:

Non éffectivement 4ian sauf erreur de ma part au debut mais ça, c’étais normale normale je pense, bref tu as beaucoup améliorer tous ça faut dire aussi :slight_smile: :wink:
non la game develop a tres peut de bug :slight_smile:

Tout peut être corrigé si on connaît la racine du problème :wink:

[…]

Attention quand même, l’interpréteur Python est BEAUCOUP plus complexe que GD, et je doute fort qu’il soit possible de l’appliquer à GD dans le sens ou l’interpréteur Python interprète un langage entier et non pas des actions prédéfinies.

( D’un coté, perso, gdb a tendance à me péter à la tronche une fois sur 4, et j’ose pas modifier une variable de peur que tout s’écroule : Avec le débugger de GD, ça plante pas et on peut même modifier pas mal de propriétés ).

Mais le truc, c’est qu’au dessus on parlait du fait que GD plante parfois : Oui, ça arrive quand j’ai fait une bourde plus ou moins grosse. Mais ça n’est pas lié au debugger intégré à GD et qui, encore une fois, permet de débugger les jeux, pas GD : Quand Game Develop crashe, il crashe avec…

Et paf, ça fait des chocapic

Game Develop, c’est for en chocolat :laughing:

[…]

[…]

Ton “IML” ( J’ai jamais entendu parler de ça, c’est l’abréviation de quoi ? ) est destinée à corriger les erreurs des jeux ou les bugs de GD ?
Parce que au départ tu parles de “pour que GD ne plante (presque) jamais” et à la fin tu dit “Ainsi, ou pourrait débugger nos jeux pendant le test.”

Car je le répète ( si tu parle effectivement d’empecher GD de planter ) quand Game Develop plante sévèrement ( Crash irrécupérable ), c’est que j’ai par exemple mal géré quelque part la mémoire, ou que dans mon code j’accède à un objet qui n’existe plus, ou tout sorte de chose horribles, mais dans ce cas, ça veut dire que le programme a fait quelque chose d’illégal au yeux du système d’exploitation, et que celui ci va le fermer sans autre forme de procès ( Et heureusement, il faudrait pas qu’un programme fasse planter le système entier dès qu’il plante lui même ).
Et il n’y a pas de manière simple de résoudre ça à part coder de façon nette, claire et précise.

Si tu parle de débugger vos jeux, deux choses :
-La première est que si GD plante quand vous testez un de vos jeux, c’est dans 99% des cas un bug de GD qu’il faut me rapporter.
-Si vos jeux ne fonctionnent pas correctement, là c’est de votre ressort ( à part évidemment si vous arrivez à mettre en lumière une action/condition qui ne fonctionne pas correctement, auquel cas c’est un bug de GD ). Bien sûr, GD essaie de faciliter votre tâche en mettant à disposition un debugger, qu’on doit pouvoir encore surement améliorer.

[…]

Tu veux dire qu’avec ton truc - IML - on doit surveiller que chaque classe contient des données correctes ? Ça doit prendre un travail phénoménal ! Moi je crois que les éléments mis à notre disposition sont déjà bien pour corriger des erreurs. D’autant plus qu’une erreur qui fait planter le programme vient forcément du programme lui-même… Enfin je trouve que c’est très inadaptée comme solution.