Adds Enchantment Glint Syntaxes

[NotSoDelayed]

Description

This PR adds the enchantment glint syntaxes into Skript!

---

Target Minecraft Versions: Minecraft 1.20.5
Requirements: Spigot 1.20.5
Related Issues: none

[sovdeeth]

needs tests

[Fusezion]

Might be worth adding an expression to give with/without enchantment glint

%itemtypes% with[:out] enchantment glint [override]

[NotSoDelayed]

The following will be added in the coming hours:

• Expression to get preset enchantment glint items
• Condition of whether an item has enchantment glint override
• TESTS!!

[Fusezion]

Aside from other requested changes looks fine to me

[APickledWalrus]

It seems unnecessary to me to have an Expression, Condition, and Effect for the same thing. I think we should pick between Condition and Effect versus Expression (I think the former may be preferrable as I am not really a fan of boolean expressions). I'd like to gather some thoughts on this :)

[sovdeeth]

It seems unnecessary to me to have an Expression, Condition, and Effect for the same thing. I think we should pick between Condition and Effect versus Expression (I think the former may be preferrable as I am not really a fan of boolean expressions). I'd like to gather some thoughts on this :)

I'm in agreement, in most cases a condition and effect flow much better. I'm not as opposed to having multiple ways to do the same thing, though, so I'd be ok with leaving the expression in too.

[NotSoDelayed]

It seems unnecessary to me to have an Expression, Condition, and Effect for the same thing. I think we should pick between Condition and Effect versus Expression (I think the former may be preferrable as I am not really a fan of boolean expressions). I'd like to gather some thoughts on this :)

For this case, how about I scrap the condition syntax? As the user can use the expression to check whether the override is set or not.

[APickledWalrus]

I honestly might rather see the expression scrapped, but I'd like opinions from others.

[ShaneBeee]

It seems unnecessary to me to have an Expression, Condition, and Effect for the same thing. I think we should pick between Condition and Effect versus Expression (I think the former may be preferrable as I am not really a fan of boolean expressions). I'd like to gather some thoughts on this :)

me personally I'm the exact opposite.
My main reason for that is I personally prefer 1 syntax (expression) over 2 syntaxes (effect and condition) that basically do the same thing as the expression.
I find that when people ask for help, it's much easier to point them to the docs of one expression vs. 2 docs for effect/condition.
But thats just my opinion.

[APickledWalrus]

I think that's a fair point. More than anything to me, when thinking about the goal of Skript to provide English-like syntax, make the player's tool glint is much better than set the player's tool's enchantment glint to true

the ability to represent it as a boolean can be useful so I wonder if it's time we examine conditions as expressions again

[sovdeeth]

With the new whether expression I think this should be condition + effect

[APickledWalrus]

Since there seems to be agreement, I am going to mark this as a requested change.

I would remove the Expression and just keep the Condition/Effect combo.

[NotSoDelayed]

I would remove the Expression and just keep the Condition/Effect combo.

The effect currently sets the override to true and false. Do I need to add an additional effect to remove the enforcement?

And how does one get the value of it if we’re going to drop the expression?

[APickledWalrus]

It would probably be good to have an effect to remove it (probably the reset changer written out, e.g. reset glint of %itemtypes%), though what is the purpose of explicitly setting it to false?

Also, there will be a whether %condition% added which will allow you to use conditions as boolean expressions

[NotSoDelayed]

…. though what is the purpose of explicitly setting it to false?

If the meta is set to true, the ItemStack will glint if there’s no enchantment, where vice versa the ItemStack will not glint if there’s an enchantment. Setting it to null removes the enforcement.

So if this expression is retained, it will return true, false, and null.

[NotSoDelayed]

The condition alone will return true if there’s an override — it could be set to either true or false. So this only tells the user that there’s an enforcement, but the value is unknown to them without the expression.

With the expression retained + the new whether %condition% expression, the user can do the following:

set {_} to whether enchantment glint override is set
set {_} to whether enchantment glint override is not set
set {_} to whether enchantment glint override is true
set {_} to whether enchantment glint override is false

[APickledWalrus]

Sorry for the confusion. We could maybe have another condition like %itemtypes% are forced [not] to glint? Might be worth seeing what others think.

[sovdeeth]

The condition alone will return true if there’s an override — it could be set to either true or false. So this only tells the user that there’s an enforcement, but the value is unknown to them without the expression.

With the expression retained + the new whether %condition% expression, the user can do the following:

set {_} to whether enchantment glint override is set
set {_} to whether enchantment glint override is not set
set {_} to whether enchantment glint override is true
set {_} to whether enchantment glint override is false

re: using set/not set as intended states
I don't like this, because it means that the expression returning nothing is good and intended. Which conflicts with how skript returns nothing when it fails to get the right type. If you get none from {_item}'s enchant glint override, then you don't know if it's working as intended or if {_item} is actually a number, or just not set. A second condition/pattern to handle that behavior would be better, imo.

[sovdeeth]

tests failing