New things about the TILEATR files

[shai]

I decided to look back into these and found some new things. First, each block has four bytes (not new, obviously), and the first two or the last two bytes can be swapped with others to make blocks with strange characteristics (00 40 01 40 makes a block infantry only and slows units down). The 00 40 makes the block infantry only and the 01 40 slows down units. It's better explained on the wiki page.

 

I haven't tested it but, you may be able to switch them around and get the same effect (01 40 00 40). 

 

Also, when I was testing this I found that making the last bytes FF FF or 5E D7 turned it into spice, and harvesters try to harvest it, but just go to the bottom right corner of it.

[THE AQIB]

nice shai..

now I can fix my tileset..

[shai]

After some more testing I accidentally found that making a block 00 40 10 40 instead of 00 40 01 40 makes a block that only infantry can go on and slows them down, BUT it turns into spice as well, so it seems that a block has 4 characteristics instead of just 2. 

 

EDIT

 

Making it 00 E0 00 00 makes it buildable, but it is still black (The second block on BLOXBASE, the one I use for testing), so it seems the third changes how it looks, it seems that anything between 01 and 0F makes it it's normal appearance, and anything above 0F makes it into spice . 

 

So, it seems that the first and third byte change the looks and the second and fourth changes if it can be built on/what units can go on it.

 

Interestingly, making the first byte 4B made the game crash with a "Two units are on one block" error. The crash was because I had units on the blocks I'm editing, but when I removed them it turns into spice, BUT the courser says that units can go on it, but they can't. Also, when a stealth Fremen walks right up to it, it uncloaks which I think is something they do when they walk up to an enemy. In the map editor spice is treated like a unit, so I guess it can be spawned like one too. Changing the second byte also seems to change if the crater is sand, dirt or nothing. 

 

The locations of the spice in the tileset seems to be hardcoded, because changing all their values in both sections to FFFFFFFF did not affect the harvesters AI. 

Edited February 2, 2014 by Shai-Gel98

[mvi]

Shai, have you tested the bit field stuff I've written on that page. I seem to recall that's how TILEATR* files are structured and I looked at the actual parsing code to work out those bit field values, so that should be a complete list. Looking at the individual bytes is the wrong approach, you should look at each four bytes as a bit field instead.

 

Example 1 - Determining what an existing value means:

Hex:

00 E0 00 20

 

Reverse the byte order (to go from little-endian to big-endian): 

20 00 E0 00

 

Convert to binary:

00100000000000001110000000000000

 

This has four flags set, if you check the bit field table, you'll see:

 

00000000000000000010000000000000 - Drive On

00000000000000000100000000000000 - Infantry On

00000000000000001000000000000000 - Build On

00100000000000000000000000000000 - Unknown (infantry related?)

 

Example 2 - Creating a new value based on desired attributes:

 

If you wanted to create a new value for a tile, let's say we want to be able to build on it, have infantry walk on it, but they have to walk slowly, we'd use:

 

00000000000000000100000000000000 - Infantry On

00000000000000001000000000000000 - Build On

01000000000000000000000000000000 - Slow Movement

 

Then combine them to get:

 

01000000000000001100000000000000

 

Convert to hex:

 

40 00 C0 00

 

Then reverse order back to little endian:

 

00 C0 00 40

Edited February 20, 2014 by mvi

[Nyerguds]

Um, that last conversion back to hex failed; that should be 40 00 C0 00 :P

[mvi]

Um, that last conversion back to hex failed; that should be 40 00 C0 00 :P

Thanks, I've amended it now

[Nyerguds]

Can't slip binary past me, heh. Something with one eight and a lot of zeroes is clearly only a single bit ;)