When running /testforblock on iron bars, fences or panes the result is not as expected.
As can be seen in the attachment, I ran
/testforblock ~1 ~ ~ minecraft:iron_bars east=false
and
/testforblock ~1 ~ ~ minecraft:iron_bars east=true
directed at an iron_bars block with the block state east=true,north=false,west=false,south=false
What I expected to happen was the first command to NOT find the block and the second command to do find the block.
Instead, the opposite happened. The first command resulted in the block being found, despite the block state for "east=" not matching my criteria. The second command resulted in the block not being found, giving the message:
"The block at -144, 67, -125 had the data value of minecraft:iron_bars[east=false,north=false,south=false,west=false] (expected: east=true)"
Note: I was told to make an issue separate from MC-109353 even though both bugs seem similar.
Affected blocks
Last updated for 1.11.2
Blockstates | Properties |
---|---|
bed[part=foot] | occupied 1 |
chorus_plant | north, east, south, west, up, down |
dirt[variant=podzol], grass, mycelium | snowy |
wooden_door[half=lower], iron_door[half=lower] | hinge, powered |
wooden_door[half=upper], iron_door[half=upper] | facing, open |
all fences | north, east, south, west |
all fence gates | in_wall |
fire | north, east, south, west, upper |
flower_pot | contents |
iron_bars, glass_pane, stained_glass_pane | north, east, south, west |
powered_repeater, unpowered_repeater | locked |
redstone_wire | north, east, south, west |
all stairs | shape |
pumpkin_stem, melon_stem | facing |
tripwire | north, east, south, west |
vine | up |
cobblestone_wall | north, east, south, west, up |
1 If the occupied
property of the foot part is false
, but the head part true
Code analysis
For flower pots, see MC-109353
Related issues
is duplicated by
Attachments
Comments


Confirmed, seems like they don't save that block state to the region, as structure files also don't see difference between a fence aiming south and one making a north east corner.

Confirmed for 17w17b

Confirmed in 1.12, and also confirmed for the detect block state of an execute...detect... command. Seems like there's just no knowledge of these block states except for rendering purposes.

I'm the developer of the Nova Renderer and I've run into a variant of this issue. For the block states listed on this issue, the IBakedModel registered to the BlockShapedMapper has no BakedQuads. I'm using MCP 9.30 for Minecraft 1.10.