mojira.dev
MC-109353

Detecting the block states of flower_pots doesn't work

When running /testforblock on a flower_pot with a block state for "contents", the flower pot does not work as expected. The same applies to /execute's detect function.

I expected this command to return positive when standing on a flowerpot with a rose in it:

/testforblock ~ ~ ~ flower_pot contents=rose

Instead, the flowerpot is only detected when contents=empty is used, even though F3 shows the contents blockstate to be "rose".

It gets stranger. After relogging, contents=empty no longer works... but nor does contents=rose. In fact, only contents=cactus runs successfully. F3 still shows the actual blockstate as being "contents=rose".

Code analysis

The following is based on a decompiled version of Minecraft 1.10 using MCP 9.30.

The problem might be that the only method which returns a block state with the correct contents is net.minecraft.block.BlockFlowerPot.getActualState(IBlockState, IBlockAccess, BlockPos) which appears to be called only client-side. It looks like in all other situations the state is received from the meta data, but as the contents property is not written to the meta data because it has more than 16 possible values, the server will very likely return that the contents property of the flower pot has the value empty.

Note: Not sure what causes the cactus part after reload.

Related issues

Comments

Pepijn96

I'm having the same problem with iron bars and fences, the east=,north=, etc states always seem to return false even when they're not. Unless I'm doing something completely wrong of course. I didn't make a new report because I figured my problem is too similar to this one, excuse me if I'm wrong.

Image showing the problem:
(http://image.prntscr.com/image/223d640e151c481fac3ebd0ab6899c5a.png)

Version: Minecraft 16w44a
OS: Windows 10

migrated

Please make a different report for panes and bars.

migrated

Resolving to more detailed MC-109591, the cause is the same: not saved in meta data. (Plus it already got marked as postponed by a dev).
(@unknown Sorry for the trouble, I thought that there was a different cause behind them, turns out there's not.)

migrated

(Unassigned)

Confirmed

Minecraft 16w43a

Retrieved