Stop overwriting block locations, root issue looks to be the TE fixer itself

Fixes GH-352
This commit is contained in:
Zach Brown 2016-06-26 18:38:39 -05:00
parent de4a16ead0
commit 98c7a31d79
2 changed files with 10 additions and 20 deletions

View file

@ -1,13 +1,16 @@
From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
From: Zach Brown <1254957+zachbr@users.noreply.github.com>
Date: Sat, 25 Jun 2016 23:55:56 -0500
Subject: [PATCH] Move setBlock tile->tile transition workaround into TE
removal code and out of setblock
Subject: [PATCH] Don't try and fix TileEntities as they are removed
Works around an issue in which running it in setBlock for all block changes could cause sign (and other?) data corruption.
Also tells CB's TE fixer to ignore removals, as it would end up in a state in which it'd set the block, then
call TE removal, which would get the TE to remove, then making CB's fixer run and get confused as to the current state of
the block, but we don't care because that's the whole reason we're removing it.
Currently, CraftBukkit tries to fix TEs that do not match the present block at the location. This is normally good,
however, this same fixer runs when the TE removal functions go through to remove a TE after its block has been changed.
So a block will be changed, the server will attempt to remove the TE present, but will then get caught up in CB's overzealous
TE fixer. That fixer checks the block against the TE present, and throws a fit because it doesn't match. Which is why we're
removing it in the first place.
The 'fix' to this issue is to skip the fixer entirely when we're removing the TE, as it shouldn't ever need to run
then anyway, we're removing it.
diff --git a/src/main/java/net/minecraft/server/BlockChest.java b/src/main/java/net/minecraft/server/BlockChest.java
index 0000000000000000000000000000000000000000..0000000000000000000000000000000000000000 100644
@ -61,18 +64,6 @@ index 0000000000000000000000000000000000000000..00000000000000000000000000000000
if (tileentity instanceof TileEntitySkull) {
TileEntitySkull tileentityskull = (TileEntitySkull) tileentity;
diff --git a/src/main/java/net/minecraft/server/BlockTileEntity.java b/src/main/java/net/minecraft/server/BlockTileEntity.java
index 0000000000000000000000000000000000000000..0000000000000000000000000000000000000000 100644
--- a/src/main/java/net/minecraft/server/BlockTileEntity.java
+++ b/src/main/java/net/minecraft/server/BlockTileEntity.java
@@ -0,0 +0,0 @@ public abstract class BlockTileEntity extends Block implements ITileEntity {
public void remove(World world, BlockPosition blockposition, IBlockData iblockdata) {
super.remove(world, blockposition, iblockdata);
world.s(blockposition);
+ world.setTypeAndData(blockposition, Blocks.AIR.getBlockData(), 0); // Paper - SPIGOT-611 workaround moved from setBlock
}
public boolean a(IBlockData iblockdata, World world, BlockPosition blockposition, int i, int j) {
diff --git a/src/main/java/net/minecraft/server/World.java b/src/main/java/net/minecraft/server/World.java
index 0000000000000000000000000000000000000000..0000000000000000000000000000000000000000 100644
--- a/src/main/java/net/minecraft/server/World.java
@ -131,7 +122,7 @@ index 0000000000000000000000000000000000000000..00000000000000000000000000000000
IBlockData blockData = getNMSBlock(type).fromLegacyData(data);
BlockPosition position = new BlockPosition(x, y, z);
+ // Paper start - Moved to TileEntity removal
+ // Paper start - Unnecessary, root issue is CB TE's fixer getting too involved. Also potential data issues.
+ /*
// SPIGOT-611: need to do this to prevent glitchiness. Easier to handle this here (like /setblock) than to fix weirdness in tile entity cleanup
if (type != 0) {

View file

@ -44,7 +44,6 @@ import BlockFluids
import BlockFurnace
import BlockIceFrost
import BlockPosition
import BlockTileEntity
import ChunkCache
import ChunkProviderFlat
import ChunkProviderGenerate