Global Events

Another advantage of Cavalry is the ability to arrive fast where it is needed - this makes it attractive to serve as reserves. However, before discussing cavalry in such a role, we have to understand event management in the software.

The reason is that reserves are usually deployed when a battle line is broken to prevent enemy forces from pushing through the gap and then starting to attack the line from the rear area. Or they might be deployed as a relief when another fighting force is in trouble. However, the system of orders and conditions used so far does not allow this - a unit can be instructed to follow certain orders when it is attacked or under fire or in the proximity of another unit, but not when another unit is attacked or threatened. But such an ability is precisely what is needed to deploy reserves.

Of course such commands can be given in interactive mode - but this is tedious and prevents a statistical analysis of different tactics. For that reason, the event manager allows to detect certain conditions on the battlefield, process them and give appropriate orders to units or formations in the way a general having an overview of the field might do, and in this way statistical analysis of problems involving reserves can be done again.

Triggers

The first element of the event manager is the trigger. A trigger looks at the state of the battlefield and evaluates whether a condition is true or false. A trigger declaration to check whether at least one of two units has lost more than 50% of soldiers might look like this:

event_trigger
id G11_G12_destroyed
logic OR
unit_destroyed_fraction 0.5
unit_destroyed G11
unit_destroyed_2 G12

The keyword id defines a name which other elements can reference. unit_destroyed_fraction defines the threshold of soldiers no longer fighting beyond which the unit counts as destroyed, and unit_destroyed identifies which unit should be checked (there are in total five slots that may be filled with units in one trigger).

What happens with this is that the event manager checks the identified units, queries how many soldiers are still fighting, if more than 50% are the condition is false for the unit, otherwiese it is true. These individual assessments are now merged using the defined logic - here options are AND (condition must be true for all units), OR (condition must be true for at least one unit), XOR (condition must be true for exactly one unit) and NOT (condition may not be true for any unit). This determines the state of the total trigger element.

Logic

The (optional) second stage of the event manager is a logic element. This has either triggers or other logic elements as input and uses a logical AND, OR, XOR or NOT to generate an output.

The idea here is to capture complicated decisions, i.e. deploy reserves to the center if 50% of the units there are destroyed, but not if the right wing us under attack by enemy cavalry and not if the first wave of reserves has already been sent to the center.

Formally the logic element looks like this:

event_logic
id line_broken
type OR
input_1 G06_7_destroyed
input_2 G11_12_destroyed

It has an id under which its own value is stored, a logic type that defines the operation being done and up to five slots for inputs which need to be the ids of other elements (either trigger or logic). If a logic element is defined below another logic element it will be evaluated afterwards, otherwise the reference will be resolved only one cycle later.

Result

The result element has the purpose to deliver a command when a trigger or logic element is true. It might look like this:

event_result
trigger_id reserves_cross
command_formation br
order seek_enemy

This element gives the order seek_enemy to the formation br when the element with the id reserves_cross becomes true. Alternatively, commands can also be given to individual units.

The combination of the three elements makes complex decision structures possible that evaluate an arbitrary number of conditions on the battlefield.

Example

The provided example09.cfg shows a simple encounter that exemplifies event triggers. Army A has heavy cavalry in front of an infantry line, army B has more infantry. The idea of A is to smash through the line, the battle plan of B is to use the additional infantry to out-flank the enemy line, and the event trigger is used to determine when the flanking units should turn around and attack the rear of the line. Technically this is done with a line_crossed trigger used on several of the flanking units.

You will find that most of the time the cavalry ends up making the difference - by breaking through the line and attacking B from the rear, it can eliminate most of B's units before the flanking maneuver works.

Syntax

A list of valid triggers is

formation_destroyed - the specified percentage of units in a formation is inactive

unit_destroyed[_2..5] - the specified percentage of soldiers in a unit is inactive

line_crossed[_2..5] - the unit has crossed a specified y-position on the field

unit_engaged[_2..5] - the unit is in combat

Continue with Cavalry - Part 2: Reserves.

Back to main index Back to science Back to historical battle simulation

Created by Thorsten Renk 2022 - see the disclaimer, privacy statement and contact information.