logo
background
 Home and Links
 Your PC and Security
 Server NAS
 Wargames
 Astronomy
 PhotoStory
 DVD making
 Raspberry Pi
 PIC projects
 Other projects
 Next >>

Fixing the annoyances and issues with Crimson Fields

CF Tricks
CF combat Units and terrain Tiles are defined in separate files. This means many 'annoyances' can be 'fixed' by making changes to the existing definition files and rebuilding the existing 'maps' - the rebuilt maps can then be played with the existing CF software. Other things require code changes to CF itself - and this means rebuilding CF from the 'source' (see later for details).

Better battles

Building your own scenarios

It's really easy to define your own Units, your own Terrain and make your own Maps using CoMET.

You can do almost anything using [events], HOWEVER any but the most basic [events] are a real pain to generate using CoMET = there is a 'wizard' like option that lets you create events, but it's really difficult to use. It's far easier to Export your Map (.lev) to a .src, hand edit the .src (to add [events]) and finally 'compile' the .src to a .lev using cfed.exe
 
Every Map needs [events] (they are the only way to define victory conditions), however there is nothing to stop you using one of the existing .lev's as a 'template' for your own map (existing Maps all have 'win by killing all the enemy' and 'win by capturing the enemy HQ' [events] built in)
 
If you create your own map 'from scratch', you will have to set-up your own victory condition Events (at the very least you must set-up the 'battle over when one side looses all their units' Events, otherwise the game will never end :-) )

Guiding AI attacks

The AI usually moves all it's units straight toward the nearest enemy, typically choosing the shortest route i.e. moving everything along the roads

By the careful positioning of both roads and hard (or impossible) to enter terrain (woods, swamps, mountains, rivers, water) you can, at least to some extent, 'guide' the route the AI will take
 
Further, it will usually move units in 'serial ID number' order (i.e. in order of 'creation', with the first created unit moving first) - if the first created is at the front, everything moves off at once - but if at the back, typically it has no room to move (due to units directly in front), at least on the first (few) turns
 
As a result, any units at the front that were created last will block other units and then, on moving last, end up becoming 'detached' from the rest

The AI has very little idea of how to use Transport units. When it has Transport aircraft, these are usually left sitting on their starting positions.

If you start the AI with units pre-loaded into transports, on the first go, it will usually move the transport first and then 'deploy' all the units being carried, even if sticking with the transport would allow them to reach the enemy faster.

Since there is no way to stop this, the only 'fair' approach is to start the AI's units closer to their 'targets'

When building units in a factory that is pre-stocked with Transport aircraft, it's rare to find the AI loading up the Transports and flying the unit to the front (when it does so - eg on an island - it usually fails to 'fill' the transport)

To give the AI a chance, Island factories should only produce ships or aircraft - or a 'handicap' [event] should be used to swap out sufficient water tiles for land (or at least 'ford') tiles, to provide a route back to the mainland
 
Remember = the AI builds whatever 'most expensive' unit it can afford (so, on low crystal generation rate it builds Infantry)

Getting the AI to defend

It's REALLY DIFFICULT to set up a map in which the AI 'defends' ! Given the chance, as soon as the enemy gets close, the AI will just moves everything out of the nice defensive positions you built for it and rushes everythng to the attack the enemy in the open. However there are few ways to 'lock it down' a bit :-

First, as a rule, the AI won't move a unit so it ends up 'further away' from a 'nearby' enemy. This means it won't take an indirect route of dozens of hex's around to it's own rear when the enemy is 'near' - so you 'only' have to stop it advancing forwards out of the trenches ...
 
One way to do this is with "can't cross" terrain (such as barbed wire, mines) directly to it's front == but that then stops the attackers as well !
 
The existing 'mines' (concrete blocks) work because they can only be destroyed by the enemy (note: the enemy can only 'sweep' your mines if they are left 'unprotected' i.e. if none of your own units are 'next to' the mine)
 
It's not possible to 'dig in' tanks etc. because it 'costs' nothing to 'exit' a terrain tile (the move 'cost' taken when you enter). So to stop the AI moving a tank out of a 'dug-out' you would have to surround it (at least to the front) with something impassible (mines, tank-traps).
 
Of course, you can always define a new unit == 'dug in tank', with a move allowance =0, but, to be realistic, you then have to use Events to 'swap' it for a movable one (so it can retreat) when the enemy is 'on top of it' = or, in the case of the Russian Front, maybe not (since neither Stalin or Hitler allowed their forces to retreat)

It's worth noting that Artillery and AA guns can be deployed into terrain they are not normally 'allowed' into (eg woods, mountains). If they are surroundied with more terrain they are not allowed to enter they will be 'locked' into position. Ranged units (such as Artillery, AA guns) can thus be 'forced' into an effective defensive line

A unit starts each turn with it's full move 'allowance', which is then reduced by the 'cost' of each tile it enters (see Terrain Tiles definitions)
 
When it's remaining allowance is lower than any of the next-door tile's 'cost to enter', it reaches the limit of it's move.

I discovered about the only way to stop the AI abandoning Trenches etc. was to define a 'Garrison Infantry' unit with a move=0, or (to be a bit more flexible) a normal move=, but with a terrain= restricted to (trenches) = so they can't run off into the surrounding grassland ...

To gain more 'granularity' (so there is some advantage to using Tracks), all move= values are multiplied up. This resulted in Roads move cost 3, tracks 4 and grass 5.
 
This allows 'defence' Tiles to be created with a move=1 cost and AI defending units given a move sufficient to allow them to move 'within the defences' but too low to move outside (so, if outside == grass, then they can be given a move of up to 4)

Controlling AI reinforcements

You can, of course, use the Events system to load re-enforcements into one of the AI's factories / depots, or even (one unit at a time) to specific map tiles. However COMET 'events' interface is a real pain, so you end up having to hand-edit the .src (and then recompile into a .lev) and this (loading reinforcemnets into a building) is only going to work if the AI manages to hold onto that particular building.

It's slighlty easier to give the AI 'a bucket load of crystals' and let the AI build it's own re-enforcements, however watch out - the AI will always build the 'most expensive' unit it can afford !

So, if you want the AI to build a bunch of medium tanks and some Artillery, you have to set up 2 factories, one for the tanks, another for the Artillery = because otherwise it will squander all it's crystals on Artillery !

A way to avoid using Events for reinforcements is to 'drip feed' the AI 'crystals' direct into (multiple) factories. If a factory can only generate one type of unit it will have to wait until enough crystals have accumulated before it builds.

For example, if you drip feed it 2 crystals per turn, and the factory can generate Infantry (cost 8) the AI will build 1 Infantry re-enforcement on the 4th (and every 4th) turn, no matter what else the factory can build (the AI always builds whatever it can afford as soon as it gets the chance)
 
This works with the AI because it's too dumb to go collect all the crystals from all the 'drip feed' factories and deliver them to a single factory (that can build tanks or artillery or some other more useful unit).
 
It can also work with a human player (so long as you don't give the player any units capable of carrying 'crystals' i.e. no transport units or APCs)

The only problem is there's nothing to stop the (clever human) enemy seizing the building (from the dumb AI that never seems to recognise the danger) and 'turning' the re-enforcements to their own use !

Or is there ?
 
Well, actually, yes there is !
 
First you set up a Building, create the factory (and GIVE IT A NAME, since CF will crash if it's left with none (name field=Error) = multiple factories can have the same name), and set it up (drip feed crystals, choose factory unit type(s) it can build).
 
Then, when you are sure all is correct, you just replace the Building 'entrance' tile with a 'normal' terrain tile (eg road/track) !!
 
The AI is not effected by this trick == it just continues to build Units and move them in and out of the factory location 'as normal', however because it's got no 'entrance' the (human) player can't 'open' the building and thus can't build anything (or even move anything out) !
 
So whilst the building (factory) can still be 'captured' (assuming you can find the 'hidden' entrance) there's no way to grab the AI's re-enforcements. If you do manage to capture the building, the AI will still recognise the value of the factory and send it's own infantry to re-capture it.
 
Upon re-capture, the AI will find all it's reinforcements (and crystals) still inside waiting to move out (or be 'spent') .. with the added bonus of 'turning' the Infantry unit used by the human player to perform the capture !
 
So whilst the (human) enemy can delay the reinforcements (which is reasonably realistic) they cannot 'convert them' (which would be total nonsense)
 
NOTE - when a building chnages hands, it's icon (terrain tile) is automatically changed to the next-door icon in the .bmp terrain tile file (so player1 with 'upward track/road' factory would become player2 'left track/road' icon). Upon recapture it reverts to the original (so you, the human, can see if it's been recaptured)

There are a few obvious limitations = first you have to set up one factory per reinforcement unit type, another is that the 'minimum' crystals per turn is 1 (so the longest the AI has to wait before building an infantry re-enforcement is 8 turns - or for a medium tank, 20) and finally, the reinforcement sequence will 'repeat'.

By adjustuing the 'start' crystals you can arrange units with different 'costs' to arraive at the same time.
 
For example, say the AI gets a Tank Corps of 10 medium tanks, 2 heavy tanks and one Artillery piece after turn 10.
 
You would set up 10 medium tank Factories, 2 Heavy Tank factories and one Artillery factory.
 
Medium tanks cost 20, so start the tank factories with 10 crystals and drip feed 1 (or just drip feed 2).
 
Artillery and heavy tanks cost 30, so you can start with 20 and drip feed 1.
 
By adjusting the 'start' count, any 'reinforcement' turn can be set (that is less than the cost) at 1 crystal per turn

Note you should avoid the 'short cut' of drip feeding more than 1 (remember, the cycle will repeat so, for example, feeding2 in a medium tank factory means the AI gets an extra tank every 10th turn !).

The AI Missile Battery

A factory that can generate the appropriate missile type (eg AA missiles, V1 flying bomb, V2 etc) by building from a (drip feed) crystal supply (or from crystals delivered by carriers) becomes a Missile Battery

To put it out of action, Events can be used. However, if you want lots of them (say, V1 launch sites) using Events is a REAL PAIN. So instead we need the ability to destroy (and even 'bomb') them without using Events :-

Of course you have to define a new unit for the actual missile (V1) which will have some effective 'attack' value but only '1' defense so it 'dies' on it's first 'attack' (CF will crash if you give a unit 0 defense, something that really needs sorting out) .
 
Next you define 2 new unit Tile icons = the 'V1 site' and a 'destroyed V1 site' .bmp (the 'destroyed' icon must not be a 'building entrance' since we want to stop the human 'opening' the site and using it themselves).
 
To stop 'normal' Infantry just walking up and capturing the Missile Site, the 'Missile Site' Tile can also be set to a move higher than normal Infantry move= allowance.
 
The 'Demolition Team' unit, of course, will have sufficient move= to enter the Missile Site Tile (as well as having 'capture building' (trooper) capability).
 
As we know, when a building changes hands, CF swaps the icon for the 'next door' one in the .bmp file == so here's the clever bit = the 'destroyed site' Tile has a 'move to enter' value that's higher than any Unit capable of capturing it.
 
A 'bomb' would be a bit unrealistic, as the 'destruction' Unit must have a move allowance, since units can't go direct from a Transporter (APC, Bomber aircraft) to enter a building.
 
So a 'bomb' would first have to be 'landed', and can only move into (and capture = 'destroy') the building on the following turn ...

Note = unfortunately the AI won't know how to 'bomb' Missile Sites, so it will always have to play the side that 'owns' them.

The joy of Mines

The Events system can be used** to 'remove' units and 'swap' them for terrain tiles. This means you have a way to 'convert' a unit (such as a Pontoon Bridge Unit) into terrain (a Pontoon Bridge Tile). However this is a right pain, as complex [events] can only really be set-up by text edit of the .src file.

However Mines (a non-moving, non-attack value but huge defence (armour) value) are easy to deply using CoMET. Since you can define a version of the Mine Unit with any 'icon' you care to choose = inluding Terrain icons (such as shallowwater, bomb creator or even grass) a 'disguised' Mine can be used for many tricks !

** For more details on using the [events] system, see my Events page>

Bridge construction / repair

Normally this would need the Events system to replace a 'Pontoon Unit' (or 'Destroyed Bridge' Tile) with a '(Pontoon) Bridge Tile', however there is a 'cunning trick' that can be used with a 'shallow-water' / 'destroyed bridge' icon Mine

You pre-position Pontoon Bridge Tiles at every location where a Pontoon Bridge could be built (or just place Bridges as normal)
 
You then place 'shallow-water-icon' Mine Units on each of the Pontoon Tiles (or 'destroyed-bridge-icon' Mines on Bridges you want to start the game 'destroyed'). This makes the bridge uncrossable (it also makes the river below impassable, which is OK for 'destroyed' bridges but less realistic for potential pontoon bridge sites).
 
To 'build' (or 'repair') a bridge, all you need is a (Pontoon) Bridge Engineer Unit that can 'remove' (sweep) the blocking Mine Unit (thus revealing the undamaged / Pontoon Bridge tile underneath) !
 
To allow both sides to 'remove the blockage' the block Unit has to be defined as type=Mine (and Bridge Engineers as type=sweeper). To prevent the block Unit being 'killed', it can be given armour=999.
 
NOTE that you can only 'sweep' an 'enemy' Mine if no 'normal' enemy Unit is 'next to' the Mine. This allows you to 'protect' destroyed bridges (and potential river crossing points) with 'defendes' who have to be killed before the bridge can be repaired/built.
 
To limit the Engineers to 'building' a single Pontoon bridge, they get a carrying capacity exactly equal to a single 'blocking' Mine unit.
 
To stop the Engineers just 'unloading' the Mine (to free up space so they can 'build' again), the Mine can be set to 'no terrain' ...
 
... CoMET will complain when you 'save' the .lev after 'pre-deploying' a 'no terrain' Mine (with a "Unit X is walking on invalid terrain"  Warning) however the .lev Map will still build OK (although cfed will refuse to build a .lev from the .src, so combining this with some (hand-edit) Events is a real pain = you have to do the Events frist, then use CoMET to add the 'no terrain' Mines last)

This trick has a big drawback = the blocking Mine Units are impassible to all other units, including air units - and that's a problem if you end up pre-deploying long lines 'shallowwater Mine Units' along rivers that cross the main battle zone.

Of course this is not an issue on Maps with no air units - or ones with rivers that have only a few locations where Pontoon Bridges can be built.

Bridge destruction

A similar trick can be pulled to 'blow' a bridge = and with less impact on game play (as there will only be a few bridges to 'blow'). Note that this trick 'works' on the Pontoon Bridges 'built' using the above trick :-)

You define 'destroyed-bridge-icon' Mine Unit with an appropriate 'terrain allowed' setting (see below)
 
The 'Demolition Engineers' (or a Bomber Aircraft) can then carry and 'deploy' (drop) the 'destroyed-bridge' Mine (bomb) onto a bridge tile.
 
To stop the Mine being 'dropped' anywhere else, you can use the 'restricted' terrain setting.
 
Bridges that can be blown then need terrain=restricted to be added to their existing terrain=shallowwater and terrain=road settings, PLUS terrain=restricted ahs to be added to all Units allowed to cross the Bridges.
 
This has the advantage that (for a specific game eg. 'Ludendorff Bridge at Remagen') you can 'deny' Heavy Tanks / Artillery crossing a specific Bridge(s).
 
A 'bombed' bridge (one with a 'destroyed-bridge-icon' Mine on it) can be repaired by a Unit with 'sweeper' capability removing the Mine Unit.
 
The weights system can be used to limit which unit(s) can Repair (sweep) the destroyed bridge (although there is no way to stop the Repair Engineers redeploying the just swept 'bomb' back onto the same bridge (or any other Bridge with 'terrain=restricted' setting)
 
To prevent the 'Demolition Engineers' (or Bomber Aircrfat) removing their own 'bomb', they are not given sweeper capability.
 
 
 
It's even be possible to have the Bridge 'repaired' (bomb removed) and destroyed (re-bombed) multiple times during the game !

Dam busting

This needs an [event] that monitors the (or all) Dam Tiles for the presence of the 'bouncing bomb' (or 'earthquake bomb' etc.) Unit (icon = destroyed dam wall)

When the bomb Unit is spotted, the [event] is triggered and a whole lot of grass tiles are 'swapped out' for shallowwater tiles...

Land units 'caught' surrounded by water will be 'drowned' - as they can't move into adjacent shallowwater tiles - whilst those 'on the edge' will be able to move out of the shallowwater tile back onto a land tile
 
The same applies to Factories caught in the flood = land units inside can't get out if the factory is surrounded with shallowwater tiles
 
So, even the effects of flooding will be realistic !

Once more unto the breach !

Mines, which can't be crossed, but can be attacked and destroyed (but don't fight back), will make ideal Castle Walls !

Shields up !

Combining 'mine laying' and 'mine sweeping' capability means you can define Units with Star Trek style 'shields'.

Your 'mines' are your shields  !
 
For complete protection, a unit gets to carry 6 'shield mines'.
 
The 'shield mines' can be 'deployed' and 'swept' back up - and they will protect you from direct attack - and they even behave as per the best SciFi narratives as enemy attacks will 'weaken' the 'mines' - which can't fight back - until they get through.
 
Even better, to fire your own missile Units, you have to first lower your shields (sweep your Mines) ...
 
... and if you have 'medic' capability, you can even repair your shields !

Next page :- Annoyances and issues

[top]