Triggerscript Conditions Overview
From FleshWorks
by Krypt
Ok, time to elaborate on script Conditions. As I wrote in the intro, Conditions tell the script when to fire and run the Actions. Note that Conditions can be tried forever until they are satisfactorily met.
An important distinction between the types of conditions:
WHEN Conditions
You need at least one of these in every script. "When" conditions wait for the condition to be met and will activate right when it happens, making them "active". How do you tell what conditions are "When" conditions? Well, most of the time the wording will give it away, because it will start with "When". Makes sense, eh? There are some exceptions to the wording rule, such as
Received trigger message [String] and a couple conditions that begin with "On the event that...". A very important note about "When" conditions: You cannot place more than one of them together in the root Condition list, or together in a
Logic AND operator. This is because it will require both events to happen at the exact same instant, which is probably not possible and is never what you'll want them to do anyway.
- Example:
When [FlagA] is set to [TRUE] activates at the moment FlagA's value changes to true. It will not activate if the script tries to fire and FlagA is already set to true, because the event of the value change is what it's looking for.
QUERY Conditions
Query conditions are passive, meaning they won't do anything on their own and require a pairing up with an active "When" condition. A Query will test the value of something, usually a global variable.
- Example: A script with conditions
When I am frobbed by player and
Query if flag [FlagA] is set to [TRUE] will activate when the player frobs the object, but only if FlagA is true when the frob occurs. The player can frob the object as many times as he wants while FlagA is false and the script will wait until it is set to true before activating.
Logic Operators
Logic operators aren't actually conditions themselves, but a way of sorting other conditions to be checked in different ways. When a logic operator is placed in a script, other conditions must be dragged under it. Logic operators can be nested to create complex scripting.
Logic AND operator is the most basic of the logic operators. All conditions under it must be be met in order for the actions to fire. Note that the root of the conditions list is an implied AND operator. Also keep in mind that you cannot pair two "When" conditions under an AND operator, as noted above.
Logic OR operator will check if any of the conditions underneath it can be met. If at least one of them is met, the the script can then fire. Each condition under an OR operator is considered a standalone entity, which means you'll need to be careful with Queries. They cannot be checked on their own. However, a setup such as this will work:
- When the object is frobbed and either FlagA or OtherFlag is true then the script will fire. Only one of them needs to be true, the other can be false.
Logic [XOR] operator is the same as an OR operator, except it requires that only one of the conditions under it are met and the rest are not met. There is not much use for this logic operator as this functionality isn't usually necessary, and can be achieved more reliably with other methods anyway. I don't think I ever used the XOR operator once for scripting in either DX:Invisible War or Thief:DS.
Logic [NOT] operator will check that the conditions under it are not met. The value checked by the condition can be anything other than the one specified under the NOT operator. The NOT operator also behaves like an inverse AND in that it will check that all conditions under it are not met. Note that "When" conditions can't be used under a NOT operator, only Queries.
Lastly, there is an important condition that is outside the Triggerscript system itself, but that can sometimes foil you with involved scripting. This condition is that the script exists. It sounds stupid and obvious, but it can be the source of a lot of problems in advanced scripting. First of all, just writing a script doesn't make it happen. It has to be on an object in the map the player is in. Be careful not to place important scripts on objects that can be destroyed or deleted. Also make sure that the script is on the right object. If you place a script on an instance of an inventory object placed in a map, it won't fire after the player picks it up. This is because that instance of the object is deleted when the player picks it up, and a fresh one spawned from gamesys is put in the player's inventory. Thus the script placed on the object no longer exists and cannot fire.
Back to Mission Design: Scripting Tutorials Page
