MC-116919Tripwire hook at invalid position does not drop when another tripwire hook is placed next to it
The bug
A tripwire hook at an invalid position does not drop if another tripwire hook is placed next to it. Since most if not all other blocks which require a supporting block do not have a special case like this, the expected behavior would be that the tripwire hook breaks regardless of which block was placed next to it.
How to reproduce
Note
In general there parameters passed to net.minecraft.block.Block.neighborChanged(IBlockState, World, BlockPos, Block, BlockPos) are pretty inconsistent. To reproduce this bug the second parameter (Block) has to be a tripwire hook. This can be achieved by using /setblock or /fill (which passes the new block), but not by placing a tripwire hook (which passes the previous block).
- Fill multiple non-tripwire hooks which require a supporting block, like torches
/fill ~ ~ ~ ~ ~2 ~ torch
→ They break and drop
- Fill multiple tripwire hook blocks
/fill ~ ~ ~ ~ ~2 ~ tripwire_hook
→ They do not break
Code analysis
Based on 1.11.2 decompiled using MCP 9.35 rc1
The method net.minecraft.block.BlockTripWireHook.neighborChanged(IBlockState, World, BlockPos, Block, BlockPos) does not test if the tripwire hook should drop if the block parameter is a tripwire hook as well.
Linked Issues
Created Issue:
Tripwire hook at invalid position does not drop when another tripwire hook is placed next to it
The bug
A tripwire hook at an invalid position does not drop if another tripwire hook is placed next to it. Since most if not all other blocks which require a supporting block do not have a special case like this, the expected behavior would be that the tripwire hook breaks regardless of which block was placed next to it.
How to reproduce
Note
In general there parameters passed to net.minecraft.block.Block.neighborChanged(IBlockState, World, BlockPos, Block, BlockPos) are pretty inconsistent. To reproduce this bug the second parameter (Block) has to be a tripwire hook. This can be achieved by using /setblock or /fill (which pass the new block, but not by placing a tripwire hook (which passes the previous block).
- Fill multiple non-tripwire hooks which require a supporting block, like torches
/fill ~ ~ ~ ~ ~2 ~ torch→ They break and drop
- Fill multiple tripwire hook blocks
/fill ~ ~ ~ ~ ~2 ~ tripwire_hook→ They do not break
The bug
A tripwire hook at an invalid position does not drop if another tripwire hook is placed next to it. Since most if not all other blocks which require a supporting block do not have a special case like this, the expected behavior would be that the tripwire hook breaks regardless of which block was placed next to it.
How to reproduce
Note
In general there parameters passed to net.minecraft.block.Block.neighborChanged(IBlockState, World, BlockPos, Block, BlockPos) are pretty inconsistent. To reproduce this bug the second parameter (Block) has to be a tripwire hook. This can be achieved by using /setblock or /fill (which pass the new block, but not by placing a tripwire hook (which passes the previous block).
- Fill multiple non-tripwire hooks which require a supporting block, like torches
/fill ~ ~ ~ ~ ~2 ~ torch→ They break and drop
- Fill multiple tripwire hook blocks
/fill ~ ~ ~ ~ ~2 ~ tripwire_hook→ They do not break
Code analysis
Based on 1.11.2 decompiled using MCP 9.35 rc1
The method net.minecraft.block.BlockTripWireHook.neighborChanged(IBlockState, World, BlockPos, Block, BlockPos) does not test if the tripwire hook should drop if the block parameter is a tripwire hook as well.
The bug
A tripwire hook at an invalid position does not drop if another tripwire hook is placed next to it. Since most if not all other blocks which require a supporting block do not have a special case like this, the expected behavior would be that the tripwire hook breaks regardless of which block was placed next to it.
How to reproduce
Note
In general there parameters passed to net.minecraft.block.Block.neighborChanged(IBlockState, World, BlockPos, Block, BlockPos) are pretty inconsistent. To reproduce this bug the second parameter (Block) has to be a tripwire hook. This can be achieved by using /setblock or /fill (which passes the new block), but not by placing a tripwire hook (which passes the previous block).
- Fill multiple non-tripwire hooks which require a supporting block, like torches
/fill ~ ~ ~ ~ ~2 ~ torch→ They break and drop
- Fill multiple tripwire hook blocks
/fill ~ ~ ~ ~ ~2 ~ tripwire_hook→ They do not break
Code analysis
Based on 1.11.2 decompiled using MCP 9.35 rc1
The method net.minecraft.block.BlockTripWireHook.neighborChanged(IBlockState, World, BlockPos, Block, BlockPos) does not test if the tripwire hook should drop if the block parameter is a tripwire hook as well.
![[Mojang] Nathan Adams](../../../data/assets/gravatar/dinnerbone.png){kind=small}
![[Mod] NeunEinser](../../../data/avatars/users/39263.png){kind=small}
is blocked by
Invalid as per
MC-129127?Can no longer be reproduced because of the intended change described in
MC-129127.Also, placing another tripwire hook behind it does cause an update.