mojira.dev
MC-157300

Trapdoors can support some blocks when open

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:

  1. Place a trap door down in the 'open=false' and 'half=top' blockstate

  2. Place down one of the affected blocks in the "Notes" section on top of the trapdoor

  3. 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:

  1. Related to other supporting block issues:
    MC-92758 MC-264563 MC-148202 MC-222212 MC-213638

  2. Standing 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

Attachments

Comments

RedCMD

Opening a trapdoor should give a single block update in the direction of which the top face was facing

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.

Alexander Ram

Can confirm in release 1.18. Would also like to make the following notes:

  1. (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.

  2. (Screenshot 16.21.38): This still applies with waterlogged trapdoors, and also applies to any kind of trapdoor.

  3. (Screenshot 16.13.22): Updating the trapdoor does not remove the redstone wire even with power.

  4. (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.

  5. (Screenshot 16.29.50): The issue is independent of orientation, as long as [half=top].

  6. (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).

  7. (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

NguyenFranky

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.

user-f2760

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

N/A

[Mod] Jingy

(Unassigned)

Confirmed

Platform

Normal

Block states

placement-and-support, rails

1.14.4, 19w41a, 1.15.2, 20w11a, 1.16.1, ..., 1.20.3, 1.20.4, 24w09a, 1.20.5, 1.21

Retrieved