Illustrative example:
Objectives previously added include xPos and is set to 0 to initiate its scoreboard tracking.
In a mcfunction, running the following lines every tick in a mcfunction via gamerule gameLoopFunction
execute @a ~ ~ ~ stats entity @a set AffectedBlocks @s xPos
execute @a ~ ~ ~ testforblocks ~ ~ ~ 0 ~ ~ 0 ~ ~
execute @a ~ ~ ~ title @s actionbar ["",{"text":"x= ","color":"dark_green"},{"score":{"name":"@a","objective":"xPos"},"color":"dark_green"}]
So long as the player is in the positive x-axis half of the world, AffectedBlocks testforblocks consistently and reliably returns a proper x-axis block count.
When the player stands in the negative x half of the world, AffectedBlocks testforblocks intermittently correctly counts the blocks in the x coordinates, and intermittently incorrectly returns a 1 or a 0.
The same is true for z coordinates. It is not relevant for y as there are no negative y coordinates to contend with in play.
See attached screen shot illustration of this occurring.
Attachments
Comments 7
Hi FVbico, see my revision, I left out the testforblocks line in my illustration, so maybe it didn't make sense to you.
Hi FVbico, see my revision, I left out the testforblocks line in my illustration, so maybe it didn't make sense to you.
This is still invalid, even when updating to the new 1.13 command formats. Here is what your testforblocks command is doing:
p=player
b=block
x=0 on x-axis
Area being checked:pbbbbbx
Area being matched:pbbbbbx
Area being checked: xbbbbbbp
Area being matched:bbbbbbbx
Testforblocks always uses the lowest value for the starting corner of the check and the largest value for the end corner of the check. If the player is on the positive x axis, then your x value is used as the end corner. If your x value is on the negative x-axis, then your x value is used as the starting corner. That is why this is invalid.
Hi Aaron,
Thank you for trying to explain it. It doesn't still explain why sometimes testforblocks works in the negative x, and sometimes doesn't. See the attached screenshot captured during a period when the script as above was working as intended, blocks from 0 in the negative x axis. Why does it intermittently work if it shouldn't work at all? Thanks.
It will still work if the check area is the same as the area being matched. In your screenshot, the area from x=-4 to x=0 must match the area from x=0 to x=4 if the command is working as expected. I know all of this because I made a setup like this already and went through the testing. I also had to leave yesterday so a few details got left out of my explanation. I should also mention that it isn't just negative values that cause this behavior. In your command,
/execute @a ~ ~ ~ testforblocks ~ ~ ~ 0 ~ ~ 0 ~ ~/execute @a ~ ~ ~ testforblocks ~ ~ ~ 0 ~ ~ 0 ~ ~if you replace 0 with <value>, having an x value less than <value> will cause the same issue. You have to add an additional command to test for anything less than <value> for this method to work properly. A rough example is to use:
/execute @a ~ ~ ~ testforblocks ~ ~ ~ <value> ~ ~ ~ ~ ~/execute @a ~ ~ ~ testforblocks ~ ~ ~ <value> ~ ~ ~ ~ ~then add conditions to determine which command should be run to give the expected behavior. Some additional tweaking will be needed to convert the score to a negative value, and this will cause issues when the player is within a block of <value>, which takes even more tweaking to fix. You're better off waiting for 1.13, where this method will be obsolete with the /execute store command being able to use(read only) the Pos tag of the player.
And for clarity, the resolution of this ticket should be works as intended, not invalid.
Not an issue anymore in 1.13 as you either get the command success count or results, and in this case result will be the amount of players that see the message.