The Event System allows the scenario designer to create unique actions depending on the actions in the game. This can range from a trigger which sets off a simple action all the way to a multi-faceted full Lua script which has long ranging tactical consequences. Using the ScenEdit functions, Lua, and the available triggers, it's possible to do nearly anything in the game. Clever use of triggers allow for good scenario design.
- 1 Events
- 2 Triggers
- 3 Conditions
- 4 Actions
- 5 Special Actions
Each event requires a trigger and an action. A condition is optional. You may set an event to be repeatable, or to occur a single time. You may also choose to show it in the log, though this can give away the surprise. A probability may be set so that the event may not fire each time.
You may have multiple triggers, conditions, or events. Only one trigger is required to set off the event, though all conditions must be met. All of the actions will activate.
Each trigger type allows the event to activate.
Unit is Destroyed
In the description area you'll want to add a descriptive and useful name. It's not uncommon for a complex scenario to have hundreds of triggers. The above example is OPFOR.Destroyed, another variant could be OPFOR.Destroyed.Aircraft. Then when you're sorting through your events it'll be very easy to determine what a trigger is doing.
You must, at least, set a target side. Then if any unit on that side is destroyed the trigger will fire. You may drill this down further to a target type, subtype (which will only show what is in the scenario), class, and even a specific unit.
Unit is Damaged
Unit damaged is very similar to unit destroyed except you can decide what damage threshold for a unit. This may not be useful for something that is easily destroyed but something like a runway or a Carrier might take quite a beating.
Side Points will trigger when the point count for a side meets a certain criteria. This can be used to determine when a player has reached a threshold to end a scenario or it can be used as a dynamic stance for a side. For example each time the player destroys a hostile unit it may add a point to the hostile side. When enough points are met it could cancel missions, allow the enemy to surrender, or even bring an outside threat.
Pro tip This value is stored between saved games.
At the appointed time the trigger will fire. Be sure that you click "SET TIME" after you have picked your time otherwise it will not be saved.
Pro Tip : Pick odd times for your time trigger to fire. Players can come to expect a change at the top of the hour, so surprise them!
Unit Remains in Area
If a unit remains inside of a defined area for a set amount of time the trigger will fire. You must at least set a side, a time, and an area to be inside. Be sure to check the area validation to make sure your area is valid. This can be useful for escorting a ship or as an exit area. Be aware that this trigger is omniscient and will fire even if a unit is undetected.
Unit Enters Area
This trigger will fire if a defined unit or side enters area during a certain time. It may also be a NOT trigger. So if a unit leaves an area the trigger will fire. Be aware that this trigger is omniscient and will fire even if a unit is undetected.
This trigger will fire somewhere between the two defined times.
Unit is Detected
This trigger is one of the best for creating a realistic reaction. You may set not only the target side, unit type, but also how well the detecting side sees the detected side. On top of that you can define an area of interest. This leads to realistic reactions depending on where the trigger is fired. It rewards the player for using terrain and minimizing detection.
For example you could make a simple version of the trigger that when the BLUFOR is detected by the OPFOR a mission is set active. Or, you could define an area, and only trigger when the BLUFOR gets close enough. One more trick is setting several detection areas and scrambling different fighter bases depending on which area the player is detected.
Scenario is Loaded
This trigger fires when the scenario is loaded. Useful for loading attachments or making sure certain variables are set.
This trigger will fire consecutively at the interval specified. Be sure to make the event repeatable or it will only fire once.
Scenario has Ended
This trigger will fire at the conclusion of the scenario. Useful to provide information to the player.
A condition is an optional check to decide whether or not an event will fire. It is binary in output. Either it returns a true statement or a false. In the case of a false statement the action does not occur. You may also use conditional statements in the action lua script.
This condition checks for the posture between two sides. So if two sides have not met a requirement then the action will not occur. For example if the player is detected but has not been marked hostile, then the action would not fire.
Scenario has Started
This condition requires the scenario to have been started (or not).
The Lua Script condition is the first time you may encounter Lua scripting. In this case we may use information to determine a more complex set of conditions. In the above example we query the unit that tripped the trigger using ScenEdit_UnitX(). This function, when assigned to a variable, gives us all of the information on the unit. Then we compare it to an altitude value and if the unit is beneath a minimum altitude we return true and if not we return false.
The return true and return false is critical. Without that information the condition will not operate properly.
The action is what occurs when the trigger has been met and the condition is true (or not defined).
This action will add, or subtract, points from a target side. This can be used to determine victory in the case of the player (or defeat). More creative use can allow the AI to use it as a storage variable to be compared later on.
This action will end the scenario and present the player with his results.
Teleport to Area
This action will take a unit and teleport it into a defined area. To be used sparingly as the non-realistic behavior can frustrate the player at times. For example a submarine suddenly existing in a patrol area will confuse the players ASW efforts and make it seem like they had failed. It is recommended that fluff is used with a special message to explain why a submarine suddenly exists where the sensors could not find it. Useful when a unit can be placed in a safe zone to be added to the scenario later.
This action allows you to create a text, or HTML, message for the player. Be sure to define the side that the message will be shown to. It is possible to link to images using html as well for dynamic messaging. 'Is it possible to link to local images?'
Change Mission Status
This action will change the status of a mission to either active or inactive. For example if a unit detected trigger fired, this action could set a patrol mission active.
Probably the most powerful option. This allows you to use Lua script to define whichever action you would like. ScenEdit is the action most used, but the sky is the limit (and your knowledge of Lua). For a complete list of functions check out the Script Repository here or go to .
The special action area allows you to give the player an action available independent of a trigger. This could allow the player to ready aircraft, bring in reinforcements, or do whatever it is you'd like using Lua. Be sure to notify the player in the briefing that a special action is available. They can be found by clicking Game, Special Actions, and then selecting the action and clicking Execute.
It is good practice to give a clear description of what executing the script does.