[MC-10303] Slimes do not spawn at world spawn point

I made a custom superflat in creative mode using seed -6310548451344270339 (I used one layer of bedrock, one layer of clay). Spawn point is at (x=288,z=592). I created a fence grid on the chunk boundaries to determine where exactly slimes spawn.

Available "slime finder" utilities (see http://www.minecraftwiki.net/wiki/Slime#Slime_Finding_Tools ) show valid slime chunks at (x=272,z=576) to (x=288,z=592) and (x=288,z=592) to (x=304,z=608).

On a normal world, these chunks do successfully spawn slimes. On this superflat, though, no slimes spawn in these chunks (see red-marked areas in pic). Other slime chunks appear to work fine (left side of pic).

So are these valid slime chunks? Or is this working as expected, but the slime finder utilities have an outdated algorithm, or are missing an exception for superflats? If so, can we have the corrected algorithm? Was this due to the slime spawning changes made in 12w25a?

(Search found a possibly-related closed ticket, MC-9440, but without the detail and pics)

Linked issues

is duplicated by 1

MC-9440 Slimes do not spawn on Superflat Worlds Resolved

relates to 1

MC-12395 Player spawnpoint used in monster spawning seems to be unaffected by sleeping in bed or /spawnpoint command Resolved

Attachments

Comments 15

Brad Corbin 2013-02-26T08:33:21Z

Note that the pillar holding the anvil in the screenshot corresponds to x=288,z=592, which is the center point of the slime finder map. There should be four valid slime chunks near the center, but only the left two appear to actually work on superflats.

Brad Corbin 2013-02-26T14:04:31Z

The wiki page on slime generation lists the following as the formula used to calculate slime chunks:

Random rnd = new Random(seed +
(long) (xPosition * xPosition * 0x4c1906) +
(long) (xPosition * 0x5ac0db) +
(long) (zPosition * zPosition) * 0x4307a7L +
(long) (zPosition * 0x5f24f) ^ 0x3ad8025f);
return rnd.nextInt(10) == 0;

I assume that this is the formula used by all the slime-finder tools. If this formula is no longer correct for superflats, that would be really handy to know 🙂

Brad Corbin 2013-02-27T13:56:35Z

Quick update: I did some further testing, and confirmed that these two chunks discussed above, (x=272,z=576) to (x=288,z=592) and (x=288,z=592) to (x=304,z=608), are valid slime chunks in a normal world (not superflat). I generated a world with the same seed, dug down to level 10, cleared out and lit up these chunks, separating them by fences. Slimes spawned in all the chunks indicated on the slime finder map.

Brad Corbin 2013-03-01T04:33:43Z

More extensive test with better results. Same seed and location as the other screenshot. The two left slime chunks are obvious, the top middle should be one, but has only spawned a very small number. The chunk on the bottom right should also be a slime chunk, according to slime finders.

Jeuv 2013-03-07T20:16:09Z

I think these are valid slime chunks but the reason that they spawn only little slimes is because of complaints that superflat worlds spawned huge amounts of slimes.

5 more comments

bugi74 2013-03-07T20:44:14Z

A bit of light:

EntitySlime.getCanSpawnHere()

...
        if (this.worldObj.getWorldInfo().getTerrainType() == WorldType.FLAT && this.rand.nextInt(4) != 1) {
            return false;
        ...

That is, if the world type is superflat, there is a 75% chance it will just decide that no, not spawning that one. (Although that should only be per-slime check, not per-chunk). Also, there are different rules for spawning at surface levels than spawning on the lower levels. The wiki-formula only applies to the lower levels (below 40).

There can be other things affecting it. For example, if one part of map spawns lots (due to it being so easy to spawn slimes there), when the algorithm gets to other parts, the maximum numbers have been reached already. I didn't check for this at all, just a quick example what sort of rule-tangles can affect the issue.

I'd suggest a further test. Fill the chunks that now do spawn slimes (so that no mobs can spawn there), and see if the now-empty chunks would then get some slimes.

Brad Corbin 2013-03-11T15:04:53Z

Jeff- Yes, high slime generation was pretty frustrating for flatlands, I believe this was changed back in 12w25a, the wiki mentions "Slimes spawning in Superflat world type has reduced." The problem is that we weren't provided with any details about how exactly slime spawning was reduced, and it certainly matters when using a "slime finder" and building slime farms based on the result. I'm not really contending that this is a bug in the game that needs to be fixed, but more of information that players/tool developers/wiki maintainers need to fix our slime finding methods for superflats.

Markku, thanks for checking on that. As you mention, that appears to be "can I spawn this specific slime" code. What does the "is this a valid slime chunk" code look like? Does it have a similar test for WorldType.FLAT? I've pasted the formula from the wiki into an earlier comment, I'm not sure if it bears any resemblance to the game code.

If the EntitySlime.getCanSpawnHere() code you posted is the only part that mentions WorldType.FLAT, do you have any theories on why those two specific chunks are non-producing, only on flatworlds? They also happen to be directly under the spawnpoint, if you think that might be relevant.

I'll see if I can also do some further testing. I had already done a 2x2 test (just the 4 chunks to the right that should have had 2 slime chunks) and couldn't generate any slimes.

bugi74 2013-03-11T15:50:51Z

The effect of that per-slime check would likely be that in its place, another mob type would be spawned (somewhere else?). I couldn't find other checks for world type in that code. And the chunk location check (for lower levels) is still the same as shown in wiki.

From wiki "Spawn": "There must be no players and no player spawn points within a 24 block distance (spherical) of the spawning block". While that does not extend far down (unless the spawn point is at low levels), I would not rule out something like that affecting. I wrote one extra test case earlier, and I would now augment it with twist of "keep the player suitable away from the test area, e.g. at least 2 chunks away".

Brad Corbin 2013-03-11T18:24:41Z

Right, but I would have expected it to give an equal 75% nerf in all (valid) slime chunks, and not to give a complete nerf to 75% of all slime chunks? (Not sure if that's really what is happening here, I don't think 75% of slime chunks are broken.)

Unless the value of this.rand.nextInt(4) is somehow being determined by the chunk coordinates? So where exactly is THIS.RAND being created/initialized? Is it a global object, or is it initialized earlier in the EntitySlime.getCanSpawnHere() routine?

Ah, I bet that's it. If the sequence looks something like (combining the wiki code and your code with a dash of speculation):

EntitySlime.getCanSpawnHere()

...
//check if we're in a valid slime chunk
Random rand = new Random(seed +
(long) (xPosition * xPosition * 0x4c1906) +
(long) (xPosition * 0x5ac0db) +
(long) (zPosition * zPosition) * 0x4307a7L +
(long) (zPosition * 0x5f24f) ^ 0x3ad8025f);

if (this.rand.nextInt(10) == 0)
{
//we're in a valid slime chunk
}
...

//check for additional nerf for flatland, added in 12w25a
if (this.worldObj.getWorldInfo().getTerrainType() == WorldType.FLAT && this.rand.nextInt(4) != 1) {
return false;
...

If it looks something like that, then this.rand.nextInt(4) would always generate the same value in the same coordinates, so we'd end up with entire slime chunks non-functional, like I'm describing in the original ticket description.

bugi74 2013-03-11T18:35:18Z

That world/terrain type check is the very first logic check in the method, and its Random is generated properly (i.e. it should provide good enough randomness).

I also expect that 75% skip chance to apply equally to every chunk (and every slime). The only explanation/idea I have had (and its related further test) I already explained earlier.

kumasasa 2013-03-18T23:35:10Z

Is this still a concern in the current Minecraft version? If so, please update the affected versions in order to best aid Mojang ensuring bugs are still valid in the latest releases/pre-releases.

bugi74 2013-03-19T14:30:22Z

I checked the code related to this, and while slime spawning has been made very rare (and there are changes for the higher level swampland spawning in 1.5, but not for lower level spawning), to the point of making testing this without adjusting the probabilities near impossible, the reason for the described lack of spawning is sort of an intended feature - the world spawn point is near those two non-spawning chunks and spawning is prevented on those areas. The idea behind this is probably to keep the spawn point somewhat clear/safe.

The reason why all chunks worked on normal world is likely because the spawn point will be higher up (vertical distance matters, too), and slime spawning was tested on lower levels.

However, that intended feature seems to be a bit bugged these days, when all games are server-based (and thus sort of multiplayer). Changing the solo-player's spawn point will not change the world's spawnpoint, which is the one used in the mob spawn test. Thus, the player's spawn point will be vulnerable to mob spawning, while that unused world spawnpoint messes up spawning in a seemingly random area (like in this issue). (I tested this by using /spawnpoint command to move my spawnpoint; nothing changed, issue continues.)

Thus, I'd resolve this one with "works as intended" (as in, spawnpoint area is kept clear), and open up a new issue for the problem I described (i.e. using incorrect spawnpoint in the prevention check), as it affects all hostile mobs and game modes, not just slimes/super-flat.

kumasasa 2013-03-19T19:49:02Z

Markku, create a new ticket (refering to this one), then we'll resolve this.

bugi74 2013-03-19T20:34:37Z

Created MC-12395.

Brad Corbin 2013-04-01T15:12:26Z

Thanks, Markku, for your testing on this. This seems correct, as I tried to replicate the problem on several other seeds, but could never get it to replicate. I realize now I was testing other chunks besides the world spawn.