Overview
Events are key to many of my 'scenario' battle maps. Typically, one or more Events are linked to some specialist Unit(s) and/or specific Terrain location
For many effects, an [event] is is not needed at all. Instead Unit (and Terrain) limitations and movement values can be set to ensure a specific unit (eg 'bouncing bomb') has to take or follow some specific path to a specific 'target' (eg dam) Tricks can also be played with Building entrances, factory settings and 'crystal' replenishment rates to generate reinforcements (after N turns) without the need for any specific [event].
Automating Events
Creating events by hand is tedious and easy to get wrong. So I've written some QBASIC scripts to automate the generation of events for my 'common' cases
Victory conditions
Adding the 'standard victory conditions' - win when you capture the enemies HQ or when you have killed all his units - is a pain.
First, the VICTORY.BAS script looks for the 'all units killed' event (for both players). If not found, they are added. Next a check is made for the comment '# score freeze 1' and '# score freeze 2' meaning skip the setting of a new score for Player 1 or 2. To adjust the settings, existing events of 'type = score' are removed. Then a new series of score events constructed around building 'ownership' using the 'depends' condition. Most maps have relatively few buildings, however the number of possible combinations quickly mount. So first I decided that a Player had to hold onto it's own HQ plus the majority of other buildings. Bunkers or depots with no crystal generation capability are ignored (as are all buildings without entrances). There is no way to reduce a players victory points when he looses a building, so all the possible "winning combination's" have to be worked out and each combination sequence linked together with 'depends' conditions. A map with 6 other buildings (Factory, Mines) and the two HQ's would require that in addition to their own HQ, a player hold 4 other buildings from the 7 possible (6 + enemy HQ). There are no less than 35 possible combinations ! Each combination is a string of 5 events. This requires 175 events per player, so 350 total !! Then, after all this, assuming each player starts with 3 buildings (plus his HQ) he only has to capture one more to win. Eventually I decided that to win the Player needed to hold 'all but one' of the buildings. The number of combinations is then equal to the number of buildings N (so, for a typical map, 8) and each string N-1 (7) long, so 42 events per player, 84 total for the typical map, which is a lot more manageable. NB.There is no reason why victory conditions should be the same for both players
Handicaps
The AI is rather a weak player. So should get extra units. This is set up using the handicap event. But it's such a pain (extra units are created one per event), that when building a new map it's the last thing I bother to do. This, of course, then upsets the 'balance' of play :-)
Again, it's easy enough to 'automate'. The script will just generate sufficient handicap [event] to add percentage of the already placed unit types 'evenly' to the Player buildings. The HANDICAP.BAS scrip starts by checking for comments '# thandicap 2 freeze' and '# thandicap 4 freeze'. Trigger thandicap 2 means Player 1 handicap is set, so Player 2 gets extra units. Trigger thandicap 4 means Player 2 handicap is set, so Player 1 gets extra units. Freeze means don't change the handicap for that condition. To avoid adding unit types that might 'break the scenario', the script first scans for the unit types deployed for each player. Then it calculates 10% of each, rounding up (so minimum 1 of each type). These are then allocated to that players 'owned' buildings.
The problem is two fold. First it requires the human player to set the 'handicap' option at the start of play, second the AI has a habit of sending it's units to their death as fast as possible. Rushing everything to the front just results in traffic jams, allowing the human plater to kill them one at a time.
My first version of REINFRCE.BAS script set up a series of createunit events. These soon got out of hand, so instead the script now looks for all the '4 tile' buildings. Each of the 3 'surround' tiles are replaced with 'shop' tiles and a Factory [building] is set up. These will give the AI sufficient crystals per turn for it to 'create' it's own reinforcement units. To prevent the human player from accessing the factories, a series of start of game [event]'s remove the 'shop' entrance tiles and puts back the 'surround' tiles (the entrances can't be pre-removed because cfed.exe will throw an error when you try to build the .lev from the .src).
Bridging
Bridges are terrain tiles. However you can't 'carry around' a tile and 'deploy' it. Units, of course, can be carried and deployed - but it's not possible to move through enemy units (and moving through your own units is only possible on my 3x maps). This means 'creating' a new bridge (or 'destroying' an old one) requires some clever tricks with Events
Bridge destruction and repair
1) A 'destroyed bridge' Tile exists, and this can be set to 'terrain = shallowwater' (allowing boats to pass) but not given any ground terrain type, so can not be crossed by any ground unit.
At least one, and more likely 2 or 4 [event]'s can be set to 'monitor' the ground accessible hex positions next to the 'destroyed bridge' icon and look for an Engineer Unit to arrive. At this point the event will trigger a 'replace tile' action to swap the destroyed bridge tile for a standard one The has the advantage that riiver traffic can continue to pass the destroyed bridge
2) An alternative, that require no [event] but also blocks river traffic is to use a 'destroyed bridge' Unit. This is a Unit, type=mine, move=0 that simply uses (a copy of) the destroyed bridge icon. The 'destroyed bridge' Unit is placed on a standard bridge tile and blocks movement. Because it's type mine, it can be 'swept' (removed) by an Engineering Unit to reveal the bridge beneath
This works well for bridges that are 2 or more tiles long, since river traffic can continue to pass under the non-destroyed sections(s) For a single tile bridge, the [event] driven approach (above) has to be used if river traffic is to continue past the destroyed bridge section.
Pontoon Bridges
As above, there are two approaches, one [event] driven, one supported by a 'removable blocking Unit'
1) The [event] approach is based on swapping a Pontoon Unit for a Pontoon Tile (using linked 'destroyunit' and 'replace tile' events)
We start by defining a new Unit, the 'Pontoon Bridge'. This can be carried by another new unit the Pontoon Bridge Carrier. The Pontoon Bridge unit is of type = 'mine', terrain=shallowwater** and move=0 so the transporter unit can (only) deploy it into a Tile with a 'terrain = shallowwater'** setting. The transporter will be limited to 'plains'. The transporter unit definition (min/max weight and 'transslots') limits how many Pontoon Bridge sections can be carried (1). **Map Tile ID 'shallow water' should not be confused with the 'terrain = shallowwater' definition. The shallow water Tile ID is #360, however many other tiles, including rivers, have a 'terrain = shallowwater' attribute The trick is to set up multiple [event]'s 'monitor' each and every possible 'shallow water' Tile hex where a Pontoon Bridge unit could be deployed. When one is found, the Bridge unit is removed (using a 'destroyunit' event) and the Tile is replaced (using a 'sethex' event) with a (newly created) Pontoon Bridge icon tile. Since each position has it's own event, a Tile of the 'correct orientation' can be set. This requires 2 events, per player, per Tile, being 'monitored' (plus up to an additional 8 events if the 'bridge' can be 'destroyed' = see at end) The 'key' to minimising the number of [events] needed is to carefully limit the number of places where the Pontoon Bridge can be deployed. When used for 'river crossing' combat maps, the Pontoon Carrier - a wheeled truck, not allowed in rough - should be used (rather than the Engineer Unit which is allowed in rough). Most of the river bank can then be 'closed' by trees, hills, sand banks, tank traps or just plain 'rough going' tiles
2) The second approach requires a Unit be defined (type mine, move 0) that 'looks like' normal river section (a copy of the Terrain icon artwork is used). The pontoon tile is laid, then the 'river section' Unit placed on top of it. To 'lay a pontoon bridge' all that is necessary is for an 'Pontoon Carrier' to come up and 'sweep' the 'river section' Unit
In theory the entire river can be covered in 'dummy river' Units. HOWEVER remember units can not be crossed over (not even by aircraft) - so such a river covered by dummy Units would totally block other units. However at least this approach does not require lots of events be generated It is simpler if the player is given an Engineering Unit to repair a 'damaged bridge' (one of Tile ID's 211, 212, 213) since there is only one place where the 'repair' can be made
The 'key' to minimising the number of [events] needed, or the 'blockage' caused by 'dummy river Units' is to carefully limit the number of places where the Pontoon Bridge can be deployed.
When used for 'river crossing' combat maps, the Pontoon Carrier - a wheeled truck, not allowed in rough - should be used (rather than the Engineer Unit which is allowed in rough). Most of the river bank can then be 'closed' by marsh, trees, hills, sand banks, tank traps or just plain 'rough going' tiles
Generating [event] sequences
Since Bridging is an integral part of many maps, I have developed a script to automate the creation of [event] definitions.
To use the script, you start by creating the map in CoMET 'as normal' (including 'broken' bridges etc). You then place Pontoon Bridge units on each map Tile where a player could deploy their own Pontoon. You then 'export' the map from CoMET as a 'source' (text) file. Before you can 'parse' the text file using QBasic, the unix 'line end' codes have to be replaced with a Windows 'carriage return / line feed' pair. This can be done by opening the map source (.src) file in a text editor and using 'save as'. When you run the QBasic scrip, it 'parses' the map source seeking [unit]'s of 'type = Pontoon Bridge'. Any found on a shallow water (or broken bridge) terrain tile are 'converted' = i.e. removed and replaced by [event]'s.
You can download the script, ABRIDGE.BAS here (right click & 'save as' - if you 'double click', Windows will try to 'run'# it :-) )
Bridge (and other Tile) destruction
1) The 'easy' method is to deploy ('drop') a 'destroyed bridge' mine Unit 'bomb' on top of the Bridge (or Pontoon Tile) from an Engineer Unit or 'bomber'
If an enemy Engineer Unit is allowed (by weight and min/max translots) to 'sweep' the 'destroyed bridge' mine, then a 'bombed' bridge can be 'repaired' by the enemy. It's easy to stop an Engineer unit 'reusing' a pre-deployed swept 'destroyed bridge' mine, the mine Unit need have no 'terrain =' definitions, so can never be 'deployed'. To 'unload' such an 'un-deployable' mine Unit, the Engineer would have to enter a building To stop the enemy re-using a removed 'bomb' requires a 'destroyunit' [event] triggered on 'haveunit' (so when 'swept' and it changes owner, it evaporates). This is only possible when the bomb Unit 'id' is 'known' (i.e. the bomb exists at the start of the game so it's 'id' can be found in the map .src file) >The disadvantage is that placing a 'destroyed Unit' on a Bridge then makes the river impassable to ship traffic (although that might be realistic since a large Bridge dropped into the river would indeed block the channel)
2) If you want to support the concept of using Artillery (rather than bombs) to destroy a bridge, or other Tile, things become rather more complicated
Tiles, of course, can't be attacked (Units can, but can't be crossed). For a bridge, that has to be crossable, the only 'trick' I could come up with was to define a 'Bunker' unit as a 'bridge control' - then (using the [event] trigger 'unitdestroyed') have the Bridge Tile replaced by a Destroyed Bridge Tile when the 'Bridge control bunker' is itself destroyed by artillery etc.
For other Tiles, that, depending on the scenario, don't have to be crossed but are required to be 'vulnerable' (eg. the Ruhr Dams) an 'invisible unit'** can be placed on top of the Tile to be 'destroyed'. The Event system uses a 'unitdestroyed' trigger to replace the underlying Tile with a 'broken' Tile
** an 'invisible' unit is just a 'normal' Unit with an unit icon (bmp) set to 100% transparent (except for one 'marker' pixel so I can see it myself in CoMET :-)). Such units should be defined with move=0 (if not, you can guarantee that if the computer AI is playing that side it will promptly move the unit :-) )
3) If an [event] is used to convert a 'pontoon' Unit (found on a 'river crossing') into a 'pontoon' Tile (i.e into a bridge that can be crossed by other units), it might be possible to use a similar [event] sequence to 'pick up' and remove the Pontoon
The big problem is that if the [event] is looking for the same Pontoon Transporter to arrive in the same next-door tile, it will trigger immediately after first [event] creates the Pontoon Tile. In other words, the pontoon Unit gets turned into a tile and then back into a Unit :-) So, instead of a Pontoon Transporter we will have to use some other unit, say a 'Demolition Engineer' Unit. In that case, we can simply deploy a 'Demolition charge' onto the Pontton Tile. [event] 'monitors' the Pontoon tile position looking for the Demolition Charge to be 'deployed' onto the Tile. When that happens, destroyunit removes the Demolition Charge and 'sethex' swaps the Pontoon Tile for a 'destroyed pontoon' Tile
How was the 'Mulberry Harbour' simulated ?
Realistically, Transport Ships have no 'shallowwater' capability. So they have to load and unload at Docks or they have to use Landing craft to gradually unload a few Units at a time. This results in a significant 'bottleneck' to getting an invasion force ashore. During WW2, this problem was solved with the Mulberry Harbour, a series of concrete blocks that were placed far enough off shore to allow Transport Ships to dock. A series of pontoons then linked the artificial dock to the shore
One way to 'simulate' the function of the Mulberry Harbour is to use a shallowwater unit 'Pontoon Bridge' Unit. The Pontoon Bridge unit is then loaded onto a Transport Ship. The Transport Ship is restricted to 'deep water' and 'water', whilst the Pontoon Bridge unit is restricted to 'shallow water'. So the Pontoon could only be 'unloaded' from the Ship, when the Ship was in a water tile next to a shallow water tile. Since each such position has to be 'monitored' by an [event], the has to be laid out with only a very few places where a single 'shallow water' tile separated 'water' tiles from the beach. This limits the places where the Transport Ship can get close enough to 'deploy' the Pontoon Bridge section into 'shallow water' and 'connect' it to the shore.
However what I wanted was a larger construction allowing more than one Transport ship to dock at the same time. I also wanted it to 'be authentic' (i.e. use concrete dock sections)
The first step is to define a new Tile = 'Mulberry Harbour position' Tile, terrain=water and a 'Mulberry Harbour Dock' Tile, terrain=plains. Next a Mulberry Harbour Unit is defined, type=ship, terrain=deepwater, move = (reasonable). When the map is created, the 'Mulberry Harbour position' Tiles are placed where the harbour is allowed to be created. Each 'position' tile then gets it's own [event] (these can be auto-created by looking for the Tile #number) with trigger tunit = 'Mulberry Harbour Unit'. When one is spotted arriving at the Tile, destroyunit removes the Unit, and 'sethex' changes the Mulberry Harbour position tile to a 'Mulberry Harbour Dock' tile. Ships then dock and unload Pontoon Carriers which 'lay' the pontoon bridge to the shore (either by removing 'covering (water icon) Units' to reveal pontoon tiles beneath or by laying Pontoon Units into 'monitored water Tiles' where events swap the Units for Pontoon Tiles).
How did you simulate the dams in the 'Dam Busters' map ?
Easy(ish). Since the aircraft have to fly over the dam, we can't use 'invisible' units sitting on the 'road over water' tiles being used as the 'dam'. However since there are no more than half a dozen Dam wall tiles, it's easy enough to use [event] to monitor each
Since we want multiple 'hits', we have to set up multiple events. The first event removes the 'bomb', adds a 'splash effect' Tile and 'enables' the second event, and so on. The last event in the 'bomb chain' replaces the wall with broken wall and starts the 'flood chain'.
[event] examples
# player 1 wins (by gaining 100 pts) if he conquers the enemy HQ (building 6) at any time...
[event]
type = score
id = 0
player = 1
trigger = havebuilding
tbuilding = 6
towner = 1
# the next line could be left out
ttime = -1
success = 100
message = 3
title = 4
# player 1 wins if he destroys all enemy units
[event]
type = score
id = 1
player = 1
trigger = unitdestroyed
tunit = -1
success = 100
# player 2 wins if he conquers the enemy HQ (building 0) at any time...
[event]
type = score
id = 2
player = 2
trigger = havebuilding
tbuilding = 0
towner = 2
success = 100
message = 3
title = 4
# player 2 wins if he destroys all enemy units
[event]
type = score
id = 3
player = 2
trigger = unitdestroyed
tunit = -1
success = 100
# display briefings on the first turn = it's player 1 turn first so that's easy
[event]
type = message
id = 4
player = 1
trigger = timer
ttime = 0
title = 5
message = 1
# Time index = 0 during player 1's turn & we must trigger the message for player 2 as well
# This way it gets queued for display during the turn 'replay' (otherwise player 2 would only see the briefing after his replay).
[event]
type = message
id = 5
player = 2
trigger = timer
ttime = 0
title = 5
message = 2
# we want to support difficulty levels (handicaps)
#
# if player 1 is handicapped we allocate some more
# crystals to players 2's factory
[event]
type = mining
id = 6
player = 2
trigger = handicap
# 1 is no handicap, 2 is player 1, 4 is player 2
thandicap = 2
building = 1
action = 1
crystals = 35
# if player 2 is handicapped player 1 gets another tank
[event]
type = createunit
id = 7
player = 1
trigger = handicap
thandicap = 4
unit = Medium Tanks
pos = 3/2
# if player1 captures the Factory at 17/5 change the entrance icon tile to p1 (FNA, brown) tile
# (whats interesting is that Crimson seems to make the change automatically anyway ..)
[event]
type = sethex
id = 8
pos = 17/5
tile = 20
trigger = havebuilding
tbuilding = 17/5
towner = 1
# if player2 captures the Factory at 17/5 change the entrance icon tile to p2 (Empire, blue) tile
# (whats interesting is that Crimson seems to make the change automatically anyway ..)
[event]
type = sethex
id = 9
pos = 17/5
tile = 21
trigger = havebuilding
tbuilding = 17/5
towner = 2
# there is a broken bridge at tile 10/6 that can be repaired
# (in a real game you might impose a crystal cost on the repair
# this could be done with a Event type=mining + 'depends' parameter)
#
# if player1 moves an Engineer unit to the tile below the broken bridge section, the bridge is repaired
[event]
type = sethex
id = 10
pos = 10/6
tile = 208
trigger = unitposition
pos = 10/7
towner = 1
tunit = Engineers
# if player2 moves a Engineer unit to the tile above the broken bridge section, the bridge is repaired
[event]
type = sethex
id = 12
pos = 10/6
tile = 208
trigger = unitposition
pos = 10/5
towner = 2
tunit = Engineers
# An Engineer unit can carry & deploy a 'Pontoon Bridge' unit
# ... this has to be converted into a terrain Tile to allow other units to move over it
# First change the existing water / broken bridge (whatever) tile into a bridge tile (icon 208)
[event]
type = sethex
id = 13
pos = 13/6
tile = 208
player = 1
trigger = unitposition
tpos = 13/5
# trigger when any unit of type = Pontoon bridge is found at pos.
tunit = Pontoon Bridge
# ... now remove the 'pontoon bridge' unit
[event]
type = destroyunit
id = 14
unit = -1
pos = 13/5
player = 1
trigger = unitposition
tpos = 13/5
tunit = Pontoon Bridge
# add the 'depend' to force the Tile swap to happen first ..
depend = 13
# now generate a second pair of events for player 2's Pontoon Bridge
# .. you can't leave 'player=' out of the definition (player = -1 is 'invalid' for these events)
Finally, a couple of tips on using [event]'s for 'reinforcements'.
The 'simple way' to give the AI (only) reinforcements is the 'entrance-less factory'. Set the type of unit it can build (remember, the AI always builds the first and most expensive unit it can) and the crystal rate per turn to set how often units will appear.
For human players, it's typically simpler to just provide 'crystals' (event type = mining) and let the player build their own reinforcements ..
1) If the scenario requires specific units at some specific location and time, it's easiest to start by defining the reinforcement units on the map (using CoMET) at the positions where they will 'arrive' (especially position the transporters units & units carried). Then hand-edit the .src to 'cut & paste' those units into [events] of type = createunit. The obvious trigger is 'timer', although 'havebuilding' or 'unitposition' can be used to 'steer' a human player into taking some objectives (to change the trigger, use the 'handicap', 'settimer' and 'manipulateevent' event types to choose the wanted behaviour) 2) If the scenario allows reinforcements to arrive in a Factory, you can avoid the need for lots of tedious 'createunit' [event]'s by giving the player a pile of 'crystals' and letting them 'build' their own reinforcements. Note that any building can be designated a Factory, including your HQ, and that using [event] 'type = research' allows additional unit types to added to the list of possible builds in a Factory
Clicking "Next >>" (nav bar, left) will take you to my Astro mount ('Barn Door') construction pages