Signs and carpet do not drop when the underlying block is moved by piston
The bug
Signs and carpet does not drop when the underlying block is moved by a piston.
This may be intended given that MC-17851 was fixed (though possibly not on purpose), however it is inconsistent with other blocks which require a supporting block. These blocks do drop when the supporting block is moved, even if the new block at that position would support them as well.
See the attached Inconsistent dropping behavior.mp4
showing a setup for reproducing this and outlining the inconsistency.
Linked Issues
is duplicated by3
relates to3
MC-5621Blocks like redstone dust, repeaters, doors, and levers don't drop when the underlying block is pushed by a pistonFixedMC-17851Blocks requiring any support block (carpets, signs) placed on piston head break when sticky piston retractsFixedMC-19403Carpets can be placed on the rod of sideways pistons, but break when the piston retractsDuplicate![[Mod] Avoma](../../../data/avatars/users/86198.png){kind=small}
- Works As Intended
Marcono1234
Alex Boros- 10
- 13
- Confirmed
- Block states
- carpet moving_piston piston sign
1.4.6 - 1.20.1
1.4.6 1.4.7 13w04a 13w05a 1.12 1.12.1 1.12.2 17w50a 1.13 18w31a 1.13.1 1.13.2 18w47a 18w47b 18w48a 18w48b 18w49a 18w50a 19w02a 1.15.1 1.15.2-pre1 1.15.2-pre2 1.15.2 20w06a 20w07a 20w08a 20w09a 20w10a 20w11a 20w12a 20w13a 20w13b 20w14a 20w15a 20w16a 20w17a 20w18a 20w19a 20w20b 20w21a 20w22a 1.16-pre1 1.16-pre2 1.16-pre3 1.16-pre4 1.16-pre5 1.16-pre7 1.16-rc1 1.16 1.16.1 20w27a 20w28a 20w29a 20w30a 1.16.2-pre1 1.16.2-pre2 1.16.2-rc1 1.16.2-rc2 1.16.2 1.16.3-rc1 1.16.3 1.16.4-pre1 1.16.4-pre2 1.16.4-rc1 1.16.4 20w45a 20w46a 20w48a 20w49a 20w51a 21w03a 1.16.5 21w05a 21w05b 21w06a 21w07a 21w08b 21w10a 21w11a 21w13a 21w14a 21w15a 21w16a 21w17a 21w18a 21w19a 21w20a 1.17-rc2 1.17 1.17.1 1.18.1 1.18.2 1.19 1.19.2 1.19.3 1.20-rc1 1.20 1.20.1
duplicates
![[Mod] Ezekiel (ezfe)](../../../data/assets/gravatar/ezekielelin.jpeg){kind=small}
![[Mod] Michael Wobst](../../../data/avatars/users/37868.png){kind=small}
duplicates
Windows8: java10 update7 64bit
Piston break signSigns do not drop when the underlying block is pushed with piston
Signs do not drop when the underlying block is pushedwithpistonSigns do not drop when the underlying block is pushed by piston
relates to
MC-56211
relates to
Signsdonot drop when the underlying block ispushed by pistonSigns and carpet does not drop when the underlying block is moved by piston
The bug
Signs and carpet does not drop when the underlying block is moved by a piston (only exception is
MC-17851).
relates to
Signs and carpet doesnot drop when the underlying block is moved by piston
![[Mod] violine1101](../../../data/avatars/users/92858.png){kind=small}
relates to
![[Mod] bemoty](../../../data/avatars/users/50554.png){kind=small}
![[Mojang] Nathan Adams](../../../data/assets/gravatar/dinnerbone.png){kind=small}
![[Mod] SPGoding](../../../data/avatars/users/44622.png){kind=small}
![[Helper] Jack McKalling](../../../data/avatars/users/92859.png){kind=small}
The bug
Signs and carpet does not drop when the underlying block is moved by a piston (only exception is
MC-17851).The bug
Signs and carpet does not drop when the underlying block is moved by a piston.
This may be intended given that
MC-17851was fixed (though possibly not on purpose), however it is inconsistent with other blocks which require a supporting block. These blocks do drop when the supporting block is moved, even if the new block at that position would support them as well.See the attached Inconsistent dropping behavior.mp4
1.png
is duplicated by
![[Mod] NeunEinser](../../../data/avatars/users/39263.png){kind=small}
is duplicated by
![[Mod] Chandler](../../../data/assets/gravatar/triwonder81.png){kind=small}
![[Helper] Johnibur](../../../data/avatars/users/28381.png){kind=small}
relates to
relates to
![[Mojang] slicedlime](../../../data/assets/gravatar/slicedlime.jpeg){kind=small}
![[Mod] LateLag](../../../data/avatars/users/92884.png){kind=small}
is duplicated by
![[Mod] ampolive](../../../data/avatars/users/18949.svg){kind=small}
![[Mojang] Maxime Lebrot](../../../data/avatars/users/18941.svg){kind=small}
The bug
Blocks requiring any support block, like carpets or signs, normally do not drop when the supporting block is moved (see MC-8836 which may be intended), however they do break when the supporting block is the piston head which retracts even though a different block is pulled beneath them.
For carpets this happens as well when the carpet itself is moved because it is on top of an upwards facing piston.
See also the attached video Carpets and signs dropping when supporting piston head retracts.mp4.
How to reproduce
- Place an upwards facing sticky piston
- Place a carpet on top
- Power the piston
→ The carpet drops - Now place a slime block between the piston and carpet
- Power the piston
→ The carpet does not drop as expected
Code analysis
Based on 1.11.2 decompiled using MCP 9.37
The problem is that the methods BlockPistonBase.eventReceived(IBlockState, World, BlockPos, int, int) and BlockPistonBase.doMove(World, BlockPos, EnumFacing, boolean) update neighboring blocks when setting blockstates.
Suggested fix
Note: It would be good if someone familiar with expected piston behavior and their use in farms or slime block machines could verify that this fix solves this problem as expected.
/** * Called on both Client and Server when World#addBlockEvent is called. On the Server, this may perform additional * changes to the world, like pistons replacing the block with an extended base. On the client, the update may * involve replacing tile entities, playing sounds, or performing other visual actions to reflect the server side * changes. */ public boolean eventReceived(IBlockState state, World worldIn, BlockPos pos, int id, int param) { EnumFacing enumfacing = (EnumFacing)state.getValue(FACING); // ... if (id == 0) { // ... } else if (id == 1) { // ... // Comment: Replaced this // worldIn.setBlockState(pos, Blocks.PISTON_EXTENSION.getDefaultState().withProperty(BlockPistonMoving.FACING, enumfacing).withProperty(BlockPistonMoving.TYPE, this.isSticky ? BlockPistonExtension.EnumPistonType.STICKY : BlockPistonExtension.EnumPistonType.DEFAULT), 3); worldIn.setBlockState(pos, Blocks.PISTON_EXTENSION.getDefaultState().withProperty(BlockPistonMoving.FACING, enumfacing).withProperty(BlockPistonMoving.TYPE, this.isSticky ? BlockPistonExtension.EnumPistonType.STICKY : BlockPistonExtension.EnumPistonType.DEFAULT), 2); worldIn.setTileEntity(pos, BlockPistonMoving.createTilePiston(this.getStateFromMeta(param), enumfacing, false, true)); if (this.isSticky) { // ... if (!flag1 && iblockstate.getMaterial() != Material.AIR && canPush(iblockstate, worldIn, blockpos, enumfacing.getOpposite(), false) && (iblockstate.getMobilityFlag() == EnumPushReaction.NORMAL || block == Blocks.PISTON || block == Blocks.STICKY_PISTON)) { this.doMove(worldIn, pos, enumfacing, false); } // Comment: Added this else { worldIn.setBlockToAir(pos.offset(enumfacing)); } } else { worldIn.setBlockToAir(pos.offset(enumfacing)); } worldIn.playSound((EntityPlayer)null, pos, SoundEvents.BLOCK_PISTON_CONTRACT, SoundCategory.BLOCKS, 0.5F, worldIn.rand.nextFloat() * 0.15F + 0.6F); } return true; }
private boolean doMove(World worldIn, BlockPos pos, EnumFacing direction, boolean extending) { if (!extending) { // Comment: Replaced this // worldIn.setBlockToAir(pos.offset(direction)); worldIn.setBlockState(pos.offset(direction), Blocks.AIR.getDefaultState(), 2); } // ... }
Thank you for your report!
However, we are already tracking this issue, and this report is a Duplicate of MC-8836, which is a report that has not been resolved yet.
If you want, you can upvote the parent ticket, and enable watching to receive any updates about it - if you believe you have any information that may be important for this issue, please leave a comment on the parent. Please also use the search function in the future to prevent duplicate reports.
Quick Links:
📓 Issue Guidelines – 🛠 Community Support – 📧 Customer Support – ✍️ Feedback and Suggestions – 📖 Game Wiki
💬 Mojira Subreddit – 💬 Mojira Discord
![[Mod] markderickson](../../../data/avatars/users/18946.svg){kind=small}
Hi there!
This looks like a duplicate of MC-8836.
Duplicate of MC-8836
Duplicate ofMC-3287.Confirmed for 1.12.1
Confirmed for 1.13.1.
Cannot reproduce in 18w47b
[~Awesoman3000], I still can reproduce for 18w47b.
I tested all possibilities more extensively, and I've come to a different outcome than I expected. While assuming the sticky piston is always setup to immediately push against a solid block, and the sign and carpet is attached to that block, the following happens.
When the sticky piston is placed to extend upwards before powering:
On extend, sign will stay but carpet moves up with the solid block
On retract, sign will still stay but carpet drops because it's not attached to a solid block anymore
When the sticky piston is placed and powered to extend upwards:
On retract, sign and carpet both will pop off
When the sticky piston is placed to extend sideways before powering:
On extend, sign and carpet both will stay put
On retract, sign and carpet both will stay put
When the sticky piston is placed and powered to extend sideways:
On retract, sign and carpet both will pop off
With these results, I'm not sure anything is broken here.
Still an issue in pre-7.
Removed the old screenshot attachments since they were in part describing
MC-17851, which was slightly misleading. Instead attached a video showing the inconsistency.Now following the video clip, I see what is wrong, and it still happens.
Can confirm in 1.18.1.
Can confirm in 1.18.2.
Can confirm in 1.19.
Can confirm in 1.19.2.
the reason for this is that carpets and signs do not require supporting faces, which the moving_piston block does not have. most other support blocks need full faces, so when the sandstone is turned into moving_piston, it no longer has a solid face to anchor to.