Unlimited Size SVG Tutorial

Update: If this is all too confusing for you, you can head over to here and let the program do all the work for you :P



SAVE_STRING_MAX_SIZE exceeded in save game. The goal of this tutorial is to teach you how to add as many mods as you want to your WaW savegames without ever running into this error again. Contrary to what the text of the error suggests, there is no max size - of singe dvars or of the dvar block in whole - that is being exceeded. Instead, what it means, is that there is an error in the format of the savegame.

For this tutorial, I've grabbed a brand new SVG from WaW. Started Semper Fi and left. I've used Modio to extract the inner savegame and that is what I will be working on through this tutorial. I've added a basic mod to make sure everything's working.

And, of course, it works:

Sweet, if the mods work, let's add some awesome stuff.

Maybe not the most awesome mods in the history of modding, but I set all the hex values correctly, so it should load right? Well, let's see what happens.

Well shit, what the hell went wrong? Let's go back a step, to the working modded svg we made and see if we can make sense of its structure. What we know so far is that we have dvars and their values. Each dvar and each value is preceded by an integer equal to the length. See the picture below:

Each pair of digits in HxD represents a byte of data in hexadecimal. An integer is four bytes of data, so that's why we have four bytes before each dvar and value. That's all well and good, but about this thing:

Files are organized into blocks. Large blocks contain smaller blocks, those smaller blocks contain blocks, those smaller smaller blocks contain smaller smaller smaller blocks, etc. It's how information is organized in files and how computers know that the data isn't corrupt. The dvars are organized into blocks containing 0x3F8 bytes (a number preceded by "0x" is hexadecimal. I will put the decimal value of hexademical values in parentheses. 0x3F8 is 1016 in decimal). Before each block is a byte that has the value 0x7F (127). I'm not quite sure what the logic behind this is, but 127 * 8 = 1016. I'll show you the first block of data in the working svg we made.

1. We see the first 0x7F byte. We should expect 0x3F8 bytes of data to follow.
2. I've selected 0x3F8 bytes of data.
3. The very next byte after my selection is 0x7F. This is the byte preceeding the next block of data.
Also:

The 0x7F byte isn't considered part of the dvar length. You can see that my selection is 0x10 (16 in decimal) bytes long, but that the integer preceeding the dvar has a value of 0xF (15 in decimal).

Because no one knew this before - Cheater912 (creator of Codtool) included - people would just keep adding mods. The WaW savegame reader is going to read the 0x7F, then read the next 0x3F8 bytes as dvars, then it expects to read either 0xFF or 0x7F. If it reads 0xFF, then it knows there are no more dvars to read and moves on. If it reads 0x7F, then it knows there's another block of dvars. If the byte if neither 0x7F or 0xFF, it throws the SAVE_STRING_MAX_SIZE error. This means that modded savegames have only contained about 0x3F8 bytes of code, otherwise the game expects to see 0x7F. The amount of space the dvars usually take up in an un-modded savegame is about 6000 bytes. This is around 5 or 6 times as much as people have been using. With this knowledge alone, you could make your savegames much bigger. That, of course, still isn't UNLIMITED space, so, if you're up to it, keep reading and I'll explain how to increase the size of your savegames.

Let's say I want to add 0x4000 bytes to my savegame. And by add, I mean add. I don't mean overwrite. If you're familiar with HxD, you know that pressing ctrl+v will open a warning message telling you that this is going to change the file size, which could corrupt the file. Normally, this is correct, but I'm going to show you how to do it without corrupting the file.

I'm inserting 0x4000 0xFF bytes after the last dvar's value. As I mentioned before, when the game reads the 0xFF byte, it stops reading the dvars and moves on to other blocks of data, so all we need to do is let the game know that there is now 4000 more bytes of data and it won't mind the large chunk of nothingness. We start at the top. At offset 0x450, there are two consecutive integers. These correspond to the block lengths of the two large blocks the savegame is divided into. It's the length of the first block we're worried about.

We added 4000 bytes to the first block, so we need to add 0x4000 to this number. Open up Windows calculator, switch it to programmer mode (making sure you're on hex mode), and add 0x4000 to 0xA66E3. We end up with 0xAA6E3.

Perfect, we now have only one thing left to change. It's another integer representing the length of a block, but this one is a bit harder to find. Remember I said the savegame is divided into two large blocks? Well, believe or not, each of those is divided into blocks as well. Dvars are in the second of these blocks. The first is at 0x460. As is the style of blocks, this first inner block is preceded by an integer with its length.

Let's see what's 0x30FA bytes later

1. I've selected the length of the first block - 0x30FA.
2. I started at offset 0x460 - the offset of the first block inside the larger first block.
3. This is the start of the dvar block, which is the second block inside the first larger block. The highlighted bytes comprise the integer representing the length of the dvar block.
First, I should mention you don't have to keep selecting bytes until HxD says the correct length, I just as well could have added 0x30FA to 0x460 to get 0x355A, which is where I ended up anyway. We added 0x4000 bytes to this block, so again, this length is no longer correct, so we have to update it. It says 0x17CA, so we add 0x4000 to that and get 0x57CA.

And now, if I save the file, add it back to the outer SVG with Modio, and load it up, it will work.

Alas, this is the end of the tutorial. I have no doubt this was quite confusing; not only in concept, but because of how I explained it, but head over to my Forum, ask some questions, and I'll see if I can not only answer them but improve this tutorial as well so that it's not so confusing anymore.

Also, when I said above that the game looks for either 0x7F or 0xFF after each block of dvars, I sort of lied. Truth is, the last dvar block usually isn't as long as the others, so instead of 0x7F it may be 0x7E or 0x7D, etc. It doesn't matter, you can replace those with 0x7F and everthing will work. I thought I would mention it though, because it might be very confusing to run into it while looking through a savegame and wonder why the fuck it isn't 0x7F.