Model components, landing structures and pointer sharing

Update: animated geometry and linked model states now implements gate/fountain transforms, exports 27 additional linked definitions, and adds state/animation controls. Earlier references below to those models being unresolved describe the previous extraction pass.

2026-09-18. Reproduce with python3 tools/inspect_model_components.py. The machine-readable inventory is components.json. Addresses below refer to the unrelocated executable image or explicitly to a bank's geometry pool.

Screen-space discs

The command is 22 colour:u8 radius_numerator:u16le. In the ordinary projection path, FC22 dispatches to 314D: it subtracts four from the projected-vertex cursor, takes that vertex's screen coordinates, resolves the colour via 3383, and calls A5C0 with the numerator in AX and projected depth in CX. Thus it consumes the last vertex slot, which subsequent vertices may reuse. The native A,B,C coordinates below use the model export's convention (A,-C,B) for Y-up coordinates.

At A5C0, unsigned integer division gives radius_numerator / projected_depth. The result is capped at 256 screen units; zero takes the single-pixel path. The following routine constructs clipped horizontal circle spans. There is no bitmap, UV map or spherical polygon mesh in this command. The near/clipped handler 3161 rejects depths below 32 before projection. Colours go through the same distance/runtime shade machinery as flat faces, then the display lookup. These are internal units, not established metres or an independent world radius.

The tower disc therefore sits at Y=2400 in the exported coordinate system. For illustration, projected depths 1024 and 2048 yield integer screen radii 30 and 15. 1C is a dynamic shade token, not simply a fixed palette index 28. The two discs of types 101–104 are real separate drawing commands.

This inventory covers the statically traversed base definitions, not every alternate/damage model or unresolved animation branch. No discs were encountered in bank 31's traversed definitions. Discs are now shown as camera-facing circles in the model preview (and city viewer), but remain omitted from OBJ surfaces. Their exact definitions and pool offsets are retained in the JSON; see preview scaling.

Other non-polygon components encountered are opcode 1E coloured lines: city types 65 and 67 in bank 30, type 41 in bank 31, and 111 and 112 in bank 32. There are also model-header distant-point representations and conditional visibility branches; these are not additional mesh faces. The static inventory is deliberately not a claim to have exhausted runtime effects or particles.

Fountain reflections: authored geometry, not transparent water

Open the assembled animated fountain. Its twelve components are placed from map 68: two instances each of types 101–104 and one each of 120–123. The authored face/disc order reproduces the tinted reflection over the opaque water; switching off Authored drawing order shows why ordinary polygon depth sorting breaks this effect. Animation starts automatically and the clock can be paused/scrubbed. The view remains orthographic, with approximate between-component sorting and disc sizing.

The facing-test sign was checked against 256 controlled executions of native 2F65: it skips when the screen-space cross product is negative, as used by the viewer. The earlier reflection failure was caused by inspection depth sorting, not an inverted conditional branch. This check covers the sign for supplied projected vertices, not equivalence of every perspective camera pose.

Visual inspection identified the lower discs and pedestal shapes as reflections. The bank-30 type-101 data confirms reflection about the water plane at exported Y=384: the upper light is at Y=608, the lower copy at Y=160, exactly 224 units on either side. Types 102–104 repeat the arrangement in the other quadrants. Both discs use radius numerator 19712, but the upper colour is 1B and the reflected colour is 93, giving the reflection its authored tint.

The lower pedestal includes exact mirrored polygon counterparts: replacing native C with -768-C maps upper faces to lower ones, with different face colours (for example 47 becomes 86, and 70 becomes 8F). These are stored vertices and palette choices, not a runtime reflection transform.

There is no transparent-water material in this model. The ordinary opaque water faces (colour 8B, Y=384) are issued first, followed by the reflected disc and tinted pedestal geometry, then the remaining fountain structure. For type 101, water commands start at pool 9D19, the reflection disc is at 9D45, and reflected pedestal faces follow at 9D49 onward. Stored command order matters more than increasing byte offsets because the model calls shared subroutines. The software renderer has no depth buffer to reject those later reflection pixels for lying below the water plane.

Thus the appearance of seeing through water is an authored reflection illusion: opaque colours and drawing order, not alpha blending. No semitransparent model material has been identified in the decoded retail model command set. Collision overlay translucency belongs solely to the inspection UI. This does not claim that every other screen effect or sprite in the game uses the same mechanism.

Landing gates and animated geometry

HQ gates were proposed for 17,19,21,23 and approach stripes for 18,20,22,24. The executable strongly supports the landing gate/approach identification:

• C598–C5A5 fetches the cell beneath the Caero. During the automated landing state, C5F9 subtracts 17, requires a result below 8, then shifts right. The odd/even branch therefore distinguishes the gate/stripe pairs explicitly.
• C656–C668 advances an animation value by CS:[7A2B] << 6, capped at E800. C631 stores that value at SS:7935. Another branch computes it from approach distance; landing/takeoff state also affects it (C5A7–C5BD).
• Each of gate types 17,19,21,23 contains 32 00, at pool offsets 1408, 168E, 1731, 1D11, respectively. Handler 319E reads the low five cell-state bits, adds the command's parameter byte and indexes words at SS:7935. The 32/35/38 handlers then alter projected geometry using that parameter.
• C670–C6EF checks the landing approach, installs the automated movement callback and toggles state bit 80 on the selected cell and its two neighbours. That bit also selects alternate model definitions, as documented previously.

This is stronger evidence than spatial proximity alone. It does not establish that every occurrence belongs to one of the four specifically named HQs on the paper map. The main-city resource contains nine type-17 and eight type-21 cells, with the corresponding stripe immediately in front of each. Types 19/20 and 23/24 do not occur in that resource. Other mission state may alter the map.

Types 14 and 16 are empty base drawing definitions, not currently undisplayed HQ meshes: both point at pool 0FC9, whose body 5A 52 61 0D emits an origin vertex and returns without polygons. Types 78 and 125 share it. Neither 14 nor 16 occurs in the supplied main-city map. An additional role elsewhere is not excluded.

Types 120–123 use another dynamic transform, 3B 09, at pool offsets BDBB, C037, C197, C2F7. Handler 334A reads the same parameter table and scales projection coefficients. DB1A–DB69 updates six parameters beginning at SS:7947 (index 9), driven by the clock and a sine lookup. This identifies a procedural animation dependency. Subsequent visual inspection identified these as probable fountain effects: their four map cells form the central 2×2 of the fountain, surrounded by pool types 101–104. See the assembled scene and coordinates. The eight animated definitions still need correct transform emulation before claiming complete exports.

Shared pointers versus copies

Within a bank, the repeated entries overwhelmingly are aliases to the exact same drawing stream, not duplicated meshes. The 33 special records use only 23 distinct pointers in bank 30, 9 in bank 31, and 19 in bank 32.

Every group, including the remaining pairs and singletons, is in components.json. The early special objects were identified as ammunition through gameplay; individual weapon names have not yet been assigned from their behaviour records. The apparent repeated tanks can be checked by their numeric slots in this table/inventory without assuming a tank name from silhouette alone.

The executable retains separate 24-byte object definitions at 1926+24*i; the bank loader fills their model pointers. Equal geometry therefore does not imply equal behaviour, weapons, damage or player controls.

Across banks, data lives in separate resource pools: there is no cross-bank pointer sharing in this directory format. Shape comparison, ignoring colour and shade attributes, finds bank-30/31 Skimma geometry identical, bank-30/32 Caero geometry identical, and specials 20 and 21 geometrically identical across all three banks. Their complete colour-bearing exports are not all identical. The underground Skimma has 97 polygon commands versus 99 in banks 30/31. Drawing streams also use relative subroutine calls; their actual targets are listed, rather than treating each directory slot as a self-contained mesh blob.

Follow-up audit: empty Delphi types 14, 16, 78 and 125

These four IDs have identical eight-byte directory records, c9 0f 80 80 00 00 00 00, not merely similar-looking previews. All select pool offset 0FC9 (resource offset 1457). None occurs in the supplied Delphi map, resource 00/68.

The 11-byte header is 00 00 00 00 f0 86 ff 00 00 00 00: both damage and alternate links are zero. The complete drawing body is 5A 52 61 0D, which produces one origin vertex and returns. There are no polygon faces, lines, light discs, transforms or subroutine calls. All 256 possible state-byte values retain that same empty result.

An audit of all 154 unique city headers reachable through the bank's type directory and state links found no incoming damage/alternate links to this definition. None of the 33 special-object pointers aliases it. Decoding city/state and special drawing streams found no calls into it; a broader raw scan also found no relative call/jump candidates into its 15-byte header/body range.

The evidence therefore supports unused empty directory slots in the shipped Delphi base assets, plausibly placeholders left by content development. Their position next to particular building IDs does not establish a hangar, collision trigger or other identity. There is no concealed model or non-polygon visual component to recover from these bytes.

This is not proof that the IDs can never be introduced dynamically: the audit does not yet cover every executable path and mission-script operation. No specific gameplay purpose has been established for them. Likewise, this finding applies to bank 30; the same numeric IDs in other banks are different definitions.

Reproduce with python3 tools/inspect_empty_models.py; results are in empty-model-audit.json.