Skript
Skript copied to clipboard
Durability shouldn't be the same as damage
Suggestion
In Skript there is that expression: https://docs.skriptlang.org/expressions.html#ExprDurability. It treats durability and damage as if it were the same thing, but it isn't. When you're using a tool, its durability should decrease, and its damage should increase. Going by the Skript's logic, the tool is more durable the more its used. The item damage should have it's own expression.
Why?
It's plainly, logically wrong. Changing this may break some code, and it may do so quietly, but it must be done, because the word "durability" shouldn't be used to get the opposite of it. It can be seen as a bug.
Durability is a property that affects all tools, weapons, and armor, as well as certain other usable items. It represents the number of useful actions an item can perform and depletes upon item use.
https://minecraft.fandom.com/wiki/Durability
Other
command /test:
trigger:
set {_test} to tool of player
message durability of {_test}
message damage value of {_test}
You'll get the same value.
Agreement
- [X] I have read the guidelines above and affirm I am following them with this suggestion.
Though your suggestion might be logical but this is how spigot handles it see Damageable.getDamage()
In Skript we can change to this behavior but more opinions from the team is needed on this
You misunderstood. The damage value of <item>
syntax gives the right value - number of times item was used (assuming no unbreaking). But the same value is given by durability of <item>
, which should be the number of uses left for an item. You linked spigot's method for damage and there's no issue with damage, it's right, but the issue is with durability, which should be max durability - damage
. Durability doesn't have a separate method in spigot I think, and it should be calculated using Material.getMaxDurability(), which is already used in Skript (max durability of <item>
).
Durability - number of uses left for the tool Damage - number of times the tool was used Max durability - number of times the (freshly crafted) tool can be used
I thought you were talking about damage that is wrong, it's clear now
~~i'm not totally sure if this is possible to implement since like @oskarkk said we would need to do max durability - damage
... but Damageable
has no method to get the max durability. Material
does, but there's no guarantee that every Damageable
is backed by a Material
~~
nevermind, it should totally be possible since we only support items, slots and blocks all of which can easily be turned into a Material
I want to add that ExprDurability
is a really weird expression, since it also gets data values of blocks from MC <=1.12. Why someone even combined this with durability?
The data/damage value of an item/block. Data values of blocks are only supported on 1.12.2 and below. You usually don't need this expression as you can check and set items with aliases easily, but this expression can e.g. be used to "add 1 to data of
- ", e.g. for cycling through all wool colours.
And funny thing that the title of that expression in docs is "Data/Damage Value", but in code it's named just ExprDurability
, when it doesn't even give the correct value for durability (it gives damage).
And since support for <1.13 will be dropped in Skript 2.7, it'll be a good time to change that expression: remove the data value, remove damage
from syntax, change it's output to max durability - damage
and make a new expression ExprDamageValue
or something which will give the value that ExprDurability
is giving now.
I want to add that ExprDurability is a really weird expression, since it also gets data values of blocks from MC <=1.12. Why someone even combined this with durability?
It is weird, but it was that way because MC and Bukkit did the same weird thing. If I remember right, tool/armour durability used to stored as a data value that counted up until it reached the max durability at which point your item broke. This is why the Skript expression counts upward as well. You are right though, it really doesn't make sense anymore and is probably worth changing.