Skript: Returning 0 using echantment level

[Runakai1]

If e.g a tool is not enchanted with efficiency and you're trying to get "%effenciency level of player's tool%" it may be more practical returning 0 instead of <none>

2.3.6 skript, 1.12.2 server

[TheBentoBox]

Kinda surprised it's not like this already. I agree this would make sense.

Also just so you know, your <none> wasn't showing up due to how GitHub parses formatting. In the future you can surround it in backticks (`, which is on the same key as ~) to mark it as code so it shows up properly. I've already fixed it for you in this case.

[TheBentoBox]

Also this is totally open for discussion since it's a small but breaking change that others might have reasoning against. But it reduces complexity of working with enchants in some situations while never really adding complexity.

[Pikachu920]

personally I feel like <none> makes more sense, especially since the arithmetic expression treats null as 0 anyway. Plus it's easy to do sharpness level of tool otherwise 0

[Blueyescat]

It should be returning <none> because level of a non-existent enchantment is unknown, just like when you do health of {_non-existent variable}. Also enchantments with 0 level are possible you know

[TheBentoBox]

level of a non-existent enchantment is unknown

I don't agree with this, it's not "unknown" in that you don't know what it is. You 100% know the enchantment isn't on the item. And realistically, yes, you're both right that from a programmatic standpoint it doesn't exist so a null value "should be" returned, but it's clearer and more consistent for the expression to always return a number.

If this expression returned an EnchantmentType reference, then of course it should return nothing for a missing enchantment. However, when specifically checking the level of the enchantment, which effectively represents the strength it has on the item, it's nice to always get a number for performing operations. And even if the null value is treated as a 0 for operations, is that intuitive? If that's our standpoint why not make it actually return a 0?

Point being, it at times can be more convenient or clear to return a 0, but I'd argue it's never more convenient or clear to return <none>. But I'd still like to hear more opinions.

[Blueyescat]

@TheBentoBox

enchantments with 0 level are possible you know

And there are no any other expressions that returns 0 instead of null

[TheBentoBox]

I don't think there are many other expressions where that logic or this conversation are applicable.

[TheBentoBox]

Also, to give an examples of something that does return 0 even when not set: checking the size of a non-existent list returns 0. So if there are no pigs in your world, number of pigs in player's world returns 0 even though there are none.

[Blueyescat]

I see the logic of the size expression returning 0, this is not the same thing.

But returning 0 for enchantment level doesn't look logical to me at all. And again, 0 level enchantments are possible, so close now?

[Wealthyturtle]

I don’t think this should be the case that enchantment levels should return 0 if it’s not there, because as Blueyescat mentioned, 0-level enchants do exist, so Skript should allow its users to differentiate between an item having a 0-level enchant an an item not having the enchant at all by returning none, so current behaviour should stay. What do you think? @TheBentoBox

[Runakai1]

I don’t think this should be the case that enchantment levels should return 0 if it’s not there, because as Blueyescat mentioned, 0-level enchants do exist, so Skript should allow its users to differentiate between an item having a 0-level enchant an an item not having the enchant at all by returning none, so current behaviour should stay. What do you think? @TheBentoBox

I can't proofe this now but I've had people on the SkUnity Discord having problems because of enchantments not returning 0. It can look pretty messy if you have to check if the enchantment exists first.

[Wealthyturtle]

I wouldn’t think it’s too difficult to check if an enchantment exists first... you can just use a simple conditional like (sharpness is set) or something

[Runakai1]

It isn't difficult at all. It just looks like a mess

[Blueyescat]

We explained why, the issue should be closed now.

[FranKusmiruk]

Being completely honest, I see this being more of an issue to the average user, returning 0 might make sense.

And as of now, I have never seen someone difference 0-level enchantments from having enchantments at all so that isn't much of an issue, if someone ever happens to complain whenever this change is made, I might be inclined to make it this way but right now this seems like the most user-friendly solution.

[Blueyescat]

Being completely honest, I see this being more of an issue to the average user, returning 0 might make sense.

And as of now, I have never seen someone difference 0-level enchantments from having enchantments at all so that isn't much of an issue, if someone ever happens to complain whenever this change is made, I might be inclined to make it this way but right now this seems like the most user-friendly solution.

no

level of nothing = nothing

[ShaneBeee]

Being completely honest, I see this being more of an issue to the average user, returning 0 might make sense.
And as of now, I have never seen someone difference 0-level enchantments from having enchantments at all so that isn't much of an issue, if someone ever happens to complain whenever this change is made, I might be inclined to make it this way but right now this seems like the most user-friendly solution.

no

level of nothing = nothing

Sorry Snow, but I agree with Blue.
I have 2 glasses sitting on my table. 1 is full of water (lets say level 10) and the other is empty (lets say level 0), "how much water is in glass # 3?" well, there is no glass 3, so we wouldn't say the level is 0 if the glass doesn't exist.

I totally see your point adding something like this to make Skript "easy" but dumbing down Skript for something like this logically makes no sense.

A lot of Skripters move on to learning Java, or another programming languages. By introducing stuff like this, we are only confusing them in the future. Again I realize Skript is meant to be "easy" but it should also be practical. Many people argue that Skript isn't a real programming languages, if we keep adding stuff to dumbify Skript then it takes it further and further from being a programming language. This is why Java has NPEs. If something is null its null, we don't just return 0 to make something easy.

[Wealthyturtle]

Null != 0. It should stay as is

[Runakai1]

The majority of people using skript will stay at using skript. If they want to move to an other programming language they'd have to learn it's way of handling things. Skript already has a bunch of weird things, adding another one that just simplifies the usage of level enchantments shouldn't cause any trouble in moving to java.

[FranKusmiruk]

@ShaneBeee that analogy is flawed due to the fact that a level 0 enchantment and not having the same enchantment at all is interpreted as the same thing, or at least most people do, I understand that null isn't 0, but if it makes sense in the context, Skript could interpret it as such. It isn't even the first time Skript handles null this way, there's default values for everything, everywhere.

If you're able to provide me a single use-case for the current behaviour other than being confusing to "non-programmers", I'll consider not touching it.

As for people not considering Skript a programming language, there's also people that actually think the earth is flat, can't really stop anyone from thinking that.

[TheBentoBox]

I agree with Snow and also agree that @ShaneBeee 's water analogy is completely flawed. Consider the water an "enchantment" in that context -- we're not saying to return 0 when asking for the level on a NON-EXISTENT item ("glass 3" in your example), but on an existing one. In an EXISTING glass that has no water in it (it's "missing the Water enchantment"), is it more user-friendly to say its water level is "null" or "0"? You can see now why 0 makes much more sense as the user-friendly option.

[Wealthyturtle]

@TheBentoBox @FranKusmiruk This change may break existing scripts that use 0-level enchants for special purposes... now if this change is implemented, then you can’t differentiate between an item not having an enchant and having a 0-level enchant.

This change will definitely improve user-friendliness, so since this could break old scripts, I think we should reconsider implementation - maybe add a conditional?

[TheBentoBox]

you can’t differentiate between an item not having an enchant and having a 0-level enchant

This is the argument that I conceded to last time and am happy to agree with. The fact that you can apply level 0 enchants to items at all means we shouldn't force this overlapping definition. I'm just making it clear that the analogy above really isn't describing the same scenario.

[FranKusmiruk]

@Wealthyturtle as said, I have never ever seen someone using this expression relying on the fact that it returns null for non-existent enchantments and 0 for 0-level enchantments, there's barely one or two use cases for 0-level enchantments at all after all. If someone is capable of demonstrating the usefulness of the current behaviour, I'll consider otherwise.

[Wealthyturtle]

@FranKusmiruk How about this scenario: When someone wants to make hidden custom enchants using Skript? Enchants can be hidden using the HideFlags NBT tag, but in order to distinguish between different vanilla enchant types and custom enchant types, 0-level enchants could be beneficial. E.g. Sharpness 0 -> Custom Enchant 1, Protection 0 -> Custom Enchant 2, etc. This is useful because [insert vanilla enchant type here] at level 0 yields no effect, i.e. sharpness 0 does not give any attack bonus, making it effectively like hidden metadata that scripts can make use of, as apposed to lore which may be clunky and inefficient (imagine having to iterate through an item's lore every hit)

[TheBentoBox]

I can attest that I've personally had a scenario in which I used rank 0 Protection with HideFlags to make an item appear enchanted with no enchantments on it. Detecting that Protection 0 or HideFlags tag (or both) is the only way to discern those items at a later date.

[Wealthyturtle]

Closing this issue in favor of #1496, which will make the testing of non-existent enchants more user friendly