All rail types can be supported by trapdoors even when the trapdoor is open. This used to affect redstone repeaters, wire, and comparaters, but no longer does.
Steps to Reproduce:
Place a trap door down in the 'open=false' and 'half=top' blockstate
Place down one of the affected blocks in the "Notes" section on top of the trapdoor
Open the trapdoor with your hand, or redstone
Observed Results:
The block will not break, but instead float above the (mostly) empty supporting block.
Expected Results:
The block would break as there is no block beneath it to support it properly.
Screenshots/Videos:
[media]Notes:
Related to other supporting block issues:
MC-92758 MC-264563 MC-148202 MC-222212 MC-213638Standing signs and banners were added to this issue, but later removed, as they were not part of the original issue, and have unique placement behavior unrelated to rails (the last affected block).
Original Description:
(The original description of the issue when it was triaged, by @unknown)
When a trapdoor is in the flat form (Closed) it is possible to place rails on them. This would be fine except that you can then open the trapdoor and still have the rail on top of it. This is a fully functional rail, however when the block is updated by anything other than the rail, it pops off as it should directly after the trapdoor is opened. Attached is a video showing everything I have described.
This also applies to e.g. redstone dust and repeaters. Other blocks like torches do pop off though
Linked issues
is duplicated by
MC-165428
Trapdoor glitch
MC-167961
Redstone components on trapdoor doesn't get destroyed
MC-177008
Trapdoors do not update some blocks above when opened manually
MC-181928
Redstone & Trapdoor
MC-194547
Rails on top half trapdoors do not break if the trapdoor below them opens
MC-231068
Rails Float on Trapdoors
MC-259403
Redstone dust stays on trapdoor when closed
Attachments
Comments
RedCMD
NeunEinser
Also applies to e.g. redstone dust and repeaters. Some blocks like torches do pop off though.
Avoma
Can confirm in 20w51a. I've attached a screenshot.
Avoma
Can confirm in 21w03a.
Avoma
Can confirm in 21w06a.
Avoma
Can confirm in 1.16.5 and 21w08b.
Avoma
Can confirm in 21w15a.
ampolive
Can confirm in 1.17.1 Release Candidate 1.
ampolive
Also affects item frames and paintings, but that is probably intended.
ampolive
Can confirm in 21w44a.
migrated
Can confirm in release 1.18. Would also like to make the following notes:
(Screenshots 16.16.37, 16.16.45): The redstone wire can be updated but only in certain ways. For example, this setup does not destroy the redstone, but removing the torch or repeater does. Note that placement order does matter; the redstone wire must be placed first. Subsequent ordering of the other two components is not important.
(Screenshot 16.21.38): This still applies with waterlogged trapdoors, and also applies to any kind of trapdoor.
(Screenshot 16.13.22): Updating the trapdoor does not remove the redstone wire even with power.
(Screenshots 16.14.32, 16.15.26): While in many cases removing the torch from the system (see note 1 above) will cause the redstone wire to break, this setup does not. See details below.
(Screenshot 16.29.50): The issue is independent of orientation, as long as [half=top].
(Screenshots 16.58.31, 16.58.36, 17.01.46): Using /setblock the trapdoors can be modified. What may be worthy of note is that some instances of /setblock will break the wire and some will not. Initially, let the right trapdoor be attributed [facing=south,half=top,open=false,powered=false,waterlogged=false]. When using /setblock to change the corresponding attributes to [facing=east,open=false] (first screenshot). This does not break the redstone wire. When attributing [facing=south,open=true] after the first command, it breaks both wires (second screenshot). When doing this independently of the first command, it breaks only the wire above the modified trapdoor (third screenshot).
(No screenshots): This is confirmed to work in singleplayer and multiplayer.
Avoma
Can confirm in 1.18.1.
Avoma
Can confirm in 1.18.2.
Avoma
Can confirm in 1.19.
Brain81505
Can confirm in 23w04a
Brain81505
Can confirm in 23w05a
Brain81505
Can confirm in 23w06a
Brain81505
Can confirm in 1.19.4 and 23w16a
migrated
Can confirm in 1.20
[Mod] Jingy
Requesting ownership of this issue has it is outdated, and needs to be updated. I would also like to maintain it going forward.
migrated
Are signs really an issue here? They can be placed on top of bottom slabs too, heck wall signs can be placed on other wall signs with the same facing state. They never consider the block states of their supporting block.
[Mod] Jingy
Fair point. Noteworthy that banners also share the same behavior as standing signs (being placeable on top of other blocks which one would think doesn't support it).
Rails were the last affected block affected by this behavior in the original issue, so I can remove banners and standing signs if that's considered seperate behavior. I've added the original description to the issue for clarity.
Brain81505
Can confirm in 1.21
[Mod] Jingy
Opening a trapdoor should give a single block update in the direction of which the top face was facing