It seems like there might be a bug when using the execute and testforblocks commands together. I'm trying to make a system that converts a player's coordinates into scoreboard values by using the testforblocks command, and so far there is only one issue.
First off, these are the commands that I'm currently using:
stats entity @p set AffectedBlocks @p X (used to get the number of blocks returned by testforblocks, using entity mode because of the execute command relative to the player)
execute @p ~ ~ ~ execute @p[x=389,dx=29999611] ~ ~ ~ testforblocks 389 ~ ~ ~ ~ ~ 389 ~ ~ all (The first execute command allows for the z coordinate of the player to be tracked rather than the z value of the command block. The x=389,dx=29999611 tests for a player between x=389 and x=30000000. The testforblocks command will always return the number of blocks between the player and x=389, at the same y and z values, as long as the player is at or above an x value of 389.)
The problem occurs with the second command. The execute @p[x=389,dx=29999611] should prevent the testforblocks command from running when the player is at x=388 or lower, but it doesn't. When moving between x=389 and x=388, the testforblocks command still runs, even though it shouldn't be able to. The command works otherwise, where going to x=387 no longer updates the command. The first two screenshots show the score changing the moment the x value changes from 389 to 388. The third one shows that the command is prevented after that point. It works properly at and above x=389, which is shown by the fourth screenshot.
If anyone knows of a workaround it would be much appreciated. Because of the way the testforblocks command works, I need to split up the command when the player crosses a certain x value. These diagrams should display how it works, if anyone is unfamiliar with the command:
command:execute @p ~ ~ ~ testforblocks 389 ~ ~ ~ ~ ~ 389 ~ ~ all
1.)
_____xbbbbp
bbbbbx
2.)
pbbbbx_____
pbbbbx_____
p=block at player location
b=block being tested
x=block at x coordinate of 389
_=empty space
For reference, this is viewed when facing south, with left being positive x and right being negative x. In the first diagram, the blocks xbbbbp are matched with the blocks bbbbbx. This happens because the last part of the testforblocks command specifies the lower valued corner of the area checked, and the player's x value is less than 389, making it the lower valued corner. The second diagram shows that the areas being checked will always match at or above an x value of 389. As the first diagram shows, the command must be split into two parts, one that checks to the left of x=389, and one that checks to the right of x=389. And that's where the trouble starts; the testforblocks command seems to check for the player's hitbox rather than their coordinates, making the issue unavoidable until a change is made.
Attachments
Comments 2
Thank you for responding quickly. After a bit of tweaking to the commands I found a workaround that eliminates the dead zone that involves using the rm parameter along with x and dx. I understand why this is "bug" is invalid now, but at the time it seemed like very odd behavior since I expected the parameters in the execute command to prevent the testforblocks command from running. I know this isn't the place to make suggestions, but perhaps they should change the command to use player coordinates instead of hitboxes, because it can lead to unintended behavior. Thank you again though, I figured it had something to do with player hitboxes being used instead of coordinates.
While it may seem odd, this is not a bug. The
dx/dy/dzparameters specifically check for entity hitbox intersection while expanding the search area to full blocks. In the attached image, the player's hitbox intersects with X389, so they will be found (and they receive a score of 2 because their center is in X388, so/testforblocksincludes that block and the target X389 block).You could remedy the issue partly by setting the player's score to 0 first before running
/execute. While this would stop the score from staying at 2 when entering the deadzone, it won't stop the score from being 2 via intersection.You could also set their score to 0 if they are at 388 or lower after the initial
/executecommand, but then that would result in their score being 0 while their center is rightly within 389 but their hitbox is intersecting with 388. Though that might be preferable over having an odd score of 2 at the X388/X389 intersection.