GIT Format (Game Instance Template)

A .git file says where everything in an area is. Creatures, doors, placeables, triggers, sound emitters, stores, encounters, waypoints, item piles and cameras all get their position and orientation here.

If the .are file is the stage, the .git is the blueprint for its actors. It does not describe what a creature is, only where one stands: for the creature itself you want UTC, and the .git entry points at it.

GIT is built on GFF (Generic File Format), the engine’s labelled key/value tree. If you have not read the GFF page, start there.

This page documents GIT’s dual role, the same schema serving a static module’s sparse template-referencing placements and a savegame’s full inline snapshots, and each dispatcher’s absent-field defaults. Evidence is drawn from Ghidra decompilation of swkotor.exe (K1 GOG build), cross-checked against a full K1 install’s vanilla .git corpus and a corpus of real save games. The tables below are lookup surfaces, meant to be searched rather than read start to end.

At a Glance

One schema, two jobs

This is the idea the whole page hangs off, and almost every oddity below is a consequence of it.

A GIT is written twice in a KOTOR install, by two different producers, for two different purposes:

• A module’s static .git places objects sparsely. Each element carries a TemplateResRef naming a blueprint, plus the handful of fields that differ per placement: position, orientation, an id. The engine loads the blueprint and overlays those few fields on top.
• A savegame’s GIT, bundled inside SAVEGAME.sav, stores each object as a full self-contained snapshot, read field by field. No TemplateResRef, no blueprint load. A field missing from one of these resolves to the engine’s hardcoded default, not to a blueprint value.

UseTemplates is the discriminator. A static file sets it to 1; a save omits it entirely, and the loader’s default of 0 selects the snapshot path.

Two things follow. The same reader function often serves both paths, so a field documented as save-only is frequently live on a static placement too. And “absent” means different things on each side: on a static placement it usually means “the blueprint supplies this”, while on a snapshot it means “the engine’s constructor supplies this”.

Static .git files ship inside module archives, one per area, produced by the Aurora toolset. Saved GITs live inside SAVEGAME.sav, one per module the player has visited, written by the engine itself. See the Save Game Deep Dive for how a save bundles them.

One object type is effectively savegame-only. Area-of-effect objects (AreaEffectList) are runtime spell and ability effects with no template at all, so they appear in saved GITs rather than in static module layouts.

Field Schema

The format’s field families, as an orientation before the full list.

Engine Audits & Decompilation

Read from CSWSArea::LoadGIT at 0x0050dd80 in swkotor.exe.

(Provenance: derived, not attested. These rows have not been separately re-derived, so they sit on the reverse-engineering queue. Individual claims say so inline where they rest on less than the rest.)

Reading an area

LoadGIT is a dispatcher. It reads a few root scalars, then hands each object list to its own loader.

The engine validates the weather fields against the .are properties during load.

An absent UseTemplates resolves to 0, the inline branch

SaveGIT never emits this field. It is present in every static .git file from a retail install and absent from every saved GIT struct across a corpus of real saves, so every save relies on the loader’s own default.

LoadGIT passes a literal 0 as the default at the read site itself, not a value carried from a constructed field and not a local seeded earlier. CResGFF::ReadFieldBYTE returns the caller’s default verbatim for an absent, wrongly-typed or otherwise unresolvable field.

That 0 is widened and forwarded into the list loaders that take it: creatures, items, doors, triggers, encounters, waypoints, sounds, placeables, stores and area effects. Properties, maps and placeable cameras do not take it, being always inline.

Every dispatch site branches on == 0, selecting the inline snapshot path, with the else taking the template path. Any nonzero byte takes the template branch, not specifically 1.

The value is not interchangeable. Because the test is == 0 rather than != 1, any nonzero default would have landed on the template branch, and 0 is what this loader uses for every other absent BYTE in the same function.

Each object list has its own struct id

An element’s kind is not carried by a field. It is the GFF struct_id on the element record itself, and each list uses exactly one value, with no list mixing ids and no id shared between lists.

Except where the table says otherwise, each value is the constant that list’s loader tests against, so it says what the engine demands rather than what vanilla happens to write. A trigger’s nested Geometry sub-list is gated the same way, on 3.

The consequence of a wrong id is a silent skip, not a wrong load. Every gated loader has the same shape: compare the element’s id against the constant, and where it differs move to the next index without loading anything. No default, no diagnostic, no failure. The object is simply not in the area, and nothing says why.

A writer that leaves these at a default emits a file the container reads without complaint and the engine does not load as intended. Note that item instances legitimately use 0, so “unset” and “an item” are the same value.

Two nested lists are unchecked, and their writers disagree. LoadEncounterGeometry and LoadEncounterSpawnPoints are reached by two routes, through ReadEncounterFromGff and again through LoadEncounters’ own override branch, and neither route asks an element for its type. Both walk by list position and take every field by label, so it is one reader arrived at twice rather than two to reconcile.

That leaves the id free, and the two writers spend it differently. A module’s static .git puts 1 on every Geometry vertex and 2 on every SpawnPointList entry. A savegame, written by CSWSEncounter::SaveEncounter, puts each element’s own position there instead. Neither is wrong and neither has an effect: an encounter restored from a save keeps its geometry.

LoadPlaceableCameras never reads an element’s struct id either. It walks CameraList by position and takes each field by label, so 14 is what every vanilla file writes and nothing enforces it. Keep writing it, since there is no reason to write anything else. What that loader does check is the list’s total length.

An absent list is a skip, not a clear

Confirmed uniformly across the CSWSArea::Load* dispatchers on this page (LoadCreatures, LoadDoors, LoadPlaceables, LoadTriggers, LoadSounds, LoadWaypoints, LoadStores, LoadItems, LoadEncounters, LoadAreaEffects): each gates its whole per-entry body on the list actually being found. When the list is absent that block never runs, and no call anywhere clears, deallocates or resets the area’s existing object collection first.

LoadPlaceableCameras is the sole exception; see CameraList.

The saved-form fallbacks a corpus actually caught

Across the saved-GIT corpus, every reader fallback fires uniformly except for a small set: the only saved-form paths where a scan caught the absent case in the wild. UseTemplates above is the highest-stakes of them. The rest are traced and settled on their own format pages, listed here so the full set is visible from one place.

Placement fields

Position and orientation are named differently per class

The labels are hardcoded per entity class in swkotor.exe.

On several lists a static element carries two orientation components and a saved one carries three. Across a full install, every Creature List, WaypointList, StoreList and area List element carries XOrientation and YOrientation and none carries ZOrientation; across a corpus of savegames, every element of those same lists carries all three. TriggerList is the exception and carries all three in both. A writer emitting the full vector onto a static placement produces a label no shipped module file has.

Bearing does not mean the same thing for the two classes that use it. A door stores its scalar bearing verbatim, while a placeable derives Bearing from the yaw of its orientation at save time, which is lossy.

Encounter spawn points inside SpawnPointList carry a single-float Orientation per point, distinct from both the Bearing scalar and the orientation vector. Sounds have no orientation at all and use Positional and RandomPosition flags plus RandomRangeX and RandomRangeY instead.

Warning

Orientation normalization Where a normalised orientation vector resolves to all zeroes, as it can in StoreList or AreaEffectList, the engine catches the division and falls back to (0, 1, 0).

ObjectId has one default across every list, static or saved

ObjectId is not read by any per-type field loader (LoadDoor, LoadPlaceable, LoadTrigger, the sound, store, encounter and item loaders, LoadWaypoint). It is read exactly once per element by the area-level list dispatcher, before that dispatcher branches into the static or the full-instance path.

Every one of those dispatchers uses the identical default, 0x7F000000 (OBJECT_INVALID). Since the read happens once, ahead of the branch, and both branches receive the same already-assigned id, there is no static-versus-saved distinction for this field anywhere in the engine.

The field-level default documented for AreaEffectList below is not a special case, it is this general rule. module.ifo’s Mod_Area_list follows it too: its ObjectId read, gated behind the save-game flag, also defaults to 0x7F000000.

Creatures are the exception, and there the field is dead rather than defaulted. CSWSArea::LoadCreatures branches on UseTemplates before touching the field rather than after, and the two branches differ in kind. The save branch reads it like every other type, with CResGFF::ReadFieldDWORD(..., "ObjectId", ..., 0x7F000000), so an absent field genuinely defaults. The static branch issues no ReadField* call against "ObjectId" anywhere: 0x7F000000 reaches the CSWSCreature constructor as a bare literal.

Both branches land on the same number and only one of them is defaulting an absent field. So whatever a static .git creature entry carries there has no effect, the same never-looked-up status as UTC’s Tail and Wings.

On the write side every area-level list writer (CSWSArea::SaveCreatures, SaveDoors, SavePlaceables, SaveTriggers, SaveSounds, SaveStores, SaveItems, SaveWaypoints, SaveEncounters, SaveAreaEffects) adds the list element, writes ObjectId straight off the live object’s id, and only then delegates the rest to the per-type save function. The per-type function never touches the label, just as the per-type loader never reads it.

Creatures are the one list whose two sides disagree. SaveCreatures writes ObjectId with no branch around it, while the static-placement branch of LoadCreatures never looks for it. Nothing the engine writes meets both, since a save carries no UseTemplates and so always takes the branch that does read. The mismatch is there for a hand-authored static .git.

The base-object fields come from one shared read

Commandable is not a per-type field, and neither are its neighbours. CSWSObject::LoadObjectState reads them, and every GIT object loader calls it: creatures, doors, placeables, waypoints, encounters, triggers, stores, items and area effects, along with the path that restores the party. An absent Commandable resolves to a literal 1.

That read happens only on the save-instance branch. It is gated the same way as the effect list and the script variable tables loaded alongside it, so a static placement’s load path never reaches the function. Which is why a module’s .git carries none of these labels and a savegame carries all of them: CSWSObject::SaveObjectState writes them unconditionally whenever anything is saved, and nothing on the static side ever looks.

LoadSounds is the exception. It is the only dispatcher that never calls LoadObjectState, so a sound object’s base state is not read back on either branch. Why it differs has not been traced.

Fields that look like overrides and are not

Three labels on a placed instance invite the same wrong assumption, that the value there overrides the blueprint’s. Only one of them does.

Appearance is a real override on doors and placeables

Both CSWSDoor::LoadDoor and CSWSPlaceable::LoadPlaceable read a field literally named Appearance as a DWORD and truncate it to a single byte, the same truncation already documented for the .utd and .utp blueprint reads.

For doors the resolved byte immediately keys doortypes.2da’s Model and VisibleModel columns to pick the door’s mesh, so this is a genuine “which visual model represents this object” field. It defaults to 0 when absent: a hardcoded literal on the placeable path, the door struct’s own zero-initialized member on the door path.

LoadDoor and LoadPlaceable are the same shared readers regardless of which path calls them. So a sparse, template-referencing door or placeable placement carrying its own Appearance has that value read as an override on top of the blueprint’s. Appearance is live on the static form, not exclusive to the snapshot form, even though a static placement only sparsely carries Bearing, position and ObjectId by convention.

Compare UTE’s Appearance, which shares the label and is never read at all. A placed WaypointList[].Appearance follows UTE’s dead pattern rather than this one: LoadWaypoint’s fully decompiled field list has no room for it, confirmed directly (see UTW). A waypoint has no rendered model to select, so that is the expected outcome rather than a surprising one.

Description is toolset residue

Description is a real blueprint-level field on both UTD and UTP, which the area loader never reads out of a placed instance’s own GIT entry.

Traced through CSWSDoor::LoadDoorExternal and CSWSArea::LoadPlaceables. The GIT-instance path resolves Description, and every other non-instance field, from the referenced blueprint through LoadFromTemplate, and the four-field door overlay (see UTD) does not include it.

So a Description in a GIT door or placeable entry is written by the toolset and never consulted, consistent with the corpus finding that almost every file carries the field and only one holds a non-empty value.

It is not area-level metadata either: CSWSArea::LoadProperties, which reads the GIT’s own AreaProperties, has no Description field at all.

This was confirmed for door and placeable entries specifically. Creature, item, store, trigger, encounter, sound and camera entries were not individually checked, so treat the same conclusion as likely but unproven for those. Waypoints are a related but distinct case: a placed waypoint’s Description is not residue with a source that goes unread, it has no source at all, because waypoints never resolve a TemplateResRef (see UTW).

The blueprint’s Tag always wins

UTD documents that a templated door’s Tag comes from its .utd blueprint with no per-instance overlay, so two doors sharing one blueprint share one tag. That is general engine behaviour rather than a door-specific gap.

Confirmed directly for placeable, trigger, sound, store and encounter, and for creature and item as time allowed:

• Placeable, sound, encounter, creature, item. The shared field-reading routine (LoadPlaceable, CSWSSoundObject::Load, ReadEncounterFromGff, the LoadCreature/LoadFromTemplate pair via ReadStatsFromGff, LoadDataFromGff) reads Tag unconditionally from whichever struct it is handed: the placed instance’s own struct on a direct load, the blueprint’s top-level struct on a template load. The area-level dispatcher’s post-template overlay, where one exists at all, only ever covers position, orientation and geometry.
• Trigger. Same pattern. CSWSArea::LoadTriggers overlays TransitionDestination, LinkedTo, LinkedToModule and LinkedToFlags plus position and geometry back from the GIT instance after a template load, and Tag is conspicuously not among them.
• Store. Uses ResRef rather than TemplateResRef for templating, but does carry a genuine separate Tag, read unconditionally by LoadStore the same way. LoadStores’ post-template overlay covers only orientation and position.

The dead copy is not a rarity a reader can dismiss: every door placement in a full install carries a Tag holding a real, non-empty value. It is a field the toolset writes on every placement and the engine reads on none of them, which is what makes it a trap rather than clutter.

Keep writing it anyway. A placement’s own Tag is dead exactly when the placement is templated and live when it is not, so this is a conditional rather than a field a writer may drop. Even where it is dead it is the only per-placement identifier anything outside the engine has, which is why fields the engine never reads records it as the highest-cost drop on that page.

There is no engine-side protection anywhere against two placements sharing one blueprint ending up with the same Tag, for any templated object type. Vanilla avoids the collision purely by authoring convention, effectively one blueprint per placed instance. A lint rule for this should be written generically across every templating GIT object type rather than scoped to doors.

AreaProperties.EnvAudio has no consumer at all

The GIT’s AreaProperties struct carries an EnvAudio INT in most vanilla files, and it is a different field from ARE’s per-room EnvAudio: same name, different struct, no engine consumer.

Neither CSWSArea::LoadProperties, which reads AreaProperties, nor its ambient-sound delegate CSWSAmbientSound::Load, which reads MusicDelay, MusicDay, MusicNight, MusicBattle, AmbientSndDay, AmbientSndNight, AmbientSndDayVol and AmbientSndNitVol off that same struct, reads a field by that name.

A binary-wide check rules out a missed function. The "EnvAudio" string exists exactly once in the executable, with exactly one cross-reference, and that reference is the ARE per-room reader.

It is plausibly a toolset habit, the area’s default or primary room EnvAudio duplicated onto AreaProperties by the editor UI and never kept in sync, but that is the strongest claim the evidence supports rather than a confirmed mechanism. There is no absent-field default to report, since nothing looks for the field.

Per-list findings

An encounter reads its whole field set either way

CSWSArea::LoadEncounters branches on UseTemplates the way the other dispatchers do, into either CSWSEncounter::LoadEncounter or LoadFromTemplate. Both arms then call ReadEncounterFromGff, the function that actually reads an element, and it reads the same fields whichever one called it. Those are its only two callers, neither narrows the field list, and no branch inside it skips anything.

That field list runs well past the placement set. Alongside TemplateResRef, position, orientation, Geometry and SpawnPointList, one pass also reads the activation and difficulty scalars, LocalizedName and Tag, a CreatureList whose elements carry a resref, a CR and a single-spawn flag, and a long run of session state: spawn counts, heartbeat and last-spawn timestamps, entered and left markers, started and exhausted flags, an AreaList and a SpawnList. The generated table names each one.

So the difference between a module’s encounter and a save’s is not which code runs over it. It is which labels the file carries. A static .git never has the session-state labels written into it, so each takes its absent-field default silently. A save’s GIT has them because the engine’s own writer put them there, and they load back as live state.

Area-of-effect objects

AreaEffectList holds runtime spell and ability effect objects (CSWSAreaOfEffectObject). These have no blueprint file: no loader anywhere in the binary opens a template for one, so every field is read straight off the GIT struct. Elements must carry struct id 13 or the loader skips them.

Note

Write-only script fields, confirmed dead on restore. OnHeartbeat, OnUserDefined, OnObjEnter and OnObjExit are written by the save writer and never read back by any loader in the binary. A restored area-of-effect object never fires these events again, and nothing re-derives them from AreaEffectId or SpellId on the load path.

That 2DA-driven derivation does exist (vfx_persistent.2da, keyed by AreaEffectId, supplying OnHeartbeat, OnObjEnter and OnObjExit script resrefs plus shape and size defaults), but it is wired exclusively into the fresh spell-cast creation path. The GIT loader has no equivalent step. OnUserDefined goes further: it is never populated by any path, fresh creation included, so it is dead in this engine build regardless.

A restored effect does not go inert. Duration countdown, position tracking and collision-based area membership all keep working after a reload, since those run off the object’s own stored data rather than off scripts. It is specifically the scripted event hooks that go silent.

AreaProperties

Tracks stealth behaviour state and dynamic audio state. It reads AmbientSndDayVol and AmbientSndNitVol and truncates their INT declarations into a single runtime byte.

The loader and the save writer disagree on where several fields live. The writer nests RestrictMode, StealthXPMax, StealthXPCurrent, StealthXPLoss, StealthXPEnabled and SunFogColor inside the AreaProperties struct, but the reader pulls those from the GIT’s top level instead. Only Unescapable is genuinely read from inside AreaProperties.

Those fields are permanently dead in every save this engine’s own writer produces. They are always written to a location the reader never checks, so they always resolve to whatever value the object already held in memory.

TransPending, TransPendNextID and TransPendCurrID are written in both places, the GIT top level and a redundant copy inside AreaProperties, but only the top-level copy is consulted, so the AreaProperties copy is a harmless duplicate. This is grounded in decompiled code with reasonably high confidence, though inferred from variable-usage patterns rather than a byte-level disassembly proof.

The ambient-sound fields read by CSWSAmbientSound::Load each carry over their constructor’s pre-armed value when absent. This is a genuine carry-over with no divergence between the constructed value and the read’s own fallback, unlike the constructor-versus-literal mismatches found elsewhere in these audits.

CameraList

Modelled as GitCamera entries, read by LoadPlaceableCameras. Position defaults to the literal zero vector (0, 0, 0) and Orientation to the literal identity quaternion (w=1, x=0, y=0, z=0; see Vector4’s on-disk component order for which array slot w occupies), both unconditional. The read helpers always populate the field from either the GFF data or the supplied default, and the loader never branches on which one it got.

An absent field does not drop the camera entry. It is always kept and registered, each field defaulting independently at its own read site with no carry-over and no derivation from a sibling.

CameraID and FieldOfView are confirmed directly against the read call. An entry left at CameraID = -1 is not treated as a sentinel by any comparison. It is simply unreachable by the script-side camera-id lookup, which matches only real positive ids.

The 51-entry cap costs the whole list, not the entries past it. The count is checked once before anything is read, and a list of 51 or more makes the function return having loaded nothing. So an area with 51 cameras has none rather than fifty. It is the only whole-list validation among the placement loaders; every other one gates per element and lets the rest through.

Warning

LoadPlaceableCameras resets state on an absent list where every other dispatcher skips. The others gate their whole per-entry body on the list being found, so an absent list is a no-op. Confirmed independently for each.

LoadPlaceableCameras never checks that flag. It passes the resolved entry count, 0 when CameraList is absent, into CGuiInGame::InitializePlaceableCameras, which overwrites the client-side camera counter unconditionally on every call.

The blast radius is narrow. That counter is transient session-scoped UI state on the CGuiInGame singleton rather than a persistent per-object list, and no per-camera data is touched, since the per-entry SetPlaceableCamera calls do not run at a count of 0.

The mechanism is still different from every other loader here, which matters if you are reasoning about what an absent list means across GIT generally. It is not uniform.

A placed store’s inventory

This reduces to the blueprint case by identity rather than analogy. StoreList’s per-instance field reader is CSWSStore::LoadStore, the same function UTM’s own load path confirms treats an absent ItemList as a pure skip. There is no separate GIT-side ItemList read or clear layered on top for a placed store instance.

The AreaMap exploration bitmap

The minimap’s explored-so-far state, bypassed entirely on a fresh load and read only from a save. It is the one struct here a save editor has to author rather than carry across, so the layout is given in full.

The measurements below come from the AreaMap structs in a save corpus of the committed fixture folders plus a local backup set, read with a GFF navigator written for the purpose. The install is modded, so nothing here describes BioWare’s own content, but every result is structural or arithmetic and transfers regardless.

Size

AreaMapDataSize carries no information the other two fields do not:

size_in_bytes = 4 * ceil( (ResX + 1) * (ResY + 1) / 32 )

That reproduces the declared size in every instance across every resolution pair present, and the declared size equals the blob’s actual length in each one.

The nearest alternative formulas were run on the same data as controls. Of the ten distinct resolution pairs, they matched five, three, one and one respectively, against this formula’s ten. So it is not a formula that fits because many would.

Grid

The cells are (ResX + 1) by (ResY + 1), one bit each. The two fields are not the cell counts, and a reader sizing from ResX * ResY is short by a full row and a full column and mis-indexes everything after the first row.

Three independent things say so: the size formula above; the fact that many partly-explored blobs carry set bits past index ResX * ResY while none carries one past (ResX+1) * (ResY+1); and the degenerate 1x1 areas, where four declared cells sit in thirty-two bits of storage and every non-saturated value puts all its set bits inside the low four positions.

Bit order and axis

Bit n is blob[n >> 3] >> (n & 7) & 1, and cell (col, row) is bit row * (ResX + 1) + col. Byte-sequential, least significant bit first, row-major.

That is settled by geometry rather than by arithmetic. Reshaping a partly-explored map row-major produces a single connected region, a corridor opening into a chamber; column-major produces noise with no connected structure. The strongest single case is a one-bit difference between two consecutive saves of the same area, which lands exactly on the ragged edge of the already-explored region and fills a one-cell notch. Under any other reading that bit falls in open space away from the frontier. Most-significant-bit-first was tested and is worse rather than better, pushing more blobs past the cell count.

Growth

Exploration is append-only. No consecutive pair of saves in the same area anywhere in the corpus loses a set bit, and the pairs that differ at all only ever gain them.

Note

Bits past the last cell are saturation, not layout The padding at the end of the allocation is the thing most likely to make a reader doubt the layout above. Some blobs do carry a set bit at or past the cell count. Every one of those is fully saturated, every bit in the allocation set, padding included, and no blob that is not saturated carries a single bit out there.

So a fully explored map is written as an all-ones fill across the whole allocation, which necessarily runs past the last cell. Nothing sits selectively in the padding.

A reader should mask to (ResX+1) * (ResY+1) and ignore the tail. A writer filling a map may set the padding or not; the engine’s own output sets it.

How rakata models the two forms

Each dispatching list is a GitObjects<Static, Saved>: Static for UseTemplates = 1 placements, Saved for UseTemplates = 0 snapshots. The flag is not kept as a separate field on Git, because the enum already records the choice and storing both would let them disagree.

Three lists sit outside that shape:

• WaypointList is a plain Vec<GitWaypoint>, because LoadWaypoints ignores the flag entirely and there is only ever one form to read.
• AreaEffectList is a plain Vec<GitAreaEffect>, because these objects have no blueprint, so the saved form is the only form.
• Encounter List is a plain Vec<GitEncounter>, because the loader reads the same field set on both sides of the flag, so there are not two forms to tell apart. Its session state is declared and not modelled: the schema names those labels so a file carrying them does not read as unrecognised, and stops there, since the committed fixture saves hold no encounter for a model of the fields to check against.

Saved snapshots are checked against the fixture save corpus rather than synthetic fixtures. Every object of every modelled type is parsed, written back, and compared field by field against what the engine originally wrote. AreaEffectList is the exception, since no fixture save has one; its field set comes from the load and save behaviour documented above, and a test asserts the list is still empty so a corpus that grows one does not go unchecked.

Implemented Linter Rules (Rakata-Lint)

Intra-resource rules needing no context, under rakata_lint::rules::git:

Resource-existence rules requiring a LintContext, under rakata_lint::rules::git_range:

GIT-006 covers Creature List[].TemplateResRef (.utc), List[].TemplateResRef (.uti), Door List[].TemplateResRef (.utd), Placeable List[].TemplateResRef (.utp), SoundList[].TemplateResRef (.uts), TriggerList[].TemplateResRef (.utt), StoreList[].ResRef (.utm) and Encounter List[].TemplateResRef (.ute).

Waypoints have no template at all, since LoadWaypoint never reads a field of that name under any circumstance. Doors do: a static door placement resolves TemplateResRef against a .utd exactly as a creature or placeable does (see UTD), so GitDoor carries the field and the rule checks it.

Trigger LinkedToModule is deferred. The rule looks only at the static form of each list, since a UseTemplates = 0 snapshot has no resref to resolve.

Open questions

• The AreaMap origin corner. Which corner of the in-game minimap holds bit 0, and whether the row index grows toward the top or the bottom of the player’s map. Everything measured above is invariant under reflection in either axis, so the saves cannot tell the four possibilities apart however many are read. That bounds what this corpus can settle; it does not bound the question. Tracked on #85.

  Two routes outside the bitmaps bear on it and neither has been tried. The game’s own minimap art ships in the GUI texture pack, swpc_tex_gui.erf, as one lbl_map<area> texture per area, so a rendered blob can be laid against the picture the player sees. And the area’s own Map sub-struct carries NorthAxis, MapPt1X/MapPt2X, WorldPt1X/WorldPt2X and MapResX, which between them are the world-to-map transform this question is asking about. The art is not indexed by chitin.key, so searching the KEY file and the module archives comes back empty and reads as an absence; the texture packs are the family that search walks past.

  A save pair closes it outright if those routes fall short. Load an area with a large, mostly unexplored map and save. Walk into one identifiable region only, something describable as “the corridor along the west wall”, without fighting or looting. Save to a different slot. Diff the two, reshape the newly set bits row-major, and compare where the patch sits against where the region appeared on the minimap. That fixes the origin and both axis directions at once, and a second pair is needed only if the first region turns out symmetric in one axis.

  What a tool can already do without it: author a map rather than merely preserve one. Size it, set arbitrary cells, and produce a blob the engine accepts and renders as a coherent region. What it cannot guarantee is that the region lands where the author intended rather than mirrored, flipped, or both. For “reveal the whole map”, the common editor feature, the origin does not matter at all, since saturation is what the engine itself writes and the corpus confirms it round-trips.

• Why LoadSounds never calls LoadObjectState. It is the only dispatcher that skips the shared base-object read, so a sound’s Commandable and its neighbours are not restored on either branch. The behaviour is confirmed; the reason is not traced.

• Description on the unchecked list types. Confirmed toolset residue for doors and placeables. Creature, item, store, trigger, encounter, sound and camera entries were not individually checked.

• AreaProperties field placement rests on variable-usage patterns. The loader-versus-writer disagreement is grounded in decompiled code with reasonably high confidence, but inferred rather than proven at byte level.

Every label the schema declares

Generated from the schema, so no label can be quietly left out. How to read these tables.

What the engine does with each field

Fields nobody has examined

Whether the engine reads these has not been established, which is not the same as establishing that it does not. Where When absent carries an answer, that half is settled.