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.
Mitchell Haugen
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
timeInSecondsparameter from the "add" sub-command of the "worldborder" command from the wiki: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 theaddcommand, 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 theaddcommand 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
addcommand 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 thetimeInSecondsparameter of theaddcommand. This is in fact what happens when theaddcommand is given notimeInSecondsparameter. 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.