COB / BOS – Bytecode für Einheitenskripte

Jede Einheit in Total Annihilation führt ein Skript aus, das ihre Pieces animiert, Mündungsblitze der Waffen erzeugt, Soundeffekte abspielt und auf Spielereignisse reagiert. Die Quellsprache ist BOS („Basic Object Script“); der kompilierte Bytecode, den die Engine tatsächlich ausführt, ist COB („Cobble“ – Cavedogs Wortspiel für „compiled BOS“). Eine Datei pro Einheit, benannt nach dem ObjectName aus der FBI der Einheit.

# 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)
}

Zwei Sprachen, ein Dateiformat#

Die Engine sieht immer nur COB. BOS ist eine Erleichterung für menschliche Autoren; wenn du „das Skript einer Einheit bearbeitest“, bearbeitest du in Wahrheit den BOS-Quelltext, kompilierst ihn neu zu COB und lieferst das COB im Add-on-.ufo der Einheit aus.

Ein minimales Beispiel:

// 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 übersetzt das in einen binären Blob. kbot cob disassemble -a zeigt den Opcode-Strom mit Kontrollfluss-Pfeilen daneben; kbot cob decompile geht den umgekehrten Weg und gewinnt BOS zurück, das fast immer bytegleich den Round-Trip übersteht (kbot cob roundtrip prüft das über den gesamten Spielkatalog).

Ein Quelltext wird als TA-Skript (COB-Version 4) kompiliert, sofern er nicht mit .version 6 beginnt. Der Compiler verweigert, was TA 3.1c falsch ausführen würde, statt einen Platzhalter zu schreiben: Die Konstrukte von TA: Kingdoms (play-sound, Mission-Command, __tak_math_*, .sound_name) und % sind in einem TA-Skript Fehler (TA hat keine Modulo-Instruktion, und 0x10037000, das Wort, zu dem % früher wurde, ist dort das bitweise XOR), ebenso unbekannte Bezeichner und Funktionen, die mehr als die 32 Stack-Slots des Spiels brauchen. Was sich trotzdem kompilieren lässt, aber einen Blick verdient – eine zweimal definierte Funktion (jeder Aufruf bindet an die erste Definition, so wie die Namenssuche des Spiels) –, wird als Warnung ausgegeben, zusammen mit jedem Befund der TA-Kompatibilitätsregeln des Linters; mit --strict lassen Warnungen den Befehl fehlschlagen. kbot cob assemble wendet dieselben Prüfungen auf handgeschriebene Listings an.

COB-Aufbau auf der Platte#

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;

Danach folgt, in diesem Aufbau:

┌─ 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

Ein Skript auflösen#

Die Code-Index-Tabelle enthält Wort-Offsets als uint32, keine Byte-Offsets. So findest du den Bytecode für Skript Nummer i:

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

Das Skript endet dort, wo das nächste beginnt (beim letzten Skript: am Anfang der Index-Tabelle).

Der Opcode-Strom#

COB ist eine stackbasierte virtuelle Maschine. Die meisten Opcodes holen ihre Argumente vom Datenstack des jeweiligen Skripts, erledigen ihre Arbeit und legen ein Ergebnis zurück. Manche Opcodes haben Inline-Operanden (Sprungziele, Piece-Nummern).

Jeder Opcode ist ein uint32 mit diesem Aufbau:

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

Das höchste Byte ist immer 0x10; family/op/flags unterscheiden sich je Opcode. Das Spiel vergleicht nicht das ganze Wort: Es verzweigt anhand von word & 0x100FF000, Bits außerhalb dieser Maske werden also ignoriert, und 0x10064001 läuft als JUMP (kbots Disassembler schreibt ein solches Wort als JUMP@0x10064001, damit es unverändert zurückassembliert wird). PUSH (0x10021000) und POP (0x10023000) lesen dann ihre Quelle bzw. ihr Ziel aus den unteren drei Bits. Der Katalog ist scripting/opcodes.go in kbot-io; scripting.Opcodes() listet jede Instruktion mit ihren Inline-Operanden und ihrem Stack-Effekt auf.

Opcode-Familien#

Eine kleine, aber repräsentative Auswahl:

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 -- )

Nebenläufigkeitsmodell#

Bei einer Einheit können viele Skripte gleichzeitig laufen – Walk, Aim, SmokeUnit, MoveWatcher usw. Sie werden kooperativ eingeplant:

• sleep <ticks> gibt für N Ticks (je 1/30 s) die Kontrolle ab.
• wait-for-turn <piece> around <axis> wartet, bis dieses Piece seine aktuelle turn-Animation beendet hat. Dasselbe gilt für wait-for-move.
• signal <n> beendet jedes Skript, für das signal_mask & n != 0 gilt.
• set-signal-mask <n> legt fest, an welchen Signalen das aktuelle Skript interessiert ist.

Über die Signalmaske setzen Skripte Präemption um: MoveWatcher setzt die Maske SIG_MOVE und beobachtet die Geschwindigkeit; hält die Einheit an, sendet es SIG_MOVE und beendet so die Laufanimationen sauber, bevor die Ruhepose beginnt.

Wie Präemption tatsächlich abläuft#

Ein gängiges Muster: MoveUnit startet ein Animationsskript Walk; endet die Bewegung, sendet die Engine SIG_MOVE, um sauber aufzuräumen, bevor Idle beginnt. Der Ablauf:

   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)

Drei Dinge fallen auf:

1. Beide Skripte, die SIG_MOVE setzen, werden beendet, wenn das Signal ausgelöst wird – auch MoveUnit selbst (was egal ist; seine Arbeit ist getan).
2. Das signalisierende Skript (MoveUnit) überlebt lange genug, um das Signal zu senden, bevor es beendet wird; die Laufzeitumgebung prüft die Masken erst nachdem der Opcode signal zurückgekehrt ist.
3. Idle setzt SIG_MOVE nicht, das nächste signal SIG_MOVE lässt es also unberührt.

Beispiel im Detail – cortruck.cob (Core Construction Truck)#

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);
}

Die zugehörige Disassemblierung (kbot cob disassemble -a -s SmokeUnit) zeigt den tatsächlichen Opcode-Strom, mit JUMP_IF_FALSE/JUMP-Pfeilen, die sich durch die Rümpfe der while/if-Blöcke ziehen – nützlich, wenn die Ausgabe des Decompilers mehrdeutig ist.

Linting#

kbot cob lint (und der Lint-Tab des Asset-Explorers) führt den Standard-Regelsatz von kbot-io aus: Stilregeln, die aus echten Bugs in Cavedogs eigenen Skripten und aus von der Community eingereichten Mod-Patches abgeleitet sind, zwei Prüfungen auf Dateiebene und – für jedes COB, das nicht Version 6 angibt – die Kompatibilitätsregeln für TA 3.1c. Der Stilkatalog:

Die TA-Kompatibilitätsregeln melden, woran TA 3.1c abbricht oder was es anders ausführt. Sie sind Fehler, erscheinen wie die anderen in der SARIF-Ausgabe von --ci und überspringen Dateien von TA: Kingdoms (Version 6):

Die vollständigen Regelbeschreibungen stehen in der README von kbot. Der Decompiler behält die ursprüngliche Nummerierung von Variablen und Pieces absichtlich bei, damit ein Zyklus dekompilieren→linten→korrigieren→kompilieren die Mods sichtbar macht, die Pflege brauchen.

Stolperfallen#

• Alle Offsets im COB-Header sind absolute Datei-Offsets, die Einträge von ScriptCodeIndexArray dagegen Wort-Offsets innerhalb des Code-Abschnitts. Beides wird leicht verwechselt.
• Piece-Nummern in Opcodes sind Indizes in die Tabelle der Piece-Namen, keine Strings. Das COB enthält die Namen als String-Pool; die Laufzeitumgebung verwendet der Geschwindigkeit wegen Indizes.
• Die get UNIT_VALUE-Opcodes unterscheiden sich subtil zwischen TA und TA: Kingdoms. TA: Kingdoms hat Wert-IDs für Magie-Regeneration, Befehlspunkte usw. hinzugefügt; die Werttabelle von TA ist kompakter. kbots Decompiler benennt derzeit die TA-Menge; TAK-Portnummern ≥ 21 werden als numerische Literale ausgegeben (die trotzdem den Round-Trip durch den Assembler überstehen). Den vollständigen Unterschied beschreibt TA: Kingdoms – Unterschiede von COB v6.
• Variablen gibt es in zwei Sorten: local_N (funktionslokaler Stack-Slot) und global_N (statische Variable pro Einheit, die über Aufrufe hinweg erhalten bleibt). Der Decompiler gibt standardmäßig local_N / global_N aus; benenne sie im Quelltext um, damit er lesbarer wird.
• Das Cavedog-Scriptor-Tool setzt CURRENT_SPEED gelegentlich als Literal 29 ein, was Skripte im Stil von MoveWatcher nach einem Round-Trip kaputtmacht. kbots Decompiler stellt den symbolischen Namen wieder her; wenn du unbedingt einen Round-Trip durch Scriptor machen musst, setze Klammern: (get CURRENT_SPEED) > 5.

Typische Größen#

TA: Kingdoms – Unterschiede von COB v6#

Dateiaufbau von 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)

Der 8 Byte große Sub-Header liegt zwischen OffsetToNameArray (dem Ende des kanonischen Headers aus 11 DWORDs bei Byte 44) und dem Anfang des Code-Abschnitts (OffsetToScriptCode, typischerweise 0x34 = 52). Er enthält zwei uint32-Werte in Little-Endian:

Jeder Eintrag der Offset-Tabelle der Sound-Namen ist der absolute Datei-Offset eines NUL-terminierten Strings im String-Pool – etwa "SetMission o 1, s", "create ARASWORD", "ARROW10". Der Bytecode verweist über den Opcode MISSION_COMMAND per Index (nicht per Offset) auf sie (siehe Anhang C). Die Tabelle heißt Sound-Namen-Array, weil der kanonische Scriptor-Compiler Strings über die Aktion ADDSOUND darin registriert; tatsächlich enthält sie Befehls-Strings für die Engine und keine Audio-Dateinamen.

Die Darstellung in kbot#

scripting.COB führt die Sound-Namen als strukturiertes []string-Feld – es werden keine undurchsichtigen Bytes mitgeschleppt. Alles andere (die Werte des Sub-Headers, die Offset-Tabelle, die Offsets der einzelnen Strings im Pool) wird beim Schreiben aus dieser Liste rekonstruiert:

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

Bei v4-Dateien ist der Slice immer nil, und sowohl der Sub-Header als auch die Offset-Tabelle der Sound-Namen fehlen in der Ausgabe.

Disassembler und Decompiler geben jeden String als Direktive .sound_name aus, damit die Strings einen Round-Trip durch .coba und .bos überstehen:

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

Neue Opcodes#

TAK-.cob-Dateien verwenden Instruktionen, für die TA 3.1c keinen Handler hat (PLAY_SOUND, MISSION_COMMAND und die TAK_MATH_*-Operatoren), dazu DONT_SHADOW, das TA als No-op ausführt. Ihre genaue Semantik im Spiel ist nicht dokumentiert, aber ihr binärer Aufbau (Größe + Anzahl der Inline-Parameter) ist aus jeder .cob der TAK-Verkaufsversion bekannt, und das genügt, damit der Round-Trip disassemblieren→assemblieren die ursprünglichen Bytes unverändert wiederherstellt. Die vollständige Referenz steht in Anhang C.

Stand des Round-Trips#

BOS-Syntax für die TAK-Erweiterungen#

Der Decompiler gibt diese Pseudoaufrufe aus, damit TAK-COBs einen Round-Trip durch BOS überstehen. Der Compiler akzeptiert dieselbe Syntax, aber nur nach .version 6 (mit Ausnahme von dont-shadow – TA führt es als No-op aus). dont-shadow und Mission-Command verwenden die kanonischen TAK-Schlüsselwörter von Scriptor; die Mathe-Opcodes haben in Scriptor keinen dokumentierten Namen (es bezeichnet sie als ?? und ????), daher behält kbot die Platzhalter __tak_math_* bei:

// 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

Das erste Argument von Mission-Command ist der Sound-Name als String in Anführungszeichen – der Compiler sucht ihn in der Sound-Namen-Tabelle (die zugehörige Direktive .sound_name muss also weiter oben in der Datei stehen). Die übrigen Argumente werden auf den Stack gelegt, und die Engine verbraucht sie.

Zwei Direktiven am Dateianfang tragen die restlichen Metadaten von v6:

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

.version wird immer ausgegeben (damit v4-Dateien von TA dieselbe Pipeline identisch durchlaufen). Jedes .sound_name ist ein Eintrag in der Sound-Namen-Tabelle des jeweiligen COB; der Writer baut den 8-Byte-Sub-Header und die Offset-Tabelle der Sound-Namen aus len(SoundNames) und der Reihenfolge der Einträge neu auf.

Den TAK-Epilog STACK_ALLOC ; RETURN, den jedes wertlose return; in v6 erzeugt, übernimmt der Compiler: return; wird bei .version 6 zu STACK_ALLOC ; RETURN, return <expr>; wird ohne Präfix zu <expr> ; RETURN (wie bei Cavedogs Compiler).

Auf deiner eigenen Installation nachvollziehen:

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

Port-Symbole jenseits von Port 20#

Skripte von TA: Kingdoms verwenden get_unit_value-Ports bis 46 (CURRENT_SPEED, VETERAN_LEVEL, Felder des Magie-Pools usw.). kbots Decompiler benennt derzeit nur die Ports 1–20 symbolisch (siehe Anhang B); TAK-Ports ≥ 21 werden als numerische Literale ausgegeben. Der Bytecode speichert sie ohnehin als Ganzzahlen, Round-Trips sind also nicht betroffen – nur die Lesbarkeit des BOS leidet. Die Ergänzung der TAK-Portnamen wird separat verfolgt.

Anhang A – Vollständige Opcode-Referenz#

Jede Instruktion, die TA oder TA: Kingdoms ausführt. Maßgeblich ist formats/scripting/opcodes.go in kbot-io. Die Stack-Notation verwendet die Forth-Schreibweise ( before -- after ). Die Spalten Inline zeigen, wie viele uint32-Wörter auf das Opcode-Wort selbst folgen (beim Dekodieren verbraucht, nicht vom Stack).

Animation – Piece-Manipulation (0x100x)#

Warteoperationen (0x101x)#

Stack-Manipulation (0x102x)#

Arithmetik (0x103x)#

TA hat keine Modulo-Instruktion: % ist in einem TA-Skript ein Kompilierfehler. 0x10039000–0x1003B000 sind die TAK_MATH_*-Operatoren von TA: Kingdoms (Anhang C); TA bricht an ihnen ab.

Abfragen an die Engine (0x104x)#

Den Katalog der Ports findest du in Anhang B.

Vergleich und Logik (0x105x)#

Kontrollfluss und Nebenläufigkeit (0x106x)#

offset ist bei JUMP / JUMP_IF_FALSE ein Byte-Offset relativ zu OffsetToScriptCode, nicht relativ zur aktuellen Instruktion.

Effekte (0x107x)#

Setz-Operationen (0x108x)#

Kodierung der Opcodes#

Jedes Opcode-Wort hat die Form 0x10CCSSFF, wobei:

• CC = das Kategorie-Byte (Animation, Mathematik, Kontrollfluss, …).
• SS = das Unterbefehls-Nibble im oberen Nibble des zweithöchsten Bytes.
• FF = das Flags-Byte.

Das Spiel verzweigt anhand von word & 0x100FF000 und ignoriert die übrigen Bits, ein Wort wie 0x10064001 läuft also als JUMP; der Disassembler schreibt es als JUMP@0x10064001, und der Assembler liest das wieder zum selben Wort ein. PUSH und POP lesen ihre Quelle bzw. ihr Ziel aus den unteren drei Bits: PUSH akzeptiert 1 (Konstante), 2 (lokal) und 4 (statisch), POP akzeptiert 2 und 4, und bei jedem anderen Wert bricht das Skript ab.

Wörter, die kein Spiel ausführt, stellt der Disassembler als UNKNOWN_0x10xxxxxx dar (und ta-unknown-opcode meldet sie); wenn du eines in einer echten Datei findest, eröffne bitte ein Issue mit dem COB als Beispiel.

Anhang B – Port-Tabelle von get_unit_value#

Die 20 Ports, die kbots Decompiler derzeit symbolisch benennt. Das echte TA hat ~80; TA: Kingdoms fügt weitere ~15 für magiebezogene Größen hinzu. Alles oberhalb von Port 20 erscheint in der Ausgabe des Decompilers heute als numerisches Literal.

Zu den höheren Ports gehören CURRENT_SPEED (29 – berüchtigt dafür, dass der Cavedog-Scriptor ihn als Literal einsetzt; siehe Stolperfallen oben), MAX_ID, UNIT_TEAM, UNIT_BUILD_PERCENT, BUILDER, UNIT_ALLIED und viele mehr. Die vollständige Liste steht in Cavedogs interner Dokumentation; das Community-Wiki in den TAUniverse-Foren hat den umfassendsten öffentlichen Katalog.

TA: Kingdoms erweitert den Portbereich. Die reinen TAK-Ports, die kbot erkennt (der Decompiler gibt den symbolischen Namen aus, der Compiler akzeptiert ihn als Eingabe), stammen aus der Tabelle [UNITVLAUES] von Scriptor:

Anhang C – Opcodes von TA: Kingdoms#

Kodierung (Zusammenfassung)#

Jedes COB-Opcode-Wort hat die Form 0x10CCSSFF, wobei CC die Kategorie und SS der Unterbefehl ist – diese TAK-Opcodes belegen einfach bisher ungenutzte CC:SS-Plätze innerhalb der bestehenden Kategorien, statt ein neues Kategorie-Byte einzuführen. DONT_SHADOW liegt in der Animationskategorie neben DONT_CACHE/DONT_SHADE, MISSION_COMMAND in der Effektkategorie neben EXPLODE und PLAY_SOUND.

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

Echte Beispiele im Referenzkatalog#

Echte Einheiten, die die Extreme des Formats ausreizen – öffne sie, um die tatsächliche Komplexität von Skripten zu sehen statt Beispielen, die für den Text zurechtgelegt wurden:

• CORKROG – Krogoth (Core) – eines der größten COBs im Spiel (~25 KB, über 30 Skripte, komplexe Animationen über viele Pieces).
• ARMCOM – Arm Commander – repräsentative „reichhaltige“ Einheit: Zyklen für Laufen/Zielen/Ruhe/Bauen, mehrere Waffen, Behandlung der D-Gun.
• CORTRUCK – Construction Truck – nahezu minimales COB, das auf dieser Seite als durchgehendes Beispiel dient (3 Skripte: SmokeUnit, Create, Killed).
• ARMSAM – Samson – gutes Beispiel für eine Einheit mit Geschützturm (turret1 dreht sich zum Zielen, Rückstoßanimation, Synchronisation per wait-for-turn).

Dekompiliere jedes davon lokal mit kbot cob decompile scripts/<name>.cob, sobald ein kbot-Kontext gesetzt ist.

Siehe auch#

• 3DO – die Piece-Namen, auf die COB-Skripte verweisen, stehen in der .3do der Einheit.
• FBI – die Metadatendatei der Einheit. ObjectName verbindet dort das COB mit einem 3DO; Sounds legt die Soundbank fest, die das Skript abspielen kann.
• Die Regeltabelle von cob lint in der kbot-CLI.
• Glossar – piece, axis, signal mask, tick.