Chapter One: The Architecture of Starcraft Data

EXE Data (Brief Mention)

Will you look at that, less than a chapter into this bible and we're already into Stargraft. Actually, not quite yet. This short section is more of a conceptual description of some of the stuff inside "the EXE" (meaning starcraft.exe, which is not an MPQ file) to help people understand how Stargraft functions when we get into that in the next chapter. (Only two chapters; not bad :)

Until now, the only type of input data that we've talked about is data and media files that the game engine (starcraft.exe) loads from the external MPQ files. Until recently, those were the only things that were known enough to do any substantial editing of... but people knew there was more, in fact much more, that resided in the actual engine itself, the EXE. Because this is the engine that tells how to run the game, by "editing" it, you are not only changing the input data the engine gets, you are changing how the engine functions itself. This would be the equivalent of changing the math function + into, say, - instead.

Now, that sounds pretty revolutionary, doesn't it? I mean you could essentially reprogram the entire game into a FPS or RPG or something... right? Possible, but not likely. The central concept that should be understood is that in the EXE, there are basically two sections: one which contains actual "code" (assembly language that your machine reads and does what it does) and one which contains more data, similar to data files in the MPQ, just not as organized (it gets that way when high level languages such as C++, in which the game was programmed in, are compiled into a binary language that your computer can understand).

To try to edit the code ("assembly" or "assembler" as it is often referred) is to spend your life hacking away at a single program that is just over one meg in size. Basically, don't ever expect it to happen -- it is simply impossible to change anything substantial in the code of the game at such low a level, and any successes would be miniscule when compared to the task of understanding all of it and isolated in any case.

Thus, that leaves us with the data section, and primarily, that is the stuff that we are interested (and have the ability) to manipulate. Because the data is structured (though it would definitely not appear that way to the untrained eye), it can be interpreted pretty easily (a gross exaggeration, but accurate in comparison to trying to interpret the code) and edited just like MPQ data files. Now, Stardraft can only pop files that are normally into the MPQ into memory, how do we get a modified sections of EXE data loaded when the game starts?

Here is where Stargraft comes in. In its current state, it is actually two programs in one. First is the Patch Creator which creates things called PAT files. Then there is the Patch loader which loads PAT files into the game (just like the Stardraft patch loader for CWADs). Now, does this mean that ther are a bunch of PAT files in the EXE that your PAT file replaces? No, in fact, far from it. First, the data in the EXE is not in the archived format that we're used to in MPQs. Instead it is mainly a series of seemingly random chunks of structured and formatted data. There is no order or much common dividers between sections and it is pretty difficult to tell what is what (unless you know the code which tells where exactly to find what when it needs it). If you look at a PAT file (just open it up in a text editor) you will see that it is just text, neatly organized, and easily editable. (Don't tell KA I told you :) The patch creator essentially creates a PAT file that is understandable and easily edited externally, and then the patch loader translates the changes in the PAT file from the default data into the data type that the game understands. And like Stardraft, it pops the stuff into memory when loading the game, having no permanent effect on anything.

In a nut-shell (what's with nut-shells any ways?), that's how SG works, and probably all you need to know about its actual functionality. (How to use it will come later) Now, there is a little controversy over whether Stargraft should implement its changes directly to an EXE or patch it temporarily into memory when the game loads (as it does now). We make custom MPQs, so why not custom EXEs? There are several good arguments as to why patching is the only decent way of doing what SG does.

The reason why Custom MPQ files can be made so easily is because MPQ files are structured archives and aren't really limited by size or organizational constraints so long as each file inside is separated from the others and the over all structure is intact (like a ZIP file, which isn't going to get corrupted unless you arbitrarily chop off a few bytes or something). The problem with the EXE is that the size of its data section is fixed (and controlled by the code mainly). Not only that, each sub-section of data in the larger chunk is also fixed; not merely by how long it is, but also where it is and where it starts. The code looks at a certain place to load certain data. If it doesn't find it there, then you have a problem.

If SG were to only edit the data in the EXE as a permanent change, then the editing would be very limited by the size and placement constraints, especially because much of the data is in compact and compressed forms. Patching in memory allows much more breathing room, because memory is only limited by how much RAM you have. Instead of having the game place certain data it reads from the EXE in particular memory addresses (locations in memory), it is easier to put new stuff in other memory addresses and then have the game read those new sets of data instead.

And some more nut-shells, and onto chapter two.