The decompiler currently follows this naming scheme:
filename.class.file_type.ext
The reason I have for not making the file_type token the file-extension is pretty simple: usability. I would rather just have all plain text files saved with a .xml extension so that they can be easily viewed in a text-viewer by default (the data is xml anyways).
So currently I have two file-extensions in use: .xml and .bin.
The current file_type tokens that I use are tag_blocks (for meta), raw_blocks (for raw binary), and string_references (special Unicode file, decompiled from unic tags).
I will be storing no extra information in the decompiled state: filenames will be given by the folder hierarchy, and tag_block files are parsed such that their pointers are converted to local file-offsets, and their raw pointers are converted to a local offset in the matching raw_blocks file (or left as external pointers). Unicode tables are decompiled back into unic tags, with the Unicode data being stored in an xml file.
Every tag_blocks file will have a companion file that will list all SIDs and TIDs, as a new SID and TID table relative to that tag alone. What this means is that if you changed an existing filename in the decompiled map-form the compiler will have no idea that you changed this filename and will probably just null the TID. Whereas SIDs will just be built into a new SID table without problem.
Decompiled Format Overview
- JacksonCougar
- Huurcat
- Posts: 2460
- Joined: Thu Dec 06, 2007 11:30 pm
- Location: Somewhere in Canada
- XZodia
- Staff
- Posts: 2208
- Joined: Sun Dec 09, 2007 2:09 pm
- Location: UK
- Contact:
Re: Decompiled Format Overview
I'm not sure I full understand what you mean by this but it doesn't sound like a good idea...JacksonCougar wrote:Every tag_blocks file will have a companion file that will list all SIDs and TIDs, as a new SID and TID table relative to that tag alone. What this means is that if you changed an existing filename in the decompiled map-form the compiler will have no idea that you changed this filename and will probably just null the TID. Whereas SIDs will just be built into a new SID table without problem.
- JacksonCougar
- Huurcat
- Posts: 2460
- Joined: Thu Dec 06, 2007 11:30 pm
- Location: Somewhere in Canada
Re: Decompiled Format Overview
After talking to Xzodia about it and seeing the merits of doing so I am going to decompile the tag's into a single file. The file format I have in mind looks like this:
Code: Select all
class TagFile
{
int TagBlocksOffset;
int TagBlocksSize;
int RawBlocksOffset;
int RawBlocksSize;
int StringReferencesCount;
int StringReferencesIndexOffset;
int StringReferencesTableOffset;
int StringReferencesTableSize;
int StringIDCount;
int StringIDIndexOffset;
int StringIDTableOffset;
int StringIDTableSize;
int TagIDCount;
int TagIDIndexOffset;
int TagIDTableOffset;
int TagIDTableSize;
struct StringReferences
{
StringID Name;
string[] EnglishStrings;
string[] JapaneseStrings;
string[] FrenchStrings;
string[] GermanStrings;
string[] ItalianStrings;
string[] SpanishStrings;
string[] KoreanStrings;
string[] ChineseStrings;
}
//StringID Table & Index will work the same as in the map file
//TagID Table and Index
//Index point to start offset of Filename string
//Table is a list of null terminated strings.
}