When experimenting with the new command blocks I noticed that blocks that are not full or "normal" blocks function highly inconsistently when using a /execute command with the detect function inside a repeating command block or on a redstone clock.
The command I used was the following:/execute @e[r=20] ~ ~ ~ detect ~ ~-1 ~ <block here> 0 /effect @e[r=20] slowness 1 1 1
Stone, Sandstone, dirt, and other normal blocks work; the execute command will trigger every tick when in a repeating command block or every time redstone triggers a normal impulse block
Grass Path blocks (
/execute @e[r=20] ~ ~ ~ detect ~ ~-1 ~ grass_path 0 /effect @e[r=20] slowness 1 1 1) will trigger once when the player steps on the block, but will not trigger again until the player steps off the block, where it'll trigger again
The attached pictures show how the slowness effect remains while on a full block (stone), but do not when on a semi-block (grass paths).
Code analysis by @unknown can be found in this comment.
Attachments
Comments 15
That's good to know for my quicksand build, but I'm not sure if that makes it less of a bug.
Confirmed for
15w36d This is a valid bug,
detectacts indeed different from/testforblock/testforblockcenters on the block when using relative coordinates (0.5, 0.5, 0.5),detectseems not to do that
So as workaround you could use /testforblock for now
Confirmed for
15w37a
The problem seems to be rather with the /execute command, but I could not find the reason
How to reproduce
Stand on soul sand
Run this command
/testforblock ~ ~ ~ airIt should succeed
Run this command
/execute @p ~ ~ ~ /testforblock ~ ~ ~ airIt fails
Why is this intended?
the reason is because you are standing in the space of the block, not a space above it
Reopening due to Marcono's explanation.
Confirmed for 1.9
Please link to this comment in the description of the report.
The following is based on decompiled version of Minecraft 1.8 using MCP. All method and class names are the names used in the decompiled version.
The reason why this happens is that the net.minecraft.client.entity.EntityOtherPlayerMP class implements the public BlockPos getPosition() differently than the anonymous ICommandSender created by the net.minecraft.command.CommandExecuteAt class.
The net.minecraft.client.entity.EntityOtherPlayerMP class offsets the x, y and z coordinate by +0.5, the anonymous ICommandSender created by the net.minecraft.command.CommandExecuteAt class does not. What the execute command is doing might be a little bit better as it selects nearly (debug screen uses minimum of bounding box whereas probably all other methods use y coordinate) the same block shown in the debug menu for Block.
Edit: This is likely partwise wrong because net.minecraft.client.entity.EntityOtherPlayerMP is a client-side only class.
Still in 1.9.1-pre1
Still in 1.9.1-pre3
Still in 1.9.3-pre3
never had this problem for pre or 1.9 releases you might have to use minecraft:itemname since that is required in most commandblocks commands and ingame text commands now and in 1.9 so your command should look like this
/execute @e[r=20] ~ ~ ~ detect ~ ~-1 ~ <minecraft:snow_layer> 0 /effect @e[r=20] slowness 1 1 1
/execute @e[r=20] ~ ~ ~ detect ~ ~-1 ~ <minecraft:snow> 0 /effect @e[r=20] slowness 1 1 1
minecraft:snow is a full snow block and minecraft:snow_layer is a layer of snow and did test this in the version said and worked fine without it being fixed in those versions.
The namespace is not required; please read the report before commenting.
This appears to be fixed in 17w45b and possibly also earlier versions above 1.12.2
The reason for this is probably that these blocks are lower. When you are stepping on them you are for a short moment above them and it successfully finds it. After that you are too low and it will test for the block 2 blocks below you