textX.dat, .bbm, .map and .rx decoded

[harold]

The K&M files text0.dat through text3.dat, the .bbm, the .map and the .rx files have all been decoded but the information is not on the site.
If it's not known, I have it. (Krom told me how the rx files worked)

Krom also knows a bit about mapelem.dat, which he told me, if that's needed.

ps: the textX.dat files are longer than I would expect, so I don't know 100% about them. Could be information about the water-movement appended to them or something.. it would be rather hard to find out though

[Merchator]

What are the text0(3).dat-files including?

[harold]

terrain tiles, they are indexed like the graphics in rx (the bytes index a colour from a pallette) but there are more bytes than one would expect (more than width * height + 8)

[Litude]

I think quite a lot of those files have been decoded and the decoding section has not seen an update on a long time (I guess it was in 2006 the last time ), other than the recent minor layout change.
If someone has documents or notes or whatever I could put them on the site, but without anykind of notes I can't go increasing the decoding % as it won't be too useful to the user will it?

[harold]

Ok here it goes

bbm files:
Starting at an offset of 48 from the beginning of the file, there are 256 3-byte RGB values, each defining a colour. The first one (the blueish colour) should be transparent, note that this colour is indexed with the value of 0 (zero).

textX.dat files:
these are the texture files for the terrain tiles. Each tile on them is 32 x 32 while ingame they are usually 40x40. (in TKE i used to have them 32 x 32 for this reason, until I saw that the buildings didnt fit onto it)
First there are 2 int32's for the width and height, but they are fixed anyway (256 x 256) so you do not need them. What comes after them is more interesting: each byte indexes the aforementioned colours in a bbm file! An index of 0 (zero) meaning that the pixel is to be transparent.

RX:
the RX files are collections of textures (all indexed colours in the same way as textX.dat files), they start with an int32 for the number of textures in them. After that come that many bytes which can be 0 or 1, if a byte is 0 it means that the texture has been removed - so there is no data defining it. This means that any indexing that is done on these textures must be offsetted at every place where a texture has been removed, it also means that you can not extract that number of textures from the RX file (you would end up trying to read beyond the end of the file).
After these enabled/disabled bytes, come the real textures. Each texture entry cosists of 5 parts, a width, a height, a X-origin, a Y-origin and pixel data. Width and height are int16's, while the origin consists of 2 int32's. (note that this is useless since those values never exceed the range of 16bit values). The pixel data once again is a byte per pixel, indexing a palette.

PS: cannot post the map description yet - no links allowed until 5th post

[Litude]

Thanks for those, will add! As for the map description file, you ain't talking about the one by The Barbarian? I remember recieving an e-mail from The Barbarian some years ago where he made it quite clear to me that he did not like how this document was leaked (I know by whom, but no names will be named here) and spread across the internet. For some reason I don't think I want to put it here (unless someone has proof that he has changed his mind). It's just that I wouldn't either want someone to put anything I have made somewhere random against my will. Just isn't fair.

[harold]

Oh I didn't know that..
I guess it wouldn't matter if I'd put my own description here though?

[Litude]

Yeah, feel free to post your own description.

[harold]

map file structure:
int32 width
int32 height (note that while you could theoretically make maps bigger than 256 x 256, KAM doesn't like this)

width * height times a tile-struct:
byte Type (indexes the tile textures, 0 through 63 is text0.dat, etc)
byte Unknown
byte Height (defines the height of the left upper corner of the tile)
byte Rotation
byte Lighting/unused (does not appear to have any effect)
byte Object (trees, rocks, etc)
byte Usage (walkable / buildable)
16 bytes unknown (usually zero)

resource record:
no idea how it works

[JBSnorro]

I noticed as well that some things are decoded and thought i'd make a new topic about it, but Harold beat me to it
Anyway, it still says 0 %, but I know it hasn't even been a week yet....
The .bbm-files are btw not entirely decoded, say 80 %, the end still contains some unknown data.

ps: the textX.dat files are longer than I would expect, so I don't know 100% about them.

And when Harold said that, I think he meant the .bbm files instead of the textX.dat-files. The textX.dat files ?re fully decoded, since they only contain the images of the various tiles.

[Lewin]

Hi everyone, I have found more on decoding.
One day when I was searching the dutch forum with babel fish, I found a page about the lib files. It makes more sense to me than what you have got at the moment. It was posted by the guy who made the TSK briefings editor.
For people who don't speak dutch:
Go Here
For people who do:
Go Here
Maybe someone dutch could translate it better and you could use it?
Lewin.

[harold]

I noticed as well that some things are decoded and thought i'd make a new topic about it, but Harold beat me to it
Anyway, it still says 0 %, but I know it hasn't even been a week yet....
The .bbm-files are btw not entirely decoded, say 80 %, the end still contains some unknown data.

ps: the textX.dat files are longer than I would expect, so I don't know 100% about them.

And when Harold said that, I think he meant the .bbm files instead of the textX.dat-files. The textX.dat files ?re fully decoded, since they only contain the images of the various tiles.

They're also too long, they would be 65544 bytes but they're not
but indeed the bbm files have something extra in them as well

[JBSnorro]

Maybe someone dutch could translate it better and you could use it?
Lewin.

A translation at request, aslo a summary of the entire topic on the dutch forum:
You can download a program with which you can edit the strings in KAM TSK(and perhaps also TPR) here.
With that program you should open the setup.lib-file.
Don't forget to back it up before you start editing.

Some people had already tried editing the texts, but KaM refused them if the stringlengths weren't exactly the same as before.
Anyway, legionairy2 found out the structure of the setup.lib:
first 8 bytes unused/unknown.
From there on there are 219 shorts, each containing the total lengths of a string. This may sound weird but this is what I can make from Legionairys descripting. It says that the found short contains the length of alll strings found so far. So the actual stringlength would be the found short, minus the previously found short.

The strings start at byte 446(=8+2*219).
Each string ends with 0b00000000.
This terminationsequence can be found at 446 + the short found before.

So if a string is altered, the shorts should also be edited, otherwise KaM will fail.
There are also a lot of FF FF bytepairs, which should be ignored, they are probably the remains of deleted strings.

[Litude]

Well, that information about the lib files has been available in the decoding section since... 2005? I gotta admit it is kinda strange to store the length of the strings like that... But maybe they didn't want to make the game that easy to hack.

[Lewin]

I know you already have stuff about it but I think this version explains it much better. The one you have at the moment doesn't make much sense to me compared to this one. Maybe you could put both of them?

Well, that information about the lib files has been available in the decoding section since... 2005? I gotta admit it is kinda strange to store the length of the strings like that... But maybe they didn't want to make the game that easy to hack.