MC-87799/execute detect functions inconsistently with semi- (snow layer, grass path, soul sand, farmland) blocks
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 Marcono1234 can be found in this comment.
Linked Issues
Created Issue:
/execute detect functions inconsistently with semi- (snow layer, grass path) blocks
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
I have not tested this with farmland as of yet.
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).
Environment
Windows 10, Java 8 Update 60
Attachments2
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
I have not tested this with farmland as of yet.
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).
relates to
![[Mod] Michael Wobst](../../../data/avatars/users/37868.png){kind=small}
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
I have not tested this with farmland as of yet.
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).
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
I have not tested this with farmland as of yet.
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 Marcono1234 can be found in this comment.
/execute detect functions inconsistently with semi- (snow layer, grass path, soul sand, farmland) blocks
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
I have not tested this with farmland as of yet.
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 Marcono1234 can be found in this comment.
is duplicated by
is duplicated by
Windows 10, Java 8 Update 60
![[Mod] Neko](../../../data/avatars/users/92901.png){kind=small}
The bug
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.
In 1.8 most of the commands use the BlockPos getPosition() method of the command sender (net.minecraft.command.ICommandSender interface). Operating with block positions creates lot of problem like MC-97316 which was luckely fixed. Most problematic in this context is the public static BlockPos func_175757_a(ICommandSender sender, String[] args, int p_175757_2_, boolean p_175757_3_) throws NumberInvalidException method of the net.minecraft.command.CommandBase class. Using this method you convert the position to a block position (ints) offset the block position (doubles) and then create a block position (ints) again.
Example
- Player is standing at x = 0.7
- Stone block is at block position 1 (middle is at x = 1.5)
- Player is using the following command
/testforblock ~ ~ ~0.5
This is what happens when the implementation of the net.minecraft.entity.player.EntityPlayerMP (x, y + 0.5, z) class is used
- Coordinate to block position: x = 0
- Coordinate: 0 + 0.5 = 0.5
- Coordinate to block position: x = 0
The command fails even though the block is only 0.3 metres away
Besides that there is also a lot inconsistency. The following table shows how the different classes implement the BlockPos getPosition() method. "x + 0.5" means that 0.5 is added to the x coordinate before it is converted to a block position. Not being ticked means that this class uses the value without adding 0.5.
| Class | x + 0.5 | y + 0.5 | z + 0.5 |
|---|---|---|---|
| net.minecraft.client.entity.EntityOtherPlayerMP |  |
|
|
| net.minecraft.client.entity.EntityPlayerSP | |
|
|
| net.minecraft.command.CommandExecuteAt ( |
 |
|
|
| net.minecraft.entity.player.EntityPlayerMP | |
|
|
| net.minecraft.entity.Entity | |
|
|
| net.minecraft.entity.EntityMinecartCommandBlock | |
|
|
(Based on Minecraft 1.8)
My suggestion would be to remove the BlockPos getPosition() method completely and use the Vec3 getPositionVector() method instead.
How to reproduce
- Use the following command
/tp 0.7 ~ ~ -90 0
- Use the following command
/setblock ~0.5 ~ ~ stone
Even though 0.7 + 0.5 = 1.2 (x block position 1) the block is placed at your position (x block position 0)
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
That's good to know for my quicksand build, but I'm not sure if that makes it less of a bug.
Confirmed for
/testforblock centers on the block when using relative coordinates (0.5, 0.5, 0.5), detect seems not to do that
So as workaround you could use /testforblock for now
Confirmed for
The problem seems to be rather with the /execute command, but I could not find the reason
How to reproduce
It should succeed
It fails
Why is this intended?
the reason is because you are standing in the space of the block, not a space above itReopening 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