You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When the player respawns, the Z axis value of the respawn position should use full range provided by the respawn_radius game rule.
Observed/Actual behavior
When the respawn_radius game rule is above 50, the Z axis value of the respawn position is always close to the lowest possible value. The closeness and the respawn_radius value seem to be proportional.
Steps/models to reproduce
Set world spawn point with /setworldspawn
Set the respawn radius to be 50 or above with /gamerule respawn_radius <value>
Respawn multiple times
Plugin and Datapack List
Server Plugins (0):
There are 3 data pack(s) enabled: [vanilla (built-in)], [file/bukkit (world)], [paper (built-in)]
Paper version
[22:14:25 INFO]: Checking version, please wait...
[22:14:26 INFO]: This server is running Paper version 1.21.11-111-main@302c47c (2026-02-07T22:59:49Z) (Implementing API version 1.21.11-R0.1-SNAPSHOT)
You are running the latest version
Previous version: 1.21.11-105-581214a (MC: 1.21.11)
Hi, we're running into this on our Leaf 26.3 SMP too. I checked the spawn selection code in Paper 26.3 build 218 and vanilla 26.3, and it looks like the problem is in PlayerSpawnFinder.
candidateCount is capped at 1,024, but the candidate index is then converted into X/Z using the full square width, 2 * radius + 1. That only covers the first few rows of the intended spawn area.
With world spawn at X=0, Z=0, the candidate columns work out as:
Radius 128: X=-128 to 128, Z=-128 to -125, with the last row only partly covered
Radius 512: X=-512 to 511, all at Z=-512
Those are the bounds calculated from the code. It can still fall back to the central spawn column if all candidates fail.
We use a larger spawn radius to reduce spawn camping, so having arrivals concentrated along one edge defeats the point.
Could Paper keep the 1,024-attempt limit but choose those candidates across the full configured square? That would address the distribution without removing the limit on the search.
Activity
semianarchymc commentedon Oct 23, 2026
Hi, we're running into this on our Leaf 26.3 SMP too. I checked the spawn selection code in Paper 26.3 build 218 and vanilla 26.3, and it looks like the problem is in
PlayerSpawnFinder.candidateCountis capped at 1,024, but the candidate index is then converted into X/Z using the full square width,2 * radius + 1. That only covers the first few rows of the intended spawn area.With world spawn at X=0, Z=0, the candidate columns work out as:
Those are the bounds calculated from the code. It can still fall back to the central spawn column if all candidates fail.
We use a larger spawn radius to reduce spawn camping, so having arrivals concentrated along one edge defeats the point.
Could Paper keep the 1,024-attempt limit but choose those candidates across the full configured square? That would address the distribution without removing the limit on the search.
This also appears to match MC-302446.