Fossil generation causes chunks to be generated far away

I wonder why this bug is so unpopular as a lot of people should have noticed those big-numbers region files suddenly appearing. It's pretty messy and gives me trouble with a Bukkit plugin I'm developing right now.

So what I found out is: This only happens in swamp biomes! While the chunks for the swamp are generated, some of them trigger a chunk to be generated with current block-coordinates as chunk-coordinates. Or in other words if a swamp chunk at x5 z7 is generated, x80 z112 possibly generates as well (5 << 4 and 7 << 4). My guess is that someone took the chunk coordinates as block coordinates and shifted or multiplied them to get the chunk coordinates which already were present. (That's the factor 16 or 16 * 16 = 256 already mentioned.)

This bug can easily be reproduced. The affected chunks are always the same with same seeds.
Just create a normal world with seed 9 and go to block location ~ x500 z450. The following chunks will be generated:
(normal + "stray")
x32 z26 + x512 z416
x32 z27 + x512 z432
x34 z27 + x544 z432
x33 z31 + x528 z496
x34 z31 + x544 z496
The block locations of the "stray" chunks are somewhere around ~ x8448 z7296. That's pretty far away. Not to mention that if you go there and trigger new stray chunks in a swamp around ... the new strays will be extremely far away.

That's interesting; reproduced in 16w33a and now trying to debug what exactly is generating those chunks now that it's clear that it's something with swamps.

And, found. This is not exclusive to swamps, but also happens in deserts it seems - it's an issue with the fossil generator.

WorldGenFossils.java

public boolean generate(World worldIn, Random rand, BlockPos position) {
        Random random = worldIn.getChunkFromChunkCoords(position.getX(), position.getZ()).getRandomWithSeed(987234911L);
        // ...

The method name there is fairly specific: it takes chunk coords, not block coords (fine, that's the MCP name). That method'll generate the chunk, even if it's that far away. To fix it, it could be replaced with getChunkFromChunkCoords(position.getX() >> 4, position.getZ() >> 4).

I have a hunch that the bug in swamps may involve the terrain generation changes introduced in version 1.8. In that version, the terrain in swamps at sea level was changed so some blocks at sea level were randomly replaced with water blocks (see attached image). If you go to the coordinates of the stray chunks and divide them by 16, you are likely to find this kind of terrain modification nearby (within 16 blocks). It happens with the coordinates in the OP, and the coordinates in all five of the ones in Chikyuno's post.

There are other similar issues with stray chunks in the terrain generation that are not related to swamps. I have previously seen stray chunks in the Nether though I have not been able to reproduce this. I have also seen stray chunks in superflat worlds with different behaviour.

The generation of this kind of terrain may be the cause of the issue in swamps (see attached image).

I know for sure that fossils are causing it from the code (you'll find fossils at the areas shifted areas if you dig down). It's probably not that weird swamp terrain since I tested in 1.9 and I'm not getting stray chunks there in 1.9 (though the weird terrain is still there); fossils were added in 1.10 so that coincides.

That said, I've also seen those random stray chunks both in the nether and overworld, and those were before fossils. So there definitely is a second thing that's causing this; fossils are just a more consistent way of seeing it.

That was fast, thank you Pokechu!!
Somehow I got confused while writing my "guess" and mixed block/chunk/coords around myself. 😃 (Well, it was late at night... 😉 )
So maybe my fault you got confused too. 😃
getChunkFromChunkCoords(position.getX() >> 4, position.getZ() >> 4) should be the right way because shifting left would make it worse 😃. Also -15 / 16 gives 0 instead of -1 which is returned by -15 >> 4, so right shift should be the only way when using block position integers. (Doesn't matter as long as block coords always are x0 z0 of chunk though. But it's cleaner to do so in my eyes.)

Interesting, it also appears in deserts? Sorry for the partly wrong info if so. I probably didn't test enough after finding bunches in swamps and nothing in surrounding forest / plains / hills...

Whoops, yea, probably wouldn't want to multiply by 16. Upon looking at the code further, >> 4 is always used with block positions and / 16 is only used with doubles, which are floored afterwards, so >> 4 is what should be used here.

Edit: I did it again...

It doesn't matter too much, but I'd like to point out that blocks positions are almost certainly using / 16 in the original source, which the compiler automatically converts to >> 4 since it is slightly faster (and thus that is what we see in the decompiled code). The source should continue to use / 16, since it comes to the same thing and is easier to read.

It's not the same. Everything from 15 to -15 / 16 is 0. So we hava a 31x31 Chunk at 0/0? Of course not, chunks are always 16x16.
Also -17 to -31 has to be -2 and not -1 and so on.
>> 4 will simply do the trick of flooring an int instead of just omit decimal.
And by the way, because it's not the same it also can't be a compiler optimization.

Just try
System.out.println(Integer.toString(-8 / 16));
System.out.println(Integer.toString(-8 >> 4));
and you'll see.

I thought that that difference existed (but didn't bring it up). In any case, the fix did use >> 4 for it, so that's not an issue.

(ideone demo)