-
Notifications
You must be signed in to change notification settings - Fork 12
Conditions
In this guide we will talk more in depth about conditions.
The first time you would encounter a condition will certainly be in a workflow through the "condition" element. With this, if the conditions are not met when the workflow is executed, it will stop the workflow at the condition element and won't go further. But conditions are available at many other places:
- In Workflows, any single effect can be conditioned. When the workflow is executed and reaches the effect, the effect will be played only if his condition is met. But it won't stop the entire workflow like the condition element would do.
- In Cutscenes, you can have "player choices" to branch the cutscene to a specific step. Each player choice can be conditioned and won't be visible if their condition is not met.
- In Campaigns, Quests and Quest Steps, you can condition event links and actions. These elements won't trigger their linked workflow if the condition is not met when the event occur or the action is performed.
Conditions are made of a list of tests linked by a OR or a AND operand. This will produce a complete logical expression that you can see below the condition frame (where each line is represented by its index). In logic arithmetic, parenthesis are important because AND and OR don't have a precedence in execution (actually it does in computer programming but not in regular mathematics): A and (B or C) is not the same as (A and B) or C so it can be problematic to just have A and B or C.
So to help the user, TRP will automatically place the parenthesis in a way to always place the OR into parenthesis. This kind of logical expression is called a Conjunctive normal form. This is great because, by definition, any logical expression can be expressed by a CNF.
In addition to the tests, conditions elements in workflows (and only these kind of conditions) also have two additional parameters: Failure message and Failure workflow.
The Failure message will be prompt if the condition fails. It will be placed in the regular game error notification, where all error messages are placed (like "Not enough mana" or "Can't do that while moving"). It's always good to tell the player why he can't do something.
The Failure workflow is the name of a workflow in the same object that will be executed if the condition failed. This workflow will be called with the same workflow context.
A condition test is a line in the condition linking two operands by a comparator. An operand is a value that will be calculated when the condition is executed (and not before that).
There are three type of operands: operands that return a number, a boolean (true/false), or a character string. Only numeric operands can be bound with a numeric comparator (<, <=, >, >=).
When you are working on your creation condition, you can preview an operand value with the Preview button, same for the entire test result. But keep in mind that it will only give you the current evaluation, not necessary the one the player would have when they use your creation.
Using conditions on Actions (for Campaign, Quest and quest step) requires to understand how the addon select an Action when the player performs an action.
Imagine that you have a Campaign with a Look action bound to a workflow. And you want to verify if the player has targeted the right NPC before continuing the workflow. You would think that you have two right possibilities:
- Condition the Action (by ctrl+click on the Action in the editor)
- Condition the workflow, by adding a condition element as the first element of the workflow.
Well, actually, the first possibility is better and the second should be avoided. The second way will have issues if you have multiple Actions in your Campaign/Quest/Step.
Here's why. When the player performs a quest Action (Look, interact, listen or talk), the addon will search for an matching Action in your Campaign and will stop on the first matching one. It starts by checking the Actions available in the Quest Step, then the Quest and finally the Campaign. So it's a reverse order. Also, the addon will only check the condition attached to the Action and not the condition that could be placed as first workflow element. That's why you should avoid using that method, because the addon would think the Action would match and won't search for any other Action in the list.
Also that reverse checking order (step, quest and finally campaign) allow you to have an Action defined in the Campaign level for instance, but "override it" at a certain quest step.
So in a general rule of thumb: Always place your condition on the Action instead of as first element of your workflow.