Trigger

Triggers enables the player to create and activate a variety of effects once certain conditions are meet. These features can be used to enhance scenarios and simulate many genres, e.g. Defend-the-Spot, Role-playing games and Fixed Force effectively. If used creatively, triggers can be used to create objects that can be found nowhere else in the game. For example, looping the creation of shore fish using the Create Object trigger can be used to simulate a fountain or splashing water.

Age of Empires II

Overview

To create a trigger, go to the File:Triggers.PNGtab and select File:New trigger.PNG. Triggers can be renamed by clicking File:Triggers info.PNG but it will always set to Trigger # and highlighted in red by default. Red indicates that the trigger will not fire while green indicates that the trigger is fully operational once New Conditions and New Effects are created. The triggers tab was updated with the Conquerors expansion pack that added new features like the Change Object Name, Change Object HP and Change Object Attack effects, which enables the creation of customized units. Designers no longer need to use the name of old, historical figures anymore: any fantasy theme could now be created. Triggers can also be looped if the box is checked. This reactivates the trigger repeatedly until the game is over.

Trivia

• The maximum amount of resources a player can have before the numbers in the display tab freeze during the game is now 2,147,483,648 or 2³¹ with the HD expansions instead of around 1 billion. The player can still spend resources despite the problem, however, and much of the glitches related to this incident have been fixed through subsequent HD expansions. Although the game does account for resources beyond this value, the numbers will not change until the number of resources is below this threshold. This value can only be reached by using triggers.
• 2³¹ is also the maximum amount of resources a Gaia player can tribute to another player at a time. Exceeding this value would cause the game to automatically round it down to 2³¹-1.

Glitches

Although triggers are very useful, it can initiate several bugs that may impact gameplay, both positive or negative. Most of the glitches caused by these bugs are minor and do not affect the game system. The most serious it can get is ending the game prematurely and forcing the game to crash unexpectedly if the editor is not careful enough. Most crashes are caused by triggers overloaded with too many effects or affecting too many units at once. Multiple triggers fired simultaneously can also cause this problem. However, this can be easily solved by spacing out triggers and distributing its effects evenly using multiple triggers under wider time intervals.

Infinite loops

Looping triggers can be useful in small amounts, but if this option is used in conjunction with extraordinarily high values, glitches and even crashes can occur. A similar situation can happen If too many triggers go off at once. Using values that exceed certain limits can also create similar problems. Anytime when an input quantity exceeds a limit, each of the following scenarios can happen even if the trigger is not being looped.

Resources

Exceeding the 999,999,999 resource display capacity will cause the digits to veer off screen. If this limit is surpassed by the input quantity and the trigger is being looped, the loop will stop automatically. An even larger number exceeding this limit by an order magnitude will result the following:

• The tribute may be reduced to any random value below 1,500,000,000 of any resource. Upon exiting the trigger tab or the playtest of that scenario, that random value will appear automatically in the quantity section of the effect tab.
• A more extreme case exists in which a bug will cause the resource display to freeze and render the player's resource economy useless since it prevents development of units and technologies. Recovering from this is impossible unless the game ends. Sometimes, the resource display number will be negative. If this were to happen, the quantity of that tribute will be set to 0 upon exiting that scenario.

Stats

A similar situation can also occur when triggers reward additional attack or hit points for units and buildings. Exceeding 32,000 in either of them at any rate initiates a bug that can cause unexpected things to happen. Upon exiting the trigger tab or the scenario playtest, the quantity will be automatically set to a random amount less than 1,500,000 if the original quantity exceeds it by an order of magnitude.

• For example, if the hit points reach 32,000 too quickly, death for that unit or building is inevitable. This can be a major problem since this will affect all units impacted by the trigger and will cause the player to lose the game prematurely.
• Alternatively, a similar bug may be initiated if a trigger causes the attack of any unit or building to exceed 32,000 at any rate. Instead of losing that unit or building, the bug will cause the attack to fluctuate very quickly between the original attack and some random number slightly less than 40,000. The attack will be initially high upon reaching the limit and then decrease to the original attack strength. This will repeat until the game is over. Although the stats will display the original attack at some point, the unit will deal only 1 damage to any unit or building until the unit gains attack again. At the same time, the hit points may also increase at a higher rate depending on how fast the attack is raised.
• On a similar note, a different bug can cause the hit points of a unit to exceed the supposed hit point capacity. This occurs when the green bar displaying amount of hit points veers off screen towards the right. This can happen at any time when the trigger increasing hit points are looped. Units that can change tasks such as villagers, monks and trebuchets will always be affected by it. Damaged buildings and converted units may also face this situation, but is less common. Buildings that constantly gain hit points will retain their appearance even as the player advances through different ages.
• In some cases, the hit points can increase faster than the limit if the trigger increasing hit points keeps looping. This is especially common to units that can change tasks. Each time a unit change tasks, the rate at which the hit points increases will accelerate. If this continues long enough, the green bar may veer off course so fast that the green bar would gradually be replaced by a red one. This usually occurs if the hit points approach 100 million, but this color change may not always happen. If it continues, this color change can oscillate repeatedly upon clicking the unit until the trigger stops or until the hit points exceed 1 billion. Any value higher than this and the numbers would turn negative while the green bar will disappear. The unit will remain immortal unless the player researches Heresy and converted by enemy Monks.

Age of Mythology

As with the triggers in the Age of Empires games, the triggers in Age of Mythology allow to combine conditions with various in-game effects. While the triggers themselves are structured by scenario designers and random map-scripters, the conditions and effects are provided by the game but can be also modded into it.

Basic triggering

Within the trigger editor new triggers can be created, renamed and modified. Within the group editor, triggers can be grouped to provide more clarity.

The Triggers allow with Check-Boxes for further modifications. Possible Settings are Active/Inactive, Fire Immediately and a Priority Slider.

You are advised to pull the priority slider to maximum always. However do only Fire Immediately one active trigger, which will be loaded together with the map. Here you only want to set up a bare minimum of effect, e.g. if you need diplomacy settings to be correct right at the start of a multiplayer game so that units don't walk out of position attacking each other.

The effects Fire Event and Disable Trigger are used to toggle the activity status of triggers. While Fire Event sets one trigger to active, Disable Trigger sets a trigger to inactive. Fire Event allows you to pick a trigger from a drop-down menu. When you rename the trigger it will automatically choose the correct one, since it saves triggers by ID and not by name. Be wary that when you pick a trigger to be fired, the trigger in your triggers system will be set to "inactive" by doing so. Disable Trigger expects a text as the triggers name. When you rename the trigger, you have to manually rename it in the Disable Trigger parameter, too.

Conditions

Besides the need for the trigger to be active, conditions are required to activate the events. When multiple conditions are added, all of them need to be met for the effects to be executed.

Checkboxes OR and NOT allow for modified conditions. With OR either one fires the effects, with NOT the conditions opposite has to be met to fire them. By boolean logic the result of using both with multiple triggers is not clear without testing.

Effects

All effects will be executed in order when the conditions are met.

Multiplayer triggering

Various triggers do not work in LAN or multiplayer games and have to be avoided, e.g. Set Animation, Unit Move or Kill. In multiplayer triggers for moving units have to use the army effects (which target command groups). For killing units Damage Unit % can be used, or if the death animation should not appear Destroy.

Other conditions and effects might lead to sync out of the game, like the Visible to Player condition. This condition was made to account for one player only in the campaign, thus is not fit for a multiplayer environment.

Creation of own conditions and effects

Within the path Age of Mythology\trigger (or trigger2 for The Titans) the conditions and effects are saved within the typetest.xml. Custom conditions and effects can be scripted into a new yourname.xml-file and will automatically be put into the game by the games file system on game start. This means after changing the trigger file to test out new conditions/effects the game will have to be restarted.

Methods which can be used can be found in the Aom Code Reference.

Basic Trigger File:

  <?xml version = "1.0"?>
  <trigger version="2">
  <Conditions>
  </Conditions>
  <Effects>
  </Effects>
  </trigger>

Exemplary Condition:

  <Condition name="$$22290$$Timer">
     <Param name="Param1" dispName="$$22291$$Seconds" VarType="long">0</Param>
     <Expression>(trTime()-cActivationTime) >= %Param1%</Expression>
  </Condition>

Exemplary Effect:

  <Effect name="$$22414$$Fire Event">
     <Param name="EventID" dispName="$$22362$$Trigger" varType="event">-1</Param>      
     <Command>trEventFire(%EventID%);</Command>
  </Effect>  

The original games names for conditions, effects and parameters take in combinations of $-Signs and numbers, which refer to entries in the language.dll, thus translating the names for other languages. However for custom effect just normal strings like "my Effect" work perfectly fine.

Be wary that the amount of parameters is not allowed to exceed 7.

A syntax error in the custom trigger file, like forgetting to end a line with a semicolon, putting a semicolon at the end of an expression or forgetting XML-tags, may cause the trigger file to not load properly. You will notice that all the conditions/effects do not show up in the drop down menu in the ingame editor. Fixing the error and restarting the game results in all the conditions/effects showing up again.

Broken conditions or effects result in all triggering not being executed. This can be easily tested if one trigger removes all players god powers right at the beginning at the game. Testing the map and keeping the god power means that the triggers have not been executed altogether.

Be also wary of the character limit for each line, since breaking it might corrupt scenario files into not being openable anymore until repaired within the hex code. It is advised to have a backup of the scenario before experimenting heavily with functions you are not familiar with yet.

trigtemp.xs

Whenever a scenario is started, the game generates a trigtemp.xs which translates all the triggers into code used by the game. This code can be looked up in the trigtemp.xs for further insight on how the game handles triggers. Among a lot other values for example armies could be hardcoded into conditions/effects and save work when picking parameters.