Adds a SetEffect lang util class

[TheLimeGlass]

Description

Separated the JUnit fixes in this pull request into #6057 will rebase this after that gets merged

Adding my implementation of how to deal with boolean expressions not reflecting proper language statements.
My addons have been using this utility class for a long time. Examples below.

What this utility class does is registers a default effect and not an expression, because returning a boolean expression should be a condition, but we still want to support changing the property value.
This conversation has been brought up before in the SkUnity developer Discord channel as needing a change. So i'm gonna add my implementation that solves that said issue. Honestly this is very helpful.

/**
 * Registers an effect with patterns "set property of %type% to %boolean%" and "set %types%'[s] property to %boolean%"
 * 
 * @param effect The SetEffect class that you are registering.
 * @param property The property of the syntax.
 * @param type The type classinfo of the syntax. Can be plural.
 */
public static void register(Class<? extends SetEffect<?>> effect, String property, String type) {
	Skript.registerEffect(effect, "set " + property + " of %" + type + "% to %boolean%",
			"set %" + type + "%'[s] " + property + " to %boolean%");
}

/**
 * Registers an effect with patterns "set property of %type% to %boolean%", "set %types%'[s] property to %boolean%"
 * and "make %types% makeProperty" with "force %types% to makeProperty"
 * 
 * @param effect The SetEffect class that you are registering.
 * @param property The property of the syntax.
 * @param makeProperty The property of the syntax used for "make %types% makeProperty".
 * @param type The type classinfo of the syntax. Can be plural.
 */
public static void registerMake(Class<? extends SetEffect<?>> effect, String property, String makeProperty, String type) {
	Skript.registerEffect(effect, "set " + property + " of %" + type + "% to %boolean%",
			"set %" + type + "%'[s] " + property + " to %boolean%",
			"make %" + type + "% " + makeProperty,
			"force %" + type + "% to " + makeProperty,
			"make %" + type + "% not " + makeProperty,
			"force %" + type + "% to not " + makeProperty);
}

set visibility of player's bossbar to false
make player's bossbar visible

Examples of my addons using this utility class:

Khoryl (There are subclasses to the set effect due to how Khoryl has to operate)https://github.com/TheLimeGlass/Khoryl/tree/master/src/main/java/me/limeglass/khoryl/elements

Skellett example: https://github.com/TheLimeGlass/Skellett/blob/master/src/main/java/me/limeglass/skellett/elements/bossbars/SetBossBarVisible.java

---

Target Minecraft Versions: any
Requirements: none

[bluelhf]

Would the resulting syntax for your example be force player's bossbar to visible?

[TheLimeGlass]

Would the resulting syntax for your example be force player's bossbar to visible?

Yes the word be should be included. In my test for the syntax class I use

registerMake(SetEffectTest.class, "all", "(return all|(have|be) all)", "itemtypes");

Which would make that force player's bossbar to be visible and disallow that exact calling.

[APickledWalrus]

I would like some discussion on the usage of the BiConsumer

[Pikachu920]

I hate to say it but I think I would have to agree with tud for the most part. I don't know if this is the best way to move forward with this kind of thing.

[sovdeeth]

I hate to say it but I think I would have to agree with tud for the most part. I don't know if this is the best way to move forward with this kind of thing.

Having thought more about this, I'm shifting my position from "this seems unnecessary but alright" to just "this seems unnecessary". Like tud said, I think the main issue with these kinds of syntaxes is having to register both a condition and an effect, which this doesn't address.

The only real solid benefit I can see here is standardizing the syntaxes for similar properties, but it comes at the cost of being a lot less flexible. As I said in my last comment, when I had trouble with this sort of thing, it was with unusual syntax that didn't fit the kind of syntax this PR creates anyways. I just think this would be a very niche addition that doesn't really help solve the real issue of needing both a condition and effect. I also think that boolean property expressions seem perfectly fine most of the time as well.

[TheLimeGlass]

The only other way about going around with this is similar to how ExprChange was applied to every expression with an overridable method, which would potentially go into a Condition?

Proposals are needed here.

I still only see this as the most valid way to avoid the ugly line of getting boolean expressions.

[APickledWalrus]

I'm not really a fan of the set patterns here. IMO they are what we are trying to get away from when avoiding using an Effect rather than an Expression.

The make/force patterns might be a little inflexible, but it's not terrible. What might be more useful IMO is a utility that registers both an Effect and a Condition (this would have to use some sort of backing interface, would probably be a little messy).

[Pikachu920]

it seems like the teams consensus is that we would rather not pursue this approach. thank you for your contribution regardless