Home and Links
 Your PC and Security
 Server NAS
 DVD making
 Raspberry Pi
 PIC projects
 Other projects
 Next >>

Crimson Fields Terrain Tile definitions

CF Tile defs.

How Terrain Tiles are defined

The terrain tile 'images' (icons) are all held together in the single file /gfx/CFTiles.bmp. The definitions (control parameters) are in the /tools/default.tsrc text file. These two files are combined (by the mktileset.exe tool) during the crimson source 'make' sequence to generate the run-time 'compiled' file, default.tiles

The first 8 icons in the CFTiles.bmp are 'specials', used by the software for showing possible movement etc. The rest of the file contains actual visible Terrain.
Each entry in the .tsrc definitions file 'references' one of the tile image icons in the .bmp file (counting from 0). The first entry in the definitions file ("HQ [player 1], north") 'points at' tile icon 9 (the second points at 10, the third at 8).
When the tile definitions and icons are 'complied', the order of tiles in the definitions file (which is also the order in which CoMET displays tiles) sets the Tile 'ID code'.
The combat Map uses the 'ID code' and NOT the icon number !!
So if you change the definitions order (eg so that CoMET will display a new tile 'next to' similar existing ones), you have to modify all the combat maps to the 're-align' the tile ID codes
To help you, in the .tsrc file, the 3 digit Tile ID codes are shown in the 'comments' line (eg "# 000: headquarters [player 1], north")
Combat maps (.src / .lev files) contain a reference to the (compiled) .tile (and .unit) files used for that Map. This allows you to have multiple tile (& unit) pairs and 'call up' the 'right' pair for your map (eg. for "ww1" maps)

NOTE. Building 'entrance' tiles MUST be defined (in .tsrc) in the order sequence 'Player 1' (brown), 'Player 2' (blue), 'neutral' (grey). This is because, when a building is captured, the 'entrance' tile is swapped AUTOMATICALLY for the next appropriate colour one

This, of course, need not be the same as the bmp order. In fact, the first 3 defined tiles reference icons 9,10 and then 8 (rather than 8,9,10) to get the Player 1 (icon 9), Player 2 (icon 10), Neutral (icon 8) .tsrc order correct

CoMET (the map editor) tile display

CoMET displays the tiles in the order they are defined in the .tsrc file (i.e. Tile ID order). The tiles are shown in 94 rows of 4, giving 376 'slots' containing the 375 tiles (the last 'slot' is unused).

The displayed tiles start with the 30 building elements (including the 'under construction' set), then, after 13 'normal' terrain tiles (starting at tile 40), 11 'blank' tiles appear. These 11 Tile ID codes are all set to 'Icon 1' The 11 'icon = 1' Tile ID codes are #039 to #049 inclusive. The odd thing is, only #045 is actually 'marked' as 'reserved' in default.tsrc (the other 10 all have 'valid' definitions !) Next we have ID #051 which is the first of the 15 'air strip' type tiles (hangers, runways etc). This is followed by 62 'normal' terrain tiles (including woods & hills) before the first of the 'tank traps' (where tile icon 103 = 'dense tank traps on grass', is used twice for both ID #130 and #131 :-) ). NB. Tile #307, icon=33, 'swamp' artwork, when seen 'on screen', appears REALLY weird :-)

How many tiles are there ?

The terrain data set (.tsrc) contains 375 ID's (#000 - #374) of which 11 'point' to 'Tile 1' (which is solid black). So there are 364 'actual' tile definitions. However the tile artwork (found in CFTiles.bmp) consists of 16 rows of 24 tiles = 384 bitmaps, so what's going on ?

The first 8 (0-7) tile bitmaps are 'specials, so don't appear in the definitions file. These specials are  :-
Tile 0 = transparent with a 'dotted' red border, used to indicate 'valid' moves.
Tile 1 = solid black & is used by the 11 'reserved' Tile ID code (all point at this icon) & maybe for the map edge fill in ?
Tile 2 = dark grey with left black edge & right white edge & used in the 'sundial' unit combat graphic
Tile 3 = transparent with a solid red border & used for ?
Tile 4 = transparent with a silver border & used for 'unit select'
Tile 5 = transparent with a 'target' overlay & used for 'attack' selection
Tile 6 = transparent with a 'red dot' overlay & used to indicate that a unit has already moved this turn
Tile 7 = transparent with a 'target box' overlay & used for artillery target selectionThe 'specials' are like 'units' in that they contain 'transparent' pixels allowing them to be 'overlayed' on top of other terrain tiles. Of the 'specials', only Tile 1 appears in the definitions file (.tsrc) and then only to define a 'unused' code.
In addition to the 8 'specials', there are also 6 'unused' (100% transparent) icons in the bmp (icon positions 58,59,60, 359,378 and 379).
This means the bitmap file contains the artwork for 384-8-6 = 370 different terrain tiles.

However, as noted above, the definitions file references only 364 tile bitmaps. This means there are (at least**) 6 icon bitmaps hiding somewhere in the CFTiles bmp that are never used (i.e. are not defined in default.tsrc so can never be included in any map) !

** It turns out that it's quite possible for the SAME TILE to be referenced in more than one 'definition' ! I discovered this when I found that bitmap icon 103 ('dense tank traps') is used (i.e. defined) twice - so there are actually 7 unused tile icons !

What are the 7 unused bitmap tile icons ?

After 'matching up' the bitmaps with the definitions, I discovered the following :-

The first of the 'undefined' (unused) icons are a pair of 'trench cross roads' (bitmaps 165 & 166).

There seems no obvious reason why they are unused, so I simply added them back into the definitions (see later)

Next there are 3 'road bridges over water' (bitmaps 180, 181 & 182), each with 'red dot' in the lower RH corner but otherwise identical to existing road bridge tiles.

I modified these icons to give me 3 'pontoon bridge over water' tiles instead

The final two are the North & South 'rail over beach' (376 and 377) icons.

Again, there seems no reason why they shouldn't be used, so again I simply added them into the definitions file

Are all the 'defined' tiles actually used in actual combat maps ?

No. There are dozens of defined Tiles that are never used (in any of the 'standard' battle maps). These are :-

#10, 11, 14, 27, 44-52
#105, 106, 108, 110, 158,159,160, 163-171
#213-221, 260, 171,272, 275,276, 178,279, 291,291, 297
#320,321, 323,324, 330,331, 333,334, 340, 373,374, 377-380
So, you could replace them all with new artwork and new definitions and not 'upset' any of the existing maps, HOWEVER it's possible they could be used in one of the 'Battle Isle' (converted) maps, so I 'left them alone'

Why are there so many similar looking building 'entrances' ?

I have no idea - the actual building 'function' such as HQ, Depot, Factory / Shop etc) is set separately and the 'lose your HQ = lose the game' is an 'Event' that can be 'assigned' to the loss of any building.

So it seems pointless, especially since, on a 'small' display (mobile phone etc), it's almost impossible to tell the difference between a HQ, Depot and Factory by the appearance of the icon. Further, whilst 'neutral' gets a HQ (why ??), there is no 'south facing' HQ entrance (in either players colors) .... and both Depot & Factory lack more than one entrance 'facing'

'HQ' is a set of 9 tiles, 3 each for Player 1, Player 2 & Neutral, facing N, W & E. There is no South facing HQ (why not ?) ... and, as noted above, there is no obvious reason why 'Neutral' requires a 'HQ' at all :-) 'Depot' consists of 3 tiles only, Player 1, Player 2 & Neutral, all facing North (so no S, E or W facing Depot at all) 'Factory' is a set of 6, Player 1, Player 2 & Neutral, facing N & E (so S & W facing 'missing')

Building 'entrance' tiles MUST be defined in the order sequence 'Player 1' (brown), 'Player 2' (blue), 'neutral' (grey) if it exists. This is because, when a building is captured, the 'entrance' tile is swapped AUTOMATICALLY for the next appropriate colour one (buildings can't 'revert' to neutral from Player X, so (unless you want that building type to start the game 'neutral') there's actually no need for matching 'neutral'

For what it's worth (and it's worth a lot = see below), a building doesn't have to have an 'entrance' == however no entrance means a human player can't 'open' the building so can't get at what's inside (although the AI has no problem)

What's that worth ? well it means if you you can define a non-entrance 'destroyed' tile 'next to' the Player 1 / Player 2 'entrance' tile, when the building changes hands, the entrance 'swaps' for a non-entrance == so it can't be 'opended' by the human player (although it can be 'recaptured', unless, of course, you make the 'destroyed' tile 'move cost = 99' (or anything > Infantry move distance), so Infantry can't ever 'enter' it.
This lets you define a 'missile launch' site (that you 'load' with missiles by transporting 'crystals' to the internal 'factory' that 'builds' the missile) that the other player (including the AI) can 'destroy' (the AI will capture buildings but has no concept of transporting crystals let alone of 'feeding a factory' == so it won't use the site against you, except, of course, for any last missile you are still building when the AI grabs the site)

Finally, there are 4 pointless 'building under construction' tiles whose only function seems to be to act as some sort of 'insurmountable obstacle' !

'Building under construction' tiles would, of course, 'make sense' in a scenario where one side had the goal (& ability) to 'complete' a new Factory / HQ / Depot etc. - however no such scenario (or simple supporting mechanism) exists, although Events could be used ('detect (specific) unit arriving at (specific) hex' = trigger build), there is no 'construction' unit (not even an 'engineer' unit exists)

See my New Tiles page (later) for the changes I made to the buildings

Contents of the Tile definitions file (default.tsrc)


name = {default}

The name of this tile-set, to be used when compiling the {default}.tiles run-time file

icons = {CFTiles.bmp}

The name of the associated tile artwork (bitmap images) file

class{n} = {tile ID}

Ten classes are defined (0 - 9), however it's unclear what, if anything, these 'classes' mean.

Initially I assumed that class controlled the tiles selected by CoMET when generating 'random' terrain, however inserting a tile at ID 30 (and changing 'class0 = 31') still resulted in CoMET using the new tile (inserted at 30) for 'grass', rather than the 'old' grass (which I had moved to 'class0 =' tile 31) !

Checking the actual tile artwork shows some correlation with the 'type', but this is not consistent. The Tile ID's & actual tile bmp referenced in the classes are as follows :-

class0 = 30 - tile # 030: plains - the first of the 'normal' terrain tiles following the "shop's" & impassable buildings (0-29)
class1 = 81 - tile # 081: forest - the first of the forest tiles (although other plains tiles are defined later)
class2 = 117, tile # 117: mountain - the first of the mountains
class3 = 150, tile # 150: trenches. This is not the first trench tile (trenches actually started at # 148: == see class9) ...
class4 = 250, tile # 250: rails. This is not the first rail tile (rails actually started at # 248:)
class5 = 360, tile # 360: water [shallow]. This is the only 'all shallow water' tile, however rivers etc. are also 'shallowwater'
class6 = 362, tile # 362: water [deep]. This is the only 'deep water' tile.
class7 = 361, tile # 361: water [medium]. This is the only 'all (medium) water' tile, however other tiles are also 'water' (docks etc)
class8 = 178, tile # 178: road. This is not the first road tile (roads started at # 176)
class9 = 148, tile # 148: trenches - the start of the trenches (but see class3 ??)
The apparent 2 tile slip when we reach class3 suggests that 2 tiles may have been 'removed' from class2 (mountains) without the 'class' count being updated ... but if we adjust by 2, then class5,6,7 and 9 makes no sense at all (if class9 is correctly the actual start of trenches, it then simply duplicates class 3, but if it should be '2 tiles back' at #146, this it is just the last 2 of the set of 15 fences - and moving class5,6,7 each 2 tiles back moves them away from the 'all water' tiles ....)

There appears to be no 'tile count' limit parameter. This suggests that you can add as many new tiles as you wish, so long as you 'define' the new tiles here (note - the existing CFTiles.bmp contains a number of 'unused' tiles, so there is no need to 'define' all the new tiles before 'testing' a new build)

It may be of some note that the ww1 Tile set definitions differ - class0 = 34, class1 = 73, class2 = 109, class3 = 141, class4 = 241, class5 = 351, class6 = 353, class7 = 352, class8 = 169, class9 = 139

# {nnn}: {text} [player {n}], {facing}

The # symbol denotes a 'comment' which means the whole line is 'ignored' by the 'script processor'.

So the 'tile ID' numbers ({nnn}:) has only been included here to assist with editing (i.e. the ACTUAL ID numbers are 'assigned' automatically (sequentially, starting from 0), when the .tsrc file is 'complied'
{nnn}: is the sequential tile 'ID number', starting from 0 (and ending with tile '# 374:'). It will be noted that the tile ID number does NOT match the tile 'icon' number (there are actually 384 tile icons !). Further, some of the tile ID's use the same icon
{text} is the tile 'name'
[player {1/2/neutral}], may be used to set the 'default' owner for factory/building tiles (since only building hex's have a [player] parameter)
{facing} indicates the tile facing, but the text used is not consistent so it is presumably shown only as to aid editing


Denotes the start of a new tile definition

terrain =

This is the basic terrain 'type' for unit movement of Ground and Ship units (which are only allowed into specific tile 'types'). Tiles with no 'type' are 'impassable' to all units (eg. buildings).

Terrain 'types' are water, trenches, swamp, shop, shallowwater, rough, road, restricted, rails, plains, mountains, forest, deepwater. The 'shop' type indicates a potential building entrance - in CoMET it enables the 'Building' -> 'Create' menu option). All the others are 'types' that a unit can be allowed (or prevented) from moving into (at some move cost)

A tile can have none (in which case it is impassible to all units), one (most tiles) or two 'terrain =' values (road + rail = a 'level crossing', water + road = a bridge, Shallowwater + Water = dock, shallowwater + plains = a 'jetty' etc.).
Note that 'destroyed bridges' are impassable to ground units since they are defined only as 'terrain = water'.
NB. Classifying terrain into just a few 'types' makes it quite difficult to 'tailor' unit movement. For example, lake shores, sea shores and rivers all have to be 'shallowwater'. Allowing Medium Tanks and APC's to cross rivers thus means allowing them to 'wade' along a river or the sea shore.
To 'fix' this we have to make it 'harder' for APC's etc to move along a river/lake shore than to move on any adjacent land tiles. This means setting the tile 'cost to enter' ('move =') to a value higher than that of 'grass' / 'woods' etc. Since 'move =' applies to all units 'allowed' into that tile, 'ship' units will have to be given higher move allowances to compensate (and all other water tiles adjusted likewise) = see 'Fixing CF issues' page later)
Further, the big 'jump' from 'plains' to 'mountains' (i.e  no 'hills' type) makes it very hard to set realistic unit movement restrictions ... instead 'low hills' have to be classed as 'rough' (so that units without mountain climbing capability can still be allowed to cross hills, see 'Fixing CF issues' page later)

icon =

The artwork bitmap nunber to use for this tile (bitmaps are numbered starting from 0 & counting across the row & then down to the next (as a book is read)

NOTE. Maps use the 'Tile ID' codes (set by the order of the definitions) and NOT the icon numbers !

attack =

Attach modifier added to a unit 'attacking from' this tile

defend =

Defence modifier added to a unit 'defending in' this tile

Thus, for example, in mountains, units receive +15 attack and +15 defence. This means 2 units fighting each other in mountains 'balance' whilst those defending in, or attacking from, mountains 'into' other tiles, will have a big advantage over their opponents

Whilst it's 'reasonable' to give those defending difficult terrain some (slight**) advantage in defence, it's total nonsense to give them an 'attack' advantage (since they plainly have to 'leave' any cover gained from the terrain when attacking).

**Modern heat sensors, telescope sights and radar detection makes it hard to remain undetected in woods / undergrowth - and whilst hiding behind trees and rocks may give some protection from bullets, splinters from shell fire can actually makes woods and mountains more dangerous than sitting in a nice deep trench in nice soft open ground

move = {n}

The cost of moving into this tile

The move 'cost' is applied to all ground/ship units allowed to enter that terrain 'type'. Aircraft ignore the 'move=' setting (all tiles are counted as move=1) Most tiles are move 1,2 or 3. The 'lower' mountains are 4 (as is 'swamp') with the summit move = 6. There are no move = 5 tiles It is to be noted that Tiles #021 - #029 (inclusive) have no 'move=' declared. This makes them 'impassible', and are the 'base', 'back' & 'sides' of buildings (and the 'factory under construction' tiles) The big problem is that roads = move 1 and grass (plains) = move 2. This means everything moves at half speed on grass = perhaps OK for wheeled vehicles, bit is total nonsense for tracked vehicles. More to the point, 'tracks' count as grass ... to fix this we have to double all 'move =' for all units and all tiles, and then adjust 'track' tiles (see my 'Fixing CF issues' page later)

color =

Other than it appears to be an RGB value, this parameter appears to have no significance

Overview of how are the 'maps' are defined

For a full explanation, see the 'Next >>' page

The map layout 'source' files can be found in the /levels folder (Anthill.src etc). These can be edited by hand (they are totally text based) HOWEVER it's a lot easier to use the GUI layout tool 'CoMET' to create new (or modify existing) maps.

Although CoMET can't 'open' the .src (only the .lev version) CoMET does allow you to 'export' the modified map as a .src, which is what you will need if you are adding it to the default 'build' set.One thing to note is that units deployed on the map are identified by their 'type= (English) name' in the source .src file (but by the sequentially assigned Unit ID number in the .lev). So if you change a unit 'name', don't forget to do a 'search & replace' on all the unit names in the .src maps :-)NB. Maps also contain the (rather cheesy) 'narrative' in each of the supported languages. This is a REAL PAIN to edit using the tiny 'line window' offered in CoMET. Instead I suggest 'exporting' the .lev as a .src in order to make changes (and then use Notepad++ .... and Google translate :-) )

What's the map size limit ?

CoMET limits both the height & width of a new 'level' to 180 hex's = 32,400 hex's. This is consistent with the use of 'short' integers (2^15 = 32,768) for some of the reference pointers etc. however it SHOULD be possible to modify the code to remove the '180' limit whilst retaining the 32k hex count limit (thus allowing for example, a battlefield of 100 x 320 (or 320 x 100)

To convert a .src map into a .lev without rebuilding everything, you can move the .src to \tools and use the cfed.exe tool (needless to say, you can't just cd into \levels and type 'make' :-) )

Note the A.I. 'quits' at some map size a lot less than 180x180 (the A.I. 'goes away for ever' when it's turn to 'move')

Clicking "Next >>" (nav bar, left) will take you to my 'Crimson Fields map file definitions' page

Next page :- CF Maps - (definitions)