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

Modifying Crimson Fields

CF code mod

What changes did you make ?

Note - if you need to make changes to the 'configure' or 'make' scripts, you must modify the 'configure.am' or 'make.am' (auto-make) 'masters' = otherwise your changes will be lost when the script is next 're-built'

Display size

Crimson Field's hex 'tile' size may be fine for a 'smart phone' but a real pain on a modern PC screen (which are all bigger than 640x480 :-) ). So the first thing I did was to 'zoom' the tile & unit size by x2 to better suit modern computer displays (see below for details)

The tile and unit artwork (.bmp source) can be 'magnified' to 200% using any photo-edit package, however the units really need to be re-worked to improve their appearance (note that bmp colour palette index '0' is used as 'transparent')

To fit with the new playing size, I adjusted the default CoMET edit window size (from 816 x 630 ???) to 1280x1024

SDL 'adds' borders and control 'bars' in different sizes depending on the 'requested' window size. To fit exactly onto a 1280 x 1024 screen you 'ask' SDL for a 1274 x 999 window :-)

Changing the 'zoom' setting

First, the tiles and units .bmp files are 'zoomed' up to 200%

Next, in lset.h, I changed the DEFAULT_TILE_WIDTH from 32 to 64 and the DEFAULT_TILE_HEIGHT from 28 to 56. In the same file, the 2nd column offsets = TileShiftX & TileShiftY have to be changed from 9 to 18 and 14 to 28.

Both Crimson.exe and CoMet.exe automatically picked up the larger tiles & unit icons. The only thing that is not quite correct is the unit height spacing in the (building / transport) 'contents' pop-up frame. The problem is that the unit 'icon' is ASSUMED to be the same height as the other icons in the frame.Whilst it is possible to change 'icon height' in gamedefs.h, this then breaks the 'test' for how many will 'fit' in the unit list before scrolling is required AND breaks the mouse 'select' (which is also based on assumptions of 32).
The more I 'fixed' the more other things 'broke', so I ended up leaving the 'contents' alone (even with the larger unit icons 'overlapping' it's still usable)

The default window size for CoMET is found in src\comet\main.cpp (opts.width & opts.height at lines 95/94), however if a cfed.ini file exists (in My Documents/crimson/) the resolution defined there will be used instead (this will be "800x600", if you ran CoMET before making changes to the opts.w/h default:-) )

CoMET has no UI to change the display window, so to change it's display size, you 'hand edit' cfed.ini

To obtain an actual window of 1280 x 1024, you have to set the 'default' size to 1274 (opts.width) x 999 (opts.height) - these are the values that will appear in cfed.ini when the actual window size is 1280x1024 :-)

In crimson.exe, a map 27 tiles wide by 17 rows high fits 'exactly' into a 1280 x 1024 pixel window.
NB. to convert a hand modified map .src into a .lev you use "cfed {name of .src} --units default.units --tiles default.tiles"

The 'next step' would be to allow user control of x1 or x2 zoom. This will require adding back the original tile & unit set and modifying the game code to add a 'button' to switch between the sets (to avoid language issues, I plan to use the '+' key to switch between zoom settings)

Terrain Tiles

For full details see my New Tiles page

Bridges get a 'water' capability (to allow naval units to pass under them

'Barbed wire' can now be crossed by Tanks

The existing 'mines' icon is renamed and redrwan as 'Tank traps'

New Tile 'icons'

One of the first things I did was to 'rework' the building icons (as already suggested in my previous Terrain Tile definitions page and detailed in my New Units page, Next)

I also wanted some 'decent' beaches = you can't "Fight them on the beaches" unless you actually have some beach terrain tiles :-) I also wanted some 'desert sand' terrain tiles

Reworking the existing 'single hex side river banks' (replacing grass with sand) allowed these 6 tiles to be multi-used for 'beach' and 'desert river banks' as well. Even so, I was forced to add one extra row 9of 24 tiles) to the CFTiles.bmp file

Using some of the spare (undefined) tiles positions I added some 'pontoon' tiles (see later re: 'Using Events' = converting a 'pontoon unit' to a 'pontoon tile') and some additional 'house' tiles. After adding these, I was left with one 'spare' position in the 'default' set which I used for an extra 'rocks' tile

New Tile 'types'

Whilst classifying the new tiles, I noted that there was no 'hills' type definition - further I noted that various 'barricade' tiles (tank traps, walls) were classed as 'rough' ? Looking into the source code for the tile 'generation' tool revealed that the 'rough' type was being classed as 'barricade'. I thus decided to re-instate barricade as a type and create 2 new types, rough and hills (see next page for details)

Modified Units

I immediately changed many of the unit 'characteristics' to address some of the multiple inconsistencies incorporated into the 'standard' unit set

All aircraft had their move distance increased (some up to double) to reflect the fact that, in any 'real world', aircraft are always (much) faster than trains (and all other 'ground' units).
Next, the 'Anti-Aircraft Guns' were renamed AA Missile Battery (the AA Tanks doing a perfectly good job as 'guns').
Troop Trains were given a 'medic' capability (which means they are allowed to repair the units being carried)
The final 'tweak' to the existing units was to rename 'Mines' (and rework the icon) into a sort of automated 'defense gun' and give them an 'attack' power (which made them a bit more useful than the 'floating rock' functionality they started with :-) )

Note every change of unit 'name' required a 'search & replace' on all the combat maps (*.src fields in \levels\ folder). See also below, new unit type, for AA missile to be carried by the Missile Battery (which was changed into a 'transporter' type)

New units

For full details see my New Units page

Whilst Battle Isle was 'promoted' as a 'future war' game, there were no missiles ! So, of course, Crimson Fields suffers from the same limitations

I cannot believe that even the most srupid 'alien' civilisation would fail to invent 'fireworks' (rockets) - and use them as a weapon - before more powerful gunpowder and metal working techniques allowed any type of 'gun' to be made.
Since Missiles are simply 'guided rockets', it is inconceivable that any 'modern' or 'future' civilisation would lack access to such basic weapons.

'Explaining away' lack of missiles with some 'hand waving' pseudo-scientific explanations (eg 'super effecting jamming', 'E.M.P. / atmospheric electro-magnetic interference**', 'cloaking devices' etc) fails to explain how artillery and tanks are able to acquire their targets, not to mention the fact that the easiest 'sensor' to fool is the human eye - any simple camouflage / smoke screen blocks direct vision as does fighting at night - so if you have Infantry they must have access to radar, IR and night vision equipment at the very least.

**whilst an E.M.P. 'gun' or other 'electro-magnetic interference' weapon might be used to 'explain' the non-availability of semi-conductor based computer systems, perfectly functional 'missile systems' were developed during WW2, i.e. well before the invention of the first 'point contact' germanium transistor in 1947.
During the 10 years it took before silicone based transistors became available (1954), let alone the first 'integrated circuit' (1960), many guided missile systems were developed (and used) based on vacuum tube technology. Indeed, an electro-mechanical 'guidance' system seems perfectly possible (so no 'EMP vulnerable valves' at all !)

Even if it is accepted that 'magic'** prohibits any sort of workable 'guidance' system, this would not stop 'unguided' rockets being deployed as short and 'medium' range weapons (see WW2 'bazooka' / 'panzerfaust' anti-tank weapons and the Katyusha / Nebelwerfer 'artillery' rocket systems), although it's to be admitted that unguided long range rockets (such as the WW2 German V2) are virtually useless against targets smaller than a city

** Jamming (or EM pulses) sufficient to disrupt (shielded) vacuum tube based systems wouldn't prevent the use of mechanically linked 'live guidance' (as the Allies discovered with the 'Kamikaze' of WW2).
In fact, you don't need human suicide pilots to guide your missiles - birds will do just as well (see the Pigeon guided missile), and, no doubt a dolphin (or squid) guided torpedo would be even simpler (see Military use of dolphins).

Another glaring omission is the lack of many standard support units.

Whilst it might be argued that in a limited battle some standard support units might be unavailable, as noted already, no sane commander would deploy an Aircraft Carrier with only Patrol Boats and Torpedo Boats as 'supports', especially when the opposition is known to possess Submarines !

I thus 'downgraded' the 'Aircraft Carrier' to 'Assault Carrier', but I still couldn't convince myself that anyone would deploy such a unit unsupported = so I added the Guided Missile Cruiser, ASW Frigate and Mine Sweeper

To support (and oppose) amphibious operations, I added Landing Craft, Coastal Defense Battery and Bunker. I also created 'mined anti-tank defences' as a unit (which allows them to be 'cleared' i.e destroyed, unlike the terrain tile anti-tank barriers)

To support units in the field, I added Transport Helicopters, a Mobile Workshop and a Bridge Laying transport (plus a Pontoon Bridge as a 'deployable' = 'mine' type unit = see note 1). I decided that adding further 'logistics' units (ammunition carrier etc) was a 'step too far', however I did modify the unit 'weights' to control what the various 'transport' units are allowed to carry (see later, especially 'Controlling Missiles')

Because units can't 'cross over' one-another, using a Pontoon Bridge is rather complex. First, you have to define an EVENT for each possible tile where the bridge COULD be deployed. When the Bridge is 'seen' on that tile, the Event triggers and that both removes the Pontoon 'unit' as well as replacing the existing tile (typically a 'destroyed bridge' or 'river'/'sea' or something that is impassible to most units) with a 'bridge' tile (i.e. something that units can cross) = see my Using Events page
If you want to get very clever, it would also be possible to define an EVENT that 'spots' the arrival of a pontoon transport 'next to' a pontoon bridge tile and 'convert' it into a pontoon unit (so it can be picked up again), however that's perhaps a step too far

To 'round out' the land units, I added a Light Anti-Tank Gun and Self-Propelled Gun

Four missiles were added :- A-A Missile, SAM Missile, Cruise Missile and (anti-tank) Rocket. To support the SAM site (see below), I added a Radar Control unit. Submarines were redefined as 'transporters' and Torpedo added as a 5th missile type (with a 'weight' that also allowed it to be carried by Torpedo Boats & Bombers)

Helicopter Gunships and Infantry were also defined as 'transporters' and allowed to carry Rockets. The only 'clever' bit is to make Cruise Missiles and Rockets type=ground (so they can be destroyed after impacting a unit with power(ground) but no power(air)). Torpedoes, of course, are type=ship and have a power(ship) only.

How to use Rockets & Missiles ?

Limiting a units use of missiles

To ensure Bombers could 'drop' Mines & launch Torpedoes & Cruise Missiles - but not AA missiles - whilst Fighters & the AA Missile Battery both used short range AA missiles (only), whilst Interceptors & SAM Site both had the choice of mixing long & short range AA Missiles, required a lot of 'playing around' with all the unit 'weights' (since 'minweight' and 'maxweight' is used to control all the 'transporter' types, not just those already mentioned). I thus created a spreadsheet of my current Unit definitions (right click and 'save link as' to download the .xls from here)

To avoid Transports becoming 'armed' with missiles would mean that any units they carry must be without their 'own' missiles. In particular, this means Infantry and Scouts would have to leave their anti-tank Rockets behind when taking Air or Sea Transport.
Since this effected the 'scenarios' rather too much, I (reluctantly) allowed Air & Sea Transport (including Landing Craft but not Hovercraft) to carry Rockets (and trust that those creating their own maps won't abuse this 'loop hole' too much)

Missiles in combat

The main problem with my Missiles is that they are 'just normal units' = so not only can keep 'flying for ever' and they can (indeed, must) be 'attacked' and destroyed like any other normal unit :-)

My (partial) solution is to give them 'no'** defence ("armour = 1"), which then allows 'anything with an AA capability' to 'shoot them down' & more or less guarantees they won't survive the first 'combat'. This means, of course, that every missile 'target' must have some 'power' against the missile type (otherwise the missiles will 'survive' the 'combat')

**Unfortunately, if you actually set "armour=0" (or 0.1) Crimson.exe "crashes" as soon as the missile is in 'combat' (a value of -1 does not cause a 'crash' but makes them 'invulnerable' instead :-) ).
At a guess, the combat code contains a 'divide by armour' (so when armour = 0 you get an unexpected overflow 'exception error' and the .exe crashes). This should be found and 'trapped', however, so far, I have not managed to track down the actual code responsible
I also tried setting "size=1" in the units definition file (units.src) for Missiles. This has no effect at all ! All new units start with size=6 when 'deployed' or when built (it is possible to adjust the size of a unit in the {level}.src map file 'by hand', however this would only 'work' if you never allowed factories to build new Missiles. This, of course, should also be fixed.
Finally, I tried defining a new 'type' = 'missile' (in addition to the standard 'ground', 'aircraft', 'ship') so that everything can be given a 'power(missile)=99'). Unfortunately, this also failed ('mkunitset' errors out during the .usrc 'make'). This would be the 'ideal' solution to ensuring missiles are 'single use', however I suspect that 'fixing' the mkunitset code would simply 'move' the failure point elsewhere (such as the obviously 'broken' combat code that's unable to cope with 'armour=0')

Since 'everything' has a combat factor against Missiles, this (hopefully) means Missiles will get 'shot down' before players realise that to 're-arm' an AA Battery all they have to do is fly their own Missiles 'into' them (since the Battery is just a 'transporter' :-) )

However (currently) there is nothing to stop Missiles being 'launched' from deep within your own lines & then sent flying around in circles for half a dozen turns before finally attacking an enemy 'target'.
Whilst this is fine for Cruise Missiles, it's not so clever for Rockets & AA missiles :-)
The only real solution is to find a way for missiles to be automatically 'destroyed' at the end of the turn after launch ... this could be done, for example, by modifying the 'after combat clean up code' so that, when it removes all units reduced to a strength of 0, it also removes those with 'armour' 0

The ideal (future goal) is to assign a 'life time' to missiles, so that Rockets and short range missiles can be 'eliminated' after 1 or 2 turns whilst Long Range missiles last a bit longer. Since aircraft never need refueling, it's not unreasonable to allow 'Cruise missiles' to fly indefinitely

Missile sites

A missile site is just a 'factory' that can only build a single unit type. The factry terrain tile is 'linked' to a 'Radar' unit using the Event system (see my Using Events page)

Essentially, the 'factory' builds (from 'crystal' resources, delivered eg. by transport units) and 'launches' Missiles.
The 'Missile Control Radar' unit (with a move = 0), which can be attacked & destroyed, is placed on the factory tile.
An 'Event' is then setup to 'monitor' the Radar unit's existence .. when the Radar unit is destroyed, the Event is triggered and replaces the Missile 'factory' tile with the 'destroyed site' (actually, the 'bomb crater' trench tile #167 was initially used).
An alternative approach - allowing the factory to be 'captured' - would have forced the enemy to send Infantry to 'capture' the missile site, which seems totally unrealistic.

I wished to avoid 'upsetting' the tile definition sequence, so I decided to 're-use' the 'bunker' tile icons (called 'city' in the .tsrc definitions). This gave me a Missile Site in each player colour (note - in most maps, 'blue' units start in the North, brown in the South = so blues Missile Site 'points' south whilst browns 'points' north). The 'neutral city' tile can then become the 'destroyed site' tile

After the 'Missile Control Radar' unit is destroyed, unless the Event script removes it, the Missile Site 'building' remains 'under the wreckage' and can be 'captured'.To allow 'repair' it is only necessary to allow the site to build a Control Radar Unit (getting it to 'deploy' is another problem)

How to create (totally) new unit artwork

I start by 'painting' the 'brown' player unit in North facing orientation on a 'transparent background' (= .bmp palette no. 0 = RGB 210,2,242) hex (64w x 56h pixels ... but watch out for the hex 'corners' !)

Since most units are laterally symmetrical, IN THEORY it is only necessary to create 'one half' of the 'N' facing master unit - 'mirror' then gives you the other half :-)

For REALLY GOOD unit artwork, you should 're-paint' each 'facing' with appropriate 'shadow' effects etc. - however the unit will still look quite acceptable if you generate the 'South' facing version by simply 'flipping' the North icon artwork by 180 degrees

The other 4 'facings' can be generated after a 60 degree rotate (with perhaps a bit of a 'tidy-up' to smooth out some of the jaggies generated by the rotate) and then using combinations of 'mirror' and 'flip'.

To create the 'blue' army colour units from 'brown' artwork, just copy the 6 'brown' icons & then in your photo-edit software, use 'Colour', 'Adjust', 'HSL (Hue Saturation Lightness)' and select "-50% Hue"

Click "Next >>" (nav bar, left) for a look at my new combat Units

Next subject :- CF Ancients