As discussed previously, the software processes conditions from top to bottom.
It will start at the first condition of the first action and move down the list.
So, in the pic below, the software will check the conditions from 1a to 1b to 2a.
If a condition has a weight however, the process will work slightly differently.
If a weighted condition has been found to be TRUE:
- the weighted part of the condition will immediately be moved to the next decision.
- the remaining weighted part will be moved to the next action.
So, for the remaining weighted part, the remaining conditions in the action will not be checked.
Example
For example, in our savefile we have a condition on top where we push with our gutshots 20% of the time.
This condition will be TRUE for QT and QJ (to see this, compute with F7 and mouse over the condition).
These 20% of QT's and QJ's will be moved to the next decision node.
The remaining 80% of them will immediately be moved to the "Call" action though.
So the ">=tp", "fd" and "oesd" conditions will be skipped.
You can check this for yourself by computing (F7) and then mousing over, for example, the "fd" condition.
As you will notice, QsTs and QsJs did not make it to this point.
They were in fact accepted by the "Call" action's "overcards" condition.
If you mouse over it, you will find them there.
Conditions that are higher in a list have a higher priority. When the "20%-gutshot" condition has just stated that only 20% of the gutshots should be in the "Raise 27" action, then this can NOT be overwritten by a condition with a lówer priority.
<< Previous | Contents | Next >> |