Anyone who has messed with mission scripting in Tiberian Dawn before, and who has done some slightly non-standard things like using more Houses than just GDI, Nod, and Neutral, has probably wondered at some point or another why a trigger they put in the mission did not work as expected, or, in some cases, even crashed the game.

And, while I dug into triggers before, and in fact have an old document circulating with my name on it[cnc.fandom.com] that claims to know all about these things, I must admit that I'm still very often wrong in my notions on how they work. Especially the role of the "House" on a trigger has been the subject of much debate.

So, one day, when I got involved in a conversation on Discord where some people were messing with these triggers, and it devolved from experimentation to guessing, philosophizing and generally getting annoyed at them, my good friend Kilkakon pointed out that we were all being silly, and should just look at the one place that explains everything: the source code.

The discoveries that were made that day were baffling, confounding, and occasionally hair-raising.

My previous notion that the House was a restriction on who could activate a trigger turned out to only apply to Celltriggers. The configured House is apparently frequently used for both the Event and the Action, often causing insane conflicts and never-working triggers. Two trigger Actions as similar in effect as Production and Autocreate turn out to be handled completely differently depending on what causes them. And the list goes on...

Notes:

• The word "House", in context of C&C scripting, refers to a player side. The name is a leftover of Dune II, where noble families were the involved factions. In TD, they are GoodGuy (GDI), BadGuy (Nod), Neutral (civilians), Special (dinosaurs), and Multi1-Multi6 for multiplayer purposes. All of these can be used in singleplayer missions, though if you try to set anything except GDI or Nod as player faction the game will probably crash when the mission is won.
  
• In this article, "Player" refers specifically to the current human player's House. This is important, since trigger handling will sometimes use the linked House, and sometimes use the player's House.
  
• The "Loop" status of the triggers is a very ambiguously-named thing. Internally it's called "persistence". This word doesn't refer to the loop-status at all, but instead to when the trigger will be removed from memory:
  • "Volatile", indicated in the stock editor as "None", indicates those will trigger only once, execute their Action, and then disappear from game memory.
    
  • "Semi-persistent", indicated as "AND", stay alive until all triggered, and then execute their Action once and disappear.
    
  • "Persistent", indicated as "OR", are true looping triggers, that execute their Action on each triggering and remain active forever (unless specifically destroyed via a "dstry trigger" Action).
  For some reason, these things are called differently in Red Alert, where it's named "Type", with values "Temporary", "Semi-Constant" and "Constant". They mean exactly the same thing, though.

I've been working on an updated version of the map editor included in the C&C Remaster. This contains a trigger check function that scans the more common pitfalls you can encounter with these triggers. You can check it out here:

https://github.com/Nyerguds/MobiusMapEditor/

See the README.MD document for install and usage instructions. The downloads are in the "Releases" section.[github.com]

In this version, I also migrated the names of the Loop stuff to a completely unambiguous list indicated as "Executes" with values "On first triggering", "When all linked objects are triggered", and "On each triggering".

Each Event can come from three different sources:

• Cell: will come from a Celltrigger
  
• Object: will come from a pre-placed unit or structure on the map that has the trigger linked to it.
  
• House: will come from neither, and will be seen as owned by the House in the trigger. Will not work if "House" is set to None, since the function that checks these is the one that processes general House-related functions.

Some events can come from multiple of these, depending on how they're configured and what they are linked to.

• From Cell: a cell is entered by a non-cloaked unit of the trigger's House.
  
• From Object: a linked object on the map is captured, regardless of by whom.

In practice, for the second case, the "object" in question will always be a structure. Units can technically be captured when docked to a Repair Facility, and this will in fact trigger a "Player Enters" event, but in reality there's no way to make an AI unit do that. Some elaborate scenario could be set up to have you deliver a unit to a repair pad and then make an AI capture it, though that sounds pretty convoluted to me. AI helicopters do go to the Repair Facility to get repaired, and can be captured on their pad, too, but those can't be put on the map in a way a trigger is attached to them.

Note that according to the source code, a "Player Enters" trigger with its House set to "None" will automatically substitute that with the player's House. However, there must be some bug involved in this, because in practice, making a "Player Enters" trigger with House "none" will crash the game when starting the mission. So even if the trigger is meant to detect a building being captured, make sure to attach a House to it.

• From Object: a linked object on the map owned by a different House than the Player is discovered by the Player.

• From Object: a linked object on the map is attacked, regardless of by whom. The set 'House' does not affect this. This will only trigger if actual damage is done.
  
• From House: any structure of the House set in the trigger is attacked, regardless of by whom. This works without the trigger being attached to anything. However, this event is only ever fired for the player's House.

These are actually treated as two different Events: "Object Attacked" and "House Attacked". An Object Attacked trigger should never have a House set, and a House Attacked one should never be linked to any map objects, otherwise, strange behaviour will occur. In fact, since the House version only works for the player, the second event is really "Any player building is attacked". Though, you do need to set the trigger House to the player's House for it to function.

The "Attacked" trigger is the only type that works from Terrain objects like trees. As mentioned, though, it does not trigger unless the object actually takes damage, meaning it is useless to put such a trigger on damage-immune objects like the rocks or tree clumps. Note that the default map editor shipped with the Remastered doesn't save triggers on Terrain objects, and will in fact wipe them when re-saving a mission. The updated map editor which I've been working on[github.com] fixes this issue (and many, many others).

• From Object: a linked object on the map is destroyed, regardless of by whom.

A Destroyed trigger should never have a House set, since that will add the trigger to the House's "House triggers" list, and nothing can activate it there. This means such triggers with their repeat status set to "AND" (execute trigger when all linked objects are triggered) will be unable to clear all instances of the trigger, causing it to never fire.

This action does not affect Terrain types (like trees), since the code that triggers the event is only implemented on the level of House-owned objects.

• From Object: any action is performed on a linked object on the map, regardless of by whom.

This is a special case, normally only used on "Cap=Win/Des=Lose". If used with any other Action, the Action will trigger from the moment any kind of triggerable event happens to the object.

• From House: any unit or structure belonging to this House is discovered by the Player.

• From House: all units of the specified House are destroyed.

This check excludes Gunboats, Transport Helicopters, delivery planes, and airstrike planes.

• From House: All structures of the specified House are destroyed.

• From House: All units and structures of the specified House are destroyed.

Again, this check excludes Gunboats, Transport Helicopters, delivery planes, and airstrike planes.

• From House: credits of the specified House increased to the specified amount.

This one is a bit unintuitive, because it only counts cash money, not harvested tiberium. So this includes starting credits, money from sold buildings or units, from cancelled constructions, and from crates. This is probably a bug, since Dune II contained missions of the "harvest to X credits" type, but Dune II did not have the cash/silo separation.

• From House: a certain amount of time has passed. The time unit is 1/10th of a minute on Moderate game speed.

Code exists to trigger this from map objects, but it is never used, since the House AI function is the only place that checks time. This is a pity, since it would've been an easy way to make timed triggers that can be cancelled by destroying an object.

Time triggers can apparently work without a House configured, but since all handling of time triggers is handled in the House AI function, and House triggers are specifically put in a list per House, I have no idea why or how this works.

• From House: a certain amount of buildings of the specified House are destroyed.

Looping is broken for this Event; if the trigger is set to loop, rather than executing after every X destroyed structures, it will constantly detect that the given number was already reached, and will execute the resulting Action at every single game tick.

• From House: a certain amount of units of the specified House are destroyed.

Looping is broken for this Event; if the trigger is set to loop, rather than executing after every X destroyed units, it will constantly detect that the given number was already reached, and will execute the resulting Action at every single game tick.

• From House: the specified House does not own any Weapons Factories, Airstrips, Barracks or Hands of Nod.

• From House: a non-technician civilian has been evacuated with a Transport Helicopter owned by this House.

This trigger event can only be used once in a mission, since the "IsCivEvacuated" status on the House does not reset.

• From House: the specified House has constructed a specific building.

If set to repeat, this will trigger every time a building of that type is built. Discovering player-owned buildings previously hidden under the shroud counts as "Built it" event. Acquiring a building by capturing it from the enemy, however, does not.

This is one rare case where the information saved in the ini file is not completely human-readable; since the data part of the trigger is numeric, the building is specified by its internal ID number. The ID of a building is its index in this list[github.com], starting at 0 for the Weapons Factory.

Now, on to the real beef: the Actions. A lot are origin-independent, while others act very differently depending on the source of the activation.

Origin-independent. The Player is flagged to win, meaning they will win as soon as any blockages from "Allow Win" triggers are cleared.

Origin-independent. The Player loses.

• From Cell: if Player is Goodguy then Badguy begins production; if Player is any other house, then Goodguy begins production.
  
• From Object: The House set in the trigger begins Production.
  
• From House: The House set in the trigger begins Production.

The inconsistency between this and Autocreate actually caused a crash in the original game, since a trigger in Nod mission 13A that tries to enable Production when two Guard Towers are Discovered is lacking its House. Whoever made the mission probably assumed the House would be taken from the linked object, as it works on Autocreate triggers linked to map objects.

Origin-independent. A Team of the linked Teamtype is created from units available on the map.

A common misconception about this Action is that it would directly make the AI produce units. This is not true; the "creation" of a Team does not refer to building the units, but to grouping them together into a team that executes the orders specified in the Teamtype. The "Max Allowed" option on the Teamtype definition is actually what causes the House to hold the necessary units for creating the team in reserve, and produce more of them if needed.

Origin-independent. All active teams of the linked Teamtype will disband, meaning their units will stop acting as team. This does not destroy the units. It also doesn't prevent the future creation of more teams of this type.

Origin-independent. All non-Player-owned vehicles and infantry on the map are detached from any teams they're in, and have their orders set to "Hunt".

This includes disconnecting harvesters from their harvesting routine and making them go on a soldier-crushing spree. It's possible that units that are docked/loaded inside other objects in a way they do not physically exist in the map at the moment the trigger is fired (like units inside an APC or delivery plane, or harvesters docked for unloading) are unaffected by this.

Origin-independent. A Team of the linked Teamtype is reinforced from the map border depending on the Edge setting of the House set in the Teamtype.

If you're editing the ini file manually, mind the dot at the end of this trigger Action; it won't work without it. The presence of the dot probably means the name is an abbreviation of "Reinforcements", despite "Reinforce" working perfectly as verb in this context.

Origin-independent. An area with a radius of 4 cells around Waypoint 25 is revealed to the Player. A yellow/green smoke signal is shown at that location, unless the waypoint is placed on a building.

The full unabbreviated name of this Action would be "Drop Zone at waypoint 'Z'". Waypoints were indicated by alphabet letters in Westwood's internal editor, which made the one on (0-based) index 25 end up as 'Z'.

• From Cell: The House set in the Trigger gets permanent Airstrike superweapon ability. If the linked House is the Player, it is made immediately ready to use.
  
• From Object: The Player gets permanent Airstrike superweapon ability, immediately ready to use.
  
• From House: The Player gets permanent Airstrike superweapon ability. If the House is the player, it's also immediately ready to use. However, if the set House is not the Player, the code to actually add it to the sidebar isn't executed, so it doesn't work at all.

Somehow, they managed to make this do three slightly different things. I'm assuming that AI houses getting the Airstrike superweapon ability through cell triggers is a bug, but it works.

Origin-independent. Enables a one-time nuclear strike for BadGuy, and immediately charges it.

This has no effect if BadGuy does not own a Temple of Nod, since it is required for firing it.

The AI will immediately fire this when it is made available to them. The Player will not receive this if they have already fired a nuke before in this mission, but if they have a Nuke that's still charging, this will immediately make it ready to use.

Origin-independent. Enables a one-time Ion Cannon strike for GoodGuy, and immediately charges it.

This should have no effect if GoodGuy does not own an Advanced Communications Center, but the reality is different. The AI ignores this fact, and simply immediately fires it when it is made available to them. For the player, the situation is a bit more problematic; they get an "Ion Cannon Ready" notification, but the Ion Cannon is not added to the sidebar, which permanently breaks the Ion Cannon ability, even if the player does get an Advanced Communications Center later.

If the Player already has the Ion Cannon, the "one-time" aspect of this is ignored, and it just acts as an instant recharge.

Origin-independent. These three triggers have one simple effect: they destroy the trigger with that name. Only triggers with these three specific names can be destroyed with triggers.

The unofficial C&C95 v1.06 patch adds three extra "Dstry Trig" actions to the game, to remove triggers called 'UUUU', 'VVVV' and 'WWWW', but these are not supported by the remaster without additional modding.

• From Cell: All Houses starts randomly creating attack teams.
  
• From Object: The House the object belongs to starts randomly creating attack teams.
  
• From House: The House set in the Trigger starts randomly creating attack teams.

Teamtypes have an "Autocreate" flag which determines that they can be used for these random attack teams.

However, the actual amount of Autocreate teams that the AI considers for construction is limited to 1/3rd of the mission's Build Level, rounded up. On top of that, the specific choice of which of the available teamtypes it selects for construction is, bizarrely, dependent on which units are already on the map; the game will prefer to build certain teams if units of that teamtype already exist. So to have completely predictable behaviour, don't make more Autocreate teams than ((BuildLevel-1)/3)+1.

• From Object: if the object is destroyed, the player loses. If the object is captured, no matter by whom, the player wins.

This is normally linked to the "Any" event, since it is the only one that has an Events check inside the Action, so it does the event filtering too to only respond to the two specified ones.

If used with a "Player Enters" event, it just act as the Win action without the Lose part. (Note that you must add a House or this will crash; see the "Player Enters" section.) Using "Destroyed" makes you lose when the building is destroyed, but doesn't allow you to capture it without losing, since capturing will eventually send a Destroyed event too.

Setting the trigger's Persistence state to Semi-persistent ('And' loop / "when all triggered", in the editor; ini value 1) doesn't work at all, and just makes it do nothing.

Note that in the C&C Remastered Collection, any structure that has a trigger with this Action attached to it will automatically become capturable (see "Neat Tricks" below).

Origin-independent. The House set in the trigger is only allowed to win after this is triggered. This quirk has some unfortunate side effects, discussed further below.

This Action actually does the exact opposite of what its name implies, namely, it prevents you from winning until it's triggered. Each "Allow Win" trigger puts a "blocker" on the House set in the trigger, which relates directly to the "persistence" discussed above; any trigger which is sprung, and is not permanent, is removed from memory, and only at that point will the "blocker" be gone. So you have to be very careful to ensure that all Allow Win triggers can not only be triggered, but in fact triggered in a way they are 'depleted' and thus removed.

Because "Allow Win" adds a blocker to winning, it is the only type of trigger that can be "activated" by using a "Dstry Trig" action to remove the trigger. Just like activating the trigger will remove it from memory, so will destroying it, so the effect is the same.

So, as you can see, there are some really messy things in there. And, pretty much all of them are due to both the Event and the Action using the House set in the trigger. Here's some examples:

Create a celltrigger setup triggered by an AI that is supposed to give the player the Airstrike, and you see it won't work. Worse; after a while, the AI will start performing periodic airstrikes. Because in the case of celltriggers, the House set in the trigger gets the Airstrike ability.

So, yes, this little gem will permanently enable the Airstrike ability on an AI House. Since this is actually the Airstrike superweapon, and not the classic reinforced A-10s used in the Nod campaign, it will use a different targeting logic, which only targets structures.

AI Airstrikes are normally done with a looped "Reinforce." trigger sending in a Team of A10s, since that setup can be interrupted by destroying the trigger. Since this is the actual superweapon permanently given to the House, and not just a looped trigger with a one-time superweapon or reinforcement, it is impossible to disable this type of Airstrike with later triggers.

"Attacked" are actually two different triggers; one set on a House, and one set on map objects. If the House is set to anything other than 'None' though, and the trigger is also attached to map objects, possibly of different Houses, things start getting understandably weird. It will get triggered both from the linked objects, and from the House having a structure attacked. Which only works for the Player, on which Autocreate is technically useless. And depending on the Persistence (the "loop" status, in the map editor), one of three things will happen in terms of the Autocreate:

• Volatile (no loop; 0; when first triggered): One of the linked objects, or a structure of the owning House (if it is the Player), must be attacked. The House of the first triggered object will get its Autocreate enabled. The others won't.
  
• Semi-persistent ('And' loop; 1; when all triggered): The linked objects, and a structure of the owning House, must be attacked. The House of the last triggered object will get its Autocreate enabled. The others won't. If the configured House is not the Player, it can never be triggered, and the "and" condition can never be satisfied, meaning the trigger will never fire.
  
• Persistent ('Or' loop; 2; on each triggering): Whenever one of the linked objects is attacked, or when a structure of the House in the trigger is attacked (again, only if it is the Player), its owner will get its Autocreate enabled. All Houses can eventually get activated with this setup.

So, wait, does that mean that one single trigger might actually affect a different House, purely depending on what the player attacks first? Yes, yes indeed. And the others are just left in the dust, trigger spent, never getting their precious Autocreate.

You might be tempted to use the Multi-Houses or House Special to add extra enemies for your player to destroy, and only let the player win after they are all destroyed. Sadly, "Allow Win" can never do this: because it stores its "win-blockers" in the House that is linked in the trigger, it has to be linked to the Player House, or it won't function at all.

A viable workaround for this is to make a dummy "Allow Win" trigger linked to your House with an event that can never be triggered ("None" is the simplest one), call it XXXX, YYYY or ZZZZ, and then use the corresponding "Dstry Trig" trigger to remove that trigger, and thus the blockage, without the House limitation. This does force you to sacrifice one of your three precious destroyable triggers.

There is a somewhat more advanced trigger setup you can also use to get around it. See the "Neat Tricks" section for more on that.

So, you want to make a trigger that deactivates a lose condition on a small squad after you discovered your base? Well, you're going to have to find a different way than "Discovered"; it only triggers when you discover a building of a different House.

A valid substitute is the "Built it" event, linked to one of the actual building types you will discover; discovering a building you own counts as building it.

There are some interesting things hidden in the game engine, which are not immediately apparent, but which are really handy to use in scripting. This list will be updated as I find more of these.

When the AI fails to repair a damaged building due to lack of funds, it will normally sell that building. However, it will never sell a building that has a trigger attached to it. This means that you can prevent selling of specific structures (like a Construction Yard or Refinery) by attaching a trigger to them, even if the trigger does nothing at all.

A trigger can perfectly be created with Event "None", to prevent activation, and then used as dummy to prevent selling.

In the original game, the Advanced Communications Center was technically set as Capturable so it could be captured in Nod mission 12. The system blocking you from normally giving that Capture order to an Engineer in all other missions was in the mouse cursor evaluating function; the part of the game that picks the context-sensitive order depending on what you have selected and what you're hovering your cursor over. However, this special code was only active in singleplayer, meaning the building was perfectly capturable in multiplayer. To make things worse, the AI doesn't use that function at all, meaning AI engineers could still perfectly capture it, and you would be unable to capture it back.

The way this was fixed in the Remaster is beautiful. Elegant. And quite exploitable. Any building is considered capturable if it has a "Cap=Win/Des=Lose" trigger attached to it, which makes sense, since that makes it a specific capture target. This opens up a huge range of possibilities in using special buildings as capture targets.

You can even ignore the actual "Cap=Win/Des=Lose" trigger simply by setting the trigger's Event to "None".

Unfortunately, if you do that, there isn't much more you can do with it. You can't attach further triggers to the building, and unfortunately, since "Built it" doesn't trigger on captured buildings, there is ironically no way to check whether the building was captured or destroyed. The only normally uncapturable buildings that give any interesting effect are the superweapon buildings, and those don't work for the opposing House, so outside a "recapture your superweapon" mission, the captured building is bound to be fairly useless, except perhaps as expansion point to build from, or maybe in a mission situation where you need to capture enemy base defenses in order to accomplish a vital objective in the mission.

Side note: the C&C95 v1.06 fan-patch has its own system for fixing the problematic capturability issue, namely that you can put a little rules-like section into the mission file that determines a building to be capturable, like this:

[BIO]
Capturable=true

So if you indeed put a Cap=Win/Des=Lose trigger on something normally uncapturable, to ensure compatibility with both the remaster and the fan-patched version of the classic game, you can add that into the ini. The editor I've been upgrading has a section to allow you to add such custom ini stuff.

When you reinforce a C17 plane carrying a unit to a House that owns an Airstrip, the C17 will drop off the unit at the airstrip. That, in itself, is already a pretty cool scripting trick.

However, when you try to deliver more than one unit this way, an interesting limitation comes to light: the C17 can only drop off one single unit, and for any others in the team, their cost gets refunded to the player. And if the player does not have an Airstrip at all, the full combined cost of all the sent units gets refunded. This means you can very accurately determine, from the costs of the combined units, how much money you send to a player.

There is a dangerous bug in this technique, though. I haven't tested this on the Remaster, but when this kind of trigger setup was applied on the original game, it occasionally caused the C17 to rampage around the map like an Airstrike. Its weapon is set to index "-1" on the weapons list to indicate it is empty, but rather than seeing this as "no weapon", the game actually reads whatever happens to be at that location in front of the real weapons list, and uses a weapon composed of that junk data to attack stuff.

When this was originally researched, a workaround for this bug was discovered; apparently, giving an "Unload:0" order to the team would prevent the rampaging. This might be related to the fact the code erroneously sets a timeout on the "Unload" order that's equal to the targeted waypoint, which, for value 0, might make the team abort what it is doing if it doesn't have any specific orders.

However, this behaviour is not fully tested, and might not be 100% reliable. In Kilkakon's C&C95 mod, where the money-giving technique is used extensively in missions, we ended up hacking into the exe to ensure all data on the "-1" weapon spot was zeroes, so any potential C17 rampaging would be done with a weapon dealing no damage.

Another bug related to this is the "bit mask overflow"; existence of buildings is checked as bit mask in the code, which, in a 32-bit program, has the annoying side effect that one value can only go up to 32 bits. This causes the system to "wrap around" on higher building IDs, causing odd bugs like making the Wheat Field (civilian building "V14", with ID 36) act like the Communications Center (the remainder when dividing 36 by 32 is 4, the ID of the Comm Center), giving the player both the construction options unlocked by the Comm Center, and the radar minimap. Likewise, "V31", the Witch Doctor's Hut in Desert theater, matches the Advanced Comm Center, and thus, in addition to the radar ability, the Witch Doctor appears to be the proud owner of a personal clandestine Ion Cannon uplink. And the large Desert theater Village Well, "V30", would be a nuke silo, were it not that the nuke requires an actual Temple of Nod to be launched from.

So, how does this bug relate to the C17 trick? Well, the code to look for an Airstrip actually searches for a valid docking target on the map, so there's no issue there. However, the code to abort the search for such a target only uses the bit mask. This means that if the receiving House owns civilian building "V21", which is "Abdul's House" in Desert theater, the plane will never leave the map, and the money will never be given.

The C17 reinforcing and money-giving techniques were originally researched by Lin Kuei Ominae, a Tiberian Sun modding veteran who likes to mess with DOS C&C. Further research was conducted by Kilkakon, as he made extensive use of the money-giving technique in his "Dawn of Tomorrow" mod for C&C95.

An interesting application of the C17 money adding is that it is the correct kind of money that can be checked with the "Credits" checking event.

The general setup of this trick is to have an action that triggers a C17 reinforcement containing a single unit, to some multiplayer-House that is 100% unused on the map, and then give that House triggers to check if a certain amount of credits is reached. To completely eliminate any potential for the rampaging C17 bug in this case, you can simply make sure that the "money bag" House is allied to everyone else on the map.

This gives some interesting scripting possibilities akin to the "Globals" system in Red Alert's triggers, to trigger multiple actions from one event; you can perfectly create multiple triggers checking for the same amount of credits, and let them each execute a different Action. Likewise, you can make several different triggers each add more money to the same House, to build up to a specific value that will trigger a single Action. Unlike with normal looped triggers set to execute after all linked objects are triggered, this setup can use input from several completely different triggers. And, as mentioned, it can trigger multiple Events too.

One of the uses of this trick is to solve the "defeat multiple houses" problem without the need to use up any of the destroyable triggers; instead of an "Allow Win" trigger linked to the destruction of multiple Houses, which, as mentioned, doesn't work, you can make the destruction of each House trigger such a C17 reinforcement containing a single minigunner, to such a money-bag House. And then, you can give that House a trigger to check if 300 credits are reached, so that after three enemy Houses are destroyed, the Win condition is triggered.

Note that there is one big limitation to this system: since the money checking is done on an unused extra House, it can't be used to trigger House-specific actions like Production, Airstrike or Autocreate on the Houses that are actually present and used on the map. However, workarounds for such things can be devised, such as reinforcing a unit for that House and making it move over a celltrigger.