COB / BOS — 유닛 스크립트 바이트코드

Total Annihilation의 모든 유닛은 스크립트를 실행합니다. 스크립트는 유닛의 피스(piece)를 움직이고, 무기 발사 섬광을 내고, 효과음을 재생하고, 게임 이벤트에 반응합니다. 소스 언어는 BOS("Basic Object Script")이고, 엔진이 실제로 실행하는 컴파일된 바이트코드는 COB("Cobble" — "compiled BOS"를 비튼 Cavedog의 말장난)입니다. 유닛마다 파일이 하나씩 있으며, 이름은 해당 유닛 FBI의 ObjectName을 따릅니다.

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

두 언어, 하나의 파일 형식#

엔진이 보는 것은 COB뿐입니다. BOS는 사람이 작성하기 편하도록 있는 것으로, "유닛의 스크립트를 편집한다"는 것은 실제로는 BOS 소스를 편집하고, COB로 다시 컴파일하고, 그 COB를 유닛의 애드온 .ufo에 넣어 배포한다는 뜻입니다.

최소한의 예:

// 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은 이것을 바이너리 덩어리로 낮춥니다. kbot cob disassemble -a는 옵코드 스트림을 제어 흐름 화살표와 나란히 보여 주고, kbot cob decompile은 반대 방향으로 BOS를 복원합니다. 복원된 BOS는 거의 언제나 바이트 단위로 동일하게 왕복 변환(round-trip)됩니다(kbot cob roundtrip이 게임 전체 카탈로그에 걸쳐 이를 검증합니다).

소스는 .version 6으로 시작하지 않는 한 TA 스크립트(COB 버전 4)로 컴파일됩니다. 컴파일러는 TA 3.1c가 잘못 실행할 코드를 만나면 자리 표시자를 써 넣는 대신 거부합니다. TA: Kingdoms 구문(play-sound, Mission-Command, __tak_math_*, .sound_name)과 %는 TA 스크립트에서 오류입니다(TA에는 나머지 연산 명령이 없으며, 예전에 %가 변환되던 워드 0x10037000은 TA에서 비트 XOR입니다). 알 수 없는 식별자, 그리고 게임의 스택 슬롯 32개를 넘게 필요로 하는 함수도 마찬가지로 오류입니다. 컴파일은 되지만 살펴볼 필요가 있는 것 — 두 번 정의된 함수(게임의 이름 조회처럼 모든 호출이 첫 번째 정의에 연결됨) — 은 TA 호환성 린트 규칙에서 발견된 내용과 함께 경고로 출력됩니다. --strict를 주면 경고가 있을 때 명령이 실패합니다. kbot cob assemble은 손으로 작성한 리스팅에도 같은 검사를 적용합니다.

COB의 디스크상 구조#

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;

그 뒤에는 다음 구조가 이어집니다.

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

스크립트 찾기#

코드 인덱스 테이블에는 바이트 오프셋이 아니라 uint32 워드 오프셋이 들어 있습니다. i번 스크립트의 바이트코드를 찾으려면:

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

스크립트는 다음 스크립트가 시작하는 곳에서 끝납니다(마지막 스크립트는 인덱스 테이블이 시작하는 곳에서 끝납니다).

옵코드 스트림#

COB는 스택 기반 가상 머신입니다. 대부분의 옵코드는 스크립트별 데이터 스택에서 인수를 꺼내(pop) 처리한 뒤 결과를 다시 넣습니다(push). 일부 옵코드는 인라인 피연산자(점프 대상, 피스 번호)를 가집니다.

각 옵코드는 다음 구조의 uint32 하나입니다.

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

최상위 바이트는 항상 0x10이고, family/op/flags는 옵코드마다 다릅니다. 게임은 워드 전체를 비교하지 않고 word & 0x100FF000으로 분기합니다. 따라서 이 마스크 밖의 비트는 무시되며 0x10064001은 JUMP로 실행됩니다(kbot의 디스어셈블러는 이런 워드를 JUMP@0x10064001로 써서 다시 어셈블해도 그대로 나오게 합니다). PUSH(0x10021000)와 POP(0x10023000)은 하위 3비트에서 출처나 대상을 읽습니다. kbot-io의 scripting/opcodes.go가 목록이며, scripting.Opcodes()는 모든 명령을 인라인 피연산자, 스택 효과와 함께 나열합니다.

옵코드 계열#

작지만 대표적인 예시:

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

동시성 모델#

한 유닛에서 여러 스크립트가 동시에 실행될 수 있습니다 — Walk, Aim, SmokeUnit, MoveWatcher 등. 이들은 협력형으로 스케줄링됩니다.

• **sleep <ticks>**는 N틱(틱당 1/30초) 동안 실행을 양보합니다.
• **wait-for-turn <piece> around <axis>**는 해당 피스가 현재 turn 애니메이션을 마칠 때까지 양보합니다. wait-for-move도 마찬가지입니다.
• **signal <n>**은 signal_mask & n != 0인 스크립트를 모두 종료합니다.
• **set-signal-mask <n>**은 현재 스크립트가 어떤 시그널에 반응할지 선언합니다.

시그널 마스크는 스크립트가 선점(preemption)을 구현하는 수단입니다. MoveWatcher는 마스크 SIG_MOVE를 설정하고 속도를 감시하다가, 유닛이 멈추면 SIG_MOVE를 보내 걷기 애니메이션을 깔끔하게 종료한 뒤 대기 자세를 시작합니다.

선점이 실제로 일어나는 과정#

흔한 패턴: MoveUnit이 Walk 애니메이션 스크립트를 시작하고, 이동이 멈추면 엔진이 SIG_MOVE를 보내 Idle이 시작되기 전에 깔끔하게 정리합니다. 순서는 다음과 같습니다.

   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)

눈여겨볼 점 세 가지:

1. 시그널이 발생하면 SIG_MOVE를 설정한 두 스크립트가 모두 종료됩니다. MoveUnit 자신도 포함됩니다(상관없습니다. 할 일은 이미 끝났으니까요).
2. 시그널을 보내는 스크립트(MoveUnit)는 종료되기 전에 시그널을 보낼 만큼은 살아 있습니다. 런타임은 signal 옵코드가 반환된 뒤에 마스크를 검사합니다.
3. Idle은 SIG_MOVE를 설정하지 않으므로 다음 signal SIG_MOVE의 영향을 받지 않습니다.

실제 예제 — 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);
}

대응하는 디스어셈블 결과(kbot cob disassemble -a -s SmokeUnit)는 실제 옵코드 스트림을 보여 주며, while/if 본문 사이로 JUMP_IF_FALSE/JUMP 화살표가 이어집니다. 디컴파일러 출력이 모호할 때 유용합니다.

린트#

kbot cob lint(그리고 에셋 탐색기의 Lint 탭)는 kbot-io의 기본 규칙 집합을 실행합니다. Cavedog 자체 스크립트와 커뮤니티가 제출한 모드 패치에서 실제로 나온 버그를 바탕으로 한 스타일 규칙, 파일 수준 검사 두 가지, 그리고 버전 6을 선언하지 않은 모든 COB에 대해서는 TA 3.1c 호환성 규칙이 포함됩니다. 스타일 규칙 목록:

TA 호환성 규칙은 TA 3.1c가 오류로 멈추거나 다르게 실행하는 것을 보고합니다. 이 규칙들은 오류(error)이며, 다른 규칙처럼 --ci SARIF 출력에 나타나고, TA: Kingdoms(버전 6) 파일은 건너뜁니다.

규칙에 대한 자세한 설명은 kbot README에 있습니다. 디컴파일러는 원래의 변수와 피스 번호를 일부러 보존하므로, 디컴파일→린트→수정→컴파일 사이클을 돌리면 손볼 필요가 있는 모드가 드러납니다.

주의할 점#

• COB 헤더의 오프셋은 모두 파일 기준 절대 오프셋이지만, ScriptCodeIndexArray의 항목은 코드 섹션 안의 워드 오프셋입니다. 헷갈리기 쉽습니다.
• 옵코드 안의 피스 번호는 문자열이 아니라 피스 이름 테이블의 인덱스입니다. COB는 이름을 문자열 풀로 담고 있고, 런타임은 속도를 위해 인덱스를 씁니다.
• get UNIT_VALUE 옵코드는 TA와 TA: Kingdoms 사이에 미묘하게 다릅니다. TA: Kingdoms는 마법 재생, 명령 포인트 등을 위한 값 ID를 추가했고, TA의 값 테이블은 더 작습니다. kbot의 디컴파일러는 현재 TA 집합에 이름을 붙이며, TAK의 21 이상 포트 번호는 숫자 리터럴로 출력합니다(이 경우에도 어셈블러를 통한 왕복 변환은 그대로 됩니다). 차이 전체는 TA: Kingdoms — COB v6 차이점을 참고하세요.
• 변수는 두 종류입니다: local_N(함수 지역 스택 슬롯)과 global_N(호출 간에 유지되는 유닛별 정적 변수). 디컴파일러는 기본적으로 local_N / global_N을 출력하니, 읽기 쉽도록 소스에서 이름을 바꾸세요.
• Cavedog Scriptor 도구는 가끔 CURRENT_SPEED를 리터럴 29로 인라인해 버려서 왕복 변환 후 MoveWatcher 스타일 스크립트를 망가뜨립니다. kbot의 디컴파일러는 기호 이름을 복원합니다. Scriptor를 거쳐 왕복 변환해야 한다면 괄호로 감싸세요: (get CURRENT_SPEED) > 5.

일반적인 크기#

TA: Kingdoms — COB v6 차이점#

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)

8바이트 서브헤더는 OffsetToNameArray(44바이트 지점에서 끝나는 표준 11-DWORD 헤더의 끝)와 코드 섹션의 시작(OffsetToScriptCode, 보통 0x34 = 52) 사이에 있습니다. 리틀 엔디언 uint32 두 개를 담습니다.

사운드 이름 오프셋 테이블의 각 항목은 문자열 풀 안에 있는 널 종료 문자열의 파일 기준 절대 오프셋입니다 — "SetMission o 1, s", "create ARASWORD", "ARROW10" 같은 것들입니다. 바이트코드는 이들을 오프셋이 아니라 인덱스로, MISSION_COMMAND 옵코드를 통해 참조합니다(부록 C 참고). 이 테이블을 사운드 이름 배열이라고 부르는 이유는 표준 Scriptor 컴파일러가 ADDSOUND 동작으로 문자열을 여기에 등록하기 때문입니다. 실제 내용은 오디오 파일 이름이 아니라 엔진 명령 문자열입니다.

kbot의 표현 방식#

scripting.COB는 사운드 이름을 구조화된 []string 필드로 담습니다 — 불투명한 바이트를 그대로 보존하지 않습니다. 나머지(서브헤더 값, 오프셋 테이블, 풀 안의 문자열별 오프셋)는 쓸 때 이 목록에서 다시 만들어집니다.

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

v4 파일에서는 이 슬라이스가 항상 nil이며, 서브헤더와 사운드 이름 오프셋 테이블 모두 출력에서 생략됩니다.

디스어셈블러 / 디컴파일러는 각 문자열을 .sound_name 지시문으로 출력하므로, .coba와 .bos를 거치는 왕복 변환에서도 살아남습니다.

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

새 옵코드#

TAK의 .cob 파일은 TA 3.1c에 핸들러가 없는 명령(PLAY_SOUND, MISSION_COMMAND, TAK_MATH_* 연산자)과, TA에서는 아무 동작도 하지 않는(no-op) DONT_SHADOW를 사용합니다. 게임 쪽의 정확한 의미는 문서화되어 있지 않지만, 바이너리 구조(크기 + 인라인 매개변수 개수)는 모든 정식 출시판 TAK .cob에서 확인되었고, 이것만으로도 디스어셈블→어셈블 왕복 변환에서 원래 바이트를 그대로 복원하기에 충분합니다. 전체 레퍼런스는 부록 C를 참고하세요.

왕복 변환 현황#

TAK 확장을 위한 BOS 문법#

디컴파일러는 TAK COB가 BOS를 거쳐 왕복 변환되도록 다음 의사 호출을 출력합니다. 컴파일러도 같은 문법을 받아들이지만, .version 6 뒤에서만 받아들입니다(dont-shadow는 예외 — TA는 이를 no-op으로 실행합니다). dont-shadow와 Mission-Command는 Scriptor의 표준 TAK 키워드를 씁니다. 수학 옵코드는 Scriptor에 문서화된 이름이 없으므로(Scriptor는 ??와 ????로 표시) kbot은 __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

Mission-Command의 첫 번째 인수는 따옴표로 감싼 사운드 이름 문자열입니다 — 컴파일러는 이를 사운드 이름 테이블에서 찾습니다(따라서 대응하는 .sound_name 지시문이 파일 앞쪽에 있어야 합니다). 나머지 인수는 스택에 넣어지고 엔진이 소비합니다.

v6의 나머지 메타데이터는 파일 맨 위의 두 지시문이 담습니다.

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

.version은 항상 출력됩니다(그래서 v4 TA 파일도 같은 파이프라인을 똑같이 왕복합니다). 각 .sound_name은 COB별 사운드 이름 테이블의 항목 하나입니다. 라이터는 len(SoundNames)와 항목이 나타나는 순서로 8바이트 서브헤더와 사운드 이름 오프셋 테이블을 다시 만듭니다.

v6에서 값이 없는 return;마다 생성되는 TAK의 STACK_ALLOC ; RETURN 에필로그는 컴파일러가 처리합니다. .version 6일 때 return;은 STACK_ALLOC ; RETURN으로, return <expr>;은 접두 없이 <expr> ; RETURN으로 낮춰집니다(Cavedog 컴파일러와 같음).

자신의 설치본에서 재현해 보세요.

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

20번을 넘는 포트 기호#

TA: Kingdoms 스크립트는 46번까지의 get_unit_value 포트를 사용합니다(CURRENT_SPEED, VETERAN_LEVEL, 마법 풀 관련 필드 등). kbot의 디컴파일러는 현재 1–20번 포트만 기호로 표시하며(부록 B 참고), TAK의 21번 이상 포트는 숫자 리터럴로 출력합니다. 바이트코드는 어느 쪽이든 정수로 저장하므로 왕복 변환에는 영향이 없고 — BOS의 가독성만 떨어집니다. TAK 포트 이름 추가는 별도로 추적하고 있습니다.

부록 A — 전체 옵코드 레퍼런스#

TA나 TA: Kingdoms가 실행하는 모든 명령입니다. 기준은 kbot-io의 formats/scripting/opcodes.go입니다. 스택 표기는 Forth 스타일의 ( before -- after )를 씁니다. 인라인 열은 옵코드 워드 자체 뒤에 오는 uint32 워드의 개수를 나타냅니다(스택이 아니라 디코딩 중에 소비됨).

애니메이션 — 피스 조작(0x100x)#

대기 연산(0x101x)#

스택 조작(0x102x)#

산술(0x103x)#

TA에는 나머지 연산 명령이 없습니다. TA 스크립트에서 %는 컴파일 오류입니다. 0x10039000–0x1003B000은 TA: Kingdoms의 TAK_MATH_* 연산자이며(부록 C), TA에서는 오류로 멈춥니다.

엔진 조회(0x104x)#

포트 목록은 부록 B를 참고하세요.

비교·논리(0x105x)#

제어 흐름·동시성(0x106x)#

JUMP / JUMP_IF_FALSE의 offset은 현재 명령이 아니라 OffsetToScriptCode를 기준으로 한 바이트 오프셋입니다.

효과(0x107x)#

설정 연산(0x108x)#

옵코드 인코딩#

모든 옵코드 워드는 0x10CCSSFF 형태이며, 각 부분은 다음과 같습니다.

• CC = 카테고리 바이트(애니메이션, 수학, 제어 흐름, …).
• SS = 위에서 두 번째 바이트의 상위 니블에 있는 하위 명령 니블.
• FF = 플래그 바이트.

게임은 word & 0x100FF000으로 분기하고 나머지 비트는 무시하므로, 0x10064001 같은 워드는 JUMP로 실행됩니다. 디스어셈블러는 이를 JUMP@0x10064001로 쓰고, 어셈블러는 이것을 읽어 같은 워드로 되돌립니다. PUSH와 POP은 하위 3비트에서 출처나 대상을 읽습니다. PUSH는 1(상수), 2(지역 변수), 4(정적 변수)를, POP은 2와 4를 받아들이며, 다른 값이면 스크립트가 오류로 멈춥니다.

어느 게임도 실행하지 않는 워드는 디스어셈블러에서 UNKNOWN_0x10xxxxxx로 표시됩니다(그리고 ta-unknown-opcode가 보고합니다). 실제 파일에서 이런 워드를 발견하면 COB 샘플과 함께 이슈를 올려 주세요.

부록 B — get_unit_value 포트 표#

kbot의 디컴파일러가 현재 기호로 표시하는 포트 20개입니다. 실제 TA에는 약 80개가 있고, TA: Kingdoms는 마법 관련 수치를 위해 약 15개를 더 추가합니다. 현재 디컴파일러 출력에서 20번을 넘는 포트는 모두 숫자 리터럴로 표시됩니다.

더 높은 포트에는 CURRENT_SPEED(29 — Cavedog Scriptor가 리터럴로 인라인해 버리는 것으로 유명합니다. 위의 주의할 점 참고), MAX_ID, UNIT_TEAM, UNIT_BUILD_PERCENT, BUILDER, UNIT_ALLIED 등이 있습니다. 전체 목록은 Cavedog의 내부 문서에 있으며, 공개된 것 중 가장 포괄적인 목록은 TAUniverse 포럼의 커뮤니티 위키에 있습니다.

TA: Kingdoms는 포트 범위를 넓힙니다. kbot이 인식하는 TAK 전용 포트(디컴파일러는 기호 이름으로 표시하고, 컴파일러는 입력으로 받아들임)는 Scriptor의 [UNITVLAUES] 테이블에서 가져왔습니다.

부록 C — TA: Kingdoms 옵코드#

인코딩(요약)#

모든 COB 옵코드 워드는 0x10CCSSFF 형태이며 CC는 카테고리, SS는 하위 명령입니다. 이 TAK 옵코드들은 새 카테고리 바이트를 도입하지 않고, 기존 카테고리 안에서 이전에 쓰이지 않던 CC:SS 자리를 차지할 뿐입니다. DONT_SHADOW는 애니메이션 카테고리에서 DONT_CACHE/DONT_SHADE와 함께, MISSION_COMMAND는 효과 카테고리에서 EXPLODE, PLAY_SOUND와 함께 있습니다.

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

레퍼런스 카탈로그의 실제 예#

형식의 극단을 보여 주는 실제 유닛들입니다. 본문 속 예제가 아니라 실제 스크립트의 복잡도를 보려면 이것들을 열어 보세요.

• CORKROG — Krogoth(Core) — 게임에서 가장 큰 COB 중 하나(약 25 KB, 스크립트 30개 이상, 복잡한 다중 피스 애니메이션).
• ARMCOM — Arm Commander — 대표적인 "풍부한" 유닛: 걷기/조준/대기/건설 사이클, 여러 무기, D-gun 처리.
• CORTRUCK — Construction Truck — 이 페이지의 해설에 쓴 거의 최소한의 COB(스크립트 3개: SmokeUnit, Create, Killed).
• ARMSAM — Samson — 포탑 유닛의 좋은 예(turret1 조준 회전, 반동 애니메이션, wait-for-turn 동기화).

kbot 컨텍스트를 설정한 뒤에는 kbot cob decompile scripts/<name>.cob으로 어떤 스크립트든 로컬에서 디컴파일할 수 있습니다.

함께 보기#

• 3DO — COB 스크립트가 참조하는 피스 이름은 유닛의 .3do에 있습니다.
• FBI — 유닛의 메타데이터 파일. 거기 있는 ObjectName이 COB와 3DO를 묶고, Sounds는 스크립트가 재생할 수 있는 오디오 뱅크를 정합니다.
• kbot CLI의 cob lint 규칙 표.
• 용어집 — piece, axis, signal mask, tick.