Q: Does Infinity Explorer support playing sounds?
A: No, it does not and will not, because Interplay doesn't approve of distributing programs that work with their audio or video formats. However, you can use Infinity Explorer to save the WAVC files to the disk, use the program ACM2WAVC (that can be found somewhere on the Net) to convert them to ordinary WAV files and play them with, for example WinAmp or the Windows Media Player.
Q: Does Infinity Explorer support playing movies?
A: No, it does not and will not, for the same reason as sounds. However, you can add the movie IDs shown by Infinity Explorer to the [MOVIES] section of the INI file of your game and view the movies through the Movies button on the main screen of the game. Also there's a program called MVE2EXE, available from the TeamBG site, that can be used to convert movies into self-playing executables.
Q: Does Infinity Explorer support editing data?
A: No, it does not and will not. Creating a good game data editor would require a totally different interface and would be the scope of a totally different project, which I'm not interested in creating. For editing savegames, check out GateKeeper, DaleKeeper and ShadowKeeper. For editing other game data, check out the TeamBG utilities or the Infinity Campaign Maker.
Q: How do I reverse-engineer a data format?
A: Here's some tips to get you started. In order to successfully reverse-engineer any data file format, you will absolutely need a hex editor and some skill in using it. It is also highly recommended to have some experience in programming (preferably in C or C++, but almost any other language will do). Knowledge of assembly language and a good disassembler (IDA is by an order of magnitude more powerful than any other disassembler available today; highly recommended!) are also a big plus.
First of all, most of the modern games (including Infinity Engine games) store the game data in big archives containing of many small individual files (in Infinity Engine these are BIFF files). Before starting further research, you need to be able to split these archives into individual files.
Generally, for these files there is some kind of a directory (in the beginning of the archive, in the end of the archive, or in a separate file) describing the contents of the archive. The directory usually contains the name of each file, its offset from the beginning of the archive, its size and sometimes its type. Records in the directory are either fixed-size or variable-size; in directories with variable-size records, the file name is usually prefixed with a byte or dword storing the length of the file name in bytes. Sometimes the directory doesn't contain file sizes; in this case, file sizes can be calculated by subtracting the offsets of two adjacent files.
Sometimes the archives are compressed. Today the most widespread compression formats are ZIP (used, for example, in Quake 3 and Fallout: Tactics) and zlib (used, for example, in Fallout 2 and Might & Magic 6/7). ZIP archives can be extracted with any tool supporting that format, for example, with WinRAR. Archives compressed with zlib usually require writing a custom unpacker using the zlib library. Such archives usually also have a directory similar to the one described above; usually the directory contains both the compressed size and the uncompressed size of each file.
Once you get the individual data files, you should figure which types of files are there. If the file names have extensions, the file type can be usually determined from the extension. If they don't, you can try looking at the beginning of the file and seeing whether there is a text signature. If there is no extension, no signature and no information about the file type stored in the archive, then you have to resort to guesswork (looking at the similarities of how files look in a hex editor).
After you get the files sorted into separate formats, you can start deciphering individual data formats. I won't cover graphics and multimedia files for now; the following description is applicable to files containing some general data (information about creatures, items and so on).
Generally, file formats used in games fall into three big categories: text files, chunked files or fixed-size record files.
Text files are usually the simplest ones to figure out. Sometimes they have extensive comments (intended for game designers) explaining the structure of the file and the data it contains. Even if they don't, they usually have some keywords or other clues to what data is contained in the file. Examples of text files in Infinity Engine games are the IDS, 2DA, INI files and the compiled AI scripts.
Chunked files contain a sequence of individual pieces - chunks. Each chunk is prefixed with a small header containing the type and length of the chunk and probably some other data. There is no global directory allowing to find a specific chunk; all the data must be read sequentially. Sometimes the structure is recursive: a chunk can itself consist of other chunks. Chunked files are used, for example, by the SCUMM engine on which the older LucasArts quests (Monkey Island 1 and 2, Day of the Tentacle and so on) are based. None of the Infinity Engine files have that structure.
Fixed-size records is the most widely used format in Infinity Engine games. Such files consist of a fixed-size header and sometimes fixed-size records of other types. If there are records of other types, the header usually contains the count of such records and the offset to the first record. Sometimes the structure is more complex; it may involve additional directories (like the CHUI format of Infinity Engine games) or other complications.
If you encounter a fixed-size record format, the first thing you should do is determine the general structure of the file: what is the size of the header, are there any additional records, what is the size of those records. One way to do that is to sort the files by size and look at the differences in the size. If all files have the same size, then probably there are no additional records. If the size is different, the smallest difference in the size can be the size of one fixed-size record. However, if the file has records of a different type, this will not be so. All in all, there are no hard and fast rules for figuring the file structure. You should just look at the file data in a hex viewer and try to notice some structure of the data, repeated patterns of bytes and so on. This could also give you clues to the data format.
The next step after figuring out the file structure is to determine the specific data stored in the file. In a role-playing or strategy game, the first place to look is the text and numeric data shown in the game: character names, abilities and skills, item weights and prices, unit parameters. If the data cannot be derived from other data and some tables (like the character saving throws in games based on the AD&D rules), then it must be stored in the game files. Usually it is quite easy to find the data represented by "unusually looking" numbers (not 0, 1 or 2, for example) - the amount of gold, hit points or something like that.
Data like the character class, race or the spell school, that is not specifically numeric but selected from some table, is a little harder to decipher, but it can still be done. It helps a lot if the tables from which the data is chosen are also available (like the IDS files in Infinity Engine games).
Usually only a fraction of data will be shown directly in the game itself. For figuring the remaining data, the following techniques can be used.
One is to change some data with a hex editor and then to load the game to see what changes were caused by it. Sometimes the game will just crash or otherwise behave strangely. Sometimes you won't be able to see any changes. But in many cases your change will have some obvious consequences giving you a clue to the meaning of data that you changed. One important notice is that you should always change only one thing at a time and always revert to the initial version if your changes didn't produce any visible effect. Otherwise you will not be able to isolate which change in the data produced the effects that you see in the game.
Another technique goes the opposite way and is mostly useful for figuring out the format of savegames. With this technique, you save the game, then do some actions using the game interface (select a different character, invoke a modal ability, dual-class a character) and immediately save the game again into a different slot. Then you do a binary compare of the two savegames and try to understand which of the changes that you see in the data was caused by what you did through the interface. You'll often see that quite a lot of data has changed. Some of the changes are attributed to the passage of time, the wandering NPCs or some other unrelated things. But after some experiments, you will usually be able to isolate the data bytes used for storing the information that you changed through the game interface.
Finally, the ultimate way to obtain complete information about any data formats is the use of a disassembler. It can be very time-consuming and much more difficult than the other techniques described here, and the full discussion of using a disassembler for figuring out file formats is outside the scope of this discussion. But it is the only way to obtain complete and precise data about the formats, and sometimes (for example, when a game uses a proprietary compression algorithm) it is the only way to obtain any results altogether.
If you have any questions or suggestions, feel free to e-mail me!