Uploaded image for project: 'Minecraft: Java Edition'
  1. Minecraft: Java Edition
  2. MC-59769

Changing worldborder size is inconsistent / behaves erratically when the border is already moving

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Works As Intended
    • None
    • Minecraft 14w26c, Minecraft 1.8
    • None
    • Community Consensus

      There are 2 ways to slowly set the worldborder size: /worldborder set and /worldborder add. These behave inconsistently when applied to already moving worldborders. For example:

      1. /worldborder set 100
      2. /worldborder set 10 60
      3. the border starts moving. type the following after around 10 seconds:
      4. /worldborder set 20 10
      5. the border suddenly jumps to a diameter of 10, then expands out to 20

      The behavior I expected is that the worldborder changes its speed to shrink from its current size (somewhere around 85 if you indeed waited 10 seconds in step 3), not its old target size (10), to its new target size (20). But if this is intended behavior, it is inconsistent with the following:

      1. /worldborder set 1
      2. /worldborder add 1 60
      3. the border starts moving. type the following after around 10 seconds:
      4. /worldborder add 1 10
      5. the border does not jump to a diameter of 2, but instead adds 1 to its current size (which is around 1.2) and uses that as its new target size

      This behavior seems weird, especially considering that /worldborder add was added with the Captive Minecraft map in mind. In Captive Minecraft, you expand the worldborder by getting achievements, 1 meter per achievement. If the map were to be changed to use /worldborder add, and a player were to get 2 achievements in quick succession (as is often the case with Time to Mine! and Getting an Upgrade), the border would not expand the full 2 blocks.

      But the first behavior is also problematic, for example when you want to change worldborder size in steps in order to prevent it from getting out of sync with the tick speed (since the rate at which the border moves is independent from tick lag). If the server ticks too fast for some reason, the worldborder will jump forward when it is being resynchronized.

      I think the correct behavior would be to always use the current size as the starting size for the new animation (to prevent the jumps described in the first scenario), but to use the old target size as the base for calculating the new target size when using /worldborder add.

            searge [Mojang] Searge (Michael Stoyke)
            fenhl Fenhl (Max Dominik Weber)
            Votes:
            2 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved:
              CHK: