Terrain Tile definitions
The Tile definitions (control parameters) are in the /tools/default.tsrc text file. The terrain tile 'images' (icons) are all held together in the single file /gfx/CFTiles.bmp. Note that the BMP colour palette allows the definition of a colour 'Transparent'. This allow (special) Tiles to be 'stacked' over (normal terrain) Tiles. The same BMP palette, including transparent, is used by the Unit icons
The Tile files definitions are combined with the tile icons by the mktileset.exe tool. This is done during the crimson source 'make' sequence to generate the run-time 'compiled' file, default.tiles file. After making changes, you can invoke mktileset.exe from the command line
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 tiles.
Each entry in the .tsrc definitions file must 'reference' a tile image icons in the .bmp file. The icon numbers are assigned automatically, counting from 0.
It is not necessary to define the icons in any particular order, nor is it necessary to actually define them all. Further, the same icon can be used in multiple definitions !
In fact, the first entry in the definitions file ("HQ [player 1], north") actually 'points at' the 10th tile (number 9), the second definition points at the 11th (number 10) and the the 3rd definition uses the 9th tile (number 8).
When the tile definitions and icons are 'complied', the order of tiles in the definitions file sets the Tile 'ID code'.
The combat Map uses the 'ID code' (which set by the order in the definitions file) and NOT the icon number (which is set by the order in the BMP file)
CoMET displays the tile icons in definition order (i.e. in ID code order)
If you change the definitions order (eg so that CoMET will display a new tile 'next to' some similar existing ones), you must 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"). These comments are ignored when the .tiles file is created. 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) = see Map .src file definition
NOTE. Building 'entrance' tiles MUST be defined (in .tsrc) in the order sequence 'Player 1' (brown), 'Player 2' (blue) and (if it exists) 'neutral' (grey). This is because, when a building is captured, the 'entrance' tile is swapped AUTOMATICALLY for the next appropriate colour one
The definition order 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 into the correct definition sequence
The unused Tiles
It's useful to know which Tile ID #'s are 'reserved' (or 'place-holder') definitions and which artwork BMP icons are 'unused'. This matters because we know for sure that none of the 'reserved' definitions and none of the unused bmp's are used in any of the existing Maps. In short, we can modify all those 'undefined' Tile ID # positions and all the 'unused' tile icons and guarantee that this will have no effect on any of the existing maps .lev's or saved games
What's more, if a new Map is accidentally used with an old .tiles (or Tile .src + BMP icon file), the 'black' tiles will show up in the new play terrain and 'tip you off' that you have slipped up.
Finally, we can add as many extra tiles to the end of the definitions file as we like and know for sure they will have no impact on any existing map
CoMET tile display
The map editor, CoMET, displays all the defined 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 display of the defined tiles starts with the 30 building elements (including the 'under construction' set). Then comes 13 normal terrain, starting with the 'grass plains' Tile ID #030 which is used when CoMET generates a 'random' terrain map. After these, starting at definition 40, ID #039 are 11 'blank' tiles appear. These 11 Tiles seem to be 'place-holders' (all 11 use the second 'special' tile icon, icon number 1). The odd thing about these 11 is that only definition #045 is actually 'marked' as 'reserved' in default.tsrc (the other 10 all have 'valid' definitions !) Next comes definition #051, the first of the 15 'air strip' type tiles (hangers, runways etc). This is followed by 62 'normal' terrain tile definitions (including woods & hills) before the first of the 'tank traps' (where tile icon 103, the 'dense tank traps on grass' icon, is used twice, for definition ID #130 and #131 :-) ). NB. Tile definition #307, icon ID 33, the 'swamp' tile, when seen 'on screen', appears REALLY weird :-)
Remember, CoMET displays the defined tiles, in order of definition, by their icon. When you create or modify a game MAP, the terrain is defined by a list of tile ID codes. You can add new definitions to the end of the existing definitions file (and new icon artwork tot he BMP file) and this will have no effect any existing Map
In the map, the terrain is defined by the tile ID codes. When the map is displayed (to the Players or by CoMET), the (current) terrain hex icons are read from the compiled default.tiles file. IF you modify the terrain definitions and/or the tile BMP's (in the CFtiles.bmp) and then recompile the default.tsrc and CFtiles.bmp to generate a new default.tiles file, then the existing Maps will use your new definitions
The Tile count
The terrain definition set (.tsrc) contains 375 ID's (#000 - #374) of which 11 'point' to icon ID 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'. These are :-
Tile 0 = transparent with a 'dotted' red border, used to indicate 'valid' moves.
Tile 1 = solid black & is used by the 11 'reserved' (place-holder) Tiles (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 selection
The '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 the Tile 1 icon appears in the definitions file (.tsrc) and then it is only used by the 11 'place holder' definitions. In addition to the 8 'specials', there are also 6 'unused' (100% transparent) icons in the bmp file (at icon positions 058,059,060,359,378 and 379).
This means the bitmap file contains artwork for 384 minus 8 minus 6 = 370 different terrain tile icons. However, as noted above, there are only 364 valid (non-black tile) definitions.
So 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) !
** Of course, just as the 11 'blank' place-holder definitions that reference the same icon, it's quite possible for any icons to be used more than once.
In fact it turns out that icon number 103 ('dense tank traps') is indeed used twice !
So there are actually 7 unused tile icons !
By using the same icon for two different terrain definitions, it is possible to set up things like (hidden) 'quick sand' and other unexpectedly difficult terrain. It is equally possible to set up unexpectedly easy terrain. For example, a hidden road through a mountain (by using using the mountain icon's with a road definition). Needless to say, the AI would not be fooled (so it could come as quite a shock to the human player when the AI forces suddenly start moving through what looks like 'impassible' terrain :-) )
The unused 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.
It is perhaps possible that these were intended to denote 'bridges wired for demolition' or some such (the EVENTS system can be used to change tiles - for example switch a bridge for a destroyed bridge etc. at some specific game turn or when some specific unit by ID number or type (or an enemy unit) tries to cross etc). 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
The unused tile ID#
In addition to the 11 'reserved' ID# (and the unsued icons) there are dozens of defined Tiles that are never actually used in any of the 'standard' battle maps. The Tile ID# numbers are :-
#010, 011, 014 (part of the 'building entrances' set)
#027, 044-052
#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
In theory, you could replace them all with new definitions (and new artwork) and not 'upset' any of the existing maps.
Since it's possible these could be used in one of the 'Battle Isle' (converted) maps, initially I just 'left them alone'Buildings
The HQ, Depot and Factory entrances are 'different' but similar. The actual building 'function' such as HQ, Depot, Factory / Shop etc) is set separately. Further, 'lose your HQ = lose the game' is an 'Event' that can be 'assigned' to the loss of any building.
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. So there is little point in wasting so many icon positions. All the building components are displayed first (before Tile ID#030, 'grass', which is fixed due to it's use in CoMET as a 'hard coded' part of the random terrain). So the first 30 'slots (ID#000 - #029) are barely enough to show the required building set. In fact, 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, Factory and Depot are all 4 tiles in size, so in addition to the entrances there are 4 tiles for the 'surround'. Finally, there are 4 pointless 'building under construction' tiles whose only function seems to be to act as some sort of 'insurmountable obstacle' !
The '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
Events could be used to 'detect (specific) unit arriving at (specific) hex' = trigger build (sethex). However there is no 'construction' Unit (not even an 'engineer' unit exists)
'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 :-)
In my 'annoyances' you will find I chose to dump the 3 Neutral HQ's and add a South facing HQ entrance for each of the players to complete the NSEW set. This reduces the 'HQ set' from 9 to 8 Tiles, so that leaves 1 spare tile in the HQ set.
Next up comes the 'Depot' entrances. These are visually similar to the HQ entrances but consists of 3 tiles only, Player 1, Player 2 & Neutral, all facing North (so no S, E or W facing Depot at all).
In 'annoyances' I opted to eliminate the separate 'depot'. Instead the 'Bunker' buildings will be used as the Depot (warehouse).
Then comes the 'Factory' set of 6, Player 1, Player 2 & Neutral, facing N & E (so S & W facing 'missing')
In annoyances, by combining the 6 now spare Depot entrances with the one spare from the HQ, I only had to find 2 more spares to put together a full set of 12 Factory entrances.
Finally, there are the 'Bunker' (pill box) buildings, followed by 4 'building surrounds', and then the 4 'factory under construction' tiles
In annoyances, the 4 'building surrounds' are reworked for use as the HQ (only) surround and 'moved' next to the HQ set. The 4 'factory under construction' surrounds are reworked and 'moved' to a position directly after the Factory set. However the 3 Bunkers (Depots) can't come next as there are only 2 definitions before ID #030 plains (grass) position. So, instead, I added in two new ground terrain (muddy, deep mud). Then came the normal 9 terrain. This places the 3 Bunkers as the first 3 of the 11 unused 'reserved' definitions (black hex in CoMET) This then leaves 8 'reserved' available for other use (I added 6 grass/sand, one total sand, one residential building)
Note Building 'entrance' tiles MUST be defined in the order sequence 'Player 1' (brown), 'Player 2' (blue), 'neutral' (grey) if it exists (the order of the icons in the icon file is irrelevant). This is because, when a building is captured, the 'entrance' tile is automatically swapped for the next defined 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 the 3rd 'neutral' Tile
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 in the Tile definitions, if you define 3 tiles in the order, Entrance Player1 Tile, non-entrance 'destroyed' Tile, Entrance Player 2 Tile, when the building changes hands, from P1 or P2, the entrance will be automatically 'swapped' for the destroyed non-entrance Tile. The result is a 'shop' that can't be 'opened' by a 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. You 'load' missiles by transporting 'crystals' to the internal 'factory' that 'builds' the missile. The other player (or AI) can then 'capture' the 'missile site' but this will result in it's destruction. The AI may have no problem 'seeing' past the 'non entrance' BUT the AI 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.
See my New Tiles page (later) for the full changes I made to the buildings
The 10 Woods
Woods kick off with 4 Tiles, starting with a few trees and building up to a reasonable thick wood. So far, so good. But then there are are 6 'Forest'' icons positions 52 to 57 (Tile ID #081 to #087), that look almost identical
In fact, Icon 57 (Tile ID #086) is the only completely covered Forest tile. The other five seem to be designed as 'edge of wood', in that there is a thin sliver of grass at the edges, mostly visible at the top. The problem is that this 'sliver of grass' is all but invisible - so all 6 icons are used almost interchangeable.
In fact, other than using 6 different icons, it turns out that all 6 Tile definitions are indeed identical, with the same attack (5), defend (10), move (3) and even color (46,86,20). The definitions don't use the icons in the same sequence they appear in the CFTiles.bmp and the comments differ :-
# 081: forest 1 - [tile], terrain = forest, icon = 52
# 082: forest 2 - [tile], terrain = forest, icon = 53
# 083: forest [large], north - [tile], terrain = forest, icon = 56
# 084: forest [large], west - [tile], terrain = forest, icon = 54
# 085: forest [large], east - [tile], terrain = forest, icon = 55
# 086: forest [large], south -[tile], terrain = forest, icon = 57 (this is the centre forest icon)
All definitions are attack = 5, defend = 10, move = 3, color = 46,86,20.
In annoyances, I rework 5 of the Tiles to give me a complete set of 'woods to forest on hills'
The definitions (default.tsrc)
[tileset]
name = {default}
The name of this tile-set. Used by mktileset.exe tool to name the '.tiles' compiled file
icons = {CFTiles.bmp}
The name of the associated tile artwork (bitmap icons) file
class{n} = {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 had moved to 31, and shoud have been picked if 'class0 = 31' had any effect) !
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 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' start being updated ... but if we adjust by 2, then class 5,6,7 and 9 makes no sense at all (if class 9 is correctly set to 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 class 5,6,7 each 2 tiles back moves them away from the 'all water' tiles ....) Since they seem to have no function, rather than trying to adjust them when I later made changes to the Tile set by inserting extra Tiles, I simply ignored them
There is no 'total tile count' or other limit parameter. This means you can add as many new tiles as you wish to the Tile definitions file. You might want to start with the 11 'place holder' Tiles. The existing CFTiles.bmp contains a number of 'unused' icons that could be changed into whatever new terrain you like, so there is no need start with a brand new Map when 'testing' your new tiles.
You can use an existing Map - so long as you haven't changed the order of the definitions - and it (should) display correctly and be perfectly playable with your new definitions and icons. After you modify the map to use some if your 'new' Tiles, should you then accidentally use it with the old definitions, it should still open OK (except the 11 'place holder' Tiles will show as black icons)
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'. This whole line is optional (the definition ACTUALLY starts with the [tile] command).
{nnn}: is just a sequential tile number to help you with editing. The real Tile ID numbers are 'assigned' automatically, sequentially, starting from 0 (ending 374 with the default definitions), when the .tsrc file is 'complied'. It should be noted that the tile numbers do NOT match the tile 'icon' number. The default file contains 375 Tile definitions, whilst the Icon file contains 384 tile icons. Some of the Tiles definitions use the same icon. CoMET displays all 375 tiles definitions, including the 11 place holders, and allows you to place any of these onto any Map.
{text} is a tile 'name' for your own reference
[player {1/2/neutral}], reminds you of the colour ('default' owner) of the Shop (building) tiles (only building hex's have a [player] reference)
{facing} indicates the tile facing (not all are correct - check the icon to find the actual facing)
[Tile]
This flag denotes the start of an actual tile definition
{terrain = [type]}
Optional, there may be multiple 'terrain=' entries. Each defines a terrain 'type' for this Tile. These are the same types used in the Units definition file. Each 'terrain =' entry defines one of 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).
A tile can have none (in which case it is impassible to all units), one (most tiles) or more 'terrain =' types. Units are only allowed into Tiles that are defined to be of a matching [type]. Tiles with no 'terrain =' (eg. the 'HQ complex' and 'Factory complex' side and rear tiles) are 'impassable' to all units (including aircraft). Note that not all Tiles that should have multiple terrain= definitions actually have them. A 'level crossing' is road + rail, but a (river) bridge is road only (it should have + shallowwater). The 'destroyed bridge' Tiles is impassible, but perhaps should be defined as 'terrain = shallowwater' (allowing boats to pass) but the Tile itself can define higher that normal move cost (see later). Some choices are very odd. For example, a dock tile (which is positioned between land and water tiles) is shallowwater + water. This allows Cargo Ships (water + deepwater), Hovercraft (shallowwater + water + most land tiles) and Patrol Boats (shallowwater) to be loaded at the docks. However, Submarines (deepwater only) are not allowed to dock. Very odd ... The jetty Tile (which 'projects out' into the sea) makes a bit more sense with shallowwater + plains. This allows land units to move out into the water to board patrol boats 'moored' at the Jetty.
Classifying terrain into just a few 'types' makes it quite difficult to 'tailor' unit movement 'access'. For example, lake shores, sea shores and rivers all have to be 'shallowwater'. Allowing Medium Tanks and APC's to cross rivers by giving them +shallowwater means allowing them to 'wade' along a river or the sea shore.
Instead of giving tanks +shallowwater, we could give rivers +rough - but then that allows all units with rough capability to cross (including infantry) which we don't want.
Another way to 'fix' this is 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 then have to be given higher move allowances to compensate (and all other water tiles adjusted likewise) = see 'Fixing CF issues'.
NB. the only way to keep track of changes to terrain= definitions is to create a spreadsheet (see later)
icon = n
n is the icon artwork bitmap number (position in the BMP file) 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 .src (source) files contain 'Tile ID#' codes (which are created by the order of the definitions in the Tiles definition ) and NOT the icon numbers. This makes it easier to 'globally' change the order of icons (as displayed in CoMET) to (say) 'group' the HQ, Depot, Factory, Pillboxes etc. together. So long as you DON'T change the ORDER of the Tile definitions, but DO update the icon = definitions to 'point at the new position' of the icon within .BMP file, then the right icon will be automatically picked up from it's new position when the map .src is re-compiled (using the modified tile and unit definitions) into the .lev level file.
attack = {-}n
n is the Attack modifier added to a unit 'attacking from' this tile. Varies from +15 (mountains) to -5 (swamp)
defend = {-}n
n is the Defence modifier added to a unit 'defending in' this tile. Varies from +15 (mountains) to -5 (swamp)
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 hiding** in difficult terrain some 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). ** it is hard for mechanised units to remain undetected in woods / undergrowth for any length of time, especially after they open fire. Of course infantry hiding behind trees and rocks will indeed gain protection from snipers and even, to some extent, machine guns. However artillery fire can actually be more dangerous to infantry in woods and mountains as wood and rock splinters fly around. Certainly, a nice deep trench in nice soft ground is to be preferred.
{move = n}
The cost of moving into this tile. Optional, if not defined, the Tile can not be entered (even by aircraft). The move 'cost' is applied to all ground/ship units allowed to enter that terrain 'type'. Aircraft count all 'move=' settings as = 1. Tiles with no move= can not be entered or flown over.
Most tiles have a move cost of 1,2 or 3. The 'lower' mountains are 4 (as is 'swamp') with the summit has a move of 6. There are no move 5 tiles.
It is to be noted that the building entrance Tiles (first dozen or so from ID#000 onward) are all set to 'move=1', whilst Tiles #021 - #029 (inclusive), the 'sides and rear' of the large buildings (HQ, Factory and 'factory under construction' tiles) have no 'move=' at all, making them 'impassible' to all units.
If it is accepted that the Units represent groups (of at least 5) tanks etc. then the 'building' Tiles are actually a representation of a large complex of buildings. It is thus debatable if it is realistic to allow entry at road speed and for the sides and rear to be 'impassable'. As part of the changes I made to address my 'annoyances', all building tiles (including entrances) are set to move=6 (i.e. a complete Infantry move). This prevents units 'rushing into buildings to hide' as a 'clever tactic' and means you have to protect your rear (and sides). Since the AI has minimal grasp of the need to protect it's buildings, at the same time I had to define a 'garrison unit' with a speed=0 (which can be pre-deployed into the building sides and rear as defender).
Another problem with the move distances is that roads are 1 and plains are 2, which means road speed is double cross-country speed. Worse, tracks are also move=2, which makes them nothing but 'decoration'
To 'fix' this annoyance, I initially doubled all Unit speeds and Tile move costs. However whilst this gives Roads move=2, Plains move=4 and made room for Tracks move=3, it still meant units were still moving twice as fast on Roads as cross-country. So I ended up multiplying by 3. This gives Plains move=6. But instead of move 3, I set Roads move=4. This allowed Tracks move=5. Compared to cross-country (plains), this gives units on road 50% extra speed (2 in 6), whilst those on tracks get 16% extra (1 in 6) which seems about right For more on the subject of speeds, see 'Building my x3 maps' page
Note that after increasing the move cost and speed by 3x, I found that this allowed Units to move through (or over) one another (at some movement cost). However when a unit is accidentally halted on top of another, crimson.exe crashes ! Those who download my 'x3 annoyances' fixed maps take note :-)
color =
Other than it is a standard RGB value, this parameter appears to have no significance. However, every Tile definition has an entry, and it is set to one of half-a-dozen values.
The color = definition might simply be a left-over from some previous incarnation of the software, like the 'class' definitions, however I'm a great believer in the "if it ain't broke don't fix it" approach, so every time I defined a new Tile I made sure it had a color= parameter For what it's worth, Player 1 (FNA, Free Nexus Army), 254,166,4 (brown) is the foreground color, 86,54,12 is the background color. For Player 2 (Empire of Kand) 0,170,255 (blue) is the foreground color, 2,38,92 is the background color. I've no idea if these have any significance.