This issue doesn't have any visible effects by itself, but it will crash if enough mods do that, which may be problem for modpacks.

The actual issue and fix:

When Minecraft populates a chunk, it actually populates the following block region (chunkX*16+8, chunkZ*16+8) to (chunkX*16+8+16-1, chunkX*16+8+16-1), and you have 8 blocks buffer radius in each direction.

Here ActuallyAdditions creates "center" position and attempts to and gives that position to caveGen which scans area in 10 blocks radius. It will always go 2 blocks out of the chunk in each direction. In positive x/z you can go 15 blocks off, but in negative x/z direction it will cause recursive chunk generation/loading (getBlockState always loads/generated needed chunks). Depending on the random position added it may go 2 blocks out of the max population area, and since getBlockState always generates chunks - it will cause recursive generation.

The fix is to simply add another +8 blocks offset in x and z directions. It doesn not apply to WorldGenMinable - it does the offset internally. The fix is to decrease the scan radius so that it

Since the structure doesn't seem very common and there is random factor it's not a big issue by itself, but it can end up in StackOverflowError if many mods do the same thing. But it would still be good to fix it since easily avoidable.

But aren't I already adding 8 blocks like you said here?

this is just to get chunk center, but center of actual population area is another +8 blocks.

So.. the next chunk?

Is that how Minecraft does it? It gives you a chunk with the coordinates x, y but expects you to actually generate chunk x+1, y+1?
That seems odd to me.

it actually expects you to populate area (chunkX*16+8, chunkZ*16+8) to (chunkX*16+8+16-1, chunkX*16+8+16-1), I know it's totally counterintuitive. But it allows minecraft to do population when only 3 surrounding chunks exist, instead of requiring all 8.

I can link to sponge or bukkit documentation on it.

Okay, I will implement that system in the next update. Thanks for the heads up.
But if it fails, I'll be blaming you :P

There, sponge documentation: https://jd.spongepowered.org/4.1.0/org/spongepowered/api/world/gen/Populator.html

Just don't do that for ores - WorldGenMinable does it automatically.

If you did it during biome decoration - this code would clearly throw an exception. And decoration is part of population.

Actually, with the way it works - it will cause recursive generation even with that offset. I don't really see the reason for randomizing the position here, but if you want to - you could reduce scan radius to 8 or 7 blocks so that it never attempts to load new chunks.

So my bug report is slightly wrong; the only thing that needs to be changes is scan radius. There is 8 block offset + random, but the 10 blocks scan radius still makes it populate too big area. I will update the original report.

I'm quite sure this BlockPos posAtHeight = world.getTopSolidOrLiquidBlock(new BlockPos(x+random.nextInt(16)+8, 0, z+random.nextInt(16)+8)); is randomized.

If this would give actual population area center instead of random position - everything would be ok as you would never go outside of the population area. Again, in this mod it's not that big issue, but when combined with many mods it sometimes does result in errors.

I'm not exactly sure how the generator is supposed to work, so I can't say for sure what would be the right thing to do.

And the radius I was talking about was genTreesAndTallGrass radius. In this case - areas scanned when populating different chunks overlap, so it seems redundant.

The position isn't randomized. The only thing that is randomized is the size of the cave.
If I lower the radius to 8, the caves will become smaller right here.
What can I do about that?

To be honest, I am somewhat confused by this whole issue.
It'd be really nice if you could make the changes and then submit a pull request. That way I know exactly what you meant, plus I won't do it wrong.
That'd be really really helpful!

That code was really confusing to me. Now that I really understand how it works - it turns out that doing is right may not be worth it. I got it working but the code is quite complex, and instead of generating lush caves anywhere below the top block, it generates it somewhere below y=64.

The only way to do that without changing what it does, is to do it similar to how normal caves are generated:

Generate the structure as if it was generated from all neighbor chunks, and see if any blocks intersect the current chunk. Except that trees make it a bit more complicated.

The only way it could cause problems the way it's now is when you make these structures very common (close to 50% probability per chunk).

Unless you want it to work under such conditions - I don't think it's worth the complicated code. I can still submit the PR if needed.

Soo.. what now?

I made it work (look at my commit), but the code is more complicated than I thought and there is a difference in functionality. If you want it fixed anyway - I can submit PR.

Do the PR, I might take a look at it.