Unit definitions

A unit definition connects the assets

An FBI is a TDF text file with a [UNITINFO] section. It names the model, weapons, corpse and sound category, and supplies capabilities, costs, movement parameters and sensor ranges. The engine derives the script path from UnitName, not from a script key.

Inspect the authored example

[UNITINFO] {
    UnitName=EX_RELAY;
    Objectname=ex_relay;
    Corpse=ex_relay_dead;
    SoundCategory=EX_UTILITY;
    Weapon1=EX_PULSE;
    BMcode=0;
    Builder=1;
    CanMove=1;
    MaxVelocity=0;
    FootprintX=4;
    FootprintZ=4;
    YardMap=oooo o..o occo oYYo;
}

The complete example adds display text, costs and work parameters. Its manifest records the parsed fields and every cell of four original yard-map cases. The generator checks these outputs without reading retail archives.

Three facts that are easy to conflate

The authored workshop deliberately combines all three. Stock factories also demonstrate that these fields are distinct. With Shading enabled, BMcode=0 selects the shaded piece path; classifying that path by CanMove loses established factory shading.

These examples show the stored identities directly. The post-sort second FBI pass can replace runtime fields; it does not perform another name sort. Full path-suffix and record-identity rules appear in the catalog section.

Which keys the engine actually reads

Established: key support comes from the unit parser and its consumers, not merely a search for literal strings. The accessor/default/width table is [02 R-KEYS-01 §5]; field effects belong to its cited behavioral sections. A string census can miss dynamically constructed localized keys and short strings. Presence establishes neither a consumer nor an effect.

The tables distinguish established parsed fields from bounded-negative reader findings and retained unknown source fields. Counts describe the cited retail sample, not all editions or mods.

Authored by retail units, with no recovered runtime reader

The bounded unit-parser census finds no reader for these authored keys [02 §5]. Preserve them when round-tripping; do not give them behavior.

The language-prefixed Name and Description keys do not belong in this table even though no literal GermanName-style string exists in the image: the accessor builds the key at runtime from the configured language name, so the whole-string census cannot see them and the engine honors them, as recorded in the Identity table below. That covers the retail joke keys too — JapaneseName, PigLatinName and PigLatinDescription, one unit each.

ArmorCategory (and its ArmorCategorie/ArmorCategories variants), Hover, MetalUse and CanRepair are third-party spellings: no shipped unit authors them and no string for them exists in the executable either.

Readable by the engine, but never authored by retail units

Exactly three weapon slots

weapon1, weapon2, and weapon3 occur in the bounded key census. There is no fourth slot in the traced unit compiler and weapon-slot runtime. Three is the established slot count [02 R-KEYS-01 §5][06 §4.2].

Field reference

Established: packed Boolean flags retain the integer accessor result modulo 2: author 0/1, because 2 clears a one-bit flag. Byte/word scalar fields have their own narrowing; do not apply this rule to BMcode or other whole-byte fields. Decimals use the accessor named for the key, so a decimal in an integer field loses its fractional suffix. Defaults and narrowing are listed in [02 R-KEYS-01 §5]. Unknown or third-party keys should be preserved, not rejected — the engine ignores what it doesn’t know.

Identity

Construction (being built)

BuildAngle is the unsigned bound consumed by the common unit-initialization sampler — not a random yaw span around the requested build facing, the reading community notes give it. The runtime heading arithmetic and lifecycle belong to [04 §2.3b]; this format entry records only the field’s authored type and interpretation. Established (bounded unit-parser and allocator trace): Ovradjust has no recovered runtime reader. Its original authoring purpose remains Unknown; it supplies no overlap, heading, or geometry behavior.

YardMap: text to footprint cells

BMcode=0;
FootprintX=4;
FootprintZ=4;
YardMap=oooo o..o occo oYYo;

Established: the unit compiler reads at most 1,023 authored bytes and allocates FootprintX × FootprintZ output cells only when BMcode is zero. The exact character table is case-sensitive [02 R-CAT-01 §5]:

Only listed characters consume cells. Spaces, newlines, lowercase g, and all other unlisted characters are skipped. A final listed character repeats until the footprint is full; excess characters after the final cell are ignored. Thus YardMap=o; fills a larger footprint, and ARMLAB’s spaced 6×6 source has the same cells as its unspaced form.

Established (malformed-source boundary): there is no all-o absent-key retail default. Empty text, or text ending in an unlisted character while cells remain, makes the skip branch advance through the string terminator; that branch neither consumes a cell nor checks the source end. A recognized final character is different: its next-byte terminator check parks the source and repeats that character. The output footprint bounds the number of accepted cells, not how far an unsuccessful source scan can read.

Established (Nanolathe host policy): when the bounded source is exhausted, ParseYardMap fills remaining cells with o and rejects nonpositive host footprints. That preserves a blocking building footprint without reading unowned memory; it is not a retail absent-key rule. Unknown: the bytes beyond retail’s exhausted source and the resulting cells or fault in a particular run. They depend on temporary storage, not solely on FBI bytes, so no file-format default can settle them. Cell-bit consumers, including uppercase G’s vent requirement and open-yard occupancy, belong to [05 “Geothermal requirement”] and [04 §6.4]; the character names alone do not define those rules.

Building others

Resources

Movement

canmove is an order/UI capability, not a locomotion classifier. Every one of the 21 stationary factory definitions in the retail corpus sets canmove=1 while also authoring MaxVelocity=0 and no MovementClass; the move order selects the rally point that newly completed units travel toward. The factory itself does not move. Engine systems that need the physical stationary/mobile distinction must therefore use actual locomotion data such as MaxVelocity, not canmove.

This distinction is visible in presentation as well as simulation, but the field that decides it is BMcode, not canmove. Retail runs its shaded piece renderer only for BMcode=0 definitions (and only while the Shading display option is on); everything else is drawn by a second piece renderer that maps textured faces with no PALETTE.SHD step. A zero-velocity factory authors canmove=1 and BMcode=0, so it is shaded through the vertex-interpolated ramp described in pal.md even though its FBI exposes the move command and its COB animates doors, pads, and other pieces. Classifying that unit as mobile — or gating the renderer on canmove or MaxVelocity — removes its shading entirely. See research/retail-executable-spec/03 [R-RND-02A].

Combat

Established — category references: the three prefixed bad-target fields and NoChaseCategory resolve an ordinary category-registry name. A matching unit name does not substitute that unit’s identity mask; only authored category membership populates the mask. Missing fields select none, while explicit empty values select the ordinary empty-name registry entry. Later definitions can contribute membership to an earlier field’s selected category [02 R-P0-03 §5].

Sensors and stealth

Miscellaneous

Catalog loading and implementation

Established — implementation inspection: internal/content/compile_unit.go applies typed reads, low-bit/byte/word narrowing, movement-class fallback and source-field retention; formats/tdf.go owns the syntax. Known defaults are listed in [02 R-KEYS-01 §5], including StandingFireOrder=2, StandingMoveOrder=2, ShootMe=0 and DamageModifier=1.0. Authored zero does not select an absent-key default.

The compiler retains armoredstate without seeding runtime armor, matching [06 R-DMG-01 §2]. The implementation’s Wacky field is retained without a consumer; the documented retail consumers are in the multiplayer restriction UI, outside the current single-player scope. Unknown source-field retention must not imply that the engine acts on those values.

The catalog retains every compatible record in retail sort order, including duplicate and empty names, and preserves the runtime name lookup. Construction, model resources, cloning and category/profile linking retain record IDs. The post-sort secondary FBI pass uses the stored name, preserving only the established discovery-only fields (side, ai_weight, ai_limit, wacky and catalog state). A missing, empty, unreadable or sectionless second file keeps discovery-only values; it does not initialize gameplay defaults. A successful second parse replaces other runtime fields even when keys are absent. A changed UnitName does not trigger another sort; the name index projects the unchanged lower-bound lookup, including its misses if the final names no longer sort [02 R-CAT-01 §5]. Empty model/script identities use objects3d/.3do and scripts/.cob. FBI, model and script resources replace the last-period suffix of the assembled path before appending the requested extension; the suffix scan does not stop at a directory separator. The AI strategic planner’s name-based candidate/count tables remain separate from this loader and record-identity contract.

Established — catalog admission: loose FBI winners are silently skipped before unit compilation [02 R-CAT-01 §4] / docs/SPEC_CONFLICTS.md SC24. Archive-backed definitions also pass the version/copyright checks. The version warning is suppressed when the same pass encounters a silent rejection; it is not guaranteed for every rejected unit [02 R-MALF-01 §5].

Unknowns and caveats

• Established (catalog identity and resource trace): absent and empty UnitName both remain empty through discovery, compatible-record compaction, case-insensitive sorting and secondary FBI selection. The resource helper consequently probes units/.FBI. If that file exists and is nonempty, the ordinary second parser can reread its fields; otherwise the empty identity is retained and the later script path is scripts/.COB; it does not recover the discovered FBI filename. An absent Objectname copies the stored UnitName, so it yields objects3d/.3DO in this case. An explicitly empty Objectname stays empty even with a nonempty unit name; an explicitly nonempty model name remains usable. A missing model follows the ordinary fatal resource path. GUI probes use the stored name plus page number, beginning with guis/0.GUI for an empty name [02 R-CAT-01 §4], [02 R-CAT-01 §5]. Nanolathe likewise preserves the empty identity rather than synthesizing a filename stem.
• Established (bounded duplicate-name behavior): retail keeps compatible definitions as records and its name lookup selects the first equal record in the sorted range, excluding the sentinel. Empty is not a special lookup rejection. The bounded static trace also establishes the unstable partition/insertion sort and its equal-name swaps [02 R-CAT-01 §5]. An insertion-only range preserves equal records; a partitioned range can exchange them. Consumers must retain record identity instead of collapsing names or imposing a discovery-order winner.
• Established (bounded negative): neither unit parsing nor allocation reads Ovradjust; a case-insensitive executable string census also finds no spelling of that key. This closes the runtime-reader question for the inspected unit path. Unknown: the original producer’s intended meaning; no period producer or authoring contract was inspected. Preserve its text without assigning behavior [02 R-P28-ANG-01R §1].
• Established: BMcode, BankScale, PitchScale, BuildAngle, BuildTime, WorkerTime and DamageModifier have traced contracts. They must not be listed as unresolved community guesses. sortbias, teleporter, ShowPlayerName, the definition armoredstate, and ai_limit are parsed without the effects their names suggest.
• Established: ShootMe=0 does not universally forbid autonomous targeting; computer-shooter and session-option alternatives remain in the admission predicate [04 R-SPEC-01 §5].
• Unknown: run-specific output after a malformed yard source is exhausted. The unchecked scan and the separate bounded host policy are established in “YardMap” above; further source scanning cannot define the adjacent bytes.
• Established: no key names the COB script; UnitName selects scripts/<name>.cob through the catalog loader [02 R-CAT-01 §5].

Historical sources

• FBI File Content Description, TA Design Guide — the variable catalog (originally from the TAORF tutorial): https://units.tauniverse.com/tutorials/tadesign/tadesign/fbidesc.htm

• Verified against units/ARMFLASH.FBI and units/ARMPW.FBI from totala1.hpi, plus a key inventory of every retail FBI (815 unit records; 278 winning files in the default mount) — the table above covers every key that occurs.

• The “which keys the engine reads” section is a whole-string census of TotalA.exe (GOG build, MD5 8e74a1dffa1f5988624c52048f5b20cd). It reports the presence or absence of literal key strings only, which is a fact about the data segment rather than about any code.

• Retail unit accessor/consumer audit: [02 R-KEYS-01 §5], with runtime contracts in the cited categories. Literal-string presence is not the deciding evidence for field semantics.

Pinned research and implementation

This page adapts the owning FBI research at commit 72dcc02. The complete source snapshot preserves the original research, evidence IDs and confidence labels. All illustrative assets on this page are original authored examples; none are extracted retail assets.

Evidence labels distinguish established behavior, bounded observations, supported inferences, unknowns and Nanolathe host policy. A field appearing in an authored file does not by itself establish a runtime consumer.