TileEdit: first beta release is here

[Martin the Dane]

Hmm. I don't remember, but there's something in the help file about it (The exsact text is "At the moment we are not sure what the meaning of the Last Block is. It appears to have something to do with the Tile-graphics used for large areas of the same terrain type.") , so someone must have told me.

I'll have to look at it, but you are probably right.

[Martin the Dane]

Just spent som time playing with the last block. At first it seemd prommising. I saved a full ocean map, with one large patch of plains, exited CTP2 changed the last block and reloaded the map, this resulted in different placements of the different plains tiles.

Then just to se what would happen I loaded the map, without altering the .til file, and got a different combination of plains tiles. I then did a couple of maploads without exiting CTP2 and got the same result.

I then deleted all the last blocks from the tile-file, and repeated the multiple mapload, and again I got different combinations of plains tiles.

Finaly I painted large swaths of all the different terrains, and they all used a number of different tiles.

My conclusion is: The last-block might or might not have something to do with the distribution of the different versions of the same terrain.

I also did a quick check of the last blocks in the tile-file there are 13 of them and they all follow the same pattern:

(Number of sets : patern)
5 : 02 ## 01 ##
5 : 03 ## 02 ##
5 : 03 ## 02 ##
4 : 03 ## 02 ##
3 : 04 ## 02 ##
3 : 04 ## 02 ##
5 : 04 ## 02 ##
5 : 04 ## 02 ##
4 : 05 ## 03 ##
5 : 07 ## 04 ##
3 : 07 ## 04 ##
5 : 08 ## 05 ##
3 : 08 ## 05 ##

Where ## is a hex number

The first ## within a given last block is a sequence ie. A8, A9, AA, AB, AC, while the second is not. The second ## within the same block is within a few numbers of each other, ie. 80, 82, 83, 82, 83.

[Martin Gühmann]

Do you remember the image I did as I replaced the green hills with my purple hills? I got also a set of green hill tiles on my purple hills. There are also other set of terrain tiles that can't be explained by the tile rhules. So here is my suggestion use a terrain.txt in that every terrain uses the TilesetIndex. In my therory you will see other terrains on the map then, too. Then you can play around with the tile file. Well when I have time I will test it myself, so in the meantime here is a preprepared terrain.txt.

-Martin

[Martin the Dane]

I just updatetd TileEdit. So now the current version is 1.0.0.26

Changes from V.1.0.0.25

• Added automatic cutout of borders for tiles.
• Added register .til-file with TileEdit.
• Added a scrollable list of the apropriate resource to the Add/Edit Dialog.
• Added Reset .ini-file. (and optimized the .ini-file usage).
• ZoomFactor is now saved to the ini-file.
• Background and Shadow colors are now saved to the ini-file.
• Fixed a few bugs on the options page.
• Fixed iport of Tiles in InGame-Color-Mode, so the colors displayd are now correct.
• Fixed a size bug for the Add/Edit and Options Dialogs, I saved and loaded the sizes and not only the possitions to/from the ini-file.

As usual you can download the newest version of TileEdit and the patch from my CTP-page
Note that the patch only works for build 25!

Martin the Dane

[Martin the Dane]

As for the Last Block I do not have the time at the pressent to pusue that, so if somone do, please try to make some sense out of it. Or try locating some of the former CTP-staff and se if they can help.

[The Big Mc]

i did some research and it is promising i have found out loads

what i did was to replace some elements of the last block what i did was to leave the first section of each last block column but on one line a coped and pasted the last hen number form one up the column the result was that i got mountings sprouting up randomly in the deep water as for the meaning of the hex number i am stuck

[Martin the Dane]

What was that hex number? the one you pasted in? Well I guess it would also be interresting to know the one you replaced as well.

Reading your post made me think about the numbers. I have been thinking of them as either DWords (4 byte) or Bytes, not as pairs of words or as a word and two bytes.

The first LastBlock is:
02A8 0180
02A9 0182
02AA 0183
02AB 0182
02AC 0183

Or in plain numbers (two Word)
680 384
681 386
682 387
683 386
684 387

And as Word, Byte, Byte
680 1 128
681 1 130
682 1 131
683 1 130
684 1 131

Does this have something to do with swamps as 680-684 are TileSetID for swamp or ?????

If the first Word is a TileSetIndex they all have somthing in comon: The tiles they refer to does not fit any TileRule.
The only other tiles that does not have a matching TileRule are the ##99 tiles (the one used where there are no matchin borders) four ##04 and the one with TileSetID 2205

I have attached a text document with the last blocks of the original Activision TileFile. (makes it easier to match them with the TileSetID's) I have made three sets of colums the first is in Hex the the last two in Decimal. The first deimal colum is Word Word, the second is Word Byte Byte.

I love the power of RAD

[The Big Mc]

yes if you change them you should get the other tile in the place

[Martin the Dane]

You meen if I change 02A8 in the first LastBlock to say 0772 I'd get desert mountains in stead of swamps in some places?

[The Big Mc]

Yes I know sound funny doesn’t it

But this is also a clue it means that some were in the code or the other section of number (or numbers) there is some kind of marker that says were it belongs but if activsion were going to put it in the source code it would be stupid to include a last block at all

Here is the last block with the representative terrain types at the side may be help full

5 02A80180 02A90182 02AA0183 02AB0182 02AC0183 // marsh
5 03290200 032A0201 032B0204 032C0201 032D0202 //mountain
4 03250200 03260202 03270202 03280202 //mountain
4 03870240 03880242 03890241 038A0242 //hill
3 04380280 04390282 043A0282 //shalow ocean
3 043B0280 043C0283 043D0283 //shallow ocean
5 04A102C0 04A202C2 04A302C3 04A402C2 04A502C2 //deep ocean
5 049C02C0 049D02C1 049E02C2 049F02C3 04A002C2 //deep ocean pit
4 05C80380 05C90382 05CA0382 05CB0382 //continental shelf
5 077204C0 077304C2 077404C3 077504C2 077604C1 //desert mountings
3 077704C0 077804C1 077904C1 //desert mountings
5 083A0540 083B0542 083C0543 083D0542 083E0541 //white mountings
3 083F0540 08400541 08410541 //white mountings

[Martin the Dane]

but if activsion were going to put it in the source code it would be stupid to include a last block at all

Well dosn't mean they didn't do it. The sprites has loads of stuff that is required for the makespr program to work, but was never actually used by the game engine.

Now I'll have to look into it But it'l have to wait till I get that Sprite Editor up and running.

[Martin the Dane]

Just found out why I couldn't replicate your findings befor. It appears that the LastBlock is only used when the map generator crates a map, not when you do it by hand in the editor or load a saved map. Actualy the tiles placed using the last block are removed when loading a saved map within the editor.

This will complicate matters a bit, but now that I know it I have a chance of finding out what's going on.

[The Big Mc]

I also found something interesting the unknown section also appears to be directional i got to do more testing but if I am right I could be on to something

[The Big Mc]

scrap that

this however is realy cool if you chang the number 3 to a 5 in the deep sea pit you get the tile apering on hills

it also works if you copy the last block to make 14 lastblocks

[Martin the Dane]

Thanks Mc.

You pointed me in the right direction with that deep-sea-pit, first I played around with the end values and noticed that they were indeed directional values. I then noticed that shallow water, TileSetIndex 10, was 028x while deep sea, TileSetIndex 11, was 02Ax. I then checked the other values an found out that if I treated the second Word as 4 octets (4bit) and not two bytes (8 bit) for all values the first 3 octets of were in deed 4 times the TileSetIndex.

The format is as follows:
bit value
( 0..15) First is the TileGraphicsID (as we have known for some time now)
(16..25) Then comes the TileSetIndex, as a 10 bit value!!!!! nope it's neither a word nor a byte value.
(26..31) And finally a 6 bit directional value

Who on earth thought that one up??????????? I mean why not use a byte for each of TileSetIndex (as in the TileID) and DirValue?

OK the positive side of it is that now I can create an interface for the LastBlock, and tile-artists can now create better looking terrain. And nobody else need to bother with the odd way of splitting a 16 bit Word, I'll let the interface handle that.

The change to "understanding the tile file.txt" is:
The sixth block: Variation rules
This is meant to create variations within large swaths of the same terrain types, most noticeable is the deep-sea pits scattered over the ocean floor.
Each Rule can have up to 5 elements, each consisting of a TileGraphicsID, a TileSetIndex and a directional value.
The Directional Value can be from 0 to 4, and is relative to the previous tile in the list.
0 = First
1 = North-West
2 = North-East
3 = South-East

Graphically it can be displayed as follows:

   1   2

     0 

   4   3

An example - The deep sea pit :

Graphics      TileSetIndex DirValue

 hex/deci

049C/1180     11                 0

049D/1181     11                 1

049E/1182     11                 2

049F/1183     11                 3

04A0/1184     11                 2

The result looks like this

    2       2

1      3

    0