M4 – The Multiplayer Mission Maker Manual

Locality of Triggers

Triggers created either in the editor or using the createTrigger command are always global objects. This means they should only be created on the server, and not necessarily on the client (although I am not sure about radio triggers, since you might want to give only one side a radio trigger and not the other). Running local triggername on a client that is not the server (i.e. a joined player or any client on a dedicated server) will return false for triggers that have been placed in the editor. In this respect, triggers are to be treated like any object in terms of locality, so that e.g. the command setTriggerActivation should run on the server since its effect is local.

When we speak about locality of triggers, we are more concerned with how they execute their statements or create their effects. Unfortunately, this isn’t as clear cut as it seems.

A radio trigger (for example Radio Alpha) will very likely run its statements on every client and the server when triggered. That means that the scripting commands in the activation field will run for at least the number of players connected, potentially one more for the server. This means that the duplication effect from global effect commands discussed in the previous chapter is very obviously a danger here.

However, as a general rule, trigger activation statements (and therefore, triggering the trigger) only run on the machine where the trigger condition evaluates to true. Let me repeat this again: The trigger only fires on those machines were the condition evaluates to true. This very important fact can have unforeseeable side effects. A common example is the “Detected By” trigger. It is very possible that a player is detected on one or more clients and/or the server, but not on others. If you use such a trigger to end a mission (say, a stealth mission which requires users to stay undetected), it might end up terminating the mission on some clients but not on others.

Another example are triggers that have a scripted condition. For example, putting !alive player into the condition of a trigger will only trigger on the clients were players have been killed. While this effect is obviously desirable, combined with other locality issues it is a very common source of problems.

Getting a grip on these issues isn’t necessarily difficult, but one needs to be aware of it.

What you should have gotten out of this section:

  1. Triggers behave like normal objects in terms of locality, but should, as a rule, only be created on the server.
  2. Most trigger conditions are globally valid, but the word “most” is the problem here.
  3. Triggers only trigger on machines that satisfy their trigger condition. Most notably, using scripted trigger condition other than this will be highly dependent on locality and variables.

Comments are closed