Fixes related to teleport Y coordinates #184
Open
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR includes two commits for separate issues related to the selection of the Y coordinate that the player is teleported to. Following are some brief descriptions of the commits, see the commit messages for more details.
The first commit probably fixes two reported issues, at least partially. There was a problem with teleporting to be on top of the highest block if it wasn't at the player's current Y coordinate which would result in the player being teleported to spawn instead if there were no air gaps. I think this fixes issue #178 and probably issue #115 too. On its own this is a trivial commit.
The second commit isn't associated with any reported issues, but while working on the above I noticed that the teleporting code wouldn't deal well with blocks at (assuming the standard world height of 256) Y = 254 or 255 because it insisted on checking if the blocks into which the player would be teleported (Y and Y + 1) were breathable. My fix assumes that the void above the top of the world is breathable. This certainly seems to be the case in vanilla Minecraft.
Since the second commit is more complicated and doesn't address an existing issue, I've kept it as a separate commit even though it touches the same areas of the code as the first commit and in fact replaces some of the changes made by that commit. This way, if you don't want the change from the second commit or just don't want to have to review it, just the first commit can be pulled.
I tested the first commit by verifying it made the problem I saw as described in issue #178 go away, and tested the second by building a sort of staircase ascending to Y = 255 and verifying that I was teleported up it all the way to the top (in a situation where the teleport moved me not only backwards but also sideways due to a circular border).