Commands which act based on block grid use decimal numbers instead of integers
The bug
Based on MC-105820 commands which modify blocks or get data from them use the block grid instead of the position of the command executor. This causes values from 0 up to 1 (exclusive) to select the block the command executer is in, while -1 to 0 (exclusive) selects the block in the negative direction. This behavior was stated as WAI by [Mojang] Grum (Erik Broes). The problem is that as these commands allow decimal values you would expect them to be based on the position of the command executor.
To make it clearer that this is not how it works, it might be more intuitive to allow only integers as coordinates (relative as well).
Affected commands
- /fill
- /setblock
- /blockdata
- /testforblock
- /testforblocks
- /stats block
- /replaceitem block
Created Issue:
Commands which act based on block grid and not player position use decimal numbers instead of integers
The bug
Based on
MC-105820commands which modify blocks or get data from them use the block grid instead of the position of the command executer. This causes values from 0 up to 1 (exclusive) to select the block the command executer is in, while -1 to 0 (exclusive) selects the block in the negative direction. This behavior was stated as WAI by [Mojang] Grum (Erik Broes). The problem is that as these commands allow decimal values you would expect them to be based on the position of the command executer.To make it clearer that this is not how it works, it might be more intuitive to allow only integers as coordinates (relative as well).
Affected commands
- /fill
- /setblock
- /blockdata
- /testforblock
- /testforblocks
- /stats block
- /replaceitem block
Commands which act based on block gridand not player positionuse decimal numbers instead of integers
The bug
Based on
MC-105820commands which modify blocks or get data from them use the block grid instead of the position of the command executer. This causes values from 0 up to 1 (exclusive) to select the block the command executer is in, while -1 to 0 (exclusive) selects the block in the negative direction. This behavior was stated as WAI by [Mojang] Grum (Erik Broes). The problem is that as these commands allow decimal values you would expect them to be based on the position of the command executer.To make it clearer that this is not how it works, it might be more intuitive to allow only integers as coordinates (relative as well).
Affected commands
- /fill
- /setblock
- /blockdata
- /testforblock
- /testforblocks
- /stats block
- /replaceitem block
Note: To not break existing commands there should maybe be a transition period.
The bug
Based on
MC-105820commands which modify blocks or get data from them use the block grid instead of the position of the command executer. This causes values from 0 up to 1 (exclusive) to select the block the command executer is in, while -1 to 0 (exclusive) selects the block in the negative direction. This behavior was stated as WAI by [Mojang] Grum (Erik Broes). The problem is that as these commands allow decimal values you would expect them to be based on the position of the command executer.To make it clearer that this is not how it works, it might be more intuitive to allow only integers as coordinates (relative as well).
Affected commands
- /fill
- /setblock
- /blockdata
- /testforblock
- /testforblocks
- /stats block
- /replaceitem block
Note: To not break existing commands there should maybe be a transition period.
relates to
The bug
Based on
MC-105820commands which modify blocks or get data from them use the block grid instead of the position of the command executer. This causes values from 0 up to 1 (exclusive) to select the block the command executer is in, while -1 to 0 (exclusive) selects the block in the negative direction. This behavior was stated as WAI by [Mojang] Grum (Erik Broes). The problem is that as these commands allow decimal values you would expect them to be based on the position of the command executer.To make it clearer that this is not how it works, it might be more intuitive to allow only integers as coordinates (relative as well).
Affected commands
- /fill
- /setblock
- /blockdata
- /testforblock
- /testforblocks
- /stats block
- /replaceitem block
The bug
Based on
MC-105820commands which modify blocks or get data from them use the block grid instead of the position of the command executor. This causes values from 0 up to 1 (exclusive) to select the block the command executer is in, while -1 to 0 (exclusive) selects the block in the negative direction. This behavior was stated as WAI by [Mojang] Grum (Erik Broes). The problem is that as these commands allow decimal values you would expect them to be based on the position of the command executor.To make it clearer that this is not how it works, it might be more intuitive to allow only integers as coordinates (relative as well).
Affected commands
- /fill
- /setblock
- /blockdata
- /testforblock
- /testforblocks
- /stats block
- /replaceitem block
relates to
Commands which act based on block grid use decimal can proven to be useful
e.g.
execute @a ~ ~ ~ detect ~0.3 ~-0.01 ~ air 0
execute @a ~ ~ ~ detect ~-0.3 ~-0.01 ~ air 0
execute @a ~ ~ ~ detect ~ ~-0.01 ~0.3 air 0
execute @a ~ ~ ~ detect ~ ~-0.01 ~-0.3 air 0
can detect if player is falling (if all returns true)
changing it to integer would make this type of command ineffective in many circumstances.
i won't recommend changing it.
p.s. OnGround:0b tag would not work,since it updates every second.
Now intended, as of 17w45a.
correction, according to dinnerbone in the commands discord, it should work with relative decimals.