MC-12395Player spawnpoint used in monster spawning seems to be unaffected by sleeping in bed or /spawnpoint command
The code which does normal animal/monster spawning (MCP naming class SpawnerAnimals.findChunksForSpawning(), or func_77192_a()), uses a single spawn point fetched as worldServer.getSpawnPoint() to keep a volume around it clear from spawning monsters.
However, sleeping on bed or using command /spawnpoint does not change that location (tested by console-logging the fetched location in the spawning method). It would also seem theoretically impossible to handle the spawnpoints of multiple players (on multiplayer server) with that code. (I think that location is the initial spawnpoint for single-player.)
Keeping an apparently "random" single location in the world clear from monster spawning, as it is doing now, seems pointless. More appropriate operation would be either ignore that location completely, or change it so that it considers the effective/current spawnpoint of any and all players.
Related to MC-10303, where the current functionality causes mobs to not spawn near that spawnpoint when using superflat gametype.
Linked Issues
Attachments2
Created Issue:
Player spawnpoint used in monster spawning seems to be unaffected by sleeping in bed or /spawnpoint command
The code which does normal animal/monster spawning (MCP naming class SpawnerAnimals.findChunksForSpawning(), or func_77192_a()), uses a single spawn point fetched as worldServer.getSpawnPoint() to keep a volume around it clear from spawning monsters.
However, sleeping on bed or using command /spawnpoint does not change that location (tested by console-logging the fetched location in the spawning method). It would also seem theoretically impossible to handle the spawnpoints of multiple players (on multiplayer server) with that code. (I think that location is the initial spawnpoint for single-player.)
Keeping an apparently "random" single location in the world clear from monster spawning, as it is doing now, seems pointless. More appropriate operation would be either ignore that location completely, or change it so that it considers the effective/current spawnpoint of any and all players.
Related to
MC-10303, where the current functionality causes mobs to not spawn near that spawnpoint when using superflat gametype.
relates to
![[Mod] Ezekiel (ezfe)](../../../data/assets/gravatar/ezekielelin.jpeg){kind=small}
As far as I'm aware, the spawnpoint protection is there for the benefit of new players on a server. It's not intended to protect spawnpoints set by the /spawnpoint command or sleeping in a bed. It's the player's responsibility to protect a player-set spawnpoint by lighting it up, but a player just creating a world or joining a new server doesn't have that ability, so the default spawnpoint is protected for them as a convenience.
When you create a world from scratch, no monsters will spawn around the word spawn point anyway because it's day and there's a player there (you). When you join a server, you spawn where the server admin have set a spawn point. Or am I misunderstanding you?
Personally I don't see the need for this "protection" at all. If you don't protect your spawn point you deserve to log in to a group of monsters. If a server doesn't, it deserves to drive away players.
The feature seems worthwhile in multiplayer, but can cause confusion in single player (see the linked ticket where slime farms created in the most obvious location, at world spawn, were ineffective).
Not sure if there is a good resolution in that specific case, except perhaps for slime finding tools to add a feature where they calculate the world spawn point, and mark those chunks as invalid for slime farms.
A couple of related questions:
How exactly is the world spawn point calculated from the seed?
Is that formula DIFFERENT for normal worlds vs superflats? (If so, this could explain why slime chunks seemed to work for the same seed in normal mode.)
Is there any way for a player to determine if she is at world spawn? (Remembering where you spawned isn't sufficient, challenge maps can change the spawn point, but the "world spawn" is fixed.) I think we get an error trying to pour out lava at world spawn, right?
Torabi: you might have a point there. Although, I think it is more for "backup spawnpoint", read next..
Wesley: I'm not completely familiar with the spawn point rules, but I'd also guess that one could end up in the "world spawn point" in single player when you e.g. lose your bed (say, blown up, lava burn, ...) If that is the case, then its functionality of keeping that area at least a little bit clear from monsters is nice. I don't think it is fair to require player to always create some safe house at that location.
However, if admins can set a default spawn point in multi-player, then indeed, the protection should be set for that location, not something random rolled by the game.
Brad: the algorithm that calculates the original spawn point is the same for all world types (at least if the suggestion in
MC-2807is not applied). The reason why the slime chunks seemed to work in normal worlds was explained in the other issue; height difference.For knowing where the world spawn is? I think that in single player the original spawn point is the same (or at least close) to the "world spawn point", so compass would point to it at all times. Multi-player? No idea.
The world spawn point is stored in the level.dat file, and changing it changes both the default spawn point and the block protection area. Although I haven't examined the code to be sure, it's likely that the monster spawning algorithm uses this same, moveable spawn point, and not just one generated from the seed. So it is likely that the compass would point to it, single- or multi-player. Probably best if someone tests all this though.
original spawn (marked with gold block)
edited level.dat (spawn moved to gold block)
Ok, I've uploaded some pics that seem to confirm that the level.dat SpawnX and SpawnZ values are in fact what the game uses to suppress spawning in a region around them. In both pics, the 4 wool-colored chunks are supposed to be valid slime chunks for this seed (-6310548451344270339), according to slime finders.
In slimes_1.png, the spawn is at its original location (x=289, y=4, z=598), marked with a gold block. It suppresses slime spawning in the red (completely) and the orange (mostly). If the suppression radius from spawn is 16 blocks (the wiki mentions a 33x33 area, which seems to confirm this), the top edge of orange can still spawn slimes. (There are also a couple of slimes that I think glitched through the fence when I re-loaded the level (known bug), these can be ignored.)
In slimes_2.png, I used NBTExplorer to modify the SpawnX and SpawnZ values, moving the spawn to (x=240, y=4, z=600), also marked with a gold block. Red, Orange, and Blue chunks produced lots of slimes, The pink chunk did not.
Regarding how the spawn point is calculated, it DOES appear to vary according to the world creation options (these are all using the same seed, -6310548451344270339):
Default normal: x=-212, y=64, z=256
Flatland (default): x=289, y=4, z=598
Flatland (custom, up to 63 layers of dirt): x=289, y=4, z=598
Flatland (custom, 64 layers of dirt): x=92, y=4, z=-239
Flatland (redstone ready): x=789, y=4, z=197
Large Biomes: x=-76, y=64, z=252
I can also confirm that a compass will point to the modified spawn point if the level.dat is edited, and not your bed location. This is very good, since it gives players in-game a way to identify a location to avoid building mob farms.
So as far as I'm concerned, this answers my questions about my original issue.
Regarding whether this mob suppression is a good idea, it definitely is for multiplayer, and since the same world could be used for both single and multiplayer, I'm not sure it would be good to have different rules for single player.
In any case, removing this is probably a feature request more than a bug report.
IIRC, the algorithm that calculates the spawn point is the same for different world types and settings. The reason why the spawn point ends up being different is that algorithm's "random seeking" is affected by the world's content, and possibly by the RNG's state at the time the seeking is started. That state is naturally different depending on what had been done during world generation before that point.
Nevertheless, the calculated spawn point can be (and usually is) different for different world types. The exact spawn point can differ even for the same world type and seed on different creation times.
However, that doesn't really affect this issue.
If the usual ways to change that "world spawnpoint" affect those level.dat values, the world spawnpoint, and thus also the protection area, I guess all is good, and this issue is "working as intended".
Correct, that ultimately means that the world spawn can't be uniquely calculated (by an outside app, like a slime finding tool) from the seed alone. But since we can use a compass in-game (and an editor out of game) to find it, I think we're ok.
Is this still a concern in the current Minecraft version 1.7.2 / Launcher version 1.3.4 ? If so, please update the affected versions in order to best aid Mojang ensuring bugs are still valid in the latest releases/pre-releases.
This ticket is incomplete without the requested information, no response has been received within a reasonable time and we are assuming the issue has been resolved. Should your issue return please submit a new complete ticket with all available information.
Please review the guidelines before reporting issues.