COB / BOS — bytecode des scripts d'unités

Chaque unité de Total Annihilation exécute un script qui anime ses pièces, produit les éclairs de tir des armes, joue les effets sonores et réagit aux événements de la partie. Le langage source est le BOS (« Basic Object Script ») ; le bytecode compilé que le moteur exécute réellement est le COB (« Cobble », le jeu de mots de Cavedog pour « compiled BOS »). Un fichier par unité, nommé d'après le champ ObjectName de son FBI.

# Decompile a unit's bytecode back to readable BOS
kbot cob decompile scripts/ARMCOM.cob

# Disassemble to opcode-level assembly with control-flow arrows
kbot cob disassemble scripts/ARMCOM.cob -a

# Lint a whole directory for common script issues
kbot cob lint scripts/ -q

# Round-trip the entire scripts/ tree to verify byte-perfect compile
kbot cob roundtrip scripts/

import "github.com/coreprime/kbot-io/formats/scripting"

cob, _ := scripting.LoadFromFile("scripts/ARMCOM.cob")
fmt.Printf("%d scripts, %d pieces\n", cob.NumScripts, cob.NumPieces)
for i, name := range cob.ScriptNames {
    fmt.Printf("  [%d] %s\n", i, name)
}

Deux langages, un seul format de fichier#

Le moteur ne voit jamais que du COB. Le BOS est une commodité pour les auteurs humains : quand vous « modifiez le script d'une unité », vous modifiez en réalité le source BOS, vous le recompilez en COB, puis vous livrez le COB dans le .ufo d'extension de l'unité.

Un exemple minimal :

// armcom.bos — fragment from the Arm Commander
piece base, pelvis, lthigh, lleg;

#define SIG_WALK 2

Create() {
    hide pelvis;
    set-signal-mask SIG_WALK;
}

Walk() {
    set-signal-mask SIG_WALK;
    while (1) {
        turn lthigh to x-axis  [-25] speed [50];
        turn lleg   to x-axis  [50]  speed [100];
        wait-for-turn lthigh around x-axis;
        sleep 100;
    }
}

kbot cob compile traduit ce code en un blob binaire. kbot cob disassemble -a affiche le flux d'opcodes avec, en regard, des flèches de flot de contrôle ; kbot cob decompile fait l'inverse et retrouve un BOS qui, presque toujours, refait l'aller-retour à l'octet près (kbot cob roundtrip le vérifie sur tout le catalogue du jeu).

Un source est compilé comme un script TA (COB version 4), sauf s'il commence par .version 6. Le compilateur refuse ce que TA 3.1c exécuterait mal au lieu d'écrire un bouche-trou : les constructions de TA: Kingdoms (play-sound, Mission-Command, __tak_math_*, .sound_name) et % sont des erreurs dans un script TA (TA n'a pas d'instruction modulo, et 0x10037000, le mot que % produisait autrefois, y est un XOR bit à bit), tout comme les identifiants inconnus et les fonctions qui demandent plus que les 32 emplacements de pile du jeu. Ce qui compile encore mais mérite un coup d'œil — une fonction définie deux fois (chaque appel se lie à la première définition, comme le fait la recherche de nom du jeu) — est affiché comme avertissement, avec tout constat des règles de lint de compatibilité TA ; --strict fait échouer la commande sur les avertissements. kbot cob assemble applique les mêmes vérifications aux listings écrits à la main.

Disposition du COB sur le disque#

typedef struct {                          // 44-byte header (11 × uint32)
    uint32 VersionSignature;              // 4 for TA, 6 for TA: Kingdoms
    uint32 NumScripts;                    // Number of functions (Create, Killed, …)
    uint32 NumPieces;                     // Number of named pieces
    uint32 LengthOfScripts;               // Total code size, in DWORDs
    uint32 NumberOfStaticVars;            // Static-variable count
    uint32 UKZero;                        // Always 0 in retail bytecode; purpose unknown
    uint32 OffsetToScriptCodeIndexArray;  // → uint32 × NumScripts: code-index per script
    uint32 OffsetToScriptNameOffsetArray; // → uint32 × NumScripts: absolute offsets into string pool
    uint32 OffsetToPieceNameOffsetArray;  // → uint32 × NumPieces: absolute offsets into string pool
    uint32 OffsetToScriptCode;            // → packed uint32 opcode stream
    uint32 OffsetToNameArray;             // Byte just past the piece-name offset array (= sound-name offset table start for TAK v6, or string-pool start for TA v4)
} COBHeader;

Viennent ensuite, dans cette disposition :

┌─ Script code ─────────────────────────────┐  uint32 opcodes/operands, packed
├─ Script code-index table ─────────────────┤  uint32[NumScripts] — *not* byte offsets
├─ Script name offset table ────────────────┤  uint32[NumScripts]
├─ Piece name offset table ─────────────────┤  uint32[NumPieces]
└─ String pool ─────────────────────────────┘  NUL-terminated names, in order

Résoudre un script#

La table des index de code contient des offsets en mots uint32, pas des offsets en octets. Pour trouver le bytecode du script numéro i :

uint32 first_instr_word = ScriptCodeIndexArray[i];
uint32 byte_offset      = OffsetToScriptCode + first_instr_word * 4;

Le script se termine là où commence le suivant (ou au début de la table d'index, pour le dernier script).

Le flux d'opcodes#

Le COB est une machine virtuelle à pile. La plupart des opcodes dépilent leurs arguments depuis une pile de données propre à chaque script, font leur travail et empilent un résultat. Certains opcodes ont des opérandes en ligne (cibles de saut, numéros de pièces).

Chaque opcode est un uint32 de la forme :

       MSB                          LSB
  ┌─────────┬─────────┬─────────┬─────────┐
  │   0x10  │ family  │ op      │ flags   │
  └─────────┴─────────┴─────────┴─────────┘

L'octet de poids fort vaut toujours 0x10 ; famille/op/flags varient selon l'opcode. Le jeu ne compare pas le mot entier : il aiguille sur word & 0x100FF000, donc les bits hors de ce masque sont ignorés et 0x10064001 s'exécute comme JUMP (le désassembleur de kbot écrit un tel mot JUMP@0x10064001 pour qu'il se réassemble à l'identique). PUSH (0x10021000) et POP (0x10023000) lisent ensuite leur source ou leur destination dans les trois bits de poids faible. Le fichier scripting/opcodes.go de kbot-io sert de catalogue ; scripting.Opcodes() liste chaque instruction avec ses opérandes en ligne et son effet sur la pile.

Familles d'opcodes#

Un petit échantillon, mais représentatif :

0x10021001 PUSH_CONST     <value>      ( -- v )
0x10021002 PUSH_LOCAL     <var#>       ( -- v )
0x10023002 POP_LOCAL      <var#>       ( v -- )
0x10033000 MUL                         ( a b -- a*b )
0x10051000 LESS_THAN                   ( a b -- a<b )
0x10066000 JUMP_IF_FALSE <byteOffset>  ( v -- )    pops; falls through if v != 0
0x10064000 JUMP          <byteOffset>  ( -- )
0x10065000 RETURN                      ( v -- )    pops the return value
0x10001000 MOVE          <piece> <axis> ( speed distance -- )
0x10003000 SPIN          <piece> <axis> ( speed -- )
0x1000F000 EMIT_SFX      <piece>       ( flags -- )
0x10068000 SET_SIGNAL_MASK              ( mask -- )

Modèle de concurrence#

Une unité peut faire tourner de nombreux scripts en même temps — Walk, Aim, SmokeUnit, MoveWatcher, etc. Leur ordonnancement est coopératif :

• sleep <ticks> rend la main pendant N ticks (1/30 s chacun).
• wait-for-turn <piece> around <axis> rend la main jusqu'à ce que cette pièce termine son animation turn en cours. Idem pour wait-for-move.
• signal <n> tue chaque script dont signal_mask & n != 0.
• set-signal-mask <n> déclare les signaux auxquels le script courant s'intéresse.

Le masque de signal est la façon dont les scripts réalisent la préemption : MoveWatcher fixe le masque SIG_MOVE et surveille la vitesse ; quand l'unité s'arrête, il envoie SIG_MOVE, ce qui tue proprement les animations de marche avant de lancer la pose de repos.

Comment la préemption se déroule réellement#

Un schéma courant : MoveUnit déclenche un script d'animation Walk ; quand le mouvement s'arrête, le moteur envoie SIG_MOVE pour faire le ménage proprement avant que Idle ne démarre. La séquence :

   Engine                 MoveUnit script        Walk script        Idle script
     │                          │                     │                  │
     │  unit ordered to move    │                     │                  │
     ├─ start-script MoveUnit──▶│                     │                  │
     │                          ├─ set-signal-mask    │                  │
     │                          │   SIG_MOVE          │                  │
     │                          ├─ start-script Walk─▶│                  │
     │                          │                     ├─ set-signal-mask │
     │                          │                     │   SIG_MOVE       │
     │                          │                     │ (loops:          │
     │                          │                     │   turn pieces,   │
     │                          │                     │   sleep, repeat) │
     │                          │                     │                  │
     │  movement completes      │                     │                  │
     ├─ engine sets velocity=0  │                     │                  │
     │                          ├─ signal SIG_MOVE ──┐│                  │
     │                          │                    ││                  │
     │   ◀─── KILLED ──────────────────────────────  ◀┤                  │
     │   ◀─── KILLED ──────────┤                     │                  │
     │                                                                   │
     ├─ start-script Idle ─────────────────────────────────────────────▶│
     │                                                                   │ (loops)

Trois points à remarquer :

1. Les deux scripts qui fixent SIG_MOVE sont tués quand le signal part — y compris MoveUnit lui-même (peu importe, son travail est fait).
2. Le script qui signale (MoveUnit) survit assez longtemps pour envoyer le signal avant d'être tué ; l'exécution vérifie les masques après le retour de l'opcode signal.
3. Idle ne fixe pas SIG_MOVE, donc le prochain signal SIG_MOVE ne le touchera pas.

Exemple commenté — cortruck.cob (camion de construction du Core)#

kbot cob decompile scripts/cortruck.cob :

piece base;

SmokeUnit() {
    var local_0, local_1, local_2;

    while (get BUILD_PERCENT_LEFT) { sleep 400; }

    while (1) {
        local_0 = get HEALTH;
        if (local_0 < 66) {
            local_2 = (256 | 2);
            if (rand(1, 66) < local_0) { local_2 = (256 | 1); }
            emit-sfx local_2 from base;
        }
        local_1 = (local_0 * 50);
        if (local_1 < 200) { local_1 = 200; }
        sleep local_1;
    }
    return 0;
}

Create() { return 0; }

Killed() {
    var severity;
    if (severity <= 25) { explode base type (32 | 256); return 0; }
    if (severity <= 50) { explode base type (32 | 256); return 0; }
    if (severity <= 99) { explode base type (32 | 256); return 0; }
    explode base type (32 | 256);
}

Le désassemblage correspondant (kbot cob disassemble -a -s SmokeUnit) montre le flux d'opcodes réel, avec les flèches de JUMP_IF_FALSE/JUMP qui traversent les corps des while/if — utile quand la sortie du décompilateur est ambiguë.

Analyse statique (lint)#

kbot cob lint (et l'onglet Lint de l'explorateur de ressources) exécute le jeu de règles par défaut de kbot-io : des règles de style tirées de vrais bogues des propres scripts de Cavedog et de correctifs de mods proposés par la communauté, deux vérifications au niveau du fichier et — pour chaque COB qui ne déclare pas la version 6 — les règles de compatibilité avec TA 3.1c. Le catalogue des règles de style :

Les règles de compatibilité TA signalent ce sur quoi TA 3.1c plante ou qu'il exécute différemment. Ce sont des erreurs ; elles apparaissent dans la sortie SARIF de --ci comme les autres et ignorent les fichiers de TA: Kingdoms (version 6) :

Les descriptions complètes des règles se trouvent dans le README de kbot. Le décompilateur conserve délibérément la numérotation d'origine des variables et des pièces, de sorte qu'un cycle décompiler→lint→corriger→compiler fait ressortir les mods qui ont besoin de maintenance.

Pièges#

• Tous les offsets de l'en-tête COB sont des offsets absolus dans le fichier, mais les entrées de ScriptCodeIndexArray sont des offsets en mots à l'intérieur de la section de code. On les confond facilement.
• Les numéros de pièces dans les opcodes sont des index dans la table des noms de pièces, pas des chaînes. Le COB porte les noms sous forme de pool de chaînes ; l'exécution utilise des index pour la rapidité.
• Les opcodes get UNIT_VALUE diffèrent subtilement entre TA et TA: Kingdoms. TA: Kingdoms a ajouté des identifiants de valeurs pour la régénération de magie, les points de commandement, etc. ; la table des valeurs de TA est plus compacte. Le décompilateur de kbot nomme pour l'instant le jeu de TA ; les numéros de ports TAK ≥ 21 sont émis comme littéraux numériques (qui refont quand même l'aller-retour par l'assembleur). Voir TA: Kingdoms — écarts du COB v6 pour l'ensemble des écarts.
• Les variables existent en deux variantes : local_N (emplacement de pile local à la fonction) et global_N (statique par unité, persistante d'un appel à l'autre). Le décompilateur émet local_N / global_N par défaut ; renommez-les dans le source pour la lisibilité.
• L'outil Scriptor de Cavedog remplace parfois CURRENT_SPEED par le littéral 29, ce qui casse les scripts de type MoveWatcher après un aller-retour. Le décompilateur de kbot rétablit le nom symbolique ; si vous devez faire l'aller-retour par Scriptor, mettez des parenthèses : (get CURRENT_SPEED) > 5.

Tailles typiques#

TA: Kingdoms — écarts du COB v6#

Disposition du fichier v6#

┌─ 44-byte v4 header ──────────────────────────────────┐
│ VersionSignature == 6, NumScripts, NumPieces, …      │
├─ Sub-header (8 bytes, TAK-only) ─────────────────────┤  (soundNameOffsetTableStart, soundNameCount)
├─ Script code (uint32 opcode stream) ─────────────────┤  same encoding as v4
├─ ScriptCodeIndexArray (uint32 × NumScripts) ─────────┤  unchanged
├─ ScriptNameOffsetArray (uint32 × NumScripts) ────────┤  unchanged
├─ PieceNameOffsetArray (uint32 × NumPieces) ──────────┤  unchanged
├─ SoundNameOffsetArray (uint32 × Count) ──────────────┤  TAK-only — count from sub-header[1]
└─ String pool ────────────────────────────────────────┘  script names → piece names → sound names (in that order)

Le sous-en-tête de 8 octets se place entre OffsetToNameArray (fin de l'en-tête canonique de 11 DWORD, à l'octet 44) et le début de la section de code (OffsetToScriptCode, en général 0x34 = 52). Il contient deux uint32 little-endian :

Chaque entrée de la table des offsets de noms de sons est un offset absolu dans le fichier vers une chaîne terminée par NUL du pool de chaînes — des choses comme "SetMission o 1, s", "create ARASWORD", "ARROW10". Le bytecode y fait référence par index (et non par offset) au moyen de l'opcode MISSION_COMMAND (voir l'annexe C). La table s'appelle le tableau des noms de sons parce que le compilateur Scriptor canonique y enregistre les chaînes par l'action ADDSOUND ; son contenu réel est fait de chaînes de commande du moteur plutôt que de noms de fichiers audio.

La représentation de kbot#

scripting.COB porte les noms de sons dans un champ structuré []string, sans conserver d'octets opaques. Tout le reste (les valeurs du sous-en-tête, la table d'offsets, les offsets de chaque chaîne dans le pool) est reconstruit à partir de cette liste à l'écriture :

type COB struct {
    // …canonical TA fields…
    SoundNames []string // TAK-only; nil for v4
}

Pour les fichiers v4, la tranche est toujours nil, et le sous-en-tête comme la table des offsets de noms de sons sont omis de la sortie.

Le désassembleur et le décompilateur émettent chaque chaîne sous forme de directive .sound_name, pour qu'elles survivent à un aller-retour par .coba et .bos :

.version 6
.statics 6
.sound_name "create NPCEMEN"
.sound_name "SetMission o 1, s"
.sound_name "ARROW10"
.script Start
…

Nouveaux opcodes#

Les fichiers .cob de TAK utilisent des instructions pour lesquelles TA 3.1c n'a aucun gestionnaire (PLAY_SOUND, MISSION_COMMAND et les opérateurs TAK_MATH_*), plus DONT_SHADOW, que TA exécute comme un no-op. Leur sémantique exacte côté jeu n'est pas documentée, mais leur disposition binaire (taille + nombre de paramètres en ligne) est connue grâce à chaque .cob d'origine de TAK, ce qui suffit pour que l'aller-retour désassembler→assembler restitue les octets d'origine à l'identique. Voir l'annexe C pour la référence complète.

État de l'aller-retour#

Syntaxe BOS des extensions TAK#

Le décompilateur émet ces pseudo-appels pour que les COB de TAK fassent l'aller-retour par le BOS. Le compilateur accepte la même syntaxe, mais seulement après .version 6 (sauf dont-shadow, que TA exécute comme un no-op). dont-shadow et Mission-Command reprennent les mots-clés TAK canoniques de Scriptor ; les opcodes mathématiques n'ont pas de nom documenté dans Scriptor (il les étiquette ?? et ????), donc kbot garde les bouche-trous __tak_math_* :

// Statement-level (emitted on their own line):
dont-shadow(<piece>);                                  // DONT_SHADOW — disables shadow casting for one piece
Mission-Command("sound name", arg1, arg2, …);          // MISSION_COMMAND — engine call (statement form drops the return value)
return_val = Mission-Command("sound name", args…);     // assignment form keeps the pushed result

// Expression-level (binary operators: two values popped, one pushed):
local_x = __tak_math_09(a, b);   // TAK_MATH_09
local_x = __tak_math_0a(a, b);   // TAK_MATH_0A
local_x = __tak_math_0b(a, b);   // TAK_MATH_0B

Le premier argument de Mission-Command est le nom de son, sous forme de chaîne entre guillemets : le compilateur le cherche dans la table des noms de sons (la directive .sound_name correspondante doit donc apparaître plus haut dans le fichier). Les arguments suivants sont empilés et le moteur les consomme.

Deux directives en tête de fichier portent le reste des métadonnées v6 :

.version 6
.sound_name "create NPCEMEN"
.sound_name "SetMission o 1, s"
.sound_name "ARROW10"

.version est toujours émise (pour que les fichiers TA v4 refassent l'aller-retour à l'identique par la même chaîne). Chaque .sound_name est une entrée de la table des noms de sons du COB ; l'écrivain reconstruit le sous-en-tête de 8 octets et la table des offsets de noms de sons à partir de len(SoundNames) et de l'ordre d'apparition des entrées.

L'épilogue TAK STACK_ALLOC ; RETURN qu'émet en v6 chaque return; sans valeur est géré par le compilateur : return; se traduit en STACK_ALLOC ; RETURN quand .version 6, et return <expr>; se traduit en <expr> ; RETURN sans préfixe (comme le compilateur de Cavedog).

Pour le reproduire sur votre propre installation :

kbot ctx use kingdoms  # or wherever you registered TAK
kbot cob roundtrip

Symboles des ports au-delà du port 20#

Les scripts de TA: Kingdoms utilisent des ports get_unit_value jusqu'à 46 (CURRENT_SPEED, VETERAN_LEVEL, champs de la réserve de magie, etc.). Le décompilateur de kbot ne nomme pour l'instant symboliquement que les ports 1–20 (voir l'annexe B) ; les ports TAK ≥ 21 sont émis comme littéraux numériques. Le bytecode les stocke de toute façon comme des entiers, donc les allers-retours ne sont pas affectés ; seule la lisibilité du BOS en pâtit. L'ajout des noms de ports TAK est suivi à part.

Annexe A — référence complète des opcodes#

Toutes les instructions qu'exécute TA ou TA: Kingdoms. La référence qui fait foi est formats/scripting/opcodes.go de kbot-io. La notation de pile suit le style Forth ( before -- after ). La colonne En ligne indique combien de mots uint32 suivent le mot d'opcode lui-même (consommés au décodage, pas pris sur la pile).

Animation — manipulation des pièces (0x100x)#

Opérations d'attente (0x101x)#

Manipulation de la pile (0x102x)#

Arithmétique (0x103x)#

TA n'a pas d'instruction modulo : % est une erreur de compilation dans un script TA. 0x10039000–0x1003B000 sont les opérateurs TAK_MATH_* de TA: Kingdoms (annexe C) ; TA plante dessus.

Requêtes au moteur (0x104x)#

Voir l'annexe B pour le catalogue des ports.

Comparaison et logique (0x105x)#

Flot de contrôle et concurrence (0x106x)#

L'offset de JUMP / JUMP_IF_FALSE est un offset en octets relatif à OffsetToScriptCode, et non à l'instruction courante.

Effets (0x107x)#

Opérations d'affectation (0x108x)#

Encodage des opcodes#

Chaque mot d'opcode est de la forme 0x10CCSSFF, où :

• CC = l'octet de catégorie (animation, maths, flot de contrôle, …).
• SS = le quartet de sous-commande, dans le quartet de poids fort du deuxième octet en partant du haut.
• FF = l'octet de flags.

Le jeu aiguille sur word & 0x100FF000 et ignore les autres bits : un mot comme 0x10064001 s'exécute donc comme JUMP ; le désassembleur l'écrit JUMP@0x10064001 et l'assembleur le relit vers le même mot. PUSH et POP lisent leur source ou leur destination dans les trois bits de poids faible : PUSH accepte 1 (constante), 2 (locale) et 4 (statique), POP accepte 2 et 4, et toute autre valeur fait planter le script.

Les mots qu'aucun jeu n'exécute sont rendus UNKNOWN_0x10xxxxxx par le désassembleur (et signalés par ta-unknown-opcode) ; si vous en trouvez un dans un vrai fichier, merci d'ouvrir une issue avec l'échantillon COB.

Annexe B — table des ports de get_unit_value#

Les 20 ports que le décompilateur de kbot nomme symboliquement pour l'instant. Le vrai TA en a environ 80 ; TA: Kingdoms en ajoute environ 15 de plus pour les grandeurs liées à la magie. Tout port au-delà de 20 est aujourd'hui rendu comme littéral numérique dans la sortie du décompilateur.

Les ports supérieurs comprennent CURRENT_SPEED (29 — que le Scriptor de Cavedog remplace tristement par un littéral ; voir les Pièges plus haut), MAX_ID, UNIT_TEAM, UNIT_BUILD_PERCENT, BUILDER, UNIT_ALLIED et bien d'autres. La liste complète se trouve dans la documentation interne de Cavedog ; le wiki communautaire des forums TAUniverse offre le catalogue public le plus complet.

TA: Kingdoms étend la plage des ports. Les ports propres à TAK que kbot reconnaît (le décompilateur affiche le nom symbolique ; le compilateur l'accepte en entrée) sont tirés de la table [UNITVLAUES] de Scriptor :

Annexe C — opcodes de TA: Kingdoms#

Encodage (rappel)#

Chaque mot d'opcode COB est de la forme 0x10CCSSFF, où CC est la catégorie et SS la sous-commande : ces opcodes TAK occupent simplement des emplacements CC:SS jusque-là inutilisés dans les catégories existantes, au lieu d'introduire un nouvel octet de catégorie. DONT_SHADOW se trouve dans la catégorie animation avec DONT_CACHE/DONT_SHADE, et MISSION_COMMAND dans la catégorie effets avec EXPLODE et PLAY_SOUND.

kbot ctx use tak-30bb-flat
kbot cob disassemble scripts/araat.cob -a | grep -E 'DONT_SHADOW|MISSION|TAK_MATH|PLAY_SOUND'

Exemples concrets dans le catalogue de référence#

De vraies unités qui poussent le format dans ses extrêmes ; ouvrez-les pour voir la complexité réelle des scripts plutôt que des exemples rédigés pour le texte :

• CORKROG — Krogoth (Core) — l'un des plus gros COB du jeu (~25 Ko, plus de 30 scripts, animations complexes à plusieurs pièces).
• ARMCOM — commandant Arm — une unité « riche » représentative : cycles de marche, de visée, de repos et de construction, plusieurs armes, gestion du D-gun.
• CORTRUCK — camion de construction — COB quasi minimal, celui qui sert d'exemple commenté sur cette page (3 scripts : SmokeUnit, Create, Killed).
• ARMSAM — Samson — bon exemple d'unité à tourelle (rotation de turret1 pour viser, animation de recul, synchronisation par wait-for-turn).

Décompilez-en n'importe lequel en local avec kbot cob decompile scripts/<name>.cob une fois un contexte kbot défini.

Voir aussi#

• 3DO — les noms de pièces référencés par les scripts COB se trouvent dans le .3do de l'unité.
• FBI — le fichier de métadonnées de l'unité. Son champ ObjectName lie le COB à un 3DO ; Sounds définit la banque de sons que le script peut jouer.
• Le tableau des règles de cob lint de la boîte à outils kbot.
• Glossaire — pièce, axe, masque de signal, tick.