Conditional Operators

In the 5E code the method checkConditional() in manager_effect_5E.lua it appears that we check all the wounded state conditionals first one check at a time and if these are exhausted then we moved onto applying all remaining conditional operators first, then seeing which applies, if any.

Just to understand the choices in case should also guide my particular operators, was the order of checking wound state first a function of expectation of higher use or just order being written first then others added?

Was there any reason unlike doing one at time, you apply all conditional matches before testing the result of any of them?

I am not nitpicking, I don't have a good feel for the environment (lua) or even commonality of conditions (5E) so any decisions I would make without asking are worse than random probably ;)

The ideas was to check "exact matches" (singular) before applying "exact matches" (sets) before applying "pattern matches". It was a more organizational decision code-wise, as well as a bit of how much work (i.e. quicker to check single vs. set vs. pattern).

Regards,
JPG

Makes sense, I think I understand your point. Actually didn't get the set comment until got home to look and realized I skimmed over the middle where they were done.

The final part of the checks are done all at once. Any reason that way other than looks organized/neater than alternating match-if-matched code blocks? Because, if any of the first couple match, the latter ones need never go through the "expression matcher" algos. OR are they just trivial anyhow? (checking if it is a pessimization to do that since they look like they need to be parsed then scanned etc)

Code:

---

                else
                        local sAlignCheck = sLower:match("^align%s*%(([^)]+)%)$");
                        local sSizeCheck = sLower:match("^size%s*%(([^)]+)%)$");
                        local sTypeCheck = sLower:match("^type%s*%(([^)]+)%)$");
                        local sCustomCheck = sLower:match("^custom%s*%(([^)]+)%)$");
                        if sAlignCheck then
                                if not ActorManager2.isAlignment(rActor, sAlignCheck) then
                                        bReturn = false;
                                        break;
                                end
                        elseif sSizeCheck then
                                if not ActorManager2.isSize(rActor, sSizeCheck) then
                                        bReturn = false;
                                        break;
                                end
                        elseif sTypeCheck then

---

But I can see the above is neater looking than the alternative and if speed is never an issue, that may be more valuable due to readability.

Just organizationally easier, though technically a little slower for comparison if it gets that far.

JPG

Yup, just making sure in case something was in play I didn’t know about.

That said, the as you go one would not be as neat as you said :)