Closed banjomarx closed 10 years ago
About the first stacktrace:
Looks like this is a bug in Natura, exposed by Terrain Control.
Technical details (copy this if you submit a bug to Natura): the BaseCropWorldgen class picks an random x and z position somewhere in the chunk, and then chooses a location at random at most 8 blocks away. That may fall outside the loaded chunks area (only (chunkX, chunkZ), (chunkX + 1, chunkZ), (chunkX, chunkZ + 1), (chunkX + 1, chunkZ + 1) are guaranteed to be loaded, so it may fail when subtracting random.nextInt(8)
when you're unlucky). Terrain Control is quite strict about this: it doesn't permit another chunk load while a chunk is being populated. The author needs to remove all - random.nextInt(...)
calls and double the numbers in + random.nextInt(...)
. So
int i1 = (x + random.nextInt(8)) - random.nextInt(8);
becomes
int i1 = (x + random.nextInt(16));
I realize that this code is probably based on vanilla Minecraft code, but vanilla Minecraft calculates the x coord in a different way in generators that use - random.nextInt(...)
.
I can remove the check in Terrain Control, but ideally the bug should be fixed in Natura.
Edit: this bug is very common in Forge mods... The second stack trace is just another example. Vanilla Minecraft doesn't complain, so I'm going to remove the check...
ok so should i not bother sending a report to natura dev? or should i do so anyways?
Nah, it's a really minor issue. I think I should add a note to the Forge wiki, that will at least prevent errors in new mods.
Setting PopulationBoundsCheck
to false in the WorldConfig will now disable this error.
Friend tried to gen a world
and he tried again