txte: localized text tables

Source

docs/formats/txte.md

SHA-256

33c1e1b7…c5120a72

The game's text format. Each txte text table is a 16-byte header, then 32-byte rows, then a pool of strings. A row pairs a text key, such as ARMSTEXT_LC_ARMS_001_NAME, with its text in one language. The keys are the strings that other files point to, for example xlce string pools (xlce.md). In localize/LocalizeText_<lang>.dat, the payload is a pakd (containers.md) of txte tables.

Header

Row

Every field is a str_ofs64: an offset from the start of the table (the txte magic) to a NUL-terminated string in the pool. Gibbed reads each as a u32 offset followed by a u32 that must be zero, which is the same bytes.

• confirmed: the upper 4 bytes of every offset are zero. Source: the round trip (the encoder writes each offset as a u64 and gives back every table). Gibbed EventTextFile agrees (fails if Unknown04, Unknown0C, Unknown14 or Unknown1C isn't zero).

String pool

• confirmed: the pool starts right after the last row, at 16 + row_count × 32. Source: the round trip (the encoder starts it there, 576/576).
• confirmed: strings are stored in row order, and within a row in field order (key, text, unk_0x10, unk_0x18), each followed by one NUL. No string is shared, empty ones included: every offset points just past the previous string's NUL, except after some text strings that are followed by two NULs (German #67 rows 620 and 680; Spanish #65 row 568, #66 rows 1732, 1734 and 1736, #67 rows 620, 680, 735 and 789, #68 row 500; all SCENARIO_ dialogue). The text form shows such an extra NUL as {nul} at the end of the string (Text encoding). Source: the round trip, all 8 languages (the encoder writes them so, 576/576 tables); DuckDB over the text forms for the {nul} rows (R36, see Method).

Padding

• confirmed: after the pool, the table is zero-padded to align16(data_size + 1), the same rule as xlce padding. Source: the round trip (576/576).

Text encoding

text is UTF-8 with escapes mixed in. Each escape starts with a Unicode private-use code point. All rows are likely: the eight languages' text uses every escape and icon below and every code whose row doesn't say no text uses it, and decodes with them with no problem reported (no unknown code, no unlisted private-use code point, no invalid UTF-8) and rebuilds byte for byte, but a round trip would also pass with some wrong code sizes, since the text form keeps every byte either way. No text uses U+F8FC or U+F8FE.

• likely: Gibbed reads U+F8FC as a variable-length span, with its own nested text. This doc reads it as a header the game skips (Escapes and control codes) and doesn't decode it; the decoder shows it as {U+F8FC} and reports it. Source: Gibbed RebornDecoder (Span), BaseDecoder.
• likely: Gibbed treats the private-use ranges U+E000–U+F8FB, U+F0000–U+FFFFD and U+100000–U+10FFFD as icon glyphs (its word is "gaiji"). Source: Gibbed RebornDecoder.

In the file pages and the decoded data (../../toolchain/README.md#decoded-data), control codes and icons are shown as {name}, or {name args} with the argument bytes in hex: How {wrap 01 01}could (an illustration). This text form is what the encoder reads back to bytes, so every byte string has exactly one text form:

Everything else is the character itself, in UTF-8. A string can't contain NUL.

Control codes

Size counts the code byte and its arguments, not the U+F8FF before it. The sizes are the 54 bytes of control_code_sizes in Font/FontAllFilePackage.dat (font.md), one per code from 0x80 to 0xB5, which is the shape of the size table the drawing routines skip codes by (Escapes and control codes); Gibbed's MacroCodeHelpers.GetSize gives the same sizes for 0x80–0xB3. Only the codes below are decoded; an unlisted code stops the decoder, which reports it and keeps the rest of the string as {?? hex}. Names and meanings are from the drawing routines (0x1402a4a00 and the others in Escapes and control codes), the game's keys and the decoded text; codes the drawing routines hand to a virtual function (0x93–0x96, 0xA9 and others) rest on keys and data only. text_formatting.md describes the PSP game, where codes start with byte FF instead of U+F8FF. Which languages use a code is from DuckDB over the text forms of the eight LocalizeText_<lang>.dat (R36, see Method); a code with no use says so.

Icons

How the game reads it

From text/textmanager.cpp and the font renderer (BaseFontRenderer, graphics/font/basefontrenderer.cpp), by static analysis with Ghidra 12.1.4 of the unpacked executable (SHA-256 7b0230a1…), so at most likely.

Loading and lookup

• likely: the game loads one language's text: group 4000, file ID = the game's language (0–7; 1 when the language is 8 or more), unwrapped (RotXor obfuscation, then ZIP; containers.md). Group 4000 is probably localize/, whose eight LocalizeText_<lang>.dat files match the eight languages. Source: 0x1402b9bf0, 0x1402ba8d0 → 0x1402b94a0 (FileTable_OpenById(4000, language)); language from 0x14026ca60.
• likely: it takes every pakd entry whose first 3 bytes are txt, without checking the 4th, which fits the magic being txt plus a version byte. For each row it turns all four fields (key, text, unk_0x10, unk_0x18) into pointers by adding the table's address, and indexes the rows by key (FNV-1a 64-bit hashes), and by text too for entries 0, 1 and 18–23 (the list at 0x14067DE28). Source: 0x1402ba410 (strncmp(entry, "txt", 3); header row_count, row_offset, row_size as in xlce); 0x1402b9cd0 undoes it on unload.
• likely: looking a key up returns that row's text. When the key isn't found, it returns the key itself (or nothing, when the caller asks). Nothing read so far uses unk_0x10 or unk_0x18. Source: 0x1402b95d0.
• likely: before the lookup, a key can be swapped for another: system/system_data.dat entry #9 is a table of rows of four strings (a key and three replacements), and when a game setting (at 0x140CDE96C, read by 0x14026ca70) is 1, 2 or 3, a key found in that table is replaced by its replacement 1, 2 or 3. What the setting is: a lead. Source: 0x1402b95d0; 0x1402bd9a0 (system/systemdata.cpp, which sets 0x140CE4DB8 from header offset 0x2C, entry #9).

How a table's ID becomes text

• confirmed: an ID like arms_data's name_id is a row index into battle_data_release.dat#35 (text_keys), often plus a first row for its kind of record; the game takes that row's string at 0x08 as the key for a name, or at 0x10 for its help, and looks it up as above. Each field that holds such an ID links text_keys with Text: and shows its English text in the decoded data. Source: the decode (R24): every value of the 11 linked fields picks a key of its own table's prefix, or an empty key on a row with no text (DuckDB, 2026-10-12, in each field's Source); 0x1402d36d0 (arms_data name_id at 0x86 → text_keys field 0x08), 0x1402d3630 (help_id at 0x62 → field 0x10); other accessors read fixed text_keys rows from 3,672 (0xE58) on (0x1402d3800, 0x1402d3830) (How the game loads it).

Escapes and control codes

• likely: a string that starts with U+F8FC begins with a header the game skips, both before a lookup and before drawing: after the code point, a byte with bit 0 clear means 5 bytes in all; with bit 0 set, 5 bytes, then 6-byte groups while the next group's first byte has bit 0 set, then one more 6-byte group. Source: 0x1402b95d0, 0x1402b99d0, and the drawing routines 0x1402a4a00, 0x1402a5fe0, 0x1402a7610, 0x1402a8c30, 0x1402aa8d0.
• likely: U+F8FD and U+F8FE are each followed by one byte b, and insert a stored string: number b − 1 for U+F8FD, b + 253 for U+F8FE. Source: the same drawing routines (0x14029b720 returns the string, through an indirect call at DAT_140ce3870).
• likely: the drawing routines handle control codes 0x80–0x89, 0x8C, 0x8D, 0x9B, 0x9D–0x9F, 0xAA, 0xB0–0xB3 themselves, and hand every other code to a virtual function; 0x93 hero_name, 0x94 order_name and the 0x95/0x96 span are among those. They skip a code by a size looked up in a table, at code − 0x80, that the renderer holds (offset 0xB0 of the object at 0x140CE3958), not by sizes written in the code; where that table comes from is a lead. Source: the drawing routines above (the switch on the code byte, default: → (*renderer->vtable[1])).
• likely: what some codes do: 0x80 breaks the line; 0x81 is a wrap point, its first argument × 2 being the width; 0x83 inserts string parameter arg1 − 1; 0x84 inserts number parameter arg1 − 1; 0x86 stops drawing there, as a page break would, and 0x89 does too once its countdown runs out; 0x88 moves the pen by a signed pixel count; 0x82 sets a color from three bytes (each minus 1) and an alpha; 0x87 and 0xAA switch between two styles by their argument; 0x9D sets and 0x9E resets a value; 0x9F uppercases the next character; 0xB2 and 0xB3 draw an image (0xB3 a button). Source: the same drawing routines.

Rebuilding

How a table is rebuilt from its rows in the text form. All steps are confirmed for the eight languages: the encoder follows them with no byte taken from the original, and gives back all 576 tables byte for byte (the round trip, see Method). Step 5 recomputes every zombie_condition length to the original bytes, and step 7 writes back every extra NUL.

1. Header: magic txte, row_count = the number of rows, row_offset 16, row_size 32 (Header).
2. Rows: in their original order, each field an offset (upper 4 bytes zero) to its string (Row).
3. String pool: right after the last row; each row's strings in field order (key, text, unk_0x10, unk_0x18), each encoded from the text form and followed by one NUL. No string is shared, so every offset is recomputed from the lengths (String pool).
4. Padding: zeros up to align16(data_size + 1), where data_size is the end of the pool (Padding).
5. zombie_condition's length bytes are recomputed for each 0x95 from its matching 0x96 (paired like brackets), so edits inside the span stay valid: with L as in Control codes, a = L div 255 + 1 and b = L mod 255 + 1, so neither byte is ever 0 (a NUL would end the string); L must be below 255 × 255. A 0x95 with no 0x96 keeps the bytes given. Every span in the eight languages is written so (one French span has a = 2). Source for the length: Gibbed BaseDecoder; for the bytes, the round trip and DuckDB over the text forms (R36, see Method).
6. unk_0x10 and unk_0x18 are kept as given; their meaning is unknown.
7. A {nul} at the end of a string writes one more NUL after it (String pool).

Leads

• What unk_0x10 and unk_0x18 hold (unk_0x10 is M or F on German, Spanish and French unit names; unk_0x18 is X in every row of table #0 only): the lookup never returns them (How the game reads it), so look for other readers of the row, such as the code that builds random unit names.
• How the renderer gets its code-size table (offset 0xB0 of the object at 0x140CE3958): its values are FontAllFilePackage.dat's chunk 10, but the code read so far frees that file unread (font.md), and no write to the field but the constructor's zero was found.
• Why some SCENARIO_ texts in German and Spanish end in an extra NUL (an editing tool's leftover, probably); the game never sees it.
• What the French-only codes 0xAB–0xAF, 0xB4 and 0xB5 do, and what icon_unk_100001 shows.
• Where the control-code size table the renderer uses comes from (offset 0xB0 of the renderer at 0x140CE3958), and what the key-swap setting at 0x140CDE96C is.
• What the arguments of each control code mean, and what the unk_ codes do. An in-game test settles most of them.
• Codes the virtual function handles (0x93–0x96, 0xA9 and others; default: → renderer->vtable[1]) weren't read, so hero_name, order_name and zombie_condition rest on game keys, strings and data; new_page has only Gibbed's guess. The icons enemy, leader and guest rest on the briefings' layout; no code maps their code points.
• Gibbed reads U+F8FC as a span; no text uses it.
• Txte.cs doesn't decode U+F8FE (it would show as {U+F8FE} and its byte as text, still lossless); no text uses it.
• Whether a string can carry an extra NUL, which step 3 of Rebuilding doesn't allow for.
• The magic may be txt plus a version byte e, as xlce is xlc plus 101: the game checks only txt (How the game reads it).
• txte tables in other files.
• legacy/formats/txte.md (../../legacy/formats/txte.md) has earlier observations to recheck (reference only).