Difference between revisions of "RGN Format"

Latest revision as of 09:13, 12 March 2005

RGN Format (version 1) is a format which was used to encode files (ending with .RGN) containing region information. This format is now deprecated, and replaced with the ELVL Format which contains region information inside the .lvl file. Nonetheless it may be useful to understand a version 1 region file if you come across it. Continuum Level / Ini Tool is capable of loading regions from a version 1 region file, and translating them to version 2 (eLVL) regions.

The Format

A version one region file uses the extention .RGN and is an ascii file (meaning you can open an edit it in any simple text editor, like Notepad). There format contains two parts, a header, and the region definitions. Lines begining with a semicolon(;) are comments and are ignored. Blank lines are also ignored.

The header is the first line of text in the file. This must be:

asss region file version 1

If the header is incorrect, you do not have a valid version 1 region file. After the header you can define your regions. Regions are defined as sets of rectangles of Tiles (not Pixels). A region can also have an optional isBase flag, meaning that it's a base. Each region must also have a unique name (not a limitation of the format, but you can't define a region in two parts in the same file and expect it to work). Let's look over an example encoding of a region:

Name: MyBase
| gutkataj
| da5talal
| pxu3asai
isbase

The name is encoded after the "Name:". This is the name of the region you are about to define. After the name we have our rectangle defintions. These lines start with a '|' and then another character (space is used here). They are then followed by 8 characters (a-z, 0-6). These tell use the rectangle encoding. In the above example we have a single rectangle encoded as "gutkataj". The first two are the x encoding, and the next two y encoding of the upper left tile contained in this rectangle. The next two pairs of letters are the width and the height. So we have:

x      -> gu
y      -> tk
width  -> at
height -> aj

Now each one of these character represents 5 bits of encoded data. To encode 0 we would use 'a', to encode 1 we would use 'b'. This goes all the way up to encoding 31 which we would use '6'. You can treat each pair of letters as 10 bits put together to make a single number that is 0-1023 (conveniently these are the only tile that a map can have). We could get the x by doing something like decode(g) * 32 + decode(u). decode(g) would give us 6 and decode(u) would give us 20. So the x coordinate encoded would be 6 * 32 + 20 or 212. We could similiarly find the y, width, and height of the encoded rectnagle. All these rectangles together make up the encoded region. Here is an example of a complete version 1 region file:

asss region file version 1
;file generated by Continuum Level / Ini Tool by 2dragons / Bak

Name: spawns
| da5talal
| p56qafaf
| pxu3asai
| gutkataj
| iy4xahah
| fbtnagai
| oztyafag
| qqnuafai
| de2hagah
| zz5vataj
| gx4xaiai
| kiraahaj
| 2s2kagah
| desoanah
| 2qspamah
| pwmqaoaj
| dqpqanaq
| ebmraiai
| 1hmaaoai
| namaapai
| 2mspaqah

Name: lefttunnel
| deseanak

Name: righttunnel
| 2nseanal

Name: cavetooutside
| dapqaoaq

Name: outsidetocave
| pxmganak

Name: basenturrets
| dankagag

Name: nred
| dqoaalba
| d2otbfan
| epoqarax
| d2oaafar

Name: nyellow
| eamsbabo
| d4oaatar
| dymha2al

Name: nblue
| eamaapas
| eamsbabo
| d4oaatar

Name: npurple
| fpmabbbo
| fkmaafao
| fhmaadac

Name: basenwin
| fqnqaqaq

Name: nbase
| damaaqbq
| dqmadaaq
| fqmqbabq
| eamqbabq
| dqoababa
| eqoqaqbq
| dapqbqaq

Name: nmines
| dknkagag