Sometimes spawnpoint will spawn players above trees
Is spawning above leaves a bug or a feature. It can happen sometimes and kinda of unnatural to think about it
Seed: 2917133137276911148
Linked Issues
is duplicated by6
MC-239722Odd Spawn LocationDuplicateMC-242577Players can spawn on top of treesDuplicateMC-243154Spawn on dereDuplicateMC-245848Players can respawn in trees canopiesDuplicateMC-250280Spawning on top of trees bug. DuplicateMC-263993When loading into a world, the player's spawnpoint can never be under a tree (leaves blocks)DuplicateAttachments1
![[Mod] Les3awe](../../../data/avatars/users/79847.png){kind=small}
Created Issue:
Sometime spawnpoint will spawn players above trees
Is spawning above leaves a bug or a feature. It can happen sometimes and kinda of unnatural to think about it
![[Mod] violine1101](../../../data/avatars/users/92858.png){kind=small}
![[Bot] Arisa](../../../data/avatars/users/43007.png){kind=small}
is duplicated by
Is spawning above leaves a bug or a feature. It can happen sometimes and kinda of unnatural to think about it
Seed: 2917133137276911148
Low![[Mojang] slicedlime](../../../data/assets/gravatar/slicedlime.jpeg){kind=small}
![[Mod] markderickson](../../../data/avatars/users/18946.svg){kind=small}
is duplicated by
![[Mod] OcelotOnesie](../../../data/avatars/users/43220.png){kind=small}
is duplicated by
![[Mod] Asteraoth](../../../data/avatars/users/92886.png){kind=small}
is duplicated by
![[Mod] ampolive](../../../data/avatars/users/18949.svg){kind=small}
Sometimes spawnpoint will spawn players above trees
is duplicated by
![[Helper] Johnibur](../../../data/avatars/users/28381.png){kind=small}
![[Mod] tryashtar](../../../data/avatars/users/41963.png){kind=small}
is duplicated by
This seems reappeared in 1.21.
relates to
![[Mod] Jiingy](../../../data/avatars/users/91802.png){kind=small}
This is a duplicate issue of MC-242348 which is currently marked as "Awaiting Response".
Thank you for your report!
We're tracking this issue in MC-242348, so this ticket is being resolved and linked as a duplicate.
If you would like to add a vote and any extra information to the main ticket it would be appreciated.
If you haven't already, you might like to make use of the search feature to see if the issue has already been mentioned.
Quick Links:
📓 Bug Tracker Guidelines – 💬 Community Support – 📧 Mojang Support
📓 Project Summary – ✍️ Feedback and Suggestions – 📖 Game Wiki
– I am a bot. This action was performed automatically! The ticket was resolved by one of our moderators, and I left this message to give more information to you.
Thank you for your report!
We're tracking this issue in MC-242348, so this ticket is being resolved and linked as a duplicate.
If you would like to add a vote and any extra information to the main ticket it would be appreciated.
If you haven't already, you might like to make use of the search feature to see if the issue has already been mentioned.
In the future, reports with this level of detail will be resolved as Incomplete. Please review the Bug Tracker Guidelines (linked below) for more information on how to properly report a bug 
Quick Links:
📓 Bug Tracker Guidelines – 💬 Community Support – 📧 Mojang Support
📓 Project Summary – ✍️ Feedback and Suggestions – 📖 Game Wiki
This bug is the cause of MC-242348.
It has been a well-known mechanic since 1.13 that /setworldspawn will allow players to respawn as close to the set y value as possible, instead of on top of the highest block (like in 1.12). This works regardless of the spawnRadius set. From my brief testing, it seems to require at least a 1x3 location at any y value. If that is not met, the player is respawned at the next highest block.
This behavior has been reverted to 1.12 behavior sometime in the development of 1.18 (which is unfortunate considering the stunning new cave generation making underground spawn points more enticing). /setworldspawn will now always pick the highest block in the column (including leaves, unlike 1.12).
Steps to Reproduce:
- Open a world between 1.13 and 1.17.1 and another in 1.18.1 (and another in 1.12 if you wish to compare)
- /setworldspawn
- /fill ~-20 ~10 ~-20 ~20 ~10 ~20 minecraft:stone
- /kill and respawn
- Repeat at any y value of your choosing with at least 1x3 space to spawn. Invalidate spawn location and the 1.13 - 1.17.1 game will pick the next highest valid location to respawn the player.
It's worked this way for 3 years. You probably should reopen this.
Sorry duplicated by MC-242348. I only filtered for "leaves" in search.
This is related to MC-113314, which was "resolved" as "working as intended". This is a follow-on ticket, showing how this "working as intended" grants players the ability to create infinite obsidian very quickly, which, in my view, is a serious exploit.
I created a nether portal in the overworld several hundred blocks from my base. I went to the nether through it and made a trek to my original nether base. Then I went back through the new nether portal in the nether, and ended up several hundred blocks from the portal I created earlier.
MC-113314 was the same root issue. However, what wasn't mentioned is what I did next. I thought, perhaps if I get rid of this new portal in the overworld, and go back to the one I created and repeat the journey to the nether and back again, I can get it to work properly.
So, I broke all the obsidian (collecting 14 obsidian in the process). Then I went back to the portal I originally created and went through again, and then back to the overworld.
Lo and behold, the game created yet another nether portal in the overworld. So, I did the whole process again. Sure enough, I could get another 14 obsidian.
So, this process allows a player to generate as much obsidian as desired, with no downside other than the time to break the blocks.
Some notes:
The new overworld portal that generated generated in a different place each time.
The first two times a new portal was created, it was created at the tops of very tall trees. This is probably related to the bug in MC-242348.
The seed is 177. The overworld portal I created was at -933/80/631 (just outside the mansion).
The corresponding nether portal created by my traveling through my overworld portal was created at -100/85/87. This isn't at one-eighth of the coordinates of my overworld portal, as it should have been.
I didn't record the locations of the first two portals created by the game when I came back to the overworld. The third one was created at -790/79/689.
I let the third portal remain, and after that I was able to port back and forth between that portal and the one in the nether. I was also still able to travel to that nether portal from the original overworld portal.
Thank you for your report!
We're tracking this issue in MC-242348, so this ticket is being resolved and linked as a duplicate.
If you would like to add a vote and any extra information to the main ticket it would be appreciated.
If you haven't already, you might like to make use of the search feature to see if the issue has already been mentioned.
Quick Links:
📓 Bug Tracker Guidelines – 💬 Community Support – 📧 Mojang Support
📓 Project Summary – ✍️ Feedback and Suggestions – 📖 Game Wiki
Thank you for your report!
We're tracking this issue in MC-242348, so this ticket is being resolved and linked as a duplicate.
If you would like to add a vote and any extra information to the main ticket it would be appreciated.
If you haven't already, you might like to make use of the search feature to see if the issue has already been mentioned.
Quick Links:
📓 Bug Tracker Guidelines – 💬 Community Support – 📧 Mojang Support
📓 Project Summary – ✍️ Feedback and Suggestions – 📖 Game Wiki
Duplicate of MC-242348; those are some simple reproduction steps, and that report would benefit from having them.
We do not have enough information to reproduce this issue.
Please provide the following information about the world you are playing in as text. Attaching a screenshot showing them is not enough.
This issue is being temporarily closed as Awaiting Response. Once the requested information has been delivered, the report will be reopened automatically.
Quick Links:
📓 Bug Tracker Guidelines – 💬 Community Support – 📧 Mojang Support
📓 Project Summary – ✍️ Feedback and Suggestions – 📖 Game Wiki
Default world type. Seed is -1854418717
My screenshot was from pre-1. I was able to repeat on the 2nd start in pre-6 in a dark_forest.
Successfully reproduced on the second attempt.
What do "made changes" and "made transition" mean? Are those developer-speak for some facet of the coding process?
No, that's JIRA speak for "the report was modified" and "the status/resolution of the report was updated".
Thanks, Dhranios.
Violine1101:
Java 1.18 rc3
Seed 131
Spawn location 79.5/127/-112.5 (on top of a leaves)
NOTE: I set the world spawn radius to 1 block vs. the default 10. This MAY be involved.
Another instance:
Java 1.18.1 multiplayer (completely vanilla; no mods or special changes of any kind)
Seed 177
One player spawned on top of a tree.
A different player spawned on the ground.
So, in addition to being annoying, it's random as well.
EDIT: This world used the default spawn radius of 10.
It's random as spawning has a radius from the xz that you can spawn in; you can reproduce this in any world with trees at spawn, it's just rare you actually happen to get that random selection.
Clarify exactly what kind of spawn/respawn are you referring to.
As this is normal, you dont respawn on the world spawn exactly, you spawn in an area? its not a bed spawn where your spawn is exact, worldspawn is randomized and puts you on top of trees sometimes. this only been a thing since like forever?
The report is about world spawn/respawning without bed/anchor.
BTW, Mojang already assigned a priority, so it is a bug in their eyes.
Caused by
MC-243079; reverted 1.13 - 1.17 worldspawn behavior to 1.12 behavior.To clarify the mechanics: 1.12 respawn picked the highest block to spawn the player, but ignored leaves unless there was a solid block beneath. Since 1.18 no longer respects y value for /setworldspawn (more info in
MC-245811), the behavior was reverted to 1.12 but without the check for a canopy. Reproduce: /setworldspawn beneath leaves and /gamerule spawnRadius 0 (for convivence) then /kill. You end up on top.If they reopened and fixed
MC-243079, then this bug would be resolved as well.can confirm in 1.19 Pre-release 1
Can confirm in 1.19.3 and 23w03a
A simple way to reproduce this bug is to repeatedly generating a bunch of single biome dark oak forest worlds, since most of the terrain in that biome is covered by leaves.
Considering
MC-243079is about a command and this is about the world's default spawn I'm not sure a 'caused by' relation makes sense, but the two are definitely closely related behavior wise. Execution is just different.