SpigotTestPlugin-0.1-SNAPSHOT.jar
[SPIGOT-5523] world#getHighestBlockAt and world#getHighestBlockYAt no longer ignore transparent blocks, returning a higher value Created: 17/Jan/20 Updated: 21/Jan/20 Resolved: 21/Jan/20 |
|
| Status: | Resolved |
| Project: | Spigot |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Minor |
| Reporter: | Zedadias Wick | Assignee: | Unassigned |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | World, getHighestBlockAt, getHighestBlockYAt | ||
| Attachments: |
SpigotTestPlugin-0.1-SNAPSHOT.jar
|
| Version: | This server is running CraftBukkit version git-Spigot-037559e-752cf95 (MC: 1.15.1) (Implementing API version 1.15.1-R0.1-SNAPSHOT) |
| Guidelines Read: | Yes |
| Description |
|
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: "Gets the lowest block at the given Location such that the block and all blocks above it are transparent for lighting purposes." "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. |
| Comments |
| Comment by md_5 [ 17/Jan/20 ] |
|
See |
| Comment by Zedadias Wick [ 17/Jan/20 ] |
|
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. |
| Comment by md_5 [ 17/Jan/20 ] |
|
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. |