/gamerule spawnradius X is supposed to change the size of the radius in which players respawn. However, in the most recent release, the Z coordinate always takes the maximum value allowed by the radius.
How to reproduce:
Create a superflat world, so that the terrain can’t influence the player’s respawn position.
Execute the following commands in any order:
/setworldspawn 0 ~ 0/gamerule respawn_radius 32/gamerule immediate_respawn trueMake sure the
player_positionpart of the debug overlay (F3) is visible.Execute the following command repeatedly:
/kill→ ❌ The Z coordinate of your respawn position is always very close to -64.
Expected result:
The player would respawn anywhere in the radius defined by the respawn_radius game rule around the world’s spawn point.
Observed result:
The player respawns at any position with an X coordinate inside the radius defined by the respawn_radius game rule, but with a Z coordinate really close to the northern edge of the radius.
Linked issues
is duplicated by 2
Attachments
Comments 7
I noticed this first on my modded server, tested with vanilla single player. I set gamerule spawnradius to 1000 and /kill over and over. I respawned about 20 times X was random in a small range: 44.5 - 10.5 and Z was always 791.5
When set to 1000 the X range was larger, -900 through about 1500. but Z was always -1791.5
When set to 2000 Z was always -2791.5
Also tried it on 25w44a with the same results.
I’m adding more detail because it seems like the automated system is trying to ignore this and it keeps marking it as resolved.
I feel like this is a game breaking bug. Any server that relies on random re-spawns will be impacted. As the spawn radius game rule gets larger the more the actual random range gets clamped. The bug will show up with respawn_radius set as low as 32. I can reproduce this in multiple versions 1.21.9 up to latest snapshot 24w44a
note: the gamerule names have, previous versions use spawnRadius and doImmediateRespawn instead
Steps to reproduce:
create new world with commands enabled.
/gamerule respawn_radius 32
/gamerule immediate_respawn true
open F3 to watch coordinates
run /kill over and over the z coordinate will always be negative instead of the expected range of +/- 32. This shows that the randomness is heavily biased to -z. The x coordinate is also effected to a lesser extent, with the radius set to a very large number IE:10000 all randomness for Z is lost and will always be -9999.5 and X ends up staying in a small range (-9000 to -9999).
I’ve attached a video to demonstrate.
note: the gamerule names have, previous versions use spawnRadius and doImmediateRespawn instead
Can confirm in 26.1 Snapshot 5
Steps to reproduce:
/setworldspawn 0 ~ 0
/gamerule respawn_radius 5000
/kill
You will always respawn at a Z of value -4999.5.
This Z should be in a range of [-5000,5000], it should not always be the same value.
Issue is in PlayerSpawnFinder.java. candidateCount gets limited to 1024, which does not allow it to take advantage of the entire spawn area.
I had immediate respawn on
I died over and over using /kill
the world was a layer of bedrock and a layer of black concrete with structures turned off, freshly generated on a vanilla client on the latest stable release of 26.1.1
amd processor nvidia gpu
At respawn radius 0 the spawn was 0 0
at respawn radius 10 behavior seems normal
at respawn radius 20 the highest z value was positive 1
at 30 the highest z value was -14
at 128 the highest z value was -124
at 512 the only observed z value was -511
For clarity by “highest” i mean most positive, so 10 is higher than -20.
The z values at any respawn radius above 10 skew very negative, and at higher values the game will only chose to spawn at the edge of possible values.
This issue is a pain to deal with as a server owner, it also seems to cause the game to hang on a tick for 60 seconds causing watchdog to crash the server when a player tries to respawn without a bed or other spawnpoint set intermittently, maybe 5% of the time, on the latest update I have not seen this crash.
I believe the crash issue was caused by the game being unable to find a spawnable block in the very small number of blocks available to be spawned on because the only locations the game was trying to use where from a single straight line of blocks. Lowering the spawn radius on a semi-anarchy server lead to players getting spawn camped so having the spawn radius high is kind of necessary.
It’s not just candidateCount being limited to 1024being the problem. It’s the whole algorithm being used. When candidate count was added the algorithm was not implemented correctly.
I created a mod to fix it, I’m not 100% sure I implemented it correctly. I haven’t updated it to 26.x yet . The code with the actual fix is here.
https://code.dakers.net/dave/daves-fixes/src/branch/main/src/main/java/net/dakers/mixin/PlayerSpawnFinderMixin.java
I can’t reproduce this in 1.21.9 or 1.21.10-rc1. Are you sure your game mode isn’t being broken by MC-302321 instead?