Maps/GNS

GNS files are just indexes of the other files in the MAP/ directory.

Their overall structure is:

1. A number (x) of 20-byte records specifying which files to use for a given day/night, weather, and room arrangement situation.
2. A number of 20-byte records that appear to be padding because they're all identical.
3. About 20 bytes of unknown data
4. About x 20-byte records of unknown data
5. 24 bytes of unknown data

Section 1

Here's the top of MAP001.GNS:

  0000000: 2200 0000 0117 3333 2b27 0000 0000 0200 5566 7788
  0000014: 2200 0000 012e 3333 6b27 0000 0098 0000 5566 7788
           AAAA BBCC DDDD aaaa EEEE      FFFF FFFF bbbb bbbb

Each 20-byte record represents a file in the MAP directory. The first few bytes indicate the conditions under which it is appropriate to use each file. Then there's a pointer to the file and an indication of its size.

• A is always either 0x22, 0x30, or 0x70, but its purpose is unknown.

         - Talcall here, this header is used to grab an appropriate script variable when the map data is refreshed (see 000f3718 - 000f4ac8 line 000f3928). seems like only 0x30 is a known variable...

• B is a room arrangement ID number. (Some maps have a version with chairs and a version without, for example.)
• C is the time of day and weather.
  • highest bit is day/night:

    0x0 = Day

    0x1 = Night

  • next 3 bits are weather:

    0x0 = No Weather

    0x1 = No Weather Alternate

    0x2 = Light Weather

    0x3 = Normal Weather

    0x4 = Heavy Weather

• D is a file type indicator.

  0x1701 = Texture Resource File

  0x2E01 = Mesh Resource File containing the Primary Data

  0x2F01 = Mesh Resource File for a state containing data to be overridden

  0x3001 = Mesh Resource File for an alternate state

  0x3101 = means "ignore this row", AFAIK (see Section 2)

• a appears to be padding
• E is the LBA block number (CD sector number) where the file is located.
• F is the length of the file

  Rounded up to the next CD sector boundary. (Divide this number by 2048 to determine the number of sectors to read)

• b appears to be padding

Section 2

Following section 1, there are a number of rows that are all identical to each other. In MAP001.GNS, there are 35 of them. They all look like this:

  0000320: 2200 0100 0131 3333 252c 0000 0018 0000 5566 7788

These extra rows appear to follow the same pattern as the rows in Section 1, but they all have 0x3101 in field D, and fields E and F have the same values as E and F from the last row of Section 1.

The purpose of these rows is unknown. When map2gl finds the first such row, it stops reading the GNS file.

Section 3

20 bytes of unknown data. In MAP001.GNS, this is:

  00005dc: 2200 0000 0180 7706 d495 6653 6709 0000 9400 3a53

The first 4 or perhaps 6 bytes look similar to Section 1.

Section 4

More rows of unknown data that look a little bit similar to Section 1. In MAP001.GNS:

  00005f0: 2200 0000 0186 0000 1400 0000 2211 4433 6655 0000
  0000604: 2200 0000 0188 0000 1400 0000 2211 4433 6655 0000

Fields A and B closely mimic the sequences found in Section 1, suggesting that this is extra data for each of the map's arrangements and weather conditions, but field E is always 0x14 and there is no file at Sector 0x14 on the CD. It also appears that field F is padding in these rows (0x11223344). Talcall - "86" and "88" in this example ask the game to clear indoors (0x86) and snow (0x88). if 0x88 were instead 0x89, the map would only snow. (see: Fort Zeakden)

Section 5

More unknown data. Does not appear to follow the pattern of the other data. In MAP001.GNS:

  0000938: 2852 b036 288a 0000 1c00 0000 0000 01fd 1100 0304
  000094c: 2200 0506 3300 0708