Fix invalid block entities created during world gen #10375
Conversation
patches/server/1055-Fix-creation-of-invalid-block-entity-during-world-ge.patch
Outdated
Show resolved
Hide resolved
|
@electronicboy I found another issue related to this (even if it's not the same) so I'm going to make another PR to fix it Basically, if a Sculk Sensor is in a broken state (Block and Block Entity aren't right) the vibration system makes the player crash, this PR doesn't fix it
|
I can move the line up, how do I reduce the diff? |
|
cleaning up the diff is moreso just accepting that the thing is going to look at bit messy, i.e. reverting the indentation changes; I was hoping that the tick logic would get to the block entity before it blew up, will probably have to just make the server check that the blockstate is valid for any block entity sets during loading in order to remove them earlier |
Yes, that's a better way to do it, do you want me to add that in this PR or another one? |
|
generally that sorta thing would be done as a separate PR |
lynxplay
force-pushed
the
fix-invalid-block-entities
branch
from
b665658
to
862d370
Compare
The previous PR PaperMC#10375 removes block entities on setBlock calls to the WorldGen region to prevent the existence of a block entity on a block that does not support it as such. The logic however assumed that such calls would always follow the order of: 1. set the base blockstate 2. create the block entity 3. finish world gen This is however not the case for all of world gen, specifically not for structure templates being placed under water, as these first set the block state, then configure its block entity (include the chests lootable) and finally waterlogs the chest by calling another setBlock. To prevent this logic from deleting the original block entity, this commit now only removes the block entity found if the blockstate to be set differs from the previous one, matching LevelChunk#setBlockState.
The previous PR PaperMC#10375 removes block entities on setBlock calls to the WorldGen region to prevent the existence of a block entity on a block that does not support it as such. The logic however assumed that such calls would always follow the order of: 1. set the base blockstate 2. create the block entity 3. finish world gen This is however not the case for all of world gen, specifically not for structure templates being placed under water, as these first set the block state, then configure its block entity (include the chests lootable) and finally waterlogs the chest by calling another setBlock. To prevent this logic from deleting the original block entity, this commit now only removes the block entity found if the blockstate to be set differs from the previous one, matching LevelChunk#setBlockState.
This patch fixes #10022 and sachingorkar102/Lootin-plugin#24
When using WorldGenRegion#setBlock on a block position where a BlockEntity exists it doesn't remove the old one, this creates a broken state in the world and makes the clients crash due to an internal server error.
To fix these issue, I'm removing the BlockEntity when WorldGenRegion#setBlock is set (to fix new worlds) and I've changed the LevelChunk#tick method to remove the invalid BlockEntity (to fix the existing worlds)