shaktazuki Oct 05, 2008 4:08 am
Subject: resource stripper help

If anyone has the time -

Here's my resource stripper program. It is supposed to write a 16 color bitmap of the resource layout from a MAX savegame. The bitmap is not turning out well, and I don't know why. If anyone can take a look and tell me how I am messing up, I would appreciate it.
Attachments:
editor.zip (Filesize: 3.77 KB)

Artlav Oct 05, 2008 12:27 pm
Subject: Re: resource stripper help

There seems to be many problems.
First, why the offset is 12768 and not 12763?
EDIT: Right, version 1.56 vs 1.04. It is 12768 in 1.04 and 12763 in 1.56, so that is all right.

Why unsigned char bmpdata[BMP_DIM / 2][BMP_DIM]; ?
You make a bitmap that is not a square, probably messing the things downcode.
Like, writebmp16(filename, BMP_DIM, BMP_DIM, (unsigned char *)&bmpdata);
Does not sound right to me.

DownloadSource code (Text):
  1.  infile.get(in);
  2.  infile.ignore(); // ignore the next character (this was probably originally stored as an int)
You ignore player visibility bitmask. Good, but comment makes it senseless.
You read bytes of resource distribution.

The resources block format is thus, in case you don't know it :
DownloadSource code (Text):
  1. 2 bytes per cell, left to right scanlines.
  2.  
  3. Byte 1 is resource type:
  4. if((b1>0x20)&&(b1<0x31))  fuel, b1-0x20 of it (0 thru 16)
  5. if((b1>0x40)&&(b1<0x51))  gold
  6. if((b1>0x80)&&(b1<0x91))  raw materials
  7.  
  8. Byte 2 is the player visibility bitmask.
  9. bit 2 - Gray player surveyed this cell
  10. bit 3 - Blue
  11. bit 4 - Green
  12. bit 5 - Red

So, your code below
DownloadSource code (Text):
  1. for(int i = 0; i < 112 && infile.tellg() <= 37854; i++){
  2.  for(int j = 0; j < 112 && infile.tellg() <= 37854; j++){
  3.   infile.get(in);
  4.   infile.ignore(); // ignore the next character (this was probably originally stored as an int)
  5.   //outfile << typetxt((unsigned char) in);
  6.   if(i % 2){   // if i is odd
  7.    bmpdata[i / 2][j] |= type((unsigned char)in); // set the low bits
  8.   }else{
  9.    bmpdata[i / 2][j] |= type((unsigned char)in) << 4; // set the high bits
  10.   }
  11.  }
  12.  //outfile << endl;
  13. }
Makes somewhat doubtful sense.

You can use my save game reader as a reference:
http://www.rumaxclub.ru/etc/maxse_081005.zip
It takes a save file as first parameter, and outputs bitmaps and information.
No source code, unless you ask for it.

Artlav Oct 05, 2008 12:59 pm
Subject: Re: resource stripper help

Ok, got it fixed.
You can disregard the BMP_DIM/2 argument, as i didn't dig deep enough on the first round to figure it out properly.

Here is the fixed code:
http://www.rumaxclub.ru/etc/editor_fixed.zip

Basically, the problem was in the data distribution in memory - you got x and y swapped in several places.

shaktazuki Oct 05, 2008 7:00 pm
Subject: Re: resource stripper help

You even aligned it to the map display in the game; wow! I would have settled for just getting it in any alignment.

Thanks!

I only knew the resource masks / amounts / offset. I wish I knew the rest - if you have a description of the savegame format, I'd like to get it.

My next step is to also output the amounts. This will take significant effort.

I wrote the bmp writer and I still didn't know exactly how it works. Thanks to you, I know now.

Artlav Oct 05, 2008 9:59 pm
Subject: Re: resource stripper help

Quote by shaktazuki:
My next step is to also output the amounts. This will take significant effort.
Why should it?

Quote by shaktazuki:
I wrote the bmp writer and I still didn't know exactly how it works.
You wrote a BMP writer without knowing about how it works?
Nicely done, considering that it seem to work well.

Quote by shaktazuki:
I only knew the resource masks / amounts / offset. I wish I knew the rest - if you have a description of the savegame format, I'd like to get it.
The whole format description does not exist yet.
I've decoded a big deal of it, but there are still lots of blind spots.

At the start, a word of version - 0x0046 for 1.04, 0x0045 for 1.56.
Then, a header:
DownloadSource code (Text):
  1. struct header104 {
  2.  game_type:byte;                        //0 - Singleplayer, 2 - Campaing, 3 - Multiplayer, 5 - Demo
  3.  game_name:array [0..29] of char;       //Game name
  4.  map_id_1:byte;                         //Map ID, first entry. Some entries are duplicated, can only speculate why.
  5.  level_num:word;                                //Campaign number, or something like that              
  6.  
  7.  //Player names
  8.  red_name,green_name,blue_name,gray_name:array[0..29]of char;
  9.  
  10.  //Player types: 0 - Absent, 1 - Human, 2 - Computer
  11.  red_type,green_type,blue_type,gray_type,alien_type:byte;
  12.  
  13.  unk104:array[0..4]of byte;             //Unknown array, only in 1.04
  14.  creation_time:dword;                   //Timestamp
  15.  cpuiq1:byte;                           //CPU level, first entry
  16.  
  17.  //Times of turn and end of turn, first enries
  18.  time_of_turn_1,time_of_end_turn_1:word;
  19.  
  20.  turn_mode_1:byte;                      //Turn mode: 0 - 'Turn Based, 1 - Simultaneous
  21.  map_id_2:dword;                        //Map id, second entry
  22.  time_of_turn_2:dword;          //Time of turn, second entry
  23.  time_of_end_turn_2:dword;              //Time of end turn, second entry
  24.  sgold:dword;                           //Starting gold
  25.  turn_mode_2:dword;                     //Turn mode, second entry
  26.  type_of_end:dword;                     //End condition: 0 - Turns, 1 - Score
  27.  amt_to_end:dword;                      //End condition amount
  28.  cpuiq2:dword;                          //CPU level, second entry
  29.  start_raw:dword;                       //Starting raw
  30.  start_fuel:dword;                      //... fuel
  31.  start_gold:dword;                      //... gold
  32.  start_alien:dword;                     //... aliens
  33. }
(Not exactly C++ syntax, but the structure is preserved)

After that, pass map - one byte per cell passability, then resource map as described above.
After the maps - player information: red, green, blue, gray one after another:
Here the blind spots become more obvious
DownloadSource code (Text):
  1. struct playerinfo{
  2.  FF1:array[0..39]of byte;               //Filled with 0xFF, no idea about meaning
  3.  plr_type:byte;                         //Player type, same as in header
  4.  unk0:byte;                             //Blind spot 1
  5.  clan:byte;                                     //Clan ID: 0 thru 7, sequenced as in the game.
  6.  
  7.  research:array[0..7]of resinfo;        //Research info, 12 bytes per type, with types going from top to bottom
  8.  //first dword - now researched, second dword - unknown, third dword - labs allocated
  9.  
  10.  score:dword;                           //Score
  11.  unk2:word;                             //Blind spot 2
  12.  unkarr1:array[0..92]of byte;           //Unknown again
  13.  FF2:array[0..11]of byte;               //Filled with 0xFF, no reason why known
  14.  unk1r:array[0..97]of byte;             //And another unknown
  15.  unk3:word;                             //Followed by one more unknown
  16.  selunit:word;                          //Selected unit id
  17.  zoom,xoff,yoff:word;                   //Zoom and offsets of the visible area
  18.  buttons:array[0..10]of byte;           //UT button states
  19.  unk4,unk5,unk6,unk7:word;              //Some more unknown values
  20.  loses:array[0..175]of byte;            //Loses of the player, one byte per unit
  21.  unk2r:array[0..9]of byte;              //Something...
  22.  goldused:word;                         //Gold used during the game
  23. }

That ends the static part, the stuff downrange from here goes somewhat cryptic.
There are unit updates tables, unit objects, updates objects, construction objects, all without an obvious structure i can cleanly define, the most common being - a word for object id, object type, object record. But there are also size-like intermittents in the stream, i can't find out the sequence of, only ignore.
It can be read nicely enough to do basic conversion to MGA in about 90% of times, but a lot is being lost and not known yet.

After the units part, there are scan maps and message log of some sort.

The current state of my save-game reader.
This one comes with both 1.04 and 1.56 version support, unlike the above one, that only worked on 1.56.
http://www.rumaxclub.ru/etc/maxse_081005_all.zip

.

shaktazuki Oct 05, 2008 11:04 pm
Subject: Re: resource stripper help

Quote:
Why should it?
Well, the purpose of this editor is for me to be able to compare the actual resource distribution of the game to my reconstruction of the resource distribution. I wanted to be able to see the entire resource map at once rather than having to pan the viewport. My screen is 1280x800, so I am able to spend about 7x7 pixels per square of map per bitmap and keep it all on one screen, or maybe 3x3 pixels per square per bitmap to have them both on the screen at once. That reqires a special font or symbol system to represent, then writing them to the bitmap correctly (from low y to high y) and it just seems like a long process. Ideally, I suppose I could use the game's resource icons...

Quote:
You wrote a BMP writer without knowing about how it works?
Nicely done, considering that it seem to work well.
Thanks. I had conceptually switched Y with X, assuming that it was outputting Y lines along the X axis; as it appears, BMP readers read them as scalines in the X direction along the Y axis, which you showed me. I had made that data arrangement assumption in my editor, which was my mistake.

About the savegame - thank you for that information! - have you determined where the victory conditions are stored? In one scenario, for example, the victory condition is to hijack 2 enemy trucks in 40 turns, and so forth.

Artlav Oct 06, 2008 2:19 pm
Subject: Re: resource stripper help

Quote by shaktazuki:
have you determined where the victory conditions are stored? In one scenario, for example, the victory condition is to hijack 2 enemy trucks in 40 turns, and so forth.
Unfortunately, it appears that the conditions are hardcoded into the game itself. There are "level" field in the save game header, that corresponds to the save file number in scenario/campaign menu.
If you swap the files, like scn 4 and scn 1, then select scn 4, you will go into scn 1, and all the descriptions and conditions will be for scn 1.
If you change the level field in scn 1 file to 4, then if you go to that scn, it will load scn 1 game, but show scn 4 descriptions, and will not respond to completing scn 1 goal, like destroy some building to win.

It is certain for campaign games, it is likely for single-player scenarios. There seems to be nothing in the actual save game file that shows any kind of correlation to victory conditions besides the default ones of turns and score.

shaktazuki Oct 07, 2008 1:19 am
Subject: Re: resource stripper help

Well, that sounds like a feature that can be added when AI is implemented: victory conditions (and perhaps scripted game events).

Aha! My next move is to display the resource results using SDL.

Eiko Dec 05, 2008 2:28 pm
Subject: Re: resource stripper help

by the way, are there any result from your resource distribution algorithm project? Smiling

Our algorithm really sucks. We had several times the situation, that one player found very much metall and the other almost nothing.

jarli Dec 08, 2008 7:13 pm
Subject: Re: resource stripper help

I put it aside until the mve player was done. I guess it's time to fire it back up, if there are no more MVE issues Wink