[MCPE-11410] When water or lava comes in contact with a sign, it breaks the sign Created: 06/Nov/15  Updated: 16/Dec/15  Resolved: 08/Dec/15

Status: Resolved
Project: Minecraft (Bedrock codebase)
Component/s: None
Affects Version/s: 0.13.0 Beta 1, 0.13.0 Beta 5, 0.13.0
Fix Version/s: Future Release

Type: Bug
Reporter: Manuel Lagarto
Resolution: Fixed Votes: 17
Labels: None

Issue Links:
Duplicate
is duplicated by MCPE-11438 My signs can't block water anymore... Resolved
is duplicated by MCPE-11445 Water breaks signs Resolved
is duplicated by MCPE-11447 Wall signs get destroyed by water lik... Resolved
is duplicated by MCPE-11520 Los carteles no detienen los flujos d... Resolved
is duplicated by MCPE-11572 The signs no longer hold water flows Resolved
is duplicated by MCPE-11602 Signs on walls Resolved
is duplicated by MCPE-11657 Water And Signs Resolved
is duplicated by MCPE-11671 los carteles se rompen al contacto co... Resolved
is duplicated by MCPE-11697 The flowing water can break signs Resolved
is duplicated by MCPE-11772 Water elevator and sign... Resolved
is duplicated by MCPE-11773 Water elevator and sign... Resolved
is duplicated by MCPE-11784 Water Destroys Signs Resolved
is duplicated by MCPE-11797 Sign will be destroyed by water when ... Resolved
is duplicated by MCPE-11862 Signs do not stop water instead they ... Resolved
is duplicated by MCPE-11884 Water removes the posters when touche... Resolved
is duplicated by MCPE-12005 signs broken by water Resolved
is duplicated by MCPE-12036 water breaks signs Resolved
is duplicated by MCPE-12052 Signs Resolved
Confirmation Status: Confirmed
Platform: Android
CHK:

 Description   

BUG !!!: When water or lava is in contact with a sign, the sign break up. Please fix it because my farms need this system.

My device is Wiko Rainbow Jam.

Steps to duplicate
-Dig down 3 blocks.
-Place sign on the wall of the 2nd block down.
-Place water or lava above the sign (1st block down.)
The water or lava should be held up by the sign but the sign breaks.



 Comments   
Comment by PHO [ 16/Dec/15 ]

Fixed in 0.13.1. Thanks.

Comment by [Mojang] MissMarzenia (Aleksandra Zajac) [ 08/Dec/15 ]

This issue will be patched in future release. We do not currently have a date.

Comment by PHO [ 20/Nov/15 ]

Yes, that is an interesting part of the glitch. Signs placed on a wall before upgrading to 0.13.0 don't break as long as they don't receive a block update, even if they receive block ticks

Comment by Justin Nicolay [ 20/Nov/15 ]

Any of my current worlds using this setup seem to function as intended, but any newly placed signs do not function correctly and get washed away.

Comment by Namitha Kumar [ 20/Nov/15 ]

Yes this still affects 0.13.0 official release.

Comment by evenvertex [ 20/Nov/15 ]

can confirm on windows phone 8.1 , on 0.13 official release

Comment by B Boyes [ 19/Nov/15 ]

Now confirmed for water touching signs in 0.13.0 on iOS 9.1 too (iPad 3).

Signs now behave like torches if placed on the side of a block for source or flowing water; breaking as soon as the sign is placed. When placed on the top of a block (a free standing sign) the water is held back as expected.

Comment by Samuel Visser [ 14/Nov/15 ]

Confirmed on Samsung Galaxy S5 Android 5.0.
This really is critical, most farming systems in Minecraft really need signs to hold back water and lava. Please fix this before the official release.
MCPE 0.13.0 build 5

Comment by Tavish McEwen [ 13/Nov/15 ]

No, lava can start a fire on the sign of there is an available air block, but otherwise it will hold it back. Besides, there is still water to deal with.

Comment by Arjho Janvir Rosario [ 13/Nov/15 ]

This is not a bug,its normal while you put in lava it naturally burned

Comment by Tavish McEwen [ 08/Nov/15 ]

Confirmed for 0.13.0 build 3 (Android 5.1.1)

Comment by Travis Strang [ 08/Nov/15 ]

Confirmed on Samsung Galaxy S4 running Cyanogenmod 12.1 (Android 5.1.1)
MCPE 0.13.0 full release.

Comment by AMAN4700 [ 07/Nov/15 ]

Confirmed on Samsung Galaxy Note 5. Android 5.1.1 Version: 0.13.0 Build 3

Generated at Sat Jan 11 14:52:01 UTC 2025 using Jira 9.12.2#9120002-sha1:301bf498dd45d800842af0b84230f1bb58606c13.