ShadowFlare's Realm
http://sfsrealm.hopto.org/cgi-bin/yabb2/YaBB.pl
ShadowFlare's Realm Forums >> Program Development >> 4.4 [GameSettings]
http://sfsrealm.hopto.org/cgi-bin/yabb2/YaBB.pl?num=1115848044

Message started by Julas.wtfwrongpass on May 11th, 2005, 11:47pm

Title: 4.4 [GameSettings]
Post by Julas.wtfwrongpass on May 11th, 2005, 11:47pm

I'm a bit confused. Should I treat GameSettongs just like Map&CreatorName - decode it just like it was a string and after decoding it check the bits? Seems a bit weird to me... Why would they encode bit information just like a string?

Title: Re: 4.4 [GameSettings]
Post by Soar on May 12th, 2005, 6:12am

Yep
Here's the reason of encryption(or we could not tell it encrypt, it is just a character transformation):
In packets transferred to server on Battle.net, the map info with map settings, map name and creator are packed as a string, without any null characters in it, so blizzard use this way to transform them.
The transform key byte(1st byte of each 8 ) is built follow this rule: After transforming, every character in the string is odd.

Where did I learn it? Don't forget that I once was one of the pvpgn developers, ;)

Title: Re: 4.4 [GameSettings]
Post by Julas.wtfwrongpass on May 12th, 2005, 2:27pm

Byte or bit?
I still don't get the reson of this transmormation. And what does it mean that the character is odd?

Title: Re: 4.4 [GameSettings]
Post by Nagger on May 12th, 2005, 3:14pm


Julas.wtfwrongpass wrote:
Should I treat GameSettongs just like Map&CreatorName - decode it just like it was a string

Yes. And it is a little bit weird.
But you dont have to. You can keep your old type of game-settings parsing.
With the new type the bits of all the game setting are better ordered.

from the old format.txt:

Code:

byte | bitnr | Description             
-------+-------+---------------------------------------------------------------             
0x0001
       |   0   | unknown (always set ?)             
       |   1   | == 1 means game speed set to 'normal'             
       |   2   | == 1 means 'visibility: hide terrain'             
       |   4   | == 1 means 'Full Shared Unit Control' was enabled             
0x0002
       |   0   | unknown (always set ?)             
       |   1   | == 1 means game speed set to 'fast'             
0x0003
       |   0   | unknown (always set ?)             
       |   1   | == 1 means 'visibility: map explored'             
       |   2   | == 1 means 'visibility: always visible' (no fog of war)             
       |   3   | == 1 means 'visibility: default'             
       |   4   | == 1 means additional players as observer allowed             
       |   5   | == 1 means 'Observers on Defeat'             
       |   6   | == 1 means 'Teams Together'             
0x0004
       |   0   | unknown (always set ?)             
       |   1   | == 1 if 'fixed teams' is set (both - bit 1 & 2 are set)             
       |   2   | == 1 if 'fixed teams' is set             
0x0005
       |   0   | unknown (always set ?)             
       |   1   | == 1 if 'random hero' is set             
       |   2   | == 1 if 'random races' is set             
       |   6   | == 1 means 'Referees'             


All the Bit0s are set to one due to the encoding method, so all the bytes have odd values (1,3,5,7,9,...,255). There will never be a zero-byte!
The setting for speed are separated in Byte0x0002 and in Byte0x0001, same for mapvisibility (byte 3 and 1).
This is also a result of the encoding. All the former Bit0-values are moved to Byte0x0001.
After decoding all makes more sense. All separated values are backtoback than. (see new format.txt)

But again, you dont have change your script. the old method is not wrong. it is just a cosmetic change.


[EDIT]
in fact the old format is wrong. not for the game settings, but for the [MapRecord] (the data between the the gamesettings and the map&creator-strings). As the mapchecksum changes due to the decoding.

If someone finds the algorithm for this checksum i will be really pleased.


Title: Re: 4.4 [GameSettings]
Post by Julas.wtfwrongpass on May 12th, 2005, 4:17pm

BTW I've simplified the encoding code a bit:


Code:
char* EncodedString;
char* DecodedString;
char  mask;
int   pos=0;
int   dpos=0;

while (EncodedString[pos] != 0)
{
 if (pos%8 == 0) mask=EncodedString[pos];
 else DecodedString[dpos++] = EncodedString[pos] - !(mask & (1 << pos%8));

 pos++;
}

Title: Re: 4.4 [GameSettings]
Post by Julas.wtfwrongpass on May 12th, 2005, 4:44pm

What am I doing wrong?

After getting the Game Name:

Code:
           $this->game['name'] = '';
           for ($i=0; $this->data{$i}!=chr(0); $i++) {
     $this->game['name'] .= $this->data{$i};
   }
           $this->data = substr($this->data, $i+1);


I immediately try to encode those strings:

Code:
   for ($i=0; $this->data{$i} != chr(0); $i++) {
     if ($i%8 == 0) {
       $mask = ord($this->data{$i});
     } else {
       $temp .= chr(ord($this->data{$i}) - !($mask & (1 << $i%8)));
     }
   }


but the first byte after null terminated GameName is 0, it goes like this:

[GameName] 0-byte 0-byte [the rest of the stuff]

Why there's another 0-byte here? Isn't it supposed to be the first control byte of the encoded string? Even if I try to start at some higher byte I still get weird results...
Are you sure that GameSetting and MapRecord are also encoded?

Title: Re: 4.4 [GameSettings]
Post by Nagger on May 13th, 2005, 2:03am

There are two nullbytes.
First one is the null termination for the game name. Second one is unknown/unused.
After that the encoded string starts (with first control byte).

So just change:
$this->data = substr($this->data, $i+1);
to:
$this->data = substr($this->data, $i+2);

Title: Re: 4.4 [GameSettings]
Post by Soar on May 13th, 2005, 5:43am


Nagger wrote:
If someone finds the algorithm for this checksum i will be really pleased.


We don't have to look this algorithm over, as we don't need to modify Map Settings/Name/Creator.
In my opinion, if you wanna get the algorithm of a checksum, you wanna modify the part which is used to generate the checksum.
That's why I find the algorithm of block checksum.

Title: Re: 4.4 [GameSettings]
Post by Nagger on May 13th, 2005, 9:59am

That's not exactly what i meant.

I did not want to modify the map-checksum. I want to validate the map. (And find the correct path - maybe to extract the minimap image)

Warcraft searches not only in the given mappath but also the map\downloads directory or maybe all the subdirs of the map directory. So warcraft has to scan a lot of maps.
Therefore i think the map-checksum of all the scanned maps is maybe not calculated ontime, but is stored in the mapfile itself. Where?

Title: Re: 4.4 [GameSettings]
Post by Soar on May 13th, 2005, 10:42am

I think it is just a checksum of the whole map file.
Blizzard don't search further dirs.
You can have a try, move(not copy) a ladder map into directory Maps\Download\, then you'll find the replay  not loaded.
The checksum algorithm might be D2 save style(each byte plus 1 and then shift left 1) or crc32.

Title: Re: 4.4 [GameSettings]
Post by Julas.wtfwrongpass on May 13th, 2005, 4:34pm


Nagger wrote:
There are two nullbytes.
First one is the null termination for the game name. Second one is unknown/unused.
After that the encoded string starts (with first control byte).

So just change:
$this->data = substr($this->data, $i+1);
to:
$this->data = substr($this->data, $i+2);


Dunnow why it works differently when I try this today :O
Anyway, after making explode() to split strings (divided by nullbyte), I get too many strings:


Code:
   [0] => x
   [1] =>
   [2] => `
   [3] => `
   [4] => &#65533;L!Maps\FrozenThrone\(4)Avalanche.w3x
   [5] => CB.Daydreams
   [6] =>
   [7] =>


And the MapName is somehow mixed with GameSettings...

Title: Re: 4.4 [GameSettings]
Post by Nagger on May 13th, 2005, 5:19pm


Julas.wtfwrongpass wrote:
Anyway, after making explode() to split strings (divided by nullbyte), I get too many strings:

explode() isn't the best function for this ;)
Some of the gamesettings-bytes may be sometimes zero and sometimes not.


Quote:
And the MapName is somehow mixed with GameSettings...

Right in front of the mapname is the map checksum which does not end with a nullbyte, so this isn't very astonishing...


For a first test just skip the first 13 bytes (4 bytes gamesettings + 5bytes unknown stuff + 4byte mapchecksum) of the decoded string. After that there are the three (well known) strings: mapname, creator and null-string.

Title: Re: 4.4 [GameSettings]
Post by Julas.wtfwrongpass on May 13th, 2005, 7:30pm

Ah, now everything seems to be clear. I'm gonna check right away ;)

Title: Re: 4.4 [GameSettings]
Post by Julas.wtfwrongpass on May 13th, 2005, 10:02pm

Ok, everything works :D

Title: Re: 4.4 [GameSettings]
Post by deerchao on Jun 18th, 2007, 6:14am


Soar wrote:
I think it is just a checksum of the whole map file.
Blizzard don't search further dirs.
You can have a try, move(not copy) a ladder map into directory Maps\Download\, then you'll find the replay  not loaded.
The checksum algorithm might be D2 save style(each byte plus 1 and then shift left 1) or crc32.


Anybody got this already?
As far as I know, it's not  a checksum of the whole map file. You can edit war3map.wts within the map file, but still able to watch replays made before modification.

ShadowFlare's Realm » Powered by YaBB 2.2.1!
YaBB © 2000-2008. All Rights Reserved.