-
Bug
-
Resolution: Duplicate
-
None
-
Minecraft 16w43a
-
None
-
Windows 7
-
Confirmed
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.
- duplicates
-
MC-109591 Detecting the block states not saved in meta data does not work
- Resolved