ARC: the engine's named archive (bl::archive)

Source

docs/formats/arc.md

SHA-256

a16150f3…52676d08

The Blade engine's archive: a header, an offset table, a list of named, typed records, and the data blocks they point to. It holds the menu layouts and their textures (menu/), the text presets and the font set, every menu texture pack, the shader package (Shaders/Shader.dat) and the one world-map model (worldmap/Worldmap.dat#28, behind a BMAR104 prefix). An ARC sits whole in a pakd entry or a ZIP member (containers.md), and a data block can hold another ARC, nested up to four deep. Textures inside are btx (another doc); layouts, presets and models are only named here (Leads).

Where it appears

confirmed: these are the only ARCs in the 10,016 unwrapped files, and no other blob has the 6-byte signature ARC\0 00 01 anywhere inside it except Worldmap.dat#28 at +8. Source: arcrebuild.cs over Data/, all files.

Header

Offsets are from the start of the ARC.

Byte-swapped ARCs (Gibbed reads CRA\0 as big-endian) don't occur, and this executable's walkers have no byte-swap path for them. Source: C# scan; 0x14005bfa0.

Records

One per data block, back to back from align32(0x30 + 4 × offset_count). Each is align32(0x14 + filename_length) bytes, and the game steps to the next one as (filename_length + 0x33) & ~0x1F. The game's own word for a record's name is "filename" (classes Traverser_filename, Traverser_type_filename). Offsets are from the start of the record.

Filename hash

h = 0; for each byte c of the filename: h = h × 33 + c (32-bit); hash = h + (h >> 5). Source: 0x14008b740 (hashes fontset), 0x1400bc530, 0x1400640b0, 0x140073d70; confirmed against every record's filename_hash (C# scan).

Data blocks

Each offsets entry points to a block: an 8-byte header, zeros, then the content. Offsets are from the start of the block.

Layout rules

arcrebuild.cs writes each ARC from its parsed fields with these rules, nested ARCs first, and the result is confirmed byte-identical for all 220 top-level ARCs (474 in all, every nested one included), with the zero padding as described:

1. Header (0x30 bytes), offsets, zeros to a multiple of 32.
2. The records in order, each padded to a multiple of 32, with filename_hash and filename_length computed from the name.
3. The data blocks in offsets order (the same as record order). Each starts at the end of the previous content (for the first, the end of the records) rounded up to the block's alignment, measured from the ARC's start.
4. The ARC ends at the last content's end rounded up to the largest alignment among its blocks (32 when it has none: the empty common_x4.pac is 0x40 bytes). A nested ARC's block size is this padded length.
5. Outside: a pakd entry holding an ARC adds its usual 16 zero bytes, and the BMAR104\0 prefix 8 (containers.md).

likely: the game needs only rules 1–3's offsets to be right, not the padding: it reads offsets, filename_length and each block's alignment, never an ARC's length. Alignment above 16 is relative to the ARC's start, and a pakd entry is only 16-aligned (menu_layout.dat's first entry is at 0x130), so nothing in memory relies on more. Source: How the game reads it.

Record types

cmp\0 content (compressed, below) never occurs. Source for every "content" claim: arcrebuild.cs, all files.

How the game reads it

Static analysis only, so every fact is at most likely; functions are in the names list.

• likely: every ARC is read in place from the buffer it was loaded in; nothing is copied or relocated. A reader checks magic and version, takes the records from align32(0x30 + 4 × offset_count), steps through record_count of them by filename_length, and for a match returns the block's content (ARC + offsets[offset_index] + align(8, alignment)), its size, its ID, its name and unk_0x06. Source: 0x14005bfa0, with 0x14005c0c0 (magic and version) and 0x14005bf30 (record_count).

• likely: a record is found by a "traverser" that tests each record in order and stops at the first match:

  Traverser	Matches	Source
  type + ID	type, unk_0x0C, and the ID (id_u32 when uses_id_u32, else id_u16)	0x14005bc00
  type + index	type and unk_0x0C; the n-th such record	0x14005bef0 (counting: 0x14005bed0)
  name	unk_0x0C; with the exact flag also filename_hash; then the first two characters; then, with the exact flag, the whole name, and without it the name up to its extension (.), so fontset would also find fontset.lpj	0x14005bc30
  type + name	type, then as name	0x14005bd70

• likely: no reader checks record_count against offset_count, an offset or size against the buffer, archive_name, the padding, or unk_0x0A, unk_0x0C, unk_0x0F, unk_0x07. A wrong offset or filename_length reads out of bounds. Source: the functions above.

• likely: a block whose content starts cmp\0 is decompressed before use when a caller asks for it (Compressed content). Source: 0x14005c210, 0x14005c0f0, 0x1400b1240.

The menu files

• likely: at startup 0x140271250 loads, all through FileTable_OpenById (group 500) and unwrap kind 1, every entry of each pakd, the entry's length taken as the next offset minus its own: the text presets 0x2815–0x2816 (menu/text/), the font set 0x2817 (looked up by name fontset, exact, through 0x14008b740), the texture packs 0x2814, 0x2818–0x2829 and the language folders' 0x282A + language, 0x2832 + … etc. (0x140272450, each entry to the common-texture list), menu_parts.dat 0x2811 (each entry's lyt record registered by name, 0x14008ad70, which returns after the first lyt record it finds), menu_layout.dat 0x2802 (0x1402725d0) and tex_common_x4.dat 0x2813. Source: decompiled 0x140271250; file IDs from FileTable.bin (filetable.md).
• likely: menu_layout.dat's entries 0–18 are taken by position as the 19 layouts the game names in its table at 0x140c98fd0: mn_common, mn_commonwin, mn_itemicon, mn_event, mn_bt_main, mn_status, mn_organize, mn_at_organize, mn_shop2, mn_warrenreport, mn_datainstall, mn_title, mn_option, mn_input, mn_world, mn_bt_result, mn_network, mn_birthday, mn_key_layout. Each later entry is named by its archive's first lyt record. confirmed: entries 0–18's lyt records carry exactly these names, in this order, and entries 19–68 each hold one lyt (mn_advertise … test_command_data). Source: 0x1402725d0; arclist.cs.
• likely: a layout's textures are found by name in its own archive (tex records) and then in the loaded texture packs, by tex + name with the extension ignored; records pac or BMT whose content is an ARC are searched too. Source: 0x1400640b0, 0x1400642a0.

So the names are what binds things: a modder can add, remove or reorder tex records and resize their btx content freely, as long as the names the layout uses still resolve, and must keep menu_layout.dat's first 19 entries in order.

Compressed content

• likely: content starting cmp\0 is compressed: a u32 compressor tag at +4 (zlib or lzma, matched by the two registered decompressors), the uncompressed size at +0xC, and the compressed data from +0x10 to the end of the block. zlib is inflated with zlib 1.2.11 (window bits 31 if it starts 1F 8B 08, a gzip header, else 15: a zlib header); lzma reads 5 bytes of LZMA properties, then the stream. The output is allocated 128-aligned. Source: 0x14005c0f0, 0x140087190, 0x140087550, 0x140087480, 0x1400876d0, 0x140087530.
• confirmed: no ARC in the game's files has compressed content. Source: arcrebuild.cs, all files.

The shader package

Shaders/Shader.dat is RotXor + ZIP like the other .dat files, but it is not in FileTable.bin (confirmed: its path isn't in the file) and the game reads it by path.

• likely: BladeGraphicsManager (0x140163d10) runs 0x1401646f0, which reads Data/Shaders/Shader.dat whole with 0x1401973b0 (its size from the file system), deobfuscates it in place with the three RotXor steps, inflates the ZIP member from the local header (raw DEFLATE, method 0 copies), and hands the result to 0x1400b1240 (Ghidra: ShaderLibUtil::constructCustomShaders' traverser). The length it passes is the file's size, not the member's; nothing reads it unless the package is cmp. Source: decompiled 0x1401646f0.
• likely: 0x1400b1240 walks every bin record of sh_tacos.pac; each must hold an ARC (<shader>.pac), whose bin records each hold a BlShaderArchive; 0x1400b0b80 counts that archive's SHG records and registers each BlShaderGroup through 0x140072f40, which finds the SARC (type + ID 0) and files the group under the SARC's name in the shader database slot for its kind; 0x1400730e0 then adds every SHP under its variant_key. Record names and IDs above the SARC level aren't used. Source: the functions named.
• likely: the game asks for shaders by name (0x1401646f0 creates a ShaderBlade for each of its names; the names are hashed at startup, overview). 19 of the 21 names in the package are in that list; color_adjust and model are looked up elsewhere, and the list's copy isn't in the package (probably built in: the executable carries its own BlShaderArchives, e.g. text_*.pac). Source: 0x1401646f0; shaderscan.cs.

Every shader has two <shader>.pac records: ID 0 holds the pixel-shader group (SARC kind 2) and ID 1 the vertex-shader group (kind 0). confirmed for all 21. Source: shaderscan.cs.

SARC

The 0x10C-byte content of a SARC record.

SHP

guess: a replaced shader must be a valid DXBC blob from Microsoft's compiler (fxc or D3DCompile, target vs_5_0 / ps_5_0), with its constant buffers and input layout compatible with what the game binds; a hand-edited blob would need its DXBC checksum recomputed (vkd3d's DXBC parser rejects a bad one unless told to ignore it: vkd3d MR 582, checked 2026-10-11). Whether Direct3D 11 itself rejects a bad checksum is untested.

BMAR models

worldmap/Worldmap.dat#28 is BMAR + 104\0 + an ARC BladeModelPac with four records, all named worldModel00: BML, BMD, BMA, BMT, in 16-aligned blocks. Their contents are chains of chunks: a u32 tag, a u32 size, a byte, a flags byte (bit 0: byte-swapped), a u16 alignment, the content at the next multiple of the alignment, and the next chunk at the content's end rounded up to 4; a chunk with tag 0 and size 0 ends the chain (NODE, DATA, … inside BML). Pointer fixups are applied from a POF0 chunk. likely, from 0x140037f40 (next chunk), 0x14005ba90 (POF0 fixups) and 0x140038570 (the model check: version 104\0, then either MDL\0 or BMAR with an ARC holding an MDL record). confirmed: the ARC part rebuilds byte for byte with the layout rules. The model formats are Leads.

Rebuilding

Rebuild an ARC from its records and contents with the layout rules; unchanged data comes back byte for byte (confirmed, 220/220). For an edited ARC (a changed layout, an added or resized texture) the game needs, likely:

• magic ARC\0 and version 0x0100;
• record_count, offsets, and each record's filename_length and offset_index consistent;
• each block's alignment and size right (nested ARCs and btx are read through them);
• the record types, names and IDs the game looks up: bin/SHG/SARC (ID 0)/SHP in the shader package, the first record lyt in a layout archive, lpj named fontset, tex names a layout uses;
• filename_hash right wherever a lookup asks for an exact name (the font set); the rebuild always computes it.

It need not be byte-identical: the padding, archive_name, unk_0x0A and unk_0x0C aren't read. A changed ARC changes its pakd entry and so its .dat's size, which needs the FileTable.bin entry updated (filetable.md), except Shaders/Shader.dat, which is read by path.

Leads

• The lyt layout format (version 01 03 0D 00), the lpj font-set and text-preset formats: bl::lyt (0x14008a230, 0x1400bc530, 0x14008af00, 0x14008bba0). Needed to edit menu layouts beyond swapping textures.
• The BML/BMD/BMA/BMT chunk formats and what reads Worldmap.dat#28 (model and animation tags MTXP, TXTR, MESH, MATE, INFO, ANMS, ANSK, ANMT, ANVS, NODE, DATA in 0x140038c90 and 0x14004b1a0).
• What unk_0x0C (the lookup sub-kind) and unk_0x06 (handed to callers) are for when non-zero, and the meaning of variant_key bits in SHP.
• Test in game that a rebuilt menu_layout.dat with a resized texture, and a Shader.dat with a recompiled shader, load.
• Walkers: the record walkers take an object whose first field is the ARC pointer, and the traversers derive from bl::archive::ArchiveAccessor::Traverser, so they are probably ArchiveAccessor methods; nothing ties the method names yet, so the names list keeps Archive_*.
• The executable's own BlShaderArchives (text_*.pac, tonemapping*.pac, …, near 0x1406b10f0 and 0x140808000): built-in engine shaders, not game files.