MC-112678the upper limit of the time value from /worldborder add|set makes no sense
So, I am aware that this might be a bit contradictable whether or not this should be considered a bug, but let me explain:
In the worldborder commands /worldborder set <...> and ~ add <...>, you can specify the time how long it will take the world border to move to the desired location. the upper limit of the time value is (without commas) 9,223,372,036,854,775.
This is the only command I am aware of that allows higher values than integer (2^31-1) and does not accept floating point values.
But this limitation makes not much sense. The limit of java's long is 9,223,372,036,854,775,807 and I would expect this value to be the upper limit. Instead the last three digits are simply cut off in this command's limit. (9,223,372,036,854,775 instead of 9,223,372,036,854,775,807).
If it was the case that Mojang really wanted to limit the time around 10 quadrillions, they could just have set the upper limit to even 10 quadrillion.
So I am assuming that they somehow accidentally didn't add the last three digits to the upper limit to match the limit of java's long (2^63 -1)
![[Mod] NeunEinser](../../../data/avatars/users/39263.png){kind=small}
Created Issue:
the upper limit of the time value from /worldborder add|set makes no sense
So, I am aware that this might be a bit contradictable whether or not this should be considered a bug, but let me explain:
In the worldborder commands /worldborder set <...> and ~ add <...>, you can specify the time how long it will take the world border to move to the desired location. the upper limit of the time value is (without commas) 9,223,372,036,854,775.
This is the only command I am aware of that allows higher values than integer (2^31-1) and does not accept floating point values.But this limitation makes not much sense. The limit of java's long is 9,223,372,036,854,775,807 and I would expect this value to be the upper limit. Instead the last three digits are simply cut off in this command's limit.
If it was the case that Mojang really wanted to limit the time around 10 quadrillions, they could just have set the upper limit to even 10 quadrillion.
So I am assuming that they somehow accidentally didn't add the last three digits to the upper limit to match the limit of java's long (2^63 -1)
So, I am aware that this might be a bit contradictable whether or not this should be considered a bug, but let me explain:
In the worldborder commands /worldborder set <...> and ~ add <...>, you can specify the time how long it will take the world border to move to the desired location. the upper limit of the time value is (without commas) 9,223,372,036,854,775.
This is the only command I am aware of that allows higher values than integer (2^31-1) and does not accept floating point values.But this limitation makes not much sense. The limit of java's long is 9,223,372,036,854,775,807 and I would expect this value to be the upper limit. Instead the last three digits are simply cut off in this command's limit. (9,223,372,036,854,775 instead of 9,223,372,036,854,775,807).
If it was the case that Mojang really wanted to limit the time around 10 quadrillions, they could just have set the upper limit to even 10 quadrillion.
So I am assuming that they somehow accidentally didn't add the last three digits to the upper limit to match the limit of java's long (2^63 -1)
Looking at the code it seems intended. The time is used as milliseconds and as the command provides seconds the maximum value can be (2^63 - 1) / 1000 (=9223372036854775.807).
Okay, I probably should have checked that before I wrote the report, but I just looked in the minecraft code and they're simply multiplying the given value by thousand to change it to miliseconds. That's why this limit actually does make sense.
Can be flagged as invalid, I'm sorry about that!