Building Maps
With the crimson source code, the standard Maps are supplied in text (.src) format, as are the Tiles and Unit definitions and icon BMP's. So, when you rebuild crimson.exe, you get to build the Maps. However there is nothing to stop you modifying the unit, tile and map definitions and rebuilding the Maps manually at a later time
It's even possible to edit the existing Maps using a specifal utility, CoMET.exe
The 'make' script that builds the crimson.exe program also builds the Map edit utility CoMET, and the seperate Map build tool, cfed.exe
The CoMET utility allows you to edit the .lev Map, and allows Maps to be Exported as a text .src. However it can't 'import' the .src (of which more later)
At the end of the crimson.exe build, the 'make' script will use cfed.exe (if it exists) to build each of the pre-defined (.src) maps into playable 'level' (.lev) file. When cfed is invoked by the Make script, it uses the 'default.tiles' and 'default.units' files to assemble the map.
When you build the maps by hand, you can use your own .tiles and .units. These are compiled versions of the text unit and tile definitions combined with their BMP icons. You can build multiple .tile (& .unit) 'sets'. Of course each (pair) needs it's own name and they have to be in the same folder as crimson.exe when you build, edit or play the map
To manually compile eg. SomeMapName.src (using the default .tiles and .units), open a command line window and cd to the folder where crimson.exe (and cfed.exe) reside. Assuming cfed is in the /tools/ folder, then SomeMapName.src must be in the /levels/ folder, whilst .tiles and .units must be in the same folder as cfed.exe. The complied .lev will be placed in /levels/. If there is a problem, look for the 'std.err' (text) file
cfed SomeMapName.src --units default.units --tiles default.tiles
The .units and .tiles files are the 'complied' Unit definitions plus icons and Tile definitions plus icons. A huge number of my 'annoyances' are 'fixed' just by changing the definitions. However then you have to rebuild the .tiles and .units and rebuild for map .src before the changes take effect
Note that, in the Map .src, terrain Tiles are referenced by their ID codes (generated by their order in the definitions .tsrc file) whilst Units are reference by their (English) names. So, if you want to use the existing maps with your new units and tiles, if you make changes to the tile definition order or unit names, this will upset the existing maps. Of course you can modify the Maps to match (a search and replace on the names is easy enough, swapping tile numbers can be harder if the numbers clash)
To build the text based Units definitions (.usrc) with the Units icons in the CTUnits.bmp (and 'thumnbnails' in CFIcons.bmp and 'u_Name.bmp') the mkunitset.exe utility is used to generate the '.units' file. To build default.units from the definitions in default.usrc :-
mkunitset default.usrc default.units {(path to bmp's}
Note that the {path to bmp's} is the relative path (so if the bmps are in /gfx folder at the same level as /tools, then the path is ../gfx). It is only needed if the icon files are not in the same folder as the default.usrc.
To build the text based Tiles definitions (.tsrc) with the Tile icons (in CFTiles.bmp) the mktileset.exe utility is used to generate the '.tiles' file. To build default.tiles from the definitions in default.tsrc :-
mktileset default.tsrc default.tiles {(path to bmp's}
Note that the {path to bmp's} parameter is only needed if the icon files are not in the same folder as the default.tsrc.
For those with browsers/systems that won't allow you to download .exe files, all these default (unmodified) Units, Tiles, .BMP icon files and all 3 .exe utilities can be downloaded in the package CF-Units-and-Tiles.zip
Modifying (and creating ) Maps
The CoMET utility can be used both to modify an existing play / saved game map (.lev) or create totally new maps.
CoMET can be used to create a basic 'random terrain' new map. It is good at changing the existing terrain (Tiles) and adding or removing Units 'one at a time'. It is unable to make 'global' changes, poor at defining 'messages' and 'events', and is incapable of changing the Map 'size' (i.e. it can't remove or add extra rows or columns of Tiles).
It's much easier to hand edit the .src, but you have to use cfed.exe to build that to a .lev before CoMET will 'open' it.
So, to create a brand new Map, start with CoMET to create an 'all grass' (assuming land battle) or 'all sea' (if sea battle) terrain Map of the required size. You can then edit the terrain to get what you want and place the Units
However to add the narrative text and, especially, the Events, it's much faster and easier to edit the .src text version. When you Export to .src, I recommend you also Save a back-up .lev at at the same time.
When you hand edit the .src file, remember it references Terrain Tile types ('map-raw') by the 'ID number' (i.e. the order in the definitions file, .tsrc, and not the order in the .bmp file) and the Unit types by their (English) 'name' (such as 'Infantry', 'Medium Tanks' etc.)
To add and edit [messages] and [events], it's easier using a text editor than it is to use CoMET's 'keyhole' text edit line window and rather poor events creation window. However you might want to add the 'victory conditions' [events] using CoMET just to make sure you get the 'format' right :-)
Making changes
For full details, see my 'Map annoyances', 'New Tiles' and 'New Units' pages. I started with the existing maps to 'play test' some ideas before getting 'stuck in' with my own maps
Remember - you can ADD as many new Tile and Unit definitions as you like SO LONG AS these are added to the END of the existing definitions (.tsrc, .usrc) and icon (CFTiles.bmp, CFUnits.bmp) files.
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.
The existing crimson 0.5.1 .exe can fit a map of 54w x 34h hex's on an old 4:3 'square' 1024 x 1280 display. If you play with a screen resolution of 1024x768, you should limit the map width to about 48 hexs and the height to about 25 hex's. My new (see later) 'x2 zoomed' Crimson-0.6.0.exe has a default play window size (1024 x 1280). On a 4:3 old style display this means a map 27 hex's wide without sideways 'scrolling', and (to avoid height scrolling) 17 hex's tall (hex's 'pack' better sideways, which is why only 17 fit in the height, rather than 3/4*27 = 20)
On modern 'HD' letterbox displays, note that the height (1080) is almost the same as the old 4:3 square display (1024), whilst the width is a lot wider (1920 v 1280)
This allows 'wider' (East - West) battlefields. However, most 'scenarios' are played North-South, so this typically means up/down scrolling will be required (so you had better discover how to turn off the 'keep taskbar on top' :-) )
Most of my own 'scenario' Maps (see later) are over 100 hex's in width or height, 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 battlefield together with the number of units 'in play' will cause the AI to 'seize up' and go 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 'default' tile to use is code 030 (basic Plains = 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 as the building 'entrance' = the 'shop' terrain tile, will no longer 'line up' with the separately defined [building] details :-) ) 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 'centre' 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 sub-folder 'CF-maps'. Any found are expanded to 48 hex's wide (by adding equal amounts 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 the 'compiled' .units and .tiles files)
Having manually changed the Map .src file, you need to use 'cfed' to build the '.src' into a '.lev'. After that you can use CoMET to 'edit' the map (especially any newly added terrain) as desired. To convert a hand modified map '/levels/MyMap.src' to a '/levels/MyMap.lev' that crimson.exe can find and play, use :-
cfed MyMap.src --units default.units --tiles default.tiles
Fixing specific issues
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 my 'annoyances'
Bridges etc.
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 terrain '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 = plains), 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 (or are) virtually identical, especially when viewed on any of today's high resolution displays)
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.
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 :-)
Mines (the joy of)
Real mines explode. In Crimson Field, mines act like lumps of (floating) concrete. However they have some unique properties (for example, they can be picked up by the enemy !) which allows them to be used for all sorts of cunning tracks :-)
I started by modifying the 'Mine' Unit definition so they can also be 'deployed' on road, rails and grass (plains), and gave them a decent 'attack' capability (35, against ground and ship units only) with minimal 'defence' (1). In other words, if you move up to and 'attack' a mine (with ground or ship), it will 'explode' (counter-attack) and 'die'. If you move up and don't attack, your opponent can use the mine to 'attack' you. Alternatively, you can use ranged units (artillery) or air units against mines with impunity. The AI, with it's 'attack the nearest enemy' approach will send it's units straight into a minefield (which is more or less as you would expect a Soviet WW2 army to behave), whilst the human player will spend time knocking them out at long range. Whilst not totally realistic, this does have the required effect of slowing down your advance.
Note - to stop Patrol Boats stealing enemy mines I removed their 'sweeper' capability (see later re: new Unit = Mine Sweeper).
Note also that CoMET allows you to place Mines (and in fact any unit) on a terrain tile that it is 'not allowed into' (you get a warning when you Save but the resulting .lev plays fine)
Fording rivers (APC's and Tanks)
This is deceptively 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 to move it's tanks 'up stream' == because that was faster than moving them cross-country !! To stop this, the speed of movement in shallowwater Tiles has to slower than in surrounding woods (and on beaches slower than grass). This in turn means that move= in water and deepwater has to be adjusted, which means speed= for all Ship units has to be increased to compensate. The move= for all the 'dual' terrain tiles (such as the water + dock/beach) needs to be carefully checked. Whilst making them 'too fast' will have minimal effect (since bridges etc are typically single tiles), you have to watch out for 'too slow' (since that can result in them becoming inaccessible to units with a low speed= allowance (i.e. Infantry)). Setting shallowwater dock tiles to a move= the same as standard Rough tiles means that units will be slower 'loading' onto transports at docks / beaches. This is fine, since loading SHOULD 'cost' time. 'Docks with cranes' (port facilities) can have a lower 'move=', making it 'worth while' for a Player to capture and make use of Ports facilities.
Note that when loading a unit eg. onto a ship/landing craft, a unit ignores the terrain= and sets move= to 1 for the tile on which the transport is waiting. This means land units can board ships without needing 'terrain=water' capability.
When 'unloading', normal terrain rules apply. The movement cost is the cost of entering the tile next to the ship. So landing on a beach will be faster than landing on an 'extended' dock (i.e. where the only hex next to the dock is another dock hex).
A terrain Tile hex hex can only have one 'cost to enter' and we don't want to kill land movement across Bridges (road + shallowwater) However traffic congestion caused by the bottle-neck of a road bridge should have some impact on speed, so the move= can be set above road (although it will be below normal shallowwater). Rail Bridges should be the same 'cost' as normal Rail hexes The 'knock on' effect of this is that any river traffic will 'pass under' a road or rail bridge will be faster than their normal shallowwater speed. NB. Pontoon bridges block river traffic (i.e. these are terrain=roads, move= same as tracks, with no 'shallowwater' setting). Rope bridges (set terrain=trenches to stop any but Infantry crossing) and fords are also possible.
To facilitate the above changes, I 'spread-sheeted' the unit and tile definitions (see below)
The Super (bad) Hovercraft
It's easy enough to cut the 'flying super tanks' down to size with changes to the .usrc file.
To stop them getting silly speeds on roads, I ended up adding 'type=aircraft', since that allows them to treat all terrain equally. Of course they don't get a terrain=woods, terrain=mountains or terrain=deepwater capability
I also drastically cut back their load carrying capacity and removed (most) of their power()= and armour=.
Later I relented somewhat. I decided that 'Combat Hovercraft' was needed, so the existing icon became a 'Transport Hovercraft'
The new Tiles and Unit definitions
Full details of my new units and new tiles are given in the other pages of this section, see my Fixing annoyances Section Index page
Additional help
The 'knock on' effects of modifying Unit speed= and Tile 'move=' settings, coupled with the rail and ship changes are so complex that I ended up 'spreadsheeting' the definitions
My Tile definitions spreadsheet can be downloaded as x3move-tiles.xls.
My Unit spreadsheet can be downloaded as x3move-units.xls.
You then have to 'convert' these into .tsrc/.usrc file format before you can 'compile' the definitions with the .bmp atrwotk. To do this, I wrote a couple of QBasic scripts to process a .csv version of the above) .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 find the .csv file in the c:\qbasic\cf\ folder. Note further, QBasic can only cope with '8.3' file names (hence the output is .tsr and .usr, not .tsrc / .usrc)
Troubleshoting
When cfed fails on the map source (\levels\*.src) it may do so 'silently'
If the .src causes an Error (rather than a Warning), cfed fails and no .lev is generated. 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 \tools folder = it should indicate what went wrong If you can't find 'stderr.txt', then 'make' that map from a Windows command prompt. a) Copy cfed, default.units and default.tiles into \levels\ b) Open a Command Window and cd to \levels\ c) Invoke cfed to 'make' the source eg for BeachRaid.src
cfed BeachRaid.src --tiles default.tiles --units default.units
d) The 'stderr.txt' file will be found in \levels\ This can be opened 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.
A number of existing maps have transports 'ready loaded' with existing Units. If you change a loaded unit to a new weight that is outside the transports (new) min/max limits, cfed '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 (all) the map .src files (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 *.src In the .lev file, units are referenced by their ID codes, not their name. So long as you keep the same ID code, 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
Always remember that 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, if you 'open' a building and 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. This, by the way, shows that CoMET is directly editing the .lev (so no 'recompile'). It's not a bad idea to use the 'Validate' option (under the 'Project' option) before you use Save (.lev) or Export (.src)
4) Finally, there are the 'invisible buildings' (buildings without entrances) I use in 'Lost Factories' to deliver reinforcements to the AI without using Events
cfed won't 'build' a .src containing an 'invisible' building. So, if you want to make (manual) changes to the (text) source of 'LostFactories-x3' you will need to start with a .src that CAN be complied with cfed
Start by opening LostFactories-x3.lev in CoMET. Then add an entrance to each of the 'hidden' buildings (these are hiding under the Marsh tiles on the islands). To check you have 'caught them all', use Validate and look for "Error: A shop exists at (row no.)/(col no.) but there is no entrance". Warnings - such as "Unit NN is walking in invalid terrain" can be ignored. Then you Export to .src. You can then hand edit the .src and use cfed to rebuild the .lev. Finally, use CoMET on the new .lev to replace the entrances with Marsh again and finally Save (as .lev)
This makes the point that CoMET allows you to do things that cfed will chock on :-)
This includes placing Units on terrain that they would not normally be allowed into, typically to maximise their defensive position. Of course if there are next-door tiles that the Unit is allowed to enter, the AI will typically abandon the defence and rush off to attack the enemy (which is why I had to define a 'Garrison Infantry' unit that was only allow to move in trenches)