Parsing .sav files - CHUNK_Partition

[tgjones]

I have a long-term project to parse the .sav files produced by C&C Generals. I'm going to document my findings using this discussion format, to encourage interaction from others who want to help with the exploration.

Perhaps it's obvious, but just for completeness: when you save an in-progress game in C&C Generals, the resulting file is in .sav format. .sav files are composed of multiple chunks. A chunk starts with the chunk name, as an ASCII string. Then there's a 32-bit integer, which is the size of the chunk in bytes. Then there's the chunk data.

Anyway, let's talk specifically about CHUNK_Partition, one of the many chunks that appears in .sav files. If you open a .sav in a binary viewer and navigate to the CHUNK_Partition chunk, you'll see something like this (this is only the start, there's a lot more of it):

It took me some time, but I've eventually figured out the overall structure:

• Version number (byte) - all chunks in .sav files, as well as plenty of individual sections of data, start with a single-byte version number like this.
• Partition cell size (float) - this always corresponds to the PartitionCellSize set in GameData.ini.
• Partition cell count (uint) - I'll describe this more below.
• Partition cell array (PartitionCell[partitionCellCount])
• Unknown count (uint) - not yet sure what this data is
• Unknown data (UnknownData[unknownCount])

Partition cell count

I don't completely know what partition cells are, only that there's this chunk called CHUNK_Partition and there's something called PartitionCellSize in GameData.ini. But I wanted to be able derive the cell count myself. I assumed it is related somehow to the terrain, and the number of cells is probably related to the size of the map. Following that thought, I found the connection between map size and cell count:

1. Get map boundary width and height.
2. Multiply this width and height by 10.0f because that's the horizontal scaling factor for the raw heightmap data in .map files.
3. Divide these values by the partition cell size (40.0f for C&C Generals).
4. Round these values up to the nearest integers.
5. Multiply the resulting width and height - this gives the number of partition cells.

In code:

var border = _game.Scene3D.MapFile.HeightMapData.Borders[0];

var boundaryWidth = border.Corner2X - border.Corner1X;
var boundaryHeight = border.Corner2Y - border.Corner1Y;

_numCellsX = (int) MathF.Ceiling((boundaryWidth * 10.0f) / _partitionCellSize);
_numCellsY = (int) MathF.Ceiling((boundaryHeight * 10.0f) / _partitionCellSize);

var numCells = _numCellsX * _numCellsY;

Partition cells

Each partition cell contains 16 "entries". An entry consists of

• a signed 16-bit value (we'll call it Status)
• and an unknown 16-bit value that so far always seem to be zero.

The Status is most common 1, but can also be 0, -1, -2, etc. I haven't seen any positive values greater than 1.

Given that these partition cells cover a 2D area, I thought it would be useful to visualise them in good old ASCII art form, by printing out the Status using

• * for 1
• - for 0
• for everything else.

From experimenting, I found that the 16 entries in each partition cell are 1 per player. Here's what it looks like when I use the 3rd entry in each partition cell (i.e. for player 3):

****************------------**************************************
***************-------------**************************************
**************--------------**************************************
*************----------------*************************************
**********--------------------************************************
********-----------------------***********************************
*******-------------------------**********************************
******---------------------------*********************************
*****----------------------------*********************************
****-----------------------------*********************************
***-------------------------------********************************
**------------------------     ---********************************
**----------------------         -********************************
*----------------------              *****************************
*---------------------                 ***************************
*--------------------                   **************************
*-------------------                     *************************
*-------------------                      ************************
*-------------------                       ***********************
*-------------------                       ***********************
*-------------------                       ***********************
**------------------                       -**********      ******
**------------------                        ********          ****
***------------------                       *******            ***
****------------------                      ******              **
*****------------------                     *****                *
******------------------                    ****                  
*******------------------                   ****                  
********-----------------                   ***                   
**********---------------                  ****                   
*************-------------                *****                   
***********************----              ******                   
****************************            *******                   
*****************************         -********                   
*******************************     -**********                   
************************************************                  
***********************************************--                 
******************************************-----                   
****************************************------                    
***************************************------                     
**************************************----                        
*************************************---                          
************************************---                           
************************************--                            
***********************************--                             
***********************************-                              
***********************************-                              
***********************************-                             *
***********************************-                            **
***********************************-                            -*
***********************************-                            -*
***********************************-                           --*
************************************-                         ---*
************************************--                       ----*
*************************************--                     -----*
**************************************-                   -------*
***************************************-                 -------**
****************************************-               --------**
******************************************            ---------***
*******************************************         ----------****
*********************************************     -----------*****
***********************************************-------------******

Now we're getting somewhere - I think we've found the shroud / fog of war! The empty areas are completely visible to the player. The - parts are fog-of-war. The * parts are shrouded. The reason the visible parts are not contiguous is because this includes the cell visibility for a player's allies - at least that's my guess, and it's worked out so far.

The Status values appear to have these meanings:

• 1 = Shrouded
• 0 = Fog of war (previously explored, but no units currently nearby)
• Negative numbers - Visible. I don't yet know what the negative numbers actually mean

That's as far as I've got so far. I still need to find out what the negative numbers mean, and also look at the unknown data that follows this partition cell data.

[tgjones]

I'm trying to figure out the negative values. I moved 12 units out of my base a certain distance, then I took 6 units and moved them a bit further, then I moved 1 unit a bit further still. I plotted the partition data into a bitmap, and animated the results. Pixel brightness is based on how big the negative number is. There's still something I'm missing, because the brightness drops more suddenly than I would expect, when I left 6 units behind and moved 6 units onwards.

[dginovker]

This is super neat 😄

[tgjones]

I found a better way to visualise it. The big circle is the command center. The small circle is a single worker. As the worker moves, the numbers go up to a maximum of 5. When the worker stops moving at the end, the numbers go down to a minimum of 2. (And the command center remains at 2 the whole time.)