Supplies
One big issue is that supplies, aka 'crystals', are only found in buildings. Since buildings are almost always well away from the front lines, by the time a unit has retreated to the building, been repaired and returned to the front, the battle is practically over. So only the fastest units are ever repaired - such as air units
This can be 'fixed' by defining a new Unit, the Mobile Repair Engineer Unit (Type = Medic + Weight, Min/Max limits what can be repaired). But the Repair Unit still has to be supplied with 'crystals' - which can only be found in buildings. So the 'return unit to building for repair' problem becomes one of 'transport crystals from building to Repair Unit at the front'. Of course the Mobile Repair Engineer Unit could go and pick up it's own crystals, but what we really want is a way for crystals to be 'delivered' as Supplies by air, especially for battles involving 'paratrooper' drops.
The magic of Mines
Air dropped supplies, of course, can be captured as well as destroyed by the enemy. But the only 'neutral' units are those inside Buildings. So how do we defind a Unit that can be 'captured' by the Enemy ?
This is where the 'magic' unit, the Mine comes in. Unlike any other Unit, which can only be destroyed in the field, a mine can be 'captured' ! To do so a Unit with Transport and 'Sweeper' capability has to be positioned next to the enemy Mine and then 'sweep' it. This is only possible if there are no enemy units also next to the Mine.
All, then, that has to be done is to define a new Unit, 'Supply Canister' of type Mine, Transport, transport weight max/min = 99 (so it can't pick up anything, assuming you have no units of weight 99), no attack, move=0, defence 1, own weight (say) 1. At the Airfield (building) you select the Transport Aircraft to move. This gives you the option of selecting a number of Supply Canisters and an amount of Crystals (which apparently weigh nothing). When your Transport Aircraft arrives at the drop zone, you select the Supply Canister to 'deploy'. Since the Canister is of type Transport, you can load it with Crystals. If your own ground units are close enough they can 'Sweep' the Supply Cannister and gain the crystals. If an enemy Sweeper gets there first, they will grab the crystals, or an enemy combat unit can destroy the Supply Cannister and you will loose the lot.
Bridge repair and Destruction
Within existing maps, there is no method that permits the 'repair' of the 'destroyed' bridge or roads, nor is there any way to construct roads / rail etc. Further, it is not possible 'destroy' a bridge or rail line, both things that a defender would normally have th option to do.
The essential issue is the whilst Units can be attacked, Terrain Tiles can not. This leaves two approaches :- 1a) To 'repair' or 'build' a bridge etc., a 'block Unit' is placed on the actual bridge Tile (or on Pontoon over water Tiles, at the position where a pontoon bridge could be constructed etc). The 'block Unit' simulates a destroyed bridge or 'normal' water thus making the Tile 'impassible'. The block Unit would have a move of 0 and an icon that 'looks like' a destroyed bridge or water Tile. To prevent the Unit being eliminated by normal 'attack', it would have a defence of 99. Making the blockage Unit of type 'mine' allows it to be 'swept'(picked up) by another unit (eg 'Engineers') with sufficient weight carrying capacity. This allows the Engineer to 'repair' the bridge - by 'sweeping' the block unit, or destroy the Bridge by 'deploying' the block unit. The same applies to pontoon bridge 'construction' (remove the water icon Unit to reveal the pontoon Terrain Tile below). This has the advantage of allowing everything to be set up using Unit definitions and CoMET. What's more, assuming the max,min and total weight carrying capacity is set correctly, Engineers of either side can 'sweep' and 'deploy' the block units ! 1b) The disadvantage is that Units can't be 'passed through'. So you can't use (for example) Engineers to remove grass icon Units to reveal a road Tile below because, unlike real grass Tiles, the grass Units would form a barrier that couldn't be crossed, not even by air units ! In a map with no air units, however, you COULD use Units to represent terrain that can't normally be crossed - eg. rivers or mountains. For example, a sequence of 'mountain' icon Units could be swept (one per turn) to reveal a road or rail Tile underneath. 2) the second method means using [events] This is the only way to 'destroy' an existing Tile (such as a bridge) that allow units to pass across. Using [events], the tiles 'next to' the 'target' Tile position must be 'monitored'. When the Engineer Unit 'arrives' on a 'next to' tile, the 'target' Tile is then 'swapped out' for a 'destroyed' (or 'repaired' etc.) Bridge Tile. Whilst this allows (for example) a road to be built across grassland, it requires one 'event' for every location being 'monitored', so is only really practical when the Engineers etc. can only reach a limited number of places.
Using units
To 'destroy' a bridge (or simulate a 'blown bridge'), we just place a 'blockage Unit' (Demolition charge) onto the bridge Tile. So 'blowing the bridge' is just a matter of carrying the 'demolition charge' Unit to the target and 'deploying' or 'unloading' it from the Transporter.
To prevent the enemy simply 'killing' the blockage Unit, it can be given very high armour (Defense value), although in some cases (eg. barriers of various types) allowing the enemy to 'kill'** it to remove the 'barrier' may be exactly what you want **Concrete 'Tank Traps' might be an example of a Unit that should be 'destroyable', however remember than units can't pass through other units and you can't 'kill' your own Units :-)
Normal blocking units
Normal Units being 'transported' must have both sufficient move allowance and terrain permissions to 'unload' into the 'target' Tile. By combining the move and terrain values, the 'demolition charge' Unit can be constrained to a specific 'target' type.
A Bridge 'target' is easy - Bridge Tiles count as both road and shallowwater and have a move 'cost' (4) lower than that of 'normal' shallowwater Tiles (5). So the 'demolition charge' Unit can be set to terrain=shallowwater (which limits it to terrain tiles of type 'shallowwater'), move=4. This means can't be unloaded anywhere else but onto a Bridge defined as shallowwater 4. To allow pre-positioned demolition charges is slightly more difficult. If there is a hex next to the bridge that can be made impassible, then you can define a pill box (building) in which the demolition charge can be placed (and later deployed onto the bridge).
The big problem with 'normal' blocking units is that the only way for the enemy to remove the blockage (i.e. 'repair' the bridge) is to 'kill' the Unit (which is rather 'counter-intuitive'). Luckily, there is one unit type that can be removed by both sides == the 'mine'
Blocking with Mines
A Unit of Type='mine' has the advantage that both sides can 'sweep' mines (using a Transporter with 'Sweeper' capability), so both sides can remove the blockage. Mines also have a move=0 (which stops them being moved around)
To 'deploy' a Mine, the Mine must have terrain permissions for the 'target' Tile (the 'move cost' is ignored). However, to 'sweep' a Mine, the transporter must both sufficient weight carrying capacity for the Mine and the Transporter must have terrain permissions for the 'target' tile. This stops, for example, the Mine Sweeper boat stealing land mines laid on the beach (if beach is not also Type shallowwater), and vis-versa. This means it is possible for Transports with Sweeper capability to lay mines onto Tiles from which they can't sweep them back up. WARNING - aircraft ignore the 'Terrain=' restrictions of normal units. This means if you define an air Unit with Sweeper capability it can snatch any Mine within its Weight limitations Note also, you can pre-load Mines (and other cargo) that exceeds a Transport's weight limits (you will get a Warning when you compile the Map but it 'complies' OK and the 'excess' weight can still be unloaded when you choose)
To 'repair' the Bridge, an Engineer unit (of type 'Sweeper', and sufficient weight carrying capacity) then just has to 'pick up' the blockage.
Unique weights can be used to limit which 'sweeper' is 'allowed' to sweep a specific 'blockage'.
Bridges that start the game 'destroyed' can be blocked with Mines that have no terrain permissions at all.
This stops the Engineer unit that 'sweeps' the blockage from 're-using' it to block some other bridge :-) When generating the game Map, CoMET will complain when it discovers that 'Unit X is walking on invalid terrain', but it builds the playable .lev map just fine (be warned, however, that cfed will 'abort' a build of that map from it's .src file) Since a 'no Terrain' blockage mine can't be 'deployed', the only way for the Sweeper to 'unload' it is to enter a building
To allow each side to repair some bridges, but not others, the 'weights' system can be used
The max/min settings can be used to limit the 'blockages' that can be 'swept' (and thus the Bridges that can be repaired). Any 'Demolition Squad' (with a Mine and sufficient carrying capacity) can destroy the Bridge. But only 'Repair Engineers' (with sweeper capability, and a max/min carrying capacity that includes the target Mine weight) can repair them. If you want one side to repair only the other sides Bridges, then one side gets 'light' mines (that only the other sides 'light sweepers' can lift), whilst that side gets heavy mines (that only the first sides 'heavy sweepers' can lift). Neither sides 'Demolition Squad' get 'sweeper capability' (so they can't just 'pick up' their own light/heavy 'demolition charges') To prevent the enemy simply 'killing' a mine 'blockage' Unit, just set the mine Unit defense armour=999
Constructing roads etc
Remember - Units can be deployed, Terrain can't (except by using Events == see later). SO, in practice, rather than 'deploy' Roads etc., you have to define the road as part of the Map, and then 'cover it up' with Units (with icon = 'impassible terrain', since it's a Unit which means no=one can pass through in)
Road (or Rail etc) 'construction' means using the Engineer (Transport) Unit to 'Sweep' (pick up) the Unit of Type=Mine and an icon that makes it 'look like' the surrounding normal, but impassible, terrain (mountains, swamp) to reveal the road/rail terrain Tile hiding underneath
Sweepers can only pick up from a 'next door' hex, so construction will proceed at the rate of one hex at a time
This approach is limited to what appears to be 'impassible terrain' (marsh or a mountain range) and to locations well away from the play area i.e. along the map edges (where a 'chain' of 'impassible units' will have minimal impact on game play) because no other unit (not even air units) will be able to cross the pre-positioned 'fake' mountains/swamps etc.
A 'chain' of 'impassible grass' units across the middle of the battle field would have a big impact = remember no unit (including air) can pass through any other unit :-) It is just about possible to 'get away with' one or two impassable 'shallowwater Units' (which are 'hiding' pontoon bridges). However the surrounding terrain must be carefully constructed so that the 'Pontoon Bridging Engineers' (sweeper Unit) can only approach those one or two specific 'shallowwater' hex's where the 'blockage' is waiting to be removed
Using [events]
The [events] system can be used to remove ('destroy') units and swap Tiles. This lets you set up 'watched tile' (a row/column position) and 'detect' the arrival of some specific unit type on that tile (for example a shallowwater Tile where a pontoon bridge could be deployed) and then 'destroy' the pontoon unit and 'swap' the shallowwater tile for a Pontoon Tile.
The drawback is the need for numerous [events]. For each Tile being monitored, 4 [events] will be needed = one pair of 'destroy unit'+ 'replace tile' [events] for each side. However careful Map terrain placement can limit the locations were the 'pontoon transporter' can reach the river / shore thereby making it more manageable
[events] can also be used to 'monitor' (all) existing bridge tiles 'watching' for the arrival of a 'demolition charge' = and, when found, 'destroy' the 'demolition charge Unit' and replace the bridge Tile with a 'destroyed bridge' Tile
This has the advantage of preventing re-use of demolition charges, but again requires large numbers of [events] be set-up To facilitate the building of maps with more than one or two bridges, the entire [events] generation can be automated (see below)
Bridge destruction/repair [events] automation
The Map .src file can be processed using a QBasic script. The [map] section is examined and the positions of each Bridge Tile noted
Water + Deepwater:- These are the 9 'loading dock' tiles. Shallowwater + Road/Rail:- There are 3 road bridges (with co-responding 'destroyed road brides') Tiles, 8 'beach and bridge' tiles (all of which can be replaced with a 'bomb creator') and 3 rail bridges (which lack 'destroyed' version, but the 'shallowwater pond' (bomb crater) Tile could be used) Streams/rivers:- There are 6 road, 6 rail, 6 'dirt track' and 3 'foot' over river bridges. In theory, any of the above could be the 'target' of Demolition Engineers. The 'Tank traps on road' (3 Tiles), 'Tank traps on grass' (6 Tiles), 'barbed wire' (15 Tiles), 'Houses, sheds and runways' (15 tiles) and (finally !) the 'shops' (19 entrances, 7 factory sides) could also be a 'target' for Demolition :-) Indeed, some scenario's may well include woods and mountains as 'targets' for 'Demolition'
'Destruction' just means checking for the appearance of a Unit, type = 'Demolition Charge', then 'destroying' that unit (i.e. the one on the target Tile), and replacing the Tile with a 'destroyed' Tile
For bridges over shallowwater, if no specific 'destroyed bridge' Tile exists, the shallowwater Tile can be used (for the bridge over beach, the 'pond' tile can be used)
To 'repair' the bridge, [events] just looks for a Unit type='pontoon' to arrive at that location
When 'pontoon' is seen, the target tile is simply replaced with the original one (i.e. whatever was there before it was destroyed)
Automating the building of bridges
'All' the shallowwater tiles can be found in the [map] definition and monitored for the arrival of a pontoon unit
The problem is one of 'choosing' the 'correct' Bridge Tile = there are 3 possible 'directions' (unlike 'repair', when the 'original' tile can simply be 'put back') Initially, rather than try to 'get clever', by defining 3 visually similar shallowwater Tiles with different Tile numbers, which would allow the 'direction' of a Bridge at that position to be predefined, I defined a a 'Pontoon Bridge' Tile that is 'uni-directional' (i.e. can 'join up' at any of it's 6 sides However when it came to play testing, I found it a real pain trying to remember where Bridges could be constructed = so I found ended up having to create 3 directional Pontoons plus 3 shallowwater tiles after all (the Icons with 'red dots' in the corner to indicate the Pontoon build direction) This did at least have the added advantage of making it easier to automate the [Event] creation ... (the VB script now only had to locate the 3 new Tile numbers - and set the Event to use the appropriate direction Pontoon)
Beach landings
Landing craft are easy enough (so long as Beach Tiles are shallowwater+plains) but 'swimming tanks' are potentially a problem, because the 'default' 'cost to enter' a shallowwater Tile is 2, the same as Grass etc. and lower than rough ground
As a consequent, the AI will choose to send 'swimming takes' up-river rather than across rough ground.
One way to 'fix' this is to use [events] to replace the 'swimming' tank with a 'normal' tank when it arrives on a beach tile.
However the better approach is to change the Move= cost of water tiles so these are higher than land - and then adjust the movement allowances of ships etc. to compensate
WARNING - to avoid two units occupying the same hex, CF adds some fixed amount (16?) to the 'cost' of entering a hex that is already occupied by a Unit After adjusting the Tile Move 'costs', some Units ended with move allowances of up to 30. Suddenly this allowed them to move 'through' both friends and enemy ! However I quickly discovered that the program will then crash if you accidentally end a Unit move 'on top of' friends (who have no Transport capability) or an enemy unit.