I know very little of the Iron Storm game, admittedly, but Saturday evening I decided to take a look at the game and wrote a loader for its package format. The package format used in Iron Storm is made up of an LST file, which is basically an index of all the files within the IBF file—the IBF being the actual file that contains the data used by the game.

There isn’t a lot to say about either of these, but I’ve provided the information below for prosperity; hopefully someone will make something neat out of it!

All the data used by Iron Storm that I’ve seen is unsurprisingly stored as little-endian, but this is worth keeping in mind if you’d like your loader to work on multiple architectures.

LST

The LST format is basic really. The first part of the file appears to be some sort of identification which will always be ‘_TSL1.0V’, I’m not aware of any exceptions to this, and this is then followed by a 32-bit unsigned integer, which represents the number of indices within the LST file, and finally this is immediately followed by the first index.

So in other words, you could imagine the header structured like so…

struct {
    char ident[8];
    uint32_t num_indices;
} header;

Each index is essentially structured in the following way…

struct {
    char name[64];
    uint32_t data_offset;
    uint32_t data_length;
} index;

So first you have the name of the file within the IBF, this has a maximum length of 64 bytes. This is then followed by the actual offset of the data within the package and then the length, both of which are 32-bit unsigned integers.

Keep in mind that the names are null terminated, although there may be some garbage after each null.

IBF

What immediately threw me off while looking at the IBF format, is that Iron Storm appears to use the Resource Interchange File Format (RIFF) for not just audio data, which is typically where you’ll see this used, but for its textures and models as well. It’s certainly not something I’ve seen done before for game content, but there’s not really any reason why you wouldn’t do it, I guess.

In the case of audio data, it’s worth noting the offset provided in the LST will actually skip over the additional RIFF information before the start of the actual WAV, which is very likely because the engine had no need of it itself, and it’s only specific to whatever tools the developers were using to produce these packages.

Otherwise, there’s nothing much else to say about the IBF format, if you use the offset and length from each index, you’ll be able to find that data within the IBF which you can then copy into memory and do whatever with.

If you’re thinking of producing modifications and other alterations to the game, I think it would be possible to do by repackaging the IBF and LST when altering their contents (if the size is different anyway), but otherwise the game is quite clearly not produced with community modifications in mind. You’re going to be incredibly constrained by what you can do here.

That’s it, for now, I’m planning on looking into both the model format and texture formats if I find the time. The texture format appears to be incredibly simple though and even provides descriptors within the RIFF block so that you know exactly what type of image data it is (DXT5 and TGA are two I’ve seen).