world#getHighestBlockAt and world#getHighestBlockYAt no longer ignore transparent blocks, returning a higher value

XMLWordPrintable

    • This server is running CraftBukkit version git-Spigot-037559e-752cf95 (MC: 1.15.1) (Implementing API version 1.15.1-R0.1-SNAPSHOT)
    • Yes

      world#getHighestBlockAt and world#getHighestBlockYAt both return the block above the highest block, including transparent blocks. Previously it only returned the highest fully opaque block.

      The JavaDocs seems to indicate that this should not include transparent blocks:

      https://hub.spigotmc.org/javadocs/spigot/org/bukkit/World.html#getHighestBlockAt-org.bukkit.Location-

      "Gets the lowest block at the given Location such that the block and all blocks above it are transparent for lighting purposes."

      https://hub.spigotmc.org/javadocs/spigot/org/bukkit/World.html#getHighestBlockYAt-org.bukkit.Location-

      "Gets the y coordinate of the lowest block at the given Location such that the block and all blocks above it are transparent for lighting purposes."

      In earlier versions (I believe 1.13.2 and below), these methods would return the highest full block, rather than the highest non-air block.

      I have attached a simple plugin to test this. With the plugin installed, stand on any block and toggle shift to see the returned y value of both methods returned in chat.

      I have tested this in 1.15.1, but I believe this change occurred in 1.14.

        1. SpigotTestPlugin-0.1-SNAPSHOT.jar
          5 kB

          [SPIGOT-5523] world#getHighestBlockAt and world#getHighestBlockYAt no longer ignore transparent blocks, returning a higher value

          md_5 added a comment -

          See SPIGOT-2595 where the doc was changed to match behaviour at the time

          md_5 added a comment - See SPIGOT-2595 where the doc was changed to match behaviour at the time

          Zedadias Wick added a comment -

          Sure. Arguably a new method could be made to maintain support for older plugins, but I think you're right. If we need to ignore transparent blocks we can easily check if the block below isn't opaque and search down from there. The reverse isn't quite so easy.

          Zedadias Wick added a comment - Sure. Arguably a new method could be made to maintain support for older plugins, but I think you're right. If we need to ignore transparent blocks we can easily check if the block below isn't opaque and search down from there. The reverse isn't quite so easy.

          md_5 added a comment -

          Honestly I think this is better / more useful behaviour and the doc should be changed.

          The only reason it was the other way is previously that was the only way the method could be more useful / faster than a simple for loop.

          md_5 added a comment - Honestly I think this is better / more useful behaviour and the doc should be changed. The only reason it was the other way is previously that was the only way the method could be more useful / faster than a simple for loop.

            Assignee:
            Unassigned
            Reporter:
            Zedadias Wick
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: