Jump to navigationJump to search
This article is about the OHRRPGCE FMF project, which is an alternate implementation of the OHRRPGCE for Java mobile phones. Technical implementation details discussed here should not be confused with those of the RPG format

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:

Data Meaning
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

Hex Binary Meaning
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

Data Meaning
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
List of Lumps specific to the XRPG format. Other lumps comply with existing .RPG lump specifications.

HEADER.LMP . _FNT.png . .PT4_# . .PT6_# . .HERO_#.png . SEZ . EFX . BFF . FOE . _TIL_#.png . _MXS_#.png . ###.MAP . HRO . ATK . SCRIPTS_#.HF . SCRIPTS.LST