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

Building new CF Maps (with new Units and new Tiles)

New Maps

How Maps are 'built'

When CF itself is built, so is the 'cfed.exe' tool. At the end of the build (make script), the cfed.exe tool is 'invoked' to build eqach of the pre-defined (.src) maps.

When cfed is invoked automatically (by the CF build 'make' script), the 'tile' and 'unit' definition files referenced in the .src Map are used.
When you (re)build a map by invoking cfed from the command line, you need to specify the 'compiled' terrain tiles (eg default.tiles) and compiled' units (eg default.units) needed to build the .lev
This means you can have multiple tile (& unit) 'sets'.

The CoMET utility can be used both to modify an existing play / saved game map (.lev) or create totally new maps.

CoMET is good at changing terrain Tiles and adding/removing Units. It is poor at defining 'messages' and 'events', and is incapable of changing a Map 'size' (i.e. can't remove or add extra rows or columns of Tiles).
The 'best' work-flow is to use CoMET to 'make' your terrain and place the units, and then 'Export' the file as both a .lev and .src (you need thje .lev as a 'nback-up' becasue CoMET can't import the .src version)
Remember - a (map).src file references Terrain Tile types ('map-raw') by 'ID number', and Unit types by 'name' (such as 'Infantry', 'Medium Tanks' etc.)
Next, use a text editor to add the [messages] and [events].
Finally, 'compile' the .src into a .lev (using cfed) 'play test' it with crimson.exe
cfed {MapName).src --units default.units --tiles default.tiles

Map Resources ('crystals')

Few Maps have buildings that generate any resources - indeed, on many maps most of the buildings/depots are simply not worth defending. Worse, no crystals = no way to repair units = no point in 'saving' a damaged unit

So the first thing I did was use CoMET to change ALL buildings so they 'generate' 3 or 4 crystals per turn, so all buildings are 'worth' defending - and all can repair Units (even if only one every other turn or so)).
This encourages rather more 'realistic' play.

Changing the combat map size

Changing the .src file 'mapwidth =' and 'mapheight =' has no effect unless you also modify the [map-raw] list to add the extra tiles.

My new 'x2 zoomed' Crimson-0.6.0.exe has a default play window size (1024 x 1280) and will accommodate a map 27 hex's wide without sideways 'scrolling'. To avoid height scrolling, the map should be no more than 17 hex's tall (hex's 'pack' better sideways, which is why only 17 fit in the height, rather than 3/4*27 = 20)
The existing 0.5.1 CF.exe will accomadate 54 x 34 hex's in the same (1024 x 1280) area.
If you play the existing game with a screen resolution of 1024x768, you should limit the map width to about 48 hexs and the height to about 25 hex's.
Note, however, my 'scenario' Maps are typically 100x100+ hex's in size, this being the only way to get a decent 'ground scale' V's unit movement (and gun ranges)
Modern CPU's are about 2 orders of magnitude faster than those available when CF was first released, so (much) bigger maps and (many) more units (for the AI to move) can now be supported. However, at some point, the size of the battle field together with the number of units 'in play' will cause the AI to 'seize up' into an 'infinite loop' (for sure, on a 120x80 map it falls over when the unit count exceeds 1,000 or so)
The [map-raw] consists of Height lines of Width tiles = so to add to the height, just duplicate and add lines to the bottom (see Note below. To add to the width, insert extra tiles to the 'right' edge (i.e. at the end of each line). A good 'defualt' tile to use is code 30 (grass).
NOTE that the 'name' of the Map shown in the CF 'Game' select menu is taken from the 'messages' text (and NOT the file name !)

The Unit positions are defined from the 'top left corner' of the map (tile position [0,0]). This means that adding an extra line (or column) of tiles to the bottom (or right) edge has no effect on the position of existing units

However adding extra tiles to the top (or left) edge of the map has the effect of 'scrolling' the map away under the existing units - and if a building 'moves away' from a 'stack' of units (that would be inside) you will have problems (especially s the building 'entrance' (terrain tile) will no longer 'line up' with the (separately defined) 'shop') :-)
When I decided to 'expand' the existing maps I wanted to add to all sides equally (so the existing tiles and units would end in the 'center' of my expanded map). This required all unit, factory etc. 'positions' to be adjusted. Whilst adjustment by hand is possible, it's rather time consuming (especially if you want to process every existing map, including the 'WW1' maps) - so I wrote a QBasic 'script' to do the job
The script looks for a *.src in the folder 'CF-maps'. Any found are expanded to 48 hex's wide (by adding equal ammounts of grass left and right). The .src is then 'complied' to a .lev (so you can finish the job using CoMET).
You can download my 'MAP_MOD.BAS' script by using right click and 'save link as' here (the .zip also contains cfed.exe and default units & tiles files plus CoMET and 'compiled' units and tiles files)

Having manually changed the Map .src file, you need to use 'cfed' to 'make' the '.src' into a '.lev' and then use CoMET to 'edit' the map (especially the terrain) as desired. To convert your hand modified map (name).src to a (name).lev that CF can run, use :

cfed {name of .src} --units default.units --tiles default.tiles

Fixing CF issues and problems

It's possible to modify the Unit and Tile definitions files (.usrc, .tsrc) without changing the artwork (or even the Map .src). If you then recompile the units/tiles (.units, .tiles) files and rebuild all the existing Map .src files, you can 'fix' almost all the annoyances of CF


Bridges are (only) set to "terrain =" type 'road' (or 'rails'). As a consequence, no boats can pass under them.

To fix this, all that's needed is to add 'terrain = shallowwater' to the definition of each Bridge tile

Movement speed

There is not enough 'granularity' in the 'cost to enter' (speed) settings. Roads cost 1, almost everything else 2 - so Tanks get to travel at double speed on roads (which allows tanks on road to move faster than Helicopters :-)).

Worse, 'tracks' count the same as cross-country (grass) so their only function appears to be to make the Map look 'nice' (in fact, there are way too many 'nice' tiles with identical definitions - for example the multiple 'forest' tiles - many of which look virtually identical, especially when viewed on any of todays high resolution displays)

To improve 'granularity', I doubled the speed of every unit (in the .usrc file) and doubled the 'cost to enter' of every terrain tile (in .tsrc).
This automatically 'solves' the problem with Air unit speeds (Helicopters being slower than tanks on road, for examle) since air units count all terrain as 'cost = 1', so all will now travel at double the old speed.
Further, since roads now 'costs' 2 and cross-country is 4, I can modify 'dirt tracks' to 3.
Units following the railway tracks should get some advantage (i.e. be faster than cross-country) but not as fast as roads = so I set Rails = 3.
Since rail units are restricted to rail terrain, I can set trains to whatever I like, and now have trains moving faster than units on road (but not quite as fast as aircraft).

Although there are only 24 Units, each Tile has an individual 'cost to enter'. The interaction of the Unit 'move =' and Terrain 'move =' (cost to enter) means a spreadsheet is a 'must'

Each individual terrain tile has a (single) 'cost to enter' but is also defined as one or more 'terrain types'. Each unit has it's own movement allowance. Each Ground or Sea Unit has a list of the terrain types it's 'allowed' to enter. Air units can enter all terrain types and count the 'cost to enter' as 1 for all terrain tiles that have a cost to enter (there are some tiles that have NO move= setting, and no unit (not even Air) can enter those tiles).
The 12** terrain 'types' are :- water, trenches, swamp, shallowwater, rough, road, restricted, rails, plains, mountains, forest, deepwater.
** There is not enough 'granularity' in the terrain types either = at a minimum I need something between 'plains' and 'mountains' (such as 'hills') and something between 'plains' and 'swamp' (for example, 'softground', which covers mud and sand), however to fix this (i.e. add a new type = 'allowed to enter') means code changes.
For now, I just defined some new tiles (hills, mud, beaches, sand etc) and gave them a suitable move= value whilst setting the 'type' to 'rough' + 'shallowwater' etc.


Real mines explode. In Crimson Field, mines act like lumps of concrete

I modified the 'Mine' Unit so they can also be 'deployed' on road, rails and planes, and gave them a decent 'attack' capability (35, against ground and ship units only) with minimal 'defense' (1).
In other words, if you move upto and 'attack' a mine (with ground or ship), it will 'explode' (counter-attack) and 'die'.
Alternatively, you can use ranged units (artillery) or air units against mines with impunity.
The AI will run it's units straight into he minefield - which is more or less as you would expect a Soviet WW2 army to behave - whils the huiman player will spend time knocking them out at long range - which may not be totally realistic but does have the required effect of slowing your advance.

Note - to stop Patrol Boats stealing the enemy mines I removed their 'sweeper' capability (see later re: new Unit = Mine Sweeper)

APC and Tanks get river fording capability

This is deceptivly easy, all I did was add 'shallowwater' to the SPC/Tank Unit definition of 'terrain types' they are allowed to enter. Then, to make deep Rivers that are 'non-fordable' I changed the Rivers on the existing Maps from shallowwater to water (or deepwater) tiles.

However when I 'play tested' this change, I discovered the AI started moving it's tanks 'up stream' == because that was faster than moving them cross-country !!
To stop this, movement speed in shallowwater has to be made much slower (and on beaches somewhat slower) than movement cross-country (plains, scrub etc).
To compensate, the speed of all Ship units then has to be increased - which in turn means movement in water and deepwater also has to be slower, including all the 'dual' terrain tiels (such as the water + dock/beach).
As a consequence, land units will be slower 'loading' onto transports at docks / beaches (which will have a 'slow to enter' value) == which is fine (since loading SHOULD 'cost' time). 'Docks with cranes' (port facilities) can have a slightly faster 'cost to enter', making it 'worth while' for a Player to capture and make use of Ports facilities.
To 'load' a unit onto a ship/landing craft waiting at dock/beach hex, a land unit must have sufficient movement allowance to enter that dock/beach hex.
However when 'unloading', the movement cost is only the cost of entering the hex NEXT to the dock/beach == so landing on a beach will be faster but landing on an 'extended' dock (i.e. where the only hex next to the dock is another dock hex) will take longer.
Road Bridges hex's should have a slightly slower value than a normal road (a hex can only have one 'cost to enter' and we don't want to kill land movement across Bridges, however traffic congestion caused by the bottle-neck of a road bridge should have some impact on speed).
Rail Bridges should be the same 'cost' as normal Rail hexes (with the 'knock on' effect that river traffic will 'pass under' the bridge faster than their normal shallow water speed)
Pontoon bridges block river traffic (i.e. are terrain=tracks, with no 'shallowwater' setting)

To facilitate the above changes, I 'spread-sheeted' the unit and tile definitions (see below)


These 'super flying tanks' have been cut back, with both their speed and load acrrying capacity reduced.

Later I modified the existing icon to 'Transport hovercraft' and added a new unit 'Combat hovercraft'

New Tiles and Units

Full details of my new units and new tiles are given in the previous pages of this section, see my Fixing annoyances Section Index page

Re-building the Unit and Tile definitions

Before you can re-build the Map source (.src) files into playable (.lev) files, you must combine (compile) your (new) Unit (.usrc) and Tile (.tsrc) definitions with their (new) artwork ()

The 'knock on' effect of modifying Unit and Tile 'move=' settings for half speed tiles/double speed uinits (and 'water' effects) are so complex that I ended up 'spreadsheeting' the definitions

My Tile definitions spreadsheet can be downloaded as x2move-tiles.xls.

My Unit spreadsheet can be downloaded as x2move-units.xls.

You then have to 'convert' these into .tsrc/.usrc file format before you can 'complie' the definitions with the .bmp atrwotk. To do this, I wrote a couple of QBasic scripts to process a .csv version of the .xls files :-

My Tile spreadsheet .csv to tile definitions source .tsrc script CSV2TSR.BAS

My Unit spreadsheet .csv to unit definitions source .usrc script CSV2USR.BAS

Note, in both cases, the QBasic script expects to fine the .csv file in the c:\qbasic\cf\ folder. Note futher, Qbasic can only cope with '8.3' file names (hence the output is .tsr and .usr, not .tsrc / .usrc)

Why cfed fails on the map source (\levels\*.src)

If the .src causes an Error (rather than a Warning), cfed fails and no .lev is genrated. Often this is due to a problem with one or more of your (new) unit definitions in my_units.usrc.

First, note which map file (eg. BeachRaid.src) caused 'make' to fail & then look for the 'stderr.txt' file in the 'buildxx'\tools' folder = it should indicate what went wrong
If you can't find 'stderr.txt', then 'make' that map from a Windows command prompt as follows :-

Copy cfed, default.units and default.tiles into \levels\.
Open a Command Window and cd to \levels\.
Invoke cfed to 'make' the source (eg "cfed BeachRaid.src --tiles default.tiles --units default.units").
Finally, go find the 'stderr.txt' file in \levels\  and open this in Notepad etc. to see what caused cfed to fail

1) The most common error I ran into was after making changes to the unit weights and transport min/max weights.

If cfed finds a unit who's (new) weight is outside the transports (new) limits it 'silently fails' (you have to go find the 'stderr.txt' file to discover what went wrong)
cfed will also fail if the (new) 'total carried weight' exceeds the transporters (new) carrying capacity (transslots).

2) The second most common error is renaming a unit in .usrc but forgetting to change the 'name' in the .src file (since you won't discover that error until the next time you 'compile' the .src) !!

To change unit names in the source, either do a "search & replace in files" on *.src in \levels\ (using Notepad++) OR open the *.lev in CoMET and 'Export' it back to the *.srcIn the .lev file, units are referenced by their ID codes, not their name = CoMET will 'look up' the (new) name when you 'Export' a .lev back to a .src

3) The third most common problem occurs after making changes to the 'Messages'. All buildings must have a 'name' which is 30 characters or less (remember - Message text is 'assigned' simply by the order in which it is found .. so 'moving' (or deleting) a whole '% text %' section is not recommended for the 'faint hearted' :-) ).

Note that the text can be 'reused' (you can have lots of buildings named 'Factory' or 'Depot', for example)

In CoMET, when you 'open' a building see 'name = [error]' this means you didn't assign a name to that building. Whilst CoMET is happy to let your 'save' the map, when you try to play that Map in Crimson Fields, CF will simply crash on you

4) Finally, there are the 'invisible buildings' (buildings without entrances) I use in 'Lost Factories' to deliver reinforcements to the AI without using Events

To rebuild from LostFactories.src, go back tot he .lev used in CoMET to generate the .src.
Then add an entrance to each of the 'hidden' buildings (Marsh tiles on the isl;ands), export to .src, rebuild, then use CoMET on the new .lev to replace the entrances with Marsh again

Next page :- The actual map fixes - (whats changed in x3)