Chests can cause loading Neighbor chunks.
Speiger opened this issue · 8 comments
Hey, I am back to show you something really cool.
(Not a bug or maybe you make it a bugreport but here is a fact)
Chest Class
public void onBlockAdded(World worldIn, BlockPos pos, IBlockState state)
{
this.checkForSurroundingChests(worldIn, pos, state);
for (EnumFacing enumfacing : EnumFacing.Plane.HORIZONTAL)
{
BlockPos blockpos = pos.offset(enumfacing);
IBlockState iblockstate = worldIn.getBlockState(blockpos); //<< a Unsave getBlock call that can load chunks if on a chunk edge
if (iblockstate.getBlock() == this)
{
this.checkForSurroundingChests(worldIn, blockpos, iblockstate);
}
}
}Chunk.class setBlockStateCall
// If capturing blocks, only run block physics for TE's. Non-TE's are handled in ForgeHooks.onPlaceItemIntoWorld
if (!this.world.isRemote && block1 != block && (!this.world.captureBlockSnapshots || block.hasTileEntity(state)))
{
block.onBlockAdded(this.world, pos, state); //<<Only called if the Block is changing not the Block State
}And guess what, if a new chunk loads do to this logic then what can potentionally happen?
The block gets overriden and do to Execution order the setBlockStateCall gets paused until the other chunk is completely generated!
If you dont believe me that this can not load new chunks even without throwing blockupdates on block placement
there is an exploit that people use to force a randomizer manipulation to make diamond ore drop always 4 ore. And guess what it uses.
Chests!
https://youtu.be/YLq5-AAmJXM?t=828
Now why is ChunkPregen causing this issue with chests more likely then vanilla?
Very simple: In Vanilla its only more likely to happen if you go into negative directions and since chunkpregen does a certain type of pregeneration where it prepaires a 2x2 grid and then asks the top left chunk to populate (Mcs logic you can look in the chunk.populate function),
that causes no buffer to be into the negative direction and thats why it happens more likely.
Now if something is generationg more into the positive direction then there is no possiblity (up to 32 blocks) to cause this issue because of the extra chunk in each direction.
But if you are generating into the negative direction its more likely to happen because there is no buffer chunks.
TL:DR is: You are generating the structure to close to the negative edge of a chunk and thats why the bug is more likely to happen. With a player walking negative its not as bad because of the randomness in movement but chunkpregen boils it down to the foundation that you didnt understand fully
Edit: Most ChunkCascading bugs actually are do to stuff getting generated to close to the negative side of a chunk (0, 0 instead of 16, 16). So a fix would be to maybe push the blocks a bit further into the chunk or force center everything?
Interesting.
I need to triple-check if the center-the-template code transitioned over when I added the ground check to ensure that it wasn't generating on surfaces that weren't suitable. At least as far as the Hut goes (which is quite a small structure), it's more likely that the edge of the structure is potentially causing the cascade by being too close rather than the chest inside, seeing as the chest is well within the bound of the structure, unless you mean that the blocks are properly being added with the correct flags to ensure it doesn't cascade, but the chest overrides this regardless?
Either way, I'll look into it. Thanks!
EDIT: Genuine thanks for the information, I was still struggling to understand what was going on.
seeing as the chest is well within the bound of the structure, unless you mean that the blocks are properly being added with the correct flags to ensure it doesn't cascade, but the chest overrides this regardless?
Yep sadly it ignores that regardless. There might be even other blocks that do that too.
No problem. I wanted to throw a try giving you the info you need. Even if it sounded a bit rude on my side.
No, it's perfectly fine! You're certainly in a position to sound rude after some of my responses, which were predicated on me failing to understand you and what you were saying. I greatly appreciate that you took the time and effort to sit down and explain it fully, even knowing what my previous responses had been, knowing that perhaps I'd just close it/ignore it.
So thank you so much for putting the effort in and helping me to properly understand it! And my own apologies for being rude to you in the past when discussing it; I can claim ignorance, but I don't think that's a reasonable excuse for my behaviour.
Tiny request.
Could you get rid of these "blaming" loggers?
https://github.com/MysticMods/MysticalWorld/blob/master/src/main/java/epicsquid/mysticalworld/world/StructureGenerator.java#L181
https://github.com/MysticMods/MysticalWorld/blob/master/src/main/java/epicsquid/mysticalworld/world/StructureGenerator.java#L198
Because I start to get Reports from people thinking its my mistake.
And please don't pull a optifine.
(Fixing it and basically not releasing the patch for 8 months even so you have 10 potential releases. and then getting angry that I am complaining, since I had to deal with the people that had a crash do to his mod)
I'm currently in the alpha cycle of Roots 3.1 and it's kind of interconnected, but I think I'll be able to get a release out. My current disclaimer is that I think my current disclaimer issue is that there is a potential for these structures to not spawn at all with Chunk Pregenerator; I'm wondering if converting the chest to actually be embedded in the NBT with the loot table in the NBT (i.e., how 1.14 village pieces do it) might be an alternative -- if that works.
Okay, sorry for the delay. Due to the alpha changes to MysticalLib, I had to shuffle a few things around to be able to release Mystical World with the changes.
I had intended to use load-from-NBT chests to hopefully bypass this issue from happening -- not sure if that would fix it or not, but I never got around to testing it.