Issue:
When an op calls "worldborder add <size> <time>" while the worldborder is currently shrinking or growing, the worldborder size will change appropriately according to the command, but it will not do it in the time given. The message printed to the user will contain the correct size, but the incorrect growth time (the time given is the time left on the current shrinking/growing of the wall added to the given time).
Example:
The worldborder is currently 100 blocks in size, shrinking at 0.5 blocks per second, down to 10 blocks wide. This could be achieved with the following commands:
/worldborder set 100
> Set the world border to 100.0 blocks wide
/worldborder set 10 180
> Shrinking the world border to 10.0 blocks wide over 180 seconds
Then, after 10 seconds, the op enters the following command:
/worldborder add 10 5
> Growing the world border to 105.0 blocks wide over 175 seconds
*Note: 175 seconds is the time remaining from the previous "set" command (170 seconds) added to the time given by this "add" command (5 seconds)
The world border then proceeds to grow to the stated width (105 blocks) in the stated time (175 seconds).
Expected Behavior:
When the "/worldborder add 10 5" command is executed, the world border should proceed to grow by 10 blocks in 5 seconds irrespective of whether or not the world border was previously shrinking/growing or not. This should be true regardless of the size and time values given.
Linked issues
relates to 1
Comments 6
MC-59769 does not explain my issue. Though if that one was marked as "WAI" by the developers, I fear this one may too, though I think there is a legitimate bug here. That issue specifically relates to the size of the world border and how it should grow or shrink. I have no issues with that and the current implementation of the size system makes sense to me.
This bug specifically has to do with timing. If you let everything play out, the sizes always end up being what they should, however it doesn't happen in the time that it should. To understand what I mean, I'm copying some wording about the timeInSeconds parameter from the "add" sub-command of the "worldborder" command from the wiki:
Optionally, a timeInSeconds may be specified such that the border grows or shrinks from the current width to that being set over the specified time in seconds. 1
This seems to indicate that if I run a command like: /worldborder add 20 10, the world border should grow 20 blocks in 10 seconds. However it will only do that in 10 seconds if the world border wasn't already shrinking/growing. If it was already shrinking/growing at the time of the add command, the time remaining in the shrink/grow that was executing (let's say 45 seconds, for example) will be added to the time given in the add command that was just submitted (10 seconds in this case). That means the world border will grow by 20 blocks, but instead of growing in 10 seconds as the given command indicates should happen it will happen in 55 seconds (45 remaining seconds + 10 seconds given in command).
The add command takes the current size of the world border and adds the given value to that value to get the new final size (Searge indicated this is the intended behavior). In other words, the add command ignores any previous commands or movement, and only accounts for the current world border size. The time component of this command should be similarly consistent, then. It should not take into account any previous commands or movements. The only growth/shrink time that should be used is that given by the timeInSeconds parameter of the add command. This is in fact what happens when the add command is given no timeInSeconds parameter. In that case, the world border is immediately grown/shrunk without respect to any time remaining in a previous grow/shrink.
Let me know if I did an okay job explaining that.
I honestly don't know why the other bug is considered WAI. Any sort of explanation would have been nice.
It essentially makes the grow over time feature useless when using "add", as the result might completely bug out (as pointed out) when multiple things trigger a growth/shrink. The process quite obviously keeps track of "time remaining", why it can't keep track of "delta remaining" too I don't understand.
Setting a border to 16 and adding 1 twice should result in a border of 18 but it doesn't (or it does, depends on timing).
Due to the fact that I can't set the size from a score I have to workaround it by setting it to 1 and recursively add 1 until I match the score (optimized by checking some powers of 2). This combined with the delta loss makes using the timing feature completely useless unfortunately. I can't even do the recursive thing and stack multiple adds in one tick as only the time stacks but not the border size.
I guess that fact illustrates OPs point as well, calling "worldborder add 1 1" three times in a function will grow the world border by 1 block in 3 seconds which makes no sense. But it frankly also doesn't make sense if it would result in 1 block in 1 second, the only sensible thing (imho) is that it grows by 3 blocks in 3 seconds, as that would be the thing it would do if you were to omit the "in seconds" part and do it instantly. Or 3 blocks in 1 second, a successive add call just "ends" or finishes all running transitions instantly and queues the new one (that would remove the timing oddities when mixing add calls with positive and negative numbers)
If we want to be fancy we would only finish running transitions when we change direction as most use cases I imagine mainly go in one direction at any given phase and those would then benefit from easy to implement smoothness.
Does MC-59769 explain your issue as well? That one was marked as Intended by the developers.