Updates to Disabled Choice Conditions
I have good news and bad news.
I’ve updated the Disabled Choice Conditions plugin to improve efficiency, compatibility, and most importantly, more flexibility and ease-of-use when it comes to disabling choices.
Previously, if you wanted to use conditional branches to disable choices, you would have to start by adding a plugin command or a comment indicating which choice to disable, followed by the conditional branch. Take a look:
Which has a number of limitations:
- It only supports one conditional branch (so you can’t easily nest your conditions)
- If you wanted to disable more than once choice at a time with the same condition…sorry, make another conditional branch with the exact same condition
- What if you wanted to disable AND hide a choice? (yes, new plugin info leak)
- Those comments are OK, but not completely necessary
- When I switched to a plugin command, it made even less sense. Take a look:
Rather than doing all this, I’ve changed it so that the plugin command itself will disable a choice, and the conditional branches are up to you to figure out how to use it. This is just normal eventing, except you’re using a plugin command to disable a choice.
Take a look at the new and improved way of disabling a choice:
Now, when you say “disable_choice”, you are actually disabling a choice. Not, telling the engine that you want to disable a choice, and that conditional branch under it is the condition to use.
Unfortunately, if you have been using the conditional branch method, you will need to change where the plugin command is placed. But beyond that, that’s about the only change that needs to be made!
For those that are using script calls, nothing has changed: you can just use the script call as usual.