Decoding Formats

[holon]

Lately, I've been reverse engineering Sim City 3000 - and I've been making varied progress. Just wondering if anybody can shed some wisdom on what might be going on with some of the formats I've encountered. The main game configuration seems to be stored in a PAK file, which is just a series of INI files. I've completely decoded this format, so it's not an issue.

The PAK file is used for storing only the game rules as far as I can tell. It has no directories, featuring a single
index of filenames. The files themselves are series of strings, seperated by new lines.

PAK files only store this special key value data, which is why a length is not required.

A note on strings however. They are prefixed with a 32-bit length indicator, like so:

{
	int32 length;
	char chars[length];
} pak_string;

==========
Header
==========

The header contains the number of variable byte file indexes.

{
	int32 entries; // number of entires
} header;


==========
Index
==========

The index is a list of entry structures to the amount specified in the header. Nothing too complicated.
Since a pak_string is variable, there is no pre-determined size, but they are always at least 8 bytes.

{
	pak_string name; // name of the file
	int32 offset; // offset in file
} entry;

==========
Entry
==========

An entry is an array of strings, as far as I know - this is used for the INI files. Each section
and combined key-value is seperated into a pak_string. For example:

pak_string = "[Admin]"
pak_string = "Enabled=true; hello"

{
	int32 values; // number of values
} entry_header;

From here, it's just an array of pak_string's for the amount of values specified for the entry.

The area that I'm having issues, is with some sort of file storage format.

The IXF file is used for the majority of the data, my guesses show that it's a directory 
with 32-bit indexes. It's extension is usually IXF.


==========
Header
==========

The header is simply a 32-bit identifier.

{
	int32 identity; // always 0xD781C380
} header;

==========
Index
==========

The index is a at a minimum 1024 20-byte entries. If there are less than 1024 actual entries, then the used entries
are terminated with zeros.

{
	int directory; // think this is the id of the ixf, like a directory name
	int id; // id, counts sequentially
	int type; // fairly sure this is the type
	int offset; // the offset in the file
	int length; // length
} entry;


==========
Data
==========

The file data is located at each offset provided by the entry, and then the size of the
length. Not too difficult.

For each entry, the first value "directory" is the same for every entry per file - so I just assumed this some sort of group id. The next weird thing is that what I think is the ID, is not actually a name - but a 32 bit number. I have no idea how they developed the game with this system, or how they came up with the seemingly random id numbers. Perhaps a CRC32 of the name? The other odd thing is the type.

While it appears to be the type, the numbers are always long and weird - often negative.

public enum IXFEntryType : uint
{
	String = 0x2026960B,
	Text = 0x81F53D09,
	LowSprite = 0x00000001,
	HighSprite = 0x00000000
}

Another thing with the ID, is it's not always unique. The only unique combinations are when group, id and type are all different values - leading me to believe that the type value is actually a second id. Lastly, .dat files also seem to use the same format in the game. Has anybody got any light on any of this?

The only PAK file in the game: [URL="a.pomf.se/krvvxy.PAK"]SYS.PAK[/URL]
An IXF file in the sprites folder: [URL="a.pomf.se/vdcfau.DAT"]0000000B_Utilities.DAT[/URL]