Tricks with buildings
In CoMET, you can 'right click' a Terrain tile that is defined as type 'shop' (building entrance) and 'Create Building'. You can set the building name (required = i.e. will 'error out' if you fail to select one) and set the initial 'owner' (neutral, player1(brwn), player2(blu)). The default owner is 'player1' (note that the ownership is NOT set by the tile icon = you have to set it explicitly).
When 'ownership' changes, the buildings entrance tile icon is changed to the tile 'next door' == and the 'next door' tile DOES NOT HAVE TO BE OF TYPE 'SHOP'
If the 'next door' tile is not of type 'shop', the 'building' will still exist (although it can't** be 'opened' until a change of ownership results in it changing to a 'shop' tile again = which it will if shop tiles have been defined (in Tiles file) in the order player1, player2 and then the (optional) neutral icon) Neutral captured by Player 1 switch to icon -2. Neutral captured by player 2 switches to icon -1. Player 1 captured by player 2 switches to icon +1 (player 2 to player 1 switches to icon -1). It's to be noted that a building which starts the game 'neutral', and is then captured, can never return to 'neutral' **actually, the AI is capable of moving units out of a building with no 'entrance', it's only the human player that can't (no building entrance == unable to 'open' the building so unable to access units inside)
Further, when the entrance changes to a new tile, that new tiles move= and terrain type= will be applied to units wishing to 'enter' the building
So, to 'capture' (or recapture) the building, the enemy 'trooper' (infantry) must be both 'allowed' into the (new) building tile terrain type and have sufficient move to do so. Even units of the player that 'owns' the building can only move into the building of they have appropriate terrain= and move= allowances. If change of ownership results in a 'new' tile with no terrain= setting, then nothing can enter that hex and the building can't be recaptured (since Infantry won't be able to enter). NB. It's not possible to 'pass over' (or stop on) a 'shop' or building (no matter what tile icon is shown)
AI Depot only
The [events] system can be used to handicap the human player, however this is a real pain. A much simpler way is to use CoMET to set up a 'Depot' of extra units (in both a P1 and P2 building) for the AI to use against a human player. To stop the human player using the units, after setting up the building and contents, in CoMET, the 'shop' tile is changed to 'road' (or other non-shop tile type). Irrespective of which side the human chooses (P1 or P2), the AI will always get a Depot of extra units. To make it 'realistic', the Depot should be set-up in a road that leads 'off map' (so on exit from the Depot units will 'appear' is reinforcements coming from off-map)
Note that units in an 'inaccessible' Depot still 'count' as part of the (human) players forces. This means you "won't loose" when all your (visible) units are destroyed until the other player 'captures' the 'hidden' Depot. This is not a problem for the AI, however in a 'head to head' with another human player the game could end with a 'hunt for the invisible Depot' :-) This can be partially avoided by making the Depots 'neutral' (the AI will still send Infantry to go capture it = however a human player "won't know" where to send it's Infantry (but could still 'stumble across' the Depot)
The trick here is to define a factory (on a shop tile) for the AI (that only builds one unit type), and then change the tile for a non-shop type
The factory remains and will allow the AI to create units (which the AI can then send out) To prevent the 'hidden' factory being captured, the new (terrain) tile is not given any terrain= setting (so nothing can enter it) The Events system can be used to control the resource 'crystals' in the factory (it's easier to give the AI, say 800 crystals (and let it create 100 infantry) than it is to define 100 separate unit creation Events) By carefully setting the 'start crystals' and giving the factory a 'crystal generation' value, it is possible to control the arrival of (a) unit from (a) factory
Capture the Ferry
To cross rivers, Transport Ships can be used, however the drawback is that these 'belong' only to one side - so getting them 'into place' in a realistic way is difficult. Whilst Transport Ships have no 'attack' capability, they can't be 'captured', only destroyed
On a typical scenario map we would want a 'ferry' that starts as 'neutral' and can then be captured and used by which-ever side arrives first (or next).
If the waterway is only 1 tile wide, then we can define a 'Ferry' tile of type 'shop' and create a building. This works well - after capturing the ferry (building) your units enter on one turn and exit on the next. Should the enemy capturer the Ferry they will also capture any of your units that are still 'being transported' (i.e. still 'inside' the building)
This has the advantage that the AI will try to 'capture' the building = and might even use it as a 'ferry' ! The drawback is that the 'shop' (building) hex can't be crossed, so sea units can't 'move up-river' (past the ferry).
For a sea crossing or multi-tile wide lake (or very wide river), a Transport Ship with terrain=water (only) is used. The edges of the waterway are shallowwater everywhere except at the two 'docking stations' (buildings) which are set to =water. To use the Transport Ship (one starts in each neutral 'docking station') you have to capture both docking stations (ports).
The drawback is it takes at least 3 turns to make the crossing :- Turn 1 = enter near-side dock Turn 2 = ferry exits the dock with your units on-board into the sea/lake Turn 3 = earliest possible time the ferry can enter the far-side dock (you can't exit one building and enter another on the same turn), however units being transported can exit the far-side dock on this turn.
Sink the Ferry
Instead of 'swapping sides' you can setup the 'docking station' / 'Ferry' so it can be captured by one side or destroyed by the other. In fact, even after it's been captured, the other side can destroy it !
The auto-tile-swap sequence is P1,P2,N = so 'all' we need to do is decide which side gets to sink the Ferry and set P1 (or P2) = shallowwater tile (not shop) The Ferry/dock starts as Neutral. One side then gets the option to 'capture' and use the ferry, whilst the other side has the chance to 'sink the ferry' / 'destroy the docking station'.
To make gliders 'single use' Transport Aircraft the [events] system has to be used to destroy each one at some specific time (realistic if the game starts after the gliders have been released from their towing aircraft). Further, to be even more 'realistic' we want the 'LZ' (Landing Zone) hex's to be 'single use' (i.e not allow a second glider to 'land' at the same place as the first) and for troops to exit the 'landed glider' at any time they wish
A new 'LZ' terrain icon is defined, type shop and mapped as a Neutral building. The (Player 1) Glider units is set to type 'trooper'. The P1 'captured LZ' tile is a 'landed glider' icon (of type shop) When the neutral building LZ is captured by the P1 Glider (trooper), the 'LZ' icon changes to a 'landed glider' (shop) icon, which means the Glider troops are now 'on the ground' (inside the building) and may exit immediately (or stay inside). To prevent the Glider being reused, the [events] system has be be used to 'destroy' each Gilder (by it's unit ID) on a 'timer' event When the Gliders are Destroyed, troops that made it to the LZ (so are inside the landed glider building) will 'survive'. Since Player 2 can 'capture' the LZ/Glider building, the P2 'captured LZ' icon will be a (non-shop) 'crater'
Tricks with mines
Any unit can be given type=mine. Units of type=mine have two very useful properties -
The first is that they can be 'deployed' (into types of terrain= they are allowed into) even if they have a move=0 (which is the normal case, since we don't want them to wander away :-) )
The second is that they can be 'picked up' by units of either side that are set to type=sweeper
Whilst the Events system can be used to change terrain tiles on a 'one per Event' basis (see my using events for bridging page) this is a right pain.
A far better approach is to use a 'mine' type unit, with an icon = 'destroyed bridge' or 'water', as a 'blocker' on top of a bridge tile. When the unit is 'swept' (by an Engineer unit) it is removed to reveal the intact bridge (or 'pontoon over water') tile it was 'sitting on'.
It's tempting to look for a way to use the automatic 'change tiles' system (on change of building 'ownership'), however the location where a building is defined becomes impassible to all, no matter what tile icon is shown
Bridge destruction and repair
To 'destroy' a bridge, you just dump a 'bomb' (type mine, move 0, icon = destroyer bridge) on it from a 'transporter' unit (since no unit can pass through any other, this effectively blocks the bridge)
To 'repair' the bridge, all you have to do is 'sweep' the 'mine' off it (both sides can 'sweep' all mines, irrespective of the original 'owner' of the mine unit)
Pontoon Bridge construction
A pontoon bridge tile is placed at each and every place where a pontoon bridge could be constructed. Each of these tiles is then covered with a 'shallow water mine' (i.e. a unit with and icon=shallow water and type=mine).
This really only 'works' on maps with no air units (or where there are very few possible pontoon locations, or the locations are well away from the center of the game map) = the problem being that aircraft can't cross over the 'mines' so a line across the middle of the Map will chop the battle field into two halves :-)
The 'pontoon transporter' is a 'sweeper' that simply removes the 'shallow water' mine to reveal the Pontoon tile below. To stop the 'shallow water' mine being unloaded ('deployed') which would allow the pontoon transporter to 'sweep' more mines (and thus reveal more pontoon bridges) it can be given no 'terrain=' permissions at all
Note the AI is very poor at this sort of trick i.e. chances are it's never going to work out it can 'sweep' the shallow water 'mine' so will never end up 'building a bridge'.
Tricks with Transporters
It's easy enough to load up a Transport Aircraft with Paratroopers, carry them into battle and 'drop' them anywhere - however we need to prevent the Paratroopers from simply 're-boarding' their transport aircraft
The trick is to define TWO Transport Aircraft units. The first (with appropriate max/min and slots) is used in CoMET to 'setup' the Paratroopers (load up the units) and for deployment (initial positioning)). The second uses the same icon, but has weight settings that prevent the units re-boarding. Once the Map has been defined, it is 'exported' as source (.src) and a hand-edit used to replace the 'setup' aircraft with the 'real' transport aircraft (with the prohibited max/min weight) using a global search and replace on the Unit 'name'. The .scr is then recompiled into a .lev using CFED.exe. This will complain ('units too heavy') but will complete the compile anyway. The result will be exactly as desired (paratroopers will exit but not be able to enter)
Gliders are similar but different - they should 'land' once and not move again (so re-boarding can be allowed but gains the player nothing). To stop 're-use' of Gliders, the Events system can be used to Destroy them (by unit ID number) on some specific turn (this is reasonable of the Scenario game starts after the gliders have been released from their towing aircraft)
If you want to give the 'defender' some (small) chance to 'react', then the 'attacker' can be given 2 turns to 'land the gliders' before they are destroyed = if not then they can be destroyed at the end of the first turn. eg. on 'turn one', player1 gets to 'fly' his Gliders to some landing zone, where they 'unload' the troops. On 'turn two' the Events system destroys each of the Gliders (and this will also destroy any units still being carried).
If you want the units still being transported to 'survive' and/or a 'landed glider' icon to be left behind, you must use the 'building' (complex glider) approach detailed above
Tank recovery and repair
Just define a new Engineer unit, type Transporter + Medic. Set trans-weights max/min for the type of Tank to be repaired. The unit will need to carry resources (crystals) since it 'costs' 5 for each repair
A Truck can be created to deliver crystals from a depot or factory to the Engineers (in which case weights have to be set that allows the Truck to be 'taken on board' in order to deliver the crystals)
Unit type tricks
There are only 3 unit types = ground, sea, air. Each unit has a single 'armour' (defense) value against any attack but (up to) 3 attack values, one against each of the 3 types.
The problem is that whilst you can define different 'attack' against air and ground, you can't have a different attack against Infantry and Armour - or can you ?
Armour attack values
On a map where there are no ships, you can 'cheat' by redefining 'ship' to mean 'armour'.
Set all armoured units (Tanks) to both ground and 'ship' (where 'ship' means armour) Anti-tank guns and Tanks can now have 2 different attack values, one against 'soft' targets the other against Armour. Tanks armed with guns that have no HE capability (such as the British Matilda) will have to get within machine gun range when attacking anti-tank guns and other soft targets.
Next page :- Planning the x3 maps