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

Using Crimson Fields [event] system

CF Events system

Overview

Events are key to many of the 'scenario' battle maps. Typically, one or more Events are combined with some specialist Unit(s) and/or Terrain.

Unit (and Terrain) movement values can be used to ensure a specific unit (eg 'bouncing bomb') has to take or follow some specific path to a specific 'target' (eg dam)
 
Note that playing tricks with the Building entrances, factory settings and 'crystal' replenishment rates will often allow the arrival of reinforcements (after N turns) to be setup without the need for any specific Event

Bridging

Bridges are terrain tiles. This means 'creating' a new bridge (or 'destroying' an old one) requires some clever tricks with Events

I start with defining the 'Pontoon Bridge', a unit that can be carried by other new units (Pontoon Bridge Carriers, Engineer and Landing Craft). The Pontoon Bridge unit is of type = 'mine', terrain=shallowwater** and move=0 so the transporter unit can (only) deploy it into a 'shallow water'** Tile hex (only). The transporter unit definition (min/max weight and 'transslots') limits how many Pontoon Bridge sections can be carried (1)

**Note. The Map Tile ID 'shallow water' should not be confused with the terrain parameter 'shallowwater'. The shallow water Tile ID is 360. Other tiles - such as rivers - have a 'terrain = shallowwater' attribute but are different Tile icons and thus different Tile ID codes

An [event] is then used to 'monitor' each 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

The 'key' to minimising the number of [events] needed is to carefully limit the number of places where the Pontoon Bridge can be deployed.

It 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)

So, 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

It is simpler if the goal is 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 (and only one possible orientation).

How do you generate the required 'events' ?

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.

The script is available for download here (right click & 'save as' - if you 'double click', Windows will try to 'run'# it :-) )

How to make the bridges 'perishable' ?

When an [event] converts 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 becomes 'invulnerable' (it is not possible to 'attack' a tile)

However, since the [event] system can be 'triggered' on a unit being destroyed, the 'sethex' can be used for 'bridge destruction' (although the approach of 'destroy a unit to destroy a bridge' is rather 'contrived', to say the least !)

One 'unit' type that could be used is the 'bunker' - however the approach I took for my 'Bridge conflict' map relies on 'invisible' units positioned either side of the 'vulnerable' bridge section

Destruction of the 'invisible unit'** is then used by the Event system as a 'trigger' to replace the 'bridge' Tile with a 'broken bridge' Tile (as well as removing any surviving 'trigger' units)

** an 'invisible' unit is just one with an unit bmp set to 100% transparent (except for one 'marker' pixel so I can see it myself in CoMET :-) and defined with move=0 (just in case the computer AI is playing that side)

Needless to say, I'll be making extensive use to 'perishable' buildings/walls in my Ancients / Medieval adaption

How was the 'Mulberry harbour' simulated ?

For my Beach Assault map, a Pontoon Bridge section was loaded onto a Transport Ship. A Transport Ship is restricted to 'deep water' and 'water', whilst the Pontoon Bridge unit is restricted to 'shallow water'. As a result, the Pontoon could only be 'unloaded' from the Ship when the Ship was in a water tile next to a shallow water tile.

The map was laid out with only a few places where a single 'shallow water' tile separated 'water' tiles from the beach - and thus there were only a few places where the Transport Ship could actually get close enough to 'deploy' the Pontoon Bridge section into 'shallow water' and 'connect' to the shore

The [event] system was then used to 'monitor' each and every tile were the 'Pontoon Bridge' unit could actually be deployed. When the unit is 'found', the Event triggers and the 'Pontoon Bridge section' unit is replaced by a Pontoon Bridge tile, and the Transport Ship unit by a 'Pier' tile.

Once 'deployed', other Transport Ships could then 'dock' with the Pontoon tile and unload units that could traverse the Pontoon and Pier to the shore ..

How did you simulate the dams in the 'Dam Busters' map ?

Easy - 'invisible' units are sitting on the 'road over water' tiles being used as the 'dam'. When (if) the 'correct' one is destroyed, the event is triggered to replace the road tiles with 'broken road over water' tiles (and remove all the invisible units). To stop bombs being 'dropped' on the 'wrong' side of the dam, a second type of invisible unit is used that has no 'vulnerability' to attack

To prevent the 'blocking' units being 'targeted' or flown over, they are defined in the same way as buildings

[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'.

1) 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 reinforcements can 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.


Clicking "Next >>" (nav bar, left) will take you to my Astro mount ('Barn Door') construction pages

Next subject :- Steves WW2 maps

[top]