main.dol Model Routing

The game finds every model block in dt_na.dat through a table in main.dol: open the file by name, seek to an offset, read a number of bytes. Nothing inside dt_na.dat says where a model lives, so relocating a model (hammerspace) only means writing the block somewhere new and repointing its DOL entry. All values are big-endian. The constants below are for the US version.

Directory pointer table

A flat array of uint32 virtual addresses at DOL file offsets 0x69C828–0x69CAD8, one per directory. Convert an address to a DOL file offset by subtracting 0x80003F00. The index into this table is the chunk number (ChunkNumber in a .sluggie; also the number in front of each export folder name).

Directory entry

Each directory is an array of 48-byte entries (12 × uint32). The index into it is the file index (FileIndex in a .sluggie). The array ends at the first entry whose word 0 is not the dt_na.dat name pointer, or where the next directory's entries begin. Directories are stored back to back, so a walk that checks only the name pointer runs on into the following directories. It then meets the same physical entry again under other chunk numbers: for example, (76,197), (77,182) … (88,17) and (89,2) are all the entry at DOL offset 0x688A28. Each entry has three language slots of four words each, and every slot has the same layout:

In every character directory, all three slots point at the same data. 118 entries do have diverging slots, all in non-character chunks (9, 10, 16, 119-123, 128, 138 and 145-148; surveyed in the input DOL on 2026-09-27). The tools read the en slot and write all three, which is correct for every character entry.

What an entry points at

• A model block (the common case). All section pointers in its header are relative to the block start, so the block can be moved as a unit.
• An archive of several members: fileCount:u32, then fileCount u32 member offsets relative to the archive start (0 = empty slot), then the members in ascending order on 32-byte boundaries. A member's length is the distance to the next populated offset, or to the archive end for the last one. Members can be models or ANM blocks. Multi-part characters (stadium bosses, map objects) use this. Some equipment entries (bats, for example) also have a short prefix in front of the model. In a .sluggie, ModelOffset/ModelLength give the member itself, which then differs from the entry's offset/length.
• How common archives are (stock US files, 2026-09-18): 619 distinct archives, 231 of them with two or more populated members, up to 222 members. Of the 1,423 exported models, 686 have their own entry, 291 sit alone in an archive, and 446 share an archive with other members; all 446 are in export folders 131 (Map Objects F) and 136 (Scoreboards Items and Obstacles). The patcher rebuilds one member and copies the others verbatim, so one patch changes one member: patching a second member of the same archive starts again from the vanilla archive and discards the first edit.
• Shared routes: several entries can hold the same offset, so the same bytes serve several chunk/file indices. Patching one of them repoints all of them. The exception is the unused characters' entries, which --untangle exports split on purpose. They always move alone; see Unused characters.

Relocating a model (hammerspace)

1. Build the new block (or the whole archive, with one member replaced and the later member offsets shifted by the size change).
2. Write it at an offset at or above BASE_SIZE (715,046,144) in the extended dt_na.dat, on a 32-byte boundary.
3. Write the new offset and length into all three language slots of the entry, and of every entry that shares its route (length also goes into the allocation-size word).
4. Grow the dt_na.dat size field in fst.bin (FST entry 1, size at byte 0x14) to match the extended file.

The block a patch replaces is zero-filled, but only when no entry in the output main.dol still points into it (in any language slot). Otherwise it is left in place with a warning, so that one route's patch never blanks another route's live bytes.

Unpatching restores the entry from the untouched input main.dol, restores the original bytes from the input dt_na.dat, and zero-fills the hammerspace range. Unused-character entries are the exception (below). The implementation is SluggiesTools/Hammerspace/HammerspaceHelper.py (readDolEntry, patchDolEntry, findSharedEntries, liveRoutesInto, removeModelFromHammerspace) and ArchiveContainer.py.

Defragmenting hammerspace

Zero-filled blocks are reused only when a later block fits into them, and dt_na.dat never shrinks by itself. start.py --defrag-hammerspace [--dry-run] (the GUI's Maintenance tab, Defragment) packs hammerspace again. The implementation is SluggiesTools/Hammerspace/Defrag.py.

• Pointers: every hammerspace block is reached only through DOL directory records. That covers the stock table and the own model directories of new IDs, in all three language slots, and the model patcher, untangle clones and roster copies (layout, icon bank, name tables, own directories) alike. A move therefore rewrites only the offset words of those slots; length and allocation size stay. fst.bin gets the new file size.
• Extents: overlapping routes (shared entries, an archive and a member, language slots of different length) merge into one extent, which moves as a unit.
• Layout: extents keep their order and pack upward from BASE_SIZE, each keeping its alignment modulo 32, so nothing moves up. The file ends 128 bytes after the last block. Non-zero bytes that no route covers are dropped.
• Safety: the output main.dol, fst.bin and the dt_na.dat tail are backed up to 3_Output_Dat/_defrag_backup. Every route is hashed before the move and checked after it, and any failure restores the backup. A backup left by an interrupted run is restored by the next run.
• Only the region past BASE_SIZE can shrink. Vanilla ranges zero-filled by patches stay where they are.
• The three files belong together: copy dt_na.dat, main.dol and fst.bin to the game at the same time.

First run on a real output (2026-10-13): 94 extents, 24.80 MB live of 25.40 MB, 93 moved, 629,568 bytes saved. All 8,460 routes read the same bytes as before, and only the 273 offset words of moved routes changed in main.dol.

Unused characters (chunks 89-94)

The six unused characters have no model data of their own in the stock game. Every file entry of theirs points at a block that a playable character also uses (input DOL, 2026-09-27):

File layout of a character directory: 0 high-poly model, 1 L_ model, 2 bat, 3 left glove, 4 right glove, 5 placeholder, 6-14 ANMs. File 5 of about 65 character directories, including 89-92 and 94, is one shared 64-byte block at 0x4B33140. It is an archive header with count 1 and a slot at +0x20, and is all zeros after that.

File 5 survey of the character directories (2026-10-05): only Peach (dir 22, a second bat, 94103648_bat.gpl, 10,688 bytes) and Wario (dir 28, chall_g.gpl, 26,208 bytes) hold a real block. 30 directories (76-79, 83, 93 and the Miis' 95-118) hold a 32-byte all-zero block, the others the shared 64-byte block. Peach's second bat appears during her Star Swing (user observation, Dolphin, 2026-10-05), so file 5 seems tied to that animation. Whether the load is keyed on the file's content or on a per-character setting, what Wario's block does, and whether another character uses a block placed in its file 5 are not known. Bats and gloves (files 2-4) are one-bone models inside a 32-byte archive container, and are widely shared between directories: one vanilla bat block serves up to 13 routes.

Split routes

--untangle exports (export.py, clone_unused_dirs_to_hammerspace_for_untangle) copy every entry of chunks 89-94 into hammerspace and repoint only those entries. The playable owner keeps the vanilla location. The list of chunks lives in SluggiesTools/Hammerspace/UntanglePolicy.py.

• The game does not rely on the sharing. In a build where every CMPR texture of Unused Yoshi A's copies was recoloured red, Unused Yoshi A was fully red, including bat and gloves, while green Yoshi and Unused Yoshi B stayed green. A split build played through at-bats and fielding without glitches (Dolphin, 2026-09-27).
• The copies are not verbatim. The texture untangling changes a few bytes (1-15 per affected block) inside texture payloads, so each unused character gets its own Dolphin texture hashes. The .sluggie records the resulting texture names.
• The copies' .sluggie offsets point into hammerspace. All offsets in a .sluggie are absolute. So when building, the patcher rebases them onto the vanilla block, and it keeps the archive prefix of entries such as the bat. The copy's own address therefore does not matter, even after it has been zeroed.

Patching and unpatching a split route

• Patch: only the patched entry is repointed. An owner never takes its split routes along, and a split route never takes its owner. The vanilla range is never zeroed for a split route, because the owner still uses it. For the high-poly model, bat and gloves, the untangled texture bytes are re-applied to every texture the edit left unchanged.
• Unpatch: the entry goes to a fresh baseline copy in hammerspace, never back to the owner's block. The baseline is the vanilla block with the untangled texture bytes re-applied. It is rebuilt from the input dt_na.dat plus the .sluggie (UntangledTextures.py replays the untangler's flip sequence until each texture's Dolphin name matches the recorded TextureFileName). This reproduces all 89 intact export copies byte for byte.
• Repair: an entry found back on its owner's offset (left there by an unpatch from an older tool version, for example) is re-split by start.py --resplit-unused (StartTools menu [6]). A patch of such an entry needs no repair first, because it moves only that entry.

Confirmed in Dolphin on Unused Yoshi A (2026-09-28/29). In each case green Yoshi and Unused Yoshi B stayed vanilla throughout:

• a re-split, then patch, unpatch and patch again of the bat;
• bat mesh and UV edits;
• texture reimport;
• a custom submesh with an appended texture;
• a specular edit;
• an added bone with a custom submesh on the high-poly model, then on L_;
• an unpatch after each step, which brought back the standard look.