The events.csv file is the trigger for everything that a designer wants to occurr in a scenario. This file is NOT required to be filled in. A designer can just place units in the units.csv file and then set the strategicAI flag in the level.ini file. This will allow the AI to take control of the battle. But.. if the designer wants specific things to happen during the course of the scenario, this is where they do it.

This file is the script of the scenario. It can make any unit do anything that you want. But... because we wrote the AI long before we wrote this scripting file, things don't always work out. For example if you gave a brigade an order to march right through the enemy lines, they would never make it. They would stop and fight as soon as they saw the enemy. It's hard. We took a ton of time in writing and testing our own scenarios, mainly because units would not go where we wanted them to. They would see the enemy and stop and fight and mess up the entire scenario. It's all random, even if you script every single movement, it will not play out exactly the same 2 times. Units want to protect themselves, and based on their "stance" they will react to seen enemies. So realize this as you design your scenarios. Realize that it's not going to be perfect, it's like the "Chaos that is War", is built right into our design.

There are 2 major parts to the events.csv file. Timed events and triggered events. The top of the file is the timed ones, the bottom are the triggered ones. Timed events occur at a specific time. They are synced with the start time of the scenario as determined in the level.ini file. They will happen at the exact time stated, no matter what else is going on. It really only makes sense to use timed events in the beginning of the scenario to get things rolling, but that's up to you. Triggered events happen when something else happens. There are many ways to trigger and events and they will all be covered in the tables below.

Note: Unless you want the game to lag when your events are run, we suggest spacing them out. Don't have a ton of timed events run on the same exact second. Space them out every second or 5 seconds.

Timed Events	Explanation
A: Time	This is the time of the day that the event should occur. These are of the format HH:MM:SS. This is NOT the time since the scenario started. This IS the time of the day. The start time of the scenario is in the level.ini file.
B: ID Name	This is the ID Name of the unit from the units.csv file. Each units that you want to reference in this file must have an ID. This is the unit that will be affected by this event.
C: Command	This is the command that will be run for this event. Commands that take multiple parameters have their parameters seperated by : colons, exact those commands that take coordinates as described below. Please see the commands reference for a complete list of commands.
D & E: X & Z Coord	On our map there are two coordinates that matter, x and z. Since y is up and we don't allow airplanes, y does not matter. All commands that require map coordinates will get the x and z from these columns. For example: moveto, forcemove, and safeplace.
F: Time Var	This column specifies to run this command a certain amount of seconds in the future. So if you want someone to happen 2 minutes after an event is triggered, you can set this column to 120. Then 2 minutes after the event is triggered, the command on this line will run.

After the timed events, there are the triggered events. These events are triggered by the scenario. They may never happen, but with some experience you'll find that the triggered events are the most powerful. In the below table we describe all of the triggeres.

Triggered Events	Explanation
evtarrived	This event is triggered when the unit defined in column: B has arrived at the location define in columns D & E. This means that the unit in column B is stopped and within 100 yards of the location. Also that all of his subordinates are also stopped. This is used to determine that a formation is halted and set up.
evtcont	This is not a trigger, but is used after a trigger to add other events after a trigger. Since a trigger line can only do one command, this is the way to add more commands to one trigger.
evtcourier	This event is triggered when the unit defined in column: B has received a courier message. Since the AI throws couriere all around, use this carefully. As the first one will occur when the first courier arrives, and the second with the second courier.
evtdeath	This event is triggered when the unit defined in column: B has died. This is how we end the game when the player dies. It can also be used to add some variety to a scenario, because units may or may not actually die.
evtfailcheck	This event is triggered when the unit defined in column: B has reached the fail grade. The fail grades are command specific. These are the events that we use in open play to end the battle. Each level of command has their own fail grade. By adding this event to a unit, that unit will now do fail checks. If their grade falls below the fail grade for their command level, then this event will be triggered.
evtfighting	This event is triggered when the unit defined in column: B has first engaged the enemy.
evtgiveup	This event is triggered when the unit defined in column: B has given up. This means that they have lost all of their subordinate units.
evtgrade	This event is triggered when the unit defined in column: B has reached a certain grade. Note that this is a greater than or equal to >= comparison and will not work to see if a unit has reached a low grade, only a high grade.
evtintrouble	This event is triggered when the unit defined in column: B is in trouble. This state can be seen by the displaying of the in trouble icon over that unit. It usually means that all of their men need rallying and that this unit is really no longer a fighting force.
evtobjarmy1	This is just like evtobjdone, except that it is only triggered when army 1 has completed the objective.
evtobjarmy2	This is just like evtobjdone, except that it is only triggered when army 2 has completed the objective.
evtobjdone	This event is triggered when the objective defined in column: B has been completed. If this is a hold objective, then this will trigger the first time it is completed. Note that this requires an objective ID, not a unit ID.
evtseetarg	This event is triggered when the unit defined in column: B has first seen the enemy. This is used for officers and it means that one of the regiments under their chain of command can see the enemy.

The following table shows the layout of the triggered events. It is much like the layout of the timed events with the exception of the first 2 columns on the trigger line.

Triggered Events	Explanation
A: Trigger Type	This is the trigger type as defined in the above table. This can also be evtcont to attach this row with the previous trigger type.
B: ID Name	This is the ID Name of the unit from the units.csv file or the objective from objectives.csv. Each units that you want to reference in this file must have an ID. This is the unit that will be affected by this event.
C: Command	This is the command that will be run for this event. Commands that take multiple parameters have their parameters seperated by : colons, exact those commands that take coordinates as described below. Please see the commands reference for a complete list of commands.
D & E: X & Z Coord	On our map there are two coordinates that matter, x and z. Since y is up and we don't allow airplanes, y does not matter. All commands that require map coordinates will get the x and z from these columns. For example: moveto, forcemove, and safeplace.
F: Time Var	This column specifies to run this command a certain amount of seconds in the future. So if you want someone to happen 2 minutes after an event is triggered, you can set this column to 120. Then 2 minutes after the event is triggered, the command on this line will run.