Changeable Conditions

[APickledWalrus]

Problem

For some time, we have been recommending a combination of Condition+Effect in favor of a boolean Expression. However, there is some loss of ease of use:

• Losing support for EffToggle: toggle the player's gliding state
• Losing support for one-line changing: set the player's gliding state to {_boolean}

If Conditions were to support changing, these features could be restored in some manner, preserving the ease of use options provided by boolean Expressions.

Solution

This PR proposes a simple API for changing the values represented by conditions. This API is further extended by PropertyCondition to make implementing even easier.

I decided to allow any changer to be used, though some modes are likely pointless. We could instead have specific methods for whether SET or RESET are allowed (as an example as those are probably the only realistic modes to support). I'd like opinions to tweak this.

This API is then used by ExprWhether to allow changing conditions:

• toggle whether player is gliding
• set whether the player is gliding to {_boolean}

There is a large number of files changed as I implemented this for most conditions where it made sense.

Testing Completed

Some in-game testing. I added at least 40 new tests covering many of the updated conditions.

Supporting Information

n/a

---

Completes: none
Related: none
AI assistance: none

[ShaneBeee]

So just to verify...
You guys didn't like expressions for booleans, so you double'd up the code by adding conditions and effects.
Then added a whether expression, to use the conditions as expressions.
And now adding a changer to the whether expression, to bring back to the original expressions y'all didn't like?

Feels messy. Feels redundant.
Is SkriptLang doing what's best for its users or what's best for the team?
I feel like it's the latter.

With all due respect, I think you guys need to have a team meeting, chill, step back... and starting thinking more about your users and less about yourselves.