mojira.dev
MCPE-36377

Testfor Command Not Working

When inputting the testfor command in a repeating command block, it fails to see the given input, even if what would give an output is correct. This seems to only happen to newly placed command blocks with the command in it. Previously placed command blocks seem to run it just fine.

Attachments

Comments 10

For context, I'm putting in testfor @p[x=a,y=b,z=c,r=d]. a, b, and c are the coord values that it's testing for, and d is the radius away from the specified coord. This has worked in previous versions of the game, so this is definitely not working as intended.

Can you please add more information about what is happening? The following seems to work correctly in a newly placed command block, set to repeating, and powered with redstone:

/testfor @p[x=1799,y=64,z=1189,r=2]
/testfor @p[x=1799,y=64,z=1189,r=2]
[media]

I've attached a picture of the issue. I put in the coords I'm standing on, and the comparator not lighting up. I will also mention this world was imported from 1.4, so it's possible it has something to do with that.

Ok so there were some changes to the radius detection range in 1.5 (see MCPE-32094 for a related example)

Basically you will need to specify the radius at more than 0. You should be able to run the following command:

testfor @p[x=78,y=4,z=33,r=1]
testfor @p[x=78,y=4,z=33,r=1]

This is line with the way commands were run in Java 1.12+

I realize you marked this as Working As Intended, but I disagree. For the project I'm working on, I need r=0 so that it detects the player standing directly on the specified coordinate. Unless you have another option, this needs to be changed.

Ok, I can see how that would be calculating from the corner of the coordinate. For that reason, could you try the following to see if that works in your set up:

testfor @p[x=78.5,y=4,z=33.5,r=0.5]
testfor @p[x=78.5,y=4,z=33.5,r=0.5]

That should only detect the player when they are within the specified coordinate.

That does work. But it worked just fine before when I could set it to r=0. Why should this have been changed? It was already useful the way it originally was.

It was changed because the old behavior was a bug.

Instead of removing it due to being a bug, why not add it back in as a feature? It was useful. And it's not like it was really breaking anything. It's more like things ended up breaking due to it being removed.

Don Nichols

(Unassigned)

Unconfirmed

Phone - Android - Motorola Moto G

1.5.2.1

Retrieved