levez .. abaissez ... levez ... balancez!

Petite réflexion de week-end: comment s'assurer que Bilou ne puisse pas tenter de prendre un 2eme objet en main. Pour l'instant, c'est en tombant une 2eme fois sur Dumblador que celui-ci passe en mode "transporté", ce qui autorise un nombre arbitrairement grand de Dumbladors à suivre Bilou.

Il faudra donc impérativement que les zones de collision déclenchant le ramassage et le lancer soient liées à un état précis ("ramasse" ou "lance") plutôt qu'à une zone générique, vu qu'on a pas de zones conditionnelles. Il suffit alors d'une des variables d'état de Bilou pour se souvenir s'il y a ou pas un objet à lancer lorsque le bouton d'action est enfoncé.

Technically speaking, we can now carry dumbladors. But we're carrying too much of them: every bop on a stunned blador turn it into the "carried" state. I'd rather avoid having 3 bladors following Bilou: grabbing a new one only if none is being carried at the moment would be by far preferable.

Conceptually, there are two "meta-states" (free hands and carrying), and we're only switching from one to the other by picking up or throwing objects. Practically speaking, however, there no such "meta-states" in the state machines, but there are some per-gob variables that can complete those states, so sIdle-> sPickup and sIdle->sThrow transitions would be conditional (and use dedicated collision areas).

Reste le problème de l'apparence proprement dite (les mains en l'air). Au départ, j'avais envisagé un mécanisme de "costumes" (cf. Monkey Island) rudimentaire qui aurait consisté à "geler" la position des mains de Bilou en ignorant toutes les commandes d'animation les concernant. Le hic, c'est que d'une animation à l'autre, les mains ne sont pas forcément liée au même "membre" logique.

Pas évident non-plus de modifier le contenu d'une page de graphisme en guise de "costume" (comme on l'aurait fait pour Kirby), à moins d'effacer complètement les mains du sprite de Bilou et de les intégrer à l'objet transporté (Dumblador, donc). La seule alternative restante serait de donner une deuxième version de *chaque* animation... j'imagine que vous comprenez aisément pourquoi j'aime autant trouver autre chose :P

To ensure proper operation, it is required that some  active collision zone could force state change after the first collision has been triggered. Then, I still have the problem of "animating the pick-up", but I came up with a nice approach for that.
Last but not least, I'll have to ensure that Bilou's hands remain above his head while moving along with a blador ... which may involve an alternative for *every* animation. I'm still thinking about a more practical way to handle that.

next steps

The July todo list is now completely check-marked. Many steps on animations are completed, and the Next Big Thing is to add support for the transanims that have been identified to be a mandatory addition to the game engine.

• [done] Regarding the slopes, I'm still in the same situation as I was with Apple Assault. No better, but not worse either.
• [done] dynamic sprite priorities are now supported by the engine, using them from the game logic needs some more thinking. However, I can easily try out transanims with just static priorities ...
• [done] Enabling SEDS to store several palettes in one .spr file will open the way to tileset tinting. then will come AnimEDS, the game engine, LEDS and the game engine again.

OAM priority issues

I'm about to introduce significant complexity in the game engine for the purpose of displaying some compound animations properly. I've took the time to think about it (while drilling staircase for a kid-safety-barrier, if you ask :P) and figured out how to sort all the needed details. I just missed one point: this is absolutely not the only place where I need OAM depth-sorting.

Remember of Apple Assault's frenzy, and how you could end up not seeing that appleman that runs towards you because it's actually sneaking behind a row of stunned applemen ? That's never been fixed to date because I had no way to instruct the game engine that "those stunned applemen should be moved to the background".

Then I remembered of that "talk" by Rafael Baptista about resource management on the GBA. Before he entered the core meat of his talk, he suggested that copying OAM entries (you can think of them as sprite descriptors) could be the right time to follow a Z-order linked list and keep the "hardware" OAM entries and their "shadow" counterpart. Nice move, although I still wonder how he manages the scaling/rotation matrices along the way...

I used to have a large, one-chunk DMA transfer of all the sprites & rotation information. I would have to split that in 3-u16 slices. That sounds like I'll have to pay sverx's report on memory copies performance benchmark a second - and more careful - read... and possibly opt for an intermediate - sorted, but in-cache - version out of the vblank period and then DMA that into VRAM when the vblank is hit.

A final consideration: there is little chance that I need a fine-grained Z-sorting. low/normal/high priority should be enough in 99% of the cases, and the remaining case could likely be "sorted" out at GOB instanciation by internally sorting the OAMs the GOB received.

edit: I asked myself the right question: 'is that move out of DMA sync'ing gonna cost me framerate or not ?'. From that point on, I hacked a modified version of my game engine, that uses CPU-driven copy with merging of OAM and rotations into one single table (as the DS hardware expects) and started Apple Assault with aggressivity setting turned at max (so many apples that you'll experience "ghost" berry bats and shots). Good news: it still works flawlessly (that is, I can't observe any slowdown). Next: the depth-re-ordering...

edit++: just applied silly reverse-priority and order-enforcement-at-sync() in an AppleAssault check: it proves the concept: now Bilou can sneak behind stunned applemen. Useless, but you can't deny it's no longer the default z-order that is applied.

edit+++: checked that a (Simple)Gob set on zlist[0] appears in front of (Compound)Gobs set on zlist[1]... now I've got to figure out how to use that best to implement the pullmask for my "roll jump" animation ...

ordinogramme

Some boxes, some arrows, and proper abstraction level ... That remain imho the best analysis tool to apply (now from code shown on e-Ink :) before I start messing up with some refactoring. This time, it turns out that I _can_ use virtual method to encode TIFrame and TIControl differently given that I revise what arguments these functions receive and pack the dependencies into an 'encoder' state structure.

Mon patron appelle ça "des boi-boîtes et des flè-flèches", avec un léger dédain dans la voix. Moi, j'applique ça depuis le Simon's BASIC sur C64, et je trouve que ça continue à me rendre de fiers services. Trouver le juste niveau d'abstraction pour l'encodage des animations par AnimEDS, par exemple...

Once that has been done, I can easily fix the I_DELAY / I_MOVETO redundancy issue that slows down Bilou's new walk animation.

Oh, and I will still have to figure out the difference between 'move 2 0' and 'move 2 *' in the implementation if I want to restore rulers climbing.

Devoir de Vacances...

Bon, on est encore loin d'avoir une "school zone demo" convaincante, mais au moins, la première vague d'upgrade des outils touche à sa fin. J'aimerais avoir pour la fin de l'été une démo avec Bilou converti en animation composite (plus ou moins indispensable, vu que j'ai déjà effacé son corps pour les étapes de marche, ce qui explique le "clignotement" dans la dernière démo) et de l'encre animée qui tue (lentement si on veut).

Let me pick a chalkboard and try to map all the improvements I still have to bring to the Bilou-in-school-zone demo, so that I can identify priorities and schedule coding sessions for this summer (if we ever happen to have a summer here this year :P)

And the winner is ...

ink animation and repair Bilou walk animation

Rien que ça, ça nécessite déjà deux interventions immédiates sur SEDS et AnimEDS. Ensuite, j'aimerais pouvoir me rapprocher du look "pile de livres" proposé par Facet, mais ça, c'est plus ambitieux, et donc à garder pour une 2eme passe.

• GridWindow::save_back_tiles(), which is involved in the cursor-driven edition, already does some 32x32<->16x16 conversion. All I need to do is to move it where it really belongs -- EditorSpriteSheet : public SpriteSheet -- so that I can reuse it in FileWindow::event().
• 32x32->16x16 is now available and the ink tiles are converted.
• modifying one line in GameScript.cpp should allow to animate the ink, but there's more code cleanup waiting there, for more efficient memory management, for instance.

branch/companim

Rien de tel qu'un peu d'UML pour commencer la nouvelle branche du SVN "animation composée" (imho). Ah, mais peut-être voulez-vous un mot d'explication sur les "branches"? C'est l'équivalent pour un programmeur de "Dis, on va commencer par dupliquer la maison dans un univers parallèle avant d'attaquer les travaux pour la véranda. Comme ça, si on doit chercher les clés à un moment donné, on a qu'à le faire dans la copie de base. Et puis on peut laisser les enfants dormir dans celle-là, aussi: inutile de les envoyer dans la copie où on a abattu le mur du salon et où l'eau ne va plus jusqu'aux WC, hein ?"

Convaincus ?

I was quite confuse on where to start working on the compound anim support, so I just started by depicting the current situation into an UML blueprint, trying to precise which are the different phases of SimpleGob::play, which member variables where involved when, and where in the class hierarchy they stand. Part of my indecision came from the fact that the abstract class GameObject is designed to capture what controllers use, so I wasn't quite tempted to push up the state management there.

And to my suprise, that alone suffice to show me the right path to take: introduce a CommonGob class that capture what's not-in-GameObject but should be in all the technical variation of the animated objects.

Bon, première tâche dans cette branche, donc, c'est de refaire un peu l'état des lieux. Une animation composée, ça change essentiellement l'animation des GOBs, mais l'état, les contrôleurs, les collisions, tout ça reste identique. Ouais, sauf que jusqu'ici, tout ça est uniquement dans SimpleGob.

Une fois tout à plat sur ce joli "bluescreen" (excusez ma nostalgie d'ex-codeur en QuickBasic), la solution devient évidente: introduire une classe "CommonGob" qui regroupe tout ce dont SimpleGob et CompoundGob auront besoin dans leur fonctions "play" sans toucher au GameObject héréditaire endogène ... ce qui fera sans doute plaisir à BlockArea, accessoirement.

If you don't get a word of UML then ... well ... I guess the sketched-up version of a former, similar reflexion might help you to figure out what is this CompoundGob stuff all about.

Pendant ce temps, dans le code ...

Oh, pas de soucis: je n'oublie pas Bilou, malgré tout cet intérêt renouvelé pour mon perso Ubisoft favori... Mais comme les études de Rayman et de Shantae ont pour objectif de construire le synopsys lointain, comprenez que je garde ça "en réserve" pour plus tard... Il faut quand-même bien que vous ayez le plaisir de la découverte quand je vous proposerai 4 écrans par monde dans nuts'n'bolts, hein :)

Don't worry: I keep working on Bilou, even though it's sort of top-secret sketching of distant scenario ideas for whatever will happen beyond the green & school zones you already know. I'll start working on the integration of animations edited with AnimEDS into the game engine. Please allow me to keep my todo-list in French only and focus back to my soup now :P

Entre-temps, il va falloir que je voie à intégrer les animations complexes générées par AnimEDS dans le moteur de jeu, sinon, c'est moins rigolo :P

• le GameScript pourra se servir des informations de anim[i] pour décider de créer un SimpleGob ou un CompoundGob (j'ai déjà une super-classe, ici)
• pas de bloc "anim%u %x { ... }" pour les animations composée, donc pas d'appel à parse(). Je pourrais soit détourner "state%u :anim%u { ... }" avec "state%u :spr%.anim%", soit pré-déclarer les animations "anim%u = spr%.%" -- l'idée étant d'autoriser des "pages d'animations" et d'avoir de préférence une page par fichier de commande.
• j'ai des commandes générales et des commandes "d'affichage" dans les anims. Est-ce que ça vaut la peine d'essayer de ne conserver qu'une seule copie des commandes générales ?
• Dès que je vais vouloir utiliser des déplacements automatiques, il me faudra de l'état par composant, ce qui rend moins attirant l'inclusion du code qui gère case ANIM_SET_SPR au sein de GobAnim ...
  

Lake District.

6h du mat... si j'ai dormi 4 heures sur la nuit, c'est beaucoup. Le lit est une vraie planche, et si mes voisins de paliers ne sont pas franchement bruyants, l'accoustique du bâtiment ne permet pas d'apprécier leurs tentatives de discrétion à leur juste valeur. Je suis en visite dans le district des lacs pour la semaine ... et je sens que ça va être un longue, très longue semaine.
Avec du café et des bananes.
Mais bon, faisons un peu le point. Début de l'année, je me fixais pour objectif de faire une première release publique de l'éditeur de niveau et de passer mes autres outils sous le "nouveau" devkitpro. C'est fait. Je me suis autorisé à faire de nouveaux graphismes pour la School zone, étant donné "qu'un premier jeu a été réalisé avec les graphismes de la green zone". Ils ne sont pas encore au complet (il me manque un décor potable, par exemple, peut-être en transformant la bibliothèque en un vrai campus), mais ils prennent forme. Le prochain jeu d'arcade de Bilou se fera dans la school zone. Ce sera sans doute "deep ink pit", mais il y aura une ou deux "gedsdemo" avant ça, pour tester le comportement des monstres... et m'amuser un peu ^_^
Ce serait peut-êtr bien le moment, tiens, de mettre le couvert avec les monsstrrrres. Un bien grand mot pour Bop, Dumblador et les encriers que ma petite puce nomme maintenant avec excitation. "Tu vas dessiner Bilou, toi?" me demande-t'elle à chaque allumage de ma DS(i) ... et ces derniers jours la réponse était plutôt "non, ma puce, Papa essaie le jeu de quelqu'un d'autre" (Shantae. On en reparlera). Voyons...

• Bop, l'éponge, pendue à son fil. Ça demande un contrôleur nouveau, capable de gérer ses oscillations. Je me suis déjà amusé à voir comment faire ça avec de "simples" accélérations autour d'un point... sur le papier, ça tient la route, mais il faudra le coder pour voir.
• "inkjet", l'encrier. Lui, il attendra sans doute que j'ai une version qui compile du nouveau moteur de collision: il est le candidat idéal pour les alignements de Gobs qui rende possible les poussées, transports et autres plate-formes mobiles.
• Dumblador. Je devrais probablement commencer par là. En plus, c'est le candidat idéal pour faire quelques tests d'animations modulaire, vu que je ne lui ai pas dessiné de pieds. J'aimerais reprendre les pieds de Bilou, mais en rouge. Solution de facilité ? les recoloriser. Solution idéale ? activer enfin le support multi-palettes, puisque la DS supporte en réalité 32 palettes de 256 couleurs (16 pour les tiles et 16 pour les sprites).

Je crois que je vais choisir la facilité pour l'instant. Sinon, on risque fort d'en causer encore à Noël. Or, ce serait plus sympa de faire des essais dans gedsdemo-books, à Noël, non ?
Bon, là-dessus, il est enfin 7h ... je vais aller trainer mes baskets jusqu'au bâtiment où ils servent le petit déj.
Oh, well. Sorry, english-speaking folks. I was just "thinking out loud" to figure out where to move now. Since I'll have to speak english the whole week (travelling), please allow me not to provide a personnal translation this time :P
edit: While speaking out loud, I was wondering which of the School Zone ennemies I should implement first and how it would help to validate new game engine features

branches/newcollide

So I finally started a new SVN branch with the collision engine modification that I sketched in the train. It's not going to be testable anytime soon, I'm afraid. The current collision engine was already abusing some "setContext(...)" calls to set static variables into GobExpression so that you can e.g. shoot things despites the eval() has no such thing in its argument. With the new "attach" and "align" features I want to develop, that becomes a huge mess of things to capture at various places in the GOB -> GOB -> area -> state -> expression call chain that happens at every collision. I bet the best move will be to extract all this context (including some of the things that are currently plain arguments) into a GobCollision structure which would have temporary lifetime (i.e. allocated on the stack) that would be passed around ...

Well, that'd be better unless the compiler is able to keep all the arguments in registers otherwise :P

Je dirais bien "assez causé, implémentons ces fameuses nouvelles collisions". Sauf qu'en fait non. Les petites modif' faites par-ci par-là dans le Boutdlard Express ne compilent pas, et si je fais ce qu'il faut pour qu'elles compilent, ça va être une véritable pagaille dans le code. Genre "la famille araignée en vacances dans une boites de spaghetti géante", voyez? J'ai une petite idée pour rationaliser tout ça sans perdre en souplesse ni (trop?) en performance. Je vous en dis plus après avoir fait le test.

Implémenter les plate-formes.

Aah. De vraies vacances, ça fait du bien, même si ce n'est que quelques jours... qui se terminaient par un peu de baby-sitting à un mariage cet après-midi. L'occasion de refaire un peu le point sur les problème des plate-formes mobiles. Le point essentiel, c'est que -- tout comme le transport d'objets par Bilou -- ces plate-formes dépendent de la possibilité de lier un gob à un autre temporairement. Un micro-contrôleur "follow", donc, qui déplace p.ex. l'appleman à l'identique de Bilou.

At last some day off ... really off. Not even some Bilou thinking until this afternoon "_". And I had no documentation or current code state with me when doing so, which somehow explained why I focused on a fairly remote problem such as moving platforms. The last thoughts came to the conclusion that being carried would involve a dedicated "follow" micro-controller where a Gob is attached to another.

Be coherent
Comment s'assurer que la plate-forme aura déjà fait son déplacement au moment de déplacer ce qui s'est posé dessus ? Sans ça, on risque d'avoir des effets de "décalage" chaque fois que la plate-forme modifie sa vitesse, comme ceux qu'on peut observer dans Zool.

To make that work, however, it is mandatory that the carrying object has moved before the carried object's movement is evaluated. Otherwise, the player will experience zool-like glitches everytime the absolute speed of the carrier is altered. The FollowController must thus be able to detect whether there is an not-yet-processed carrier situation and execute anticipatively the "animation" of that carrier. That will require some more book-keeping at the core of Engine::animate(), but I think it'd be more flexible than pre-encoded priority levels.

Pour y parvenir, le mieux sera de faire en sorte que FollowController::think() puisse détecter si son objet-cible a déjà été exécuté ou non. On joue là au plus profond du moteur de jeu, qui appelle Animator::play() sur chaque objet qui s'est enregistré via reganim(). J'ai déjà une liste "pending" séparée de "todo", il me reste à noter au niveau de Animator lui-même où on en est. Après ça, il suffira de se faire un petit if (target.state==QUEUED) target.play(). L'objet-transporté voit alors son exécution interrompue le temps que l'objet-transporteur soit mis à jour.

Thou shall not follow the NULL pointer
Avec ce mécanisme, je vais introduire pour la toute première fois une référénce directe entre deux personnages du jeu. Jusque là, je passais systématiquement par le tableau GameScript::gob[] ou je me limitais à une interaction éphémère lors d'une collision. Si je ne fais rien de spécial, une plate-forme détruite pourrait amener les objets transportés dans un état incohérent, voire provoquer de sérieux problèmes au gestionnaire de mémoire ou planter sauvagement le jeu.

The second challenge I addressed is to ensure that we can handle the disappearing of the carrier transparently for the carried object(s). We can do that in different ways, some including list of cross-references, etc. but it looks like the best way around could be to delay actual Animator::DELETE requests by one frame so that the former carrier can be caught in DISCARDED state by FollowController::think() method that would drop then the reference.

Je pourrais exiger du "programmeur gobscript" qu'il règle ça lui-même en prévoyant des états-tampons ou des collisions de désolidarisation, mais ça signifierait qu'une erreur de script dans la machine d'état d'un objet pourrait se traduire en un dysfonctionnement du moteur lui-même... à proscrire à tout prix. Ca risque donc de me coûter un Engine::animate() un peu plus sophistiqué, mais l'idée est de garantir que tout objet "qui s'en va" sera présent au moins pendant une frame dans l'état "DISCARDED".

anim0-10 = spr0.anim0-10

I forgot to commit the few modifications I made to AnimEDS this week-end. That sort of rules out any lunchtime coding today ^^". So instead, let's plan a little bit what has to be done to allow the new animations to be used by the game engine ...

Les animations sont attachées au fichier qui a servi lors de spr.load "$FILENAME":$SPRSETNO. On souhaitera sans-doute en charger plusieurs à la fois, e.g. via anim$FIRSTNO..$LASTNO = spr$ANIMSHEET.anim$FIRST..$LAST. Cette "simple" instruction dans un fichier .cmd construit les structures GobAnim comme l'aurait fait une commande anim$NO $SPRPAGENO { ... }.

L'idée est de pouvoir ensuite réutiliser state$SNO : anim$ANNO { ... } sans plus devoir se soucier du type d'animation créée. Celà veut dire aussi qu'au moment d'interpréter gob$NO : state$SNO ($X, $Y) , le GameScript devra inspecter le GobState enregistré dans sa table pour décider s'il doit construire un SimpleGob ou un MultiGob.

Organisation globale d'AnimeDS

Pas d'excitation excessive, hein: c'est encore entièrement à coder. Mais puisque je range un peu (en particulier, je cherche mon appareil photo :-/), j'en profite pour scanner ce petit "cas d'utilisation de haut niveau" allant des choix de fichiers jusqu'à l'édition des étapes de l'animation.

Where's my camera ? I'm pretty sure it was there. Behind the sofa ? No. Maybe under this pile of paper ? Nope. ... Hey, but I might have used of that "user-interface sketch" for further coding of AnimeDS, right. Let's boot the scanner ...

FileWindow et SpriteTable

Je pense qu'on peut dire que le développement de mon éditeur d'animation a (enfin ?) commencé. Je me base sur le code du Sprite Editor, ce qui simplifie deux ou trois choses, mais amène aussi son lot de surprise...

J'avais plus ou moins oublié que la table des sprites qui apparaît sur la droite de l'éditeur dans SEDS est un objet "partagé" entre les différentes fenêtres, affiché par la "méta-fenêtre" qui a tout construit, notamment.

A small screenshot to illustrate that I've really started working on the animation editor. Reusing the sprite editor as a basis helps sometimes, but it also brings in some surprises. I had to refresh my memory on how the SpriteTable widget is generated and displayed by MetaWindow, while GridWindow, AnimWindow and FileWindow can manipulate it only because the MetaWindow passes a reference to that widget to their constructors. The widget accepts several listeners to be attached to it -- which is rather unusual -- and an "enabled" field in all those SpriteListenerInterfaces tells who actively reacts to an operation. release() and restore() methods of the different window enable() and disable() those listeners accordingly to achieve the desired effect.

Animeds

As soon as I've got Apple Assault running and my level editor "repaired" so that we can toy with monsters despite the new "file-scope" state numbering, the next big thing I'd like to work on is the animation editor extension to SEDS.
So far, animation edition is pretty crude: you just push frames by clicking them on the sprite sheet, and you can't modify them afterwards. Plus, you can't save your work for later use in a game.

Le prochain "gros morceau" pour l'édition de jeux sur la DS, ce sera l'introduction d'un "véritable" éditeur d'animation. Enfin, dès que j'en ai fini avec Apple Assault et que LEDS est réparé, bien-sûr. Parce que si SEDS est déjà capable de donner un aperçu d'une animation, il faut bien avouer que devoir tout recommencer au moindre faux-pas est moyennement intéressant. Et qu'être incapable de sauver son travail le cantonne au rôle "d'outil de validation" pour les graphismes en cours.
Pourtant, le workflow de base restera le même: une fois qu'on s'est choisi la spritesheet avec laquelle on travaille, on ajoute des étapes à l'animation en cours en cliquant sur les sprites sur la droite de l'écran.

I've toyed with a lot of concepts around "animeds", which most likely explain why it's only 5% done so far. But this last one seems to work better. It keeps the basic of the current system (click a sprite to add it as a frame), but it builds a timeline representation where you can do additional manipulation. I used the animated apple bonus as an example:

• click a frame on the timeline to select it
• L-click somewhere on the time line to move it there
• select another frame,
• move it as well.
• click the "time arrow" to adjust the whole animation duration (and scale delays of every frame accordingly).

And that's just for the basics. From then on, being able to store the animation list in the .spr file rather than being part of the .cmd file will be a major improvement in how I build new monsters.

Pour pouvoir gérer et retoucher tout ça, il faut que j'ajoute un widget "ligne du temps" sur lequel il serait possible de déplacer les étapes d'animation pour ajuster les délais. Accélerer et ralentir l'animation complète peut aussi s'avérer intéressant. "Historiquement", les animations sont stockées sous forme de commande texte parce que je n'ai pas voulu introduire de dépendance trop forte entre le moteur de jeu et l'éditeur. Sans doute une sage idée compte tenu des "condloop" et autre "move 2 *" qui sont venus se rajouter par la suite. Je ne vais donc certainement pas essayer de produire des GobAnims[] dans mes fichiers .spr, plutôt une version "lexèmisée" de l'animation avec une liste de constante et une liste d'instruction à traiter conjointement pour produire ces GobAnims.

I also need the opportunity to duplicate/kill a frame ([+ X] buttons depicted below as (3)); undo a deletion (the little x at (5) can be clicked to summon a frame back to life)

The most challenging aspect, I guess, will be to include engine-related features such as conditional loops (loop the animation only if testpoints are satisfied), the use of "spatial timeline" rather than "temporal timeline" (yeah, that's an odd concept, but I don't see how to phrase it differently :P)

And then, finally, I'll have to include that so-long-delayed composed -- à la Rayman --animation that was present in the BASIC version ^^"

J'ai quelques idées pour avoir une représentation graphique efficace des opérations telles que "copier une étape, supprimer ou récupérer une étape supprimée", etc. Ce qui sera plus complexe, ce sera justement de prendre en compte les boucles (conditionnelles ou non) et les déplacements (en ajout comme en remplacement des délais)... Je me demande dans quelle mesure il serait possible de garder cet aspect-là dans le .cmd, tiens.