Research the changes made in GAT version 1.3

[rdw-software]

GAT 1.3, GND 1.6 and RSW 2.6, the waterinfo is still not correct for those new, they removed waterinfo in RSW 2.6 and moved it to GND 1.6 (they changed that somewhere between 2021-11-03 and 2021-11-16)

Source: Discord

[rdw-software]

Example file: icecastle.gat

Observations:

• There are no leftover bytes that are unaccounted for
• The file can be parsed with the 1.2-compatible decoder I wrote just fine (no errors)
• The map's terrain (height map) can be visualized without issues

The results seem to be correct, as well:

This strongly implies the file structure wasn't changed very much. It might be the terrain types were updated? This could necessitate a minor version bump, as the file could conceivably contain terrain type IDs that older clients might not know how to interpret?

This is pure speculation so far. Something does seem off with that ID since some entries should be invalid (2^31), but I need to check out some older maps first to see if it's actually a problem introduced by this version or just something I overlooked earlier.

[rdw-software]

I've so far assumed the terrain type is simply one signed 32 bit integer, with values in the interval of 0 to 6 (as implemented by ROB and various other projects). Analysis of all GAT files using version 1.2 shows that this works and all the values that occur are indeed in this interval, i.e. the first 16 byte (second in the file due to Little Endian) are always zero.

Something however doesn't add up with the new version, since some (or even all?) of the 1.3 files violate this criterion, with values such as 2147483653 or 2147483648 appearing in clock_01.gat and 2147483649 in 1@exsh.gat if interpreted in this manner. So I decided to read two separate 16-byte values instead of the one 32-byte integer, which confirms my suspicions.

Whether reading signed or unsigned, the result is always the same. The terrain type lies in the above interval, and the other value is zero when reading only the old GAT files:

Now, let's try reading the new GAT files also, interpreting the first value as signed 16-byte integer:

Trying the same, but this time reading an unsigned 16-byte integer:

Now, what is the purpose behind this change? It's clearly not an accident as it required updating the version number. My best guess at this time is that they wanted to add some information without using up more space, so they discarded the useless bytes from the terrain type and put something else in there... except only one value is used, for now.

Might be worth keeping an eye on to see if other values pop up, but unless there's a way to test things with an updated client I don't think I can do much here. In the meantime, some random ideas and notes:

• It might be two 8-byte values, as the second can be interpreted as such and would yield a non-random looking value
• One could be a minimum (often zero) and the other either zero (empty interval) or some maximum?
• The info must be related to the terrain somehow?
• It is likely to be related to the updates to GND and RSW that occured at the same time

[rdw-software]

Nevermind, it's much simpler:

The blue tiles are those that have a nonzero (always 0x0080) byte, or flag of 128 (or -128 if signed) when interpreted as a 8-byte integer.

Clearly these are the tiles that match the vertices of the water plane, or rather "ice" (fitting with the theme of episode 19), when frozen. Can players walk on ice in these zones? I wonder what the gameplay purpose is, if any, or whether it's just meant to render the water plane as ice in these locations? Could be something else entirely, of course.

Either way, not much to do here unless I find some more footage of the new zones to investigate how it might affect the client.

[rdw-software]

Pretty sure this is the exact map: https://youtu.be/3a9_UKpHALo?t=966

I don't understand a word of Korean, but it looks like there is indeed ice, though it doesn't appear to be walkable. Even if you could, why wouldn't they just make it a regular walkable area? There has to be more to it. The regular "icy water" areas clearly aren't walkable, since there are even bridges to walk across the river (shown later in the video).

Why does the client need to know about the presence of the water plane at all, in these areas? It has to be relevant to the placement of objects (or units) somehow, I guess? And then of course it's been introduced alongside the RSW/GND changes that added some info to the water plane's properties (looks like a "wind" or rather "surface disturbance" effect). Which, of course, doesn't really affect the terrain altitude now, or does it?

Very curious, I must say.

[rdw-software]

One other peculiarity: It seems like there are multiple different water areas in icecastle.gat, at different heights: Sea level, then the frozen river at a slightly elevated altitude, and finally the upper parts (above the waterfall). I guess that wasn't possible with the old format, if the vertices of the water plane are simply rendered at the map's water level (stored in the RSW, and now GND).

In that case, one might feel inclined to eliminate the water level property and use only these flags, however, so that can't be quite all there is to it since it's still part of the new GND format. Also, only a few of the new maps actually use this water flag, but there is at least one that must have a water plane (judging from the visualization), but has no such flags. If it simply defaulted to the regular water level, then there is still no purpose in storing the same info twice since it might as well be stored here and not in the GND.

[rdw-software]

Added via d15218b.