2DA (2D Array)

2DAs are data tables defining the engine’s core rules and constraints (such as item costs and Force powers, which the engine internally stores as spells.2da). They bridge the gap between human-readable text for modding and fast-loading binaries for the final game.

At a Glance

File Layout (binary V2.b)

Six blocks, none of them located by an offset. Everything is found by parsing sequentially, which is why a malformed block does not produce a wrong lookup so much as a wrong everything after it.

Three delimiting conventions in one file

The header run is terminated by a NUL, the rows are counted by a u32, and the headers and row labels are delimited one by one. See counted, terminated, or neither. Assuming one convention throughout is the single easiest way to misparse this format.

The string-table size field

Important

The size field is skipped by the engine and is still not yours to choose The u16 between the offset table and the strings is read by nothing. The loader steps over it with a +2 and never validates it, which is where the phrase “orphaned size field” comes from, and it is why a file carrying any value at all still loads.

It is not arbitrary in practice. Across every 2DA in chitin.key, the field holds exactly the number of bytes of string table that follow it, without exception, and adding the two bytes for the field itself lands on the end of the file every time.

So the engine’s answer and the writer’s answer differ, which is the general case this manual states elsewhere. Write the remaining byte count. A reader should not depend on it, because nothing makes the engine enforce it, and a tool that trusted it would be trusting a field the game never checks.

The delimiter, and the thirteen twinned tables

Warning

Thirteen tables ship twice, and the two copies use different delimiters The delimiter is a tab: one after each column header, one after each row label. That holds for every 2DA in chitin.key, without exception.

Thirteen of those tables also appear in rims/global.rim, and that copy is byte-identical except that every delimiter tab is a NUL instead. (rims/miniglobal.rim carries the same thirteen in the same form, and is never mounted: the string does not occur in the executable at all.) Established by diffing the two copies of each: the number of differing bytes equals the column count plus the row count exactly, every difference is a 0x09 where the other copy has 0x00, and the offset table and string table are untouched. The two copies are the same length, so the substitution is one byte for one.

The thirteen are appearance, appearancesndset, baseitems, bodybag, doortypes, genericdoors, heads, inventorysnds, placeableobjsnds, placeables, portraits, soundset and traps. Every other 2DA in that archive is byte-identical to its chitin.key copy, tabs included.

The NUL-delimited copy is the one the game reads, so handling both delimiters is required rather than prudent. global.rim is mounted by name, and the key table’s search order puts RIM archives above the base archives with no per-resource-type branching, so a lookup for any of the thirteen finds the rims/ copy first and never reaches chitin.key.

A reader that assumes a tab therefore does not fail on an obscure variant. It fails on the live copy of thirteen of the most-read tables in the game, reading each header run as a single column name. Both forms terminate that run with a NUL, so a reader that scans for the terminator rather than the separator survives either.

Warning

u16 cell offsets cap the string table at 64 KiB Every cell points into the string table with a two-byte offset, so no cell’s text can begin beyond byte 65,535 of that block. Deduplication is what keeps real tables comfortably inside it: repeated strings share one entry, and a 2DA column is usually a handful of distinct values repeated down thousands of rows. A generator that writes each cell’s string separately can overflow a table the game ships without trouble.

The text form (V2.0) carries the same logical table with none of this machinery: no offset matrix and no shared string table, just whitespace-separated cells, with **** standing in for an empty one.

Two ways a text cell comes out blank, and they differ

V2.0 has two conventions that both leave a cell looking empty, and they resolve to different values. Conflating them writes the wrong content into short rows.

An explicit **** becomes the empty string. The row-parsing loop checks each raw token for that literal and stores "" for the cell. This runs unconditionally and consults nothing else.

A row that runs out of tokens gets the table’s default. Where a row carries fewer tab-separated fields than the table has columns, every trailing cell it never supplied is filled with the value from the file’s DEFAULT: block. That is the whole of what DEFAULT: governs.

So **** and a short row are not two spellings of one idea. One says “empty here”, the other says “whatever this table falls back to”.

The DEFAULT: block

It sits on the line after the version, before the column headers, and it is optional. The parser reads that line’s first token, uppercases it, and accepts two spellings: DEFAULT: as a single token, or DEFAULT followed by a separate token beginning with :, which absorbs a stray space before the colon. Either match consumes one further token as the default value.

A line matching neither spelling is not an error. The parser moves straight on to column headers and no default is ever set, which leaves a short row’s trailing cells with nothing to fill them from.

Read from C2DA::Load2DArray at 0x004143b0. Provenance: traced, through the tokenizing path every fresh text-format 2DA takes. A second path through the same function, gated by a flag from the resource helper, skips this logic in favour of an offset scan over an already-processed buffer; what sets that flag was not followed.

Engine Audits & Decompilation

Read from C2DA::Load2DArray at 0x004143b0 in swkotor.exe. Provenance: derived, not attested. The rows below have not been separately re-derived, so they sit on the reverse-engineering queue.

Tip

Orphaned Size Field: In binary row blocks, the engine steps over the 2-byte cell_data_size u16 with a +2 and neither reads nor validates it. That is a statement about the loader only; what a writer should put there is above.