Fire Emblem: Path of Radiance notes.
Thanks to Kirb for helping me get started.
int is 4 bytes, short is 2 bytes, i mark offsets with 0x hex notations, headers are sections at the start of a file with info about it always a multiple of 0x10 long, pointers are 4 bytes long, point at a different offset in the file, and usually start their counting from the start of the file proper, which is after any eventual header or other file in the same pack file. Tables use 00 as an entry separator character.
The entries here i have the most interesting things to say about are the .cmp format, the file system.cmp, and the collection of files all named dispos.cmp
Compressed with LZ77, usually multiple files of other types packaged together. When unpacked, it goes:
0x00 = plaintext “pack”
0x04 = short, nr of files packed together
0x08 = first file entry. File entries are 0x10 long, consisting of:
int, 00 00 00 00
pointer, to file name
pointer, to file start
int, length of file
All pointers in files are counted from the start of that individual file, not the start of the .cmp file, nor just the start of the first file.
In my experience appending things to the file doesn’t break anything. This can be used to add data that isn’t normally in a given file, like a new class ID, in there to be pointed to.
Contains text. Formatted as:
header size: 0x20
0x00 = int, length of file
0x04 = pointer, to start of offsets list
0x0C = int, number of entries
The offsets list consist of pointers to starts of entries, followed directly by a list of all their ID’s in the same order.
.ga (.g, .gs)
.ga are animations. They are closely related to .g and .gs, but i don’t know how. Making the file basically all 00 removes the animation, but doesn’t make the time it takes any shorter.
Textures. There are editing tools for these out there in other GC/Wii hacking communities, like Mario Kart Wii.
Visuals and camera control? The camera stuff makes me think this is about models, and not textures. These are actually largely comprised of Shift-JIS encoded plaintext instructions. Commented all over in Japanese.
Script files. Contain some offsets, then all the function names used in the file, and then tons of numbers with plaintext inbetween here and there.
Fonts. I assume so, since they are in the fonts folder, and are named things like “fe_font” and “bigkana”.
Contains chapter data. Each chapter has one or more folders. The numbering is thrown off by the prologue being 01, and the Black Knight fight is also counted as a chapter. Map.cmp i can’t understand, but dispos.cmp contains the characters to be loaded in. It gets its own section.
Contains battle camera movements sorted in folders by class. Most of the contents are compressed into a single .cmp, though some stragglers are left outside, presumably from being finished late in development. As .dbx files, these are readily readable once decompressed, though from my small tests you have to be careful what you change.
Contains an .m file for each chapter, containing all the dialogue.
Contains character illustrations, including the ones unlocked by linking with the GBA games.
Contains the CG cutscenes, in .thp format you can just straight up play in a video player.
I think this might be the actual map map that is narrated over between chapters.
Various misc. graphics like the cursor and the game over screen.
A ton of bizarrely named files. They obviously seem to contain 8 byte big entries, but what they are for is a mystery.
Contains the .cmb files for each chapter.
Contains the files for shop inventory for each difficulty. The shopitem files are binary files structured as:
headersize = 0x20
0x00 = int, length of file
0x04 = pointer, to table over shops?
0x08 = int, nr of items in the first table?
0x0C = int, 0x60, dunno what it means
0x20 = pointer, to table of items
0x24 = pointer, to end of item table
0x28 = pointer, to an item. Followed by more of them, interspersed with 0 pointers that might be separators.
Contains sound and music, in a whole bunch of different formats it looks like
Class animations. Also some textures?
I think this is terrain models?
Character models and textures.
The root contains several files that are just standalone copies of the files that make up system.cmp. system.cmp is the one this data is actually read from!
Thanks to Kirb for explaining the character entries
This is the big boy, the file where most of the interesting things goes on. Like most .cmp files, it starts out declaring what files it consists of and where to find them. The first file is FE8DATA.bin. Starts with a 0 pointer, a pointer to the start of the big table with all the ID’s and a lot more, a pointer to another such table, and then the number of character entries.
Then start the character entries. They are 0x54 long, out of which:
0x00 = pointer, to PID, the character id
0x04 = pointer, to MPID, the name id
0x08 = always 0
0x0C = pointer, to FID, the portrait id
0x10 = pointer, to JID, the class id. (Has to match with the corresponding ID in the relevant dispos.cmp)
0x14 = pointer, to affiliation
0x18 = pointer, to weapon levels, stored as the -EDCBAS ratings in plain text.
0x1C = pointer, to SID, skill id (adding a value here if it is 0 doesn’t work for some reason)
0x20 = pointer, to SID, skill id (adding a value here if it is 0 doesn’t work for some reason)
0x24 = pointer, to SID, skill id (adding a value here if it is 0 doesn’t work for some reason)
0x28 = pointer, to unpromoted/untransformed AID, model/texture id
0x2C = pointer, to promoted/transformed AID, model/texture id
0x30 = 6 bytes, unknown
0x36 = byte, level
0x37 = byte, build
0x38 = byte, weight
0x39 = 8 bytes, base stats
0x41 = 8 bytes, growth rates
0x49 = 8 bytes, unknown. My theory is that this relates to supports somehow
0x52 = 3 bytes, always 0
You can follow any of these pointers to find the table for their respective id’s. Pointing to the same ID’s in files further down the pack will also work, as will writing ID’s at the end of the file and pointing to that. I would be very surprised if the Class entries and Item entries were anywhere else than this file as well, though i haven’t gone looking for them.
I found the Class entries at 0x71A4 in the PAL version, they are 0x64 bytes long and just like the character entries they start with pointers to their primary ID and their name ID.
The items follow hot on its heels at 0x9E94 in PAL, again starting with pointers to primary ID and name ID.
The majority of the .dbx files of the game are all stuffed together in this one file.
Contains information, presumably about models, textures, or both, on a very wide selection of things:
UI elements, Terrain list, Sky list, Camera, an unnamed list that looks like it connects classes with their corresponding /zu/ folder, visual effect list, Class list, 16 different lensflares, a list called “C:/DVDDATA/” that seems to contain a BOATLOAD of numerical constants for all kinds of things, Skill list, another UI element of some sort?, a list corresponding japanese item names with the english internal ones, what i can only assume to be the UI of the debug menu from the sheer number of ComboBoxes in there, 3 more tables of UI elements that belong in an editor and not a game that i assume is more debug, test.dbx, Anime list, “Model object” entries, seems like it distributes the /zu/ contents? Contain “Model” and “Param” sections, weapon model entries containing what model goes with what weapon including what effects to display, CameraAnime entries whatever that means, a bunch of non-plaintext data, and finally entries about what effects to play for various tiles like what footstep sounds to play.
These files accompany every map file, containing information about what characters and items to load. There is one special case in /zmap/always/ that is a selfcontained file for everything going on between chapters, like characters that join between chapters and the trial map characters. All the others consist of 4 files packed together: a .c .h .m and .n variant of the same file, not necessarily in that order. The .m .n .h files correspond to each difficulty, while the .c is cross-difficulty. The .c file is the one that actually determines your playable units. The way they are generated by the chapter they join in is how they will stay for the rest of the game.
This means characters that appear in chapters before joining need to be edited in each appearance until they join, as that is the moment their parameters get locked in.
The dispos files have typical .cmp headers, usually 0xA0 long. The files start with a pointer to the contents table, then 4 bytes. The first is how many entries follow, and then 3 bytes indicating what type of entries they are. Then it follows with those entries, after which there can be a new 4 byte info thing. It is often as the same type as the previous, so it probably uses the separations for something.
The dispos entries are 0x6C long and among other things contain:
0x00 = pointer, to the PID of the character they represent
0x04 = pointer, to the JID (class) of the character
0x08 = int, always 0
0x0C = 4 pointers, to IID of weapons (adding a value here if it is 0 doesn’t work for some reason)
0x1C = 4 pointers, to IID of items (adding a value here if it is 0 doesn’t work for some reason)
0x5C = 2 bytes, starting location (X,Y) coordinates
0x5E = 2 bytes, final location (X,Y) coordinates
Thanks to /u/PokecheckHozu for telling me about the coordinates.
Note that the playable area with grid on it doesn’t cover all of the map’s coordinates. The prologue for example has 2 tiles left and 1 up outside of the playable area, that the cutscenes make use of.
The entry can also contain pointers to AI patterns named with “SEQ”, and “MTYPE” whatever that is, usually “MTYPE_NORMAL” including cavalry and flying units.