Maps received the most attention; the current format was too unweildy. All maps were now stored as "lumps of lumps"; each lump complying with the general lump format. However, there was an additional stipulation: sub-lumps must appear in the following order: .MN, .MD, .T, .P, .N, .E, .D.
All maps are named using the "new" convention XXX.MAP, where XXX is the ID of the map, padded with zeroes.
Consists of a single null-terminated string: the map's name.
Contains 20 integers, laid out in the standard MAP format. Compression on this lump was deemed un-necessary; there's just not enough space to save.
Unchanged from its standard format; except that the BSave header was removed.
Using the width and height from T, passability is encoded as a bitstream. A "0" in the bitstream means "all bits off", and a "1" means that the next 8 bits contain passability information for this tile, in the standard format.
For example, the hex bytes 13 01 80 translate to the binary string 100110000000110000000, which means the next five tiles have passability ids of
00110000 (block south & west)
10000000 (block north)
Each .N sub-lump contains a one-byte header indicating the number of NPC definitions contained within. Following this header are the records, in the following format:
|BYTE||ID of this NPC (to accomodate null NPCs)|
|15 INTs||Data as defined in N, except that offset 3 (the speed) is replaced with the actual speed. And the npc's picture is incremented by one; an id of zero now means "no picture+". Compression, again, was deemed insignificant and not worth implementing.|
|BYTE||Number of instances of this NPC|
|2 INTs and a BYTE for each instance||x position, y position and direction (see L) of this instance of the NPC|
+ Walkabouts with every pixel in every frame set to 0 are deemed "null", and are not saved into the resulting XRPG folder.
Enemy maps usually contain a lot of one number (be it zero or some formation set) and a handful of other numbers. This makes it the perfect candidate for prefix-free code replacement. The first byte of this sub-lump contains the number of dictionary entries. For each dictionary entry, a byte follows with the value of that entry. It is implicitly assumed that dictionary entries will be numbered as follows:
Then, a bitstream follows representing the foe-map.
An example will help to make this clear. Suppose we have the following hex steam: 05 00 05 01 03 02 00 01 6E BA 0E... This translates as follows
|05||There are 5 dictionary entries|
|00||The bit "0" corresponds to "0"|
|05||The bits "10" corresponds to "5"|
|01||The bits "110" corresponds to "1"|
|03||The bits "1110" corresponds to "3"|
|02||The bits "11110" corresponds to "2"|
|00 01||00000000 0000000||The next 15 tiles have no enemies|
|(01) 6E||10 110 1110||The next 3 tiles start battles with formation sets 5, 1, and 3, respectively|
|BA||10 1110 10||The next 3 tiles start battles with formation sets 5, 3, and 5, respectively|
|0E||0 0 0 0 1110||The next 5 tiles start battles with formation sets 0, 0, 0, 0, and 3, respectively|
Doors no longer have IDs, on the observation that it's very rare for multiple doors to link to the same destination door. Instead, this sub-lump contains a number of 7-integer records, in the following format
|INT||Source door's x-position|
|INT||Source door's y-position + 1|
|INT||Destination door's x-position|
|INT||Destination door's y-position + 1|
|INT||Destination door's map ID|
|INT||First conditional tag ID|
|INT||Second conditional tag ID|