/*
 * Filename: RARCTemplate.bt
 * Last Modified: 2014-06-12
 * Author: Phillip "Antidote" Michael Thomas Stephens
 * Purpose: J3D Engine Archives (RARC)
 * License: GPLv2
 * 010 Version: >= 5.0
 */
BigEndian();

struct FileDescriptor
{
    // All "files" have an ID, it can be used to create a find by ID function
    // rather than searching by name, iirc it corresponds with the file number used in
    // STB files, I think I confirmed this a while back but I'm not entirely sure
    ushort ID;
    // The next value appears to be a sort of hash, if it's a directory node and NOT "." or "..",
    // it matches it's corresponding node in the node table, not sure of it's purpose,
    // changing it's value does nothing of merit
    ushort Unknown1 <format = hex>;
    // Not sure what this one is
    ushort Unknown2 <format = hex>;
    ushort FilenameOffset;
    uint   DataStart <format = hex>;
    uint   DataSize <format = hex>;
    uint   Zero;
};

struct Node
{
    // Kind of misleading, it's not really a Type descriptor,
    // it's more of a 4 letter uppercase version of the directories name.
    char   Type[4];
    uint   FilenameOffset;
    // Read the above notation for Unknown1 in FileDescriptor
    ushort Unknown <format = hex>;
    ushort FileEntryCount;
    uint   FirstFileStart;
};

struct FileEntry;
struct FileEntry
{
    FileDescriptor Descriptor;
    local int tmp = FTell();
    FSeek((file.StringTableStart + file.HeaderSize) + Descriptor.FilenameOffset);
    string Filename;
    FSeek(tmp);
    // If the descriptor's ID is 0xFFFF it's a directory, otherwise it's a file
    if (Descriptor.ID == 0xFFFF && Filename != "." && Filename != "..")
    {
        // If we're a directory AND we're not "." or ".." we read in our children
        FSeek(file.FileEntriesStart + (file.Nodes[Descriptor.DataStart].FirstFileStart * sizeof(FileDescriptor)) + 0x20);
        FileEntry FileEntries[file.Nodes[Descriptor.DataStart].FileEntryCount] <optimize = false>;
        FSeek(tmp);
        // The reason we don't want to handle "." and ".." is because of a known quirk in computers,
        // I won't elaborate but here is a link on the issue:
        // http://stackoverflow.com/questions/2630054/does-c-limit-recursion-depth
        // I.E, blame the stack implementation :P
    }
    else if (Filename != "." && Filename != "..")
    {
        FSeek(file.DataStart + Descriptor.DataStart + 0x20);
        ubyte Data[Descriptor.DataSize];
        FSeek(tmp);
    }
};

struct RARCHeader
{
    // The archive's Magic, must always be "RARC", if it's "Yaz0" it's "compressed"
    uint Magic <format = hex>;
    if (Magic != 0x52415243)
    {
        Warning("Not a valid RARC File");
        return;
    }
    // This value MUST equal the total size of the file, if it doesn't the game will reject it
    // if it's a vital archive the game will hang, otherwise the data simply won't be loaded
    uint FileSize <format = hex>;
    if (FileSize != FileSize())
    {
        Warning("Malformed file, stored size does not match actual size");
        return;
    }
    uint HeaderSize;
    uint DataStart <format = hex>;
    // Appears to be a series of offsets, they do nothing of merit
    uint Unknown[4] <format = hex>;
    uint NodeCount;
    // These appear to be counts of some sort, again they do nothing of merit.
    uint Unknown2[2] <format = hex>;
    uint FileEntriesStart <format = hex>;
    uint StringTableSize <format = hex>;
    uint StringTableStart <format = hex>;
    uint Unknown4[2] <format = hex>;

    Node Nodes[NodeCount] <optimize = false>;
    local int tmp = FTell();
    FSeek(FileEntriesStart + Nodes[0].FirstFileStart + 0x20);
    FileEntry FileEntries[Nodes[0].FileEntryCount] <optimize = false>;
    FSeek(tmp);
}file;