[MC-9097] /testfor producing true comparator signal with invalid parameters Created: 03/Feb/13 Updated: 31/Jul/14 Resolved: 31/Jul/14 |
|
| Status: | Resolved |
| Project: | Minecraft: Java Edition |
| Component/s: | None |
| Affects Version/s: | Snapshot 13w05b, Minecraft 1.5.2, Minecraft 1.6.1, Minecraft 1.6.2 |
| Fix Version/s: | Minecraft 14w30c |
| Type: | Bug | ||
| Reporter: | Pvt_Meatshield | Assignee: | Unassigned |
| Resolution: | Fixed | Votes: | 3 |
| Labels: | None | ||
| Issue Links: |
|
||||||||
| CHK: | |||||||||
| Confirmation Status: | Confirmed | ||||||||
| Game Mode: | Creative | ||||||||
| Description |
|
I place a command block and give it this command: /testfor @p[x=180,y=56,z=22=,r=10] I connect a comparator to the command block(comparing mode) it remains "false" until power is connected. Once a redstone clock is connected the comparator outputs a "true" signal even when a player is not anywhere near the coordinates and the signal is constantly being refreshed by the clock. When the clock is deactivated the comparator still remains powered unless the command block is removed. It also becomes powered even if the previous result was false. However when the command is changed to: /testfor @a[r=10] the command block is connected to the clock the comparator issues true/false commands when the player is within that radius as normal. I feel like other players have mentioned this a lot but been ignored because their complaints were rather vaguely worded. Any help would be wonderful, thank you. |
| Comments |
| Comment by Hubertus Boos [ 28/Jul/14 ] |
|
Works in 14w30c. I think this can be closed. |
| Comment by [Mod] Ezekiel (ezfe) [ 26/Jul/14 ] |
|
Is this still a concern in the latest Minecraft version 14w30c? If so, please update the affected versions in order to best aid Mojang ensuring bugs are still valid in the latest releases/pre-releases. |
| Comment by Galaxy_2Alex [ 22/Jan/14 ] |
|
Is this still a concern in the current Minecraft version 1.7.4 / Launcher version 1.3.8 or later? If so, please update the affected versions in order to best aid Mojang ensuring bugs are still valid in the latest releases/pre-releases. |
| Comment by WolfieMario [ 07/Aug/13 ] |
|
Able to reproduce now that I noticed there's an extra = sign after the z=22. Thanks for updating the description to make it clear that this only happens when selector arguments* are considered invalid. *I'm not sure how many people are aware, but the official name for @p, @a, and @r are apparently "selectors", and the contents of the brackets are "selector arguments". |
| Comment by GrygrFlzr [ 07/Aug/13 ] |
|
Reopened. Confirmed issue still exists in 1.6.2, and also happens on all commands that have invalid parameters. |
| Comment by Tails [ 19/May/13 ] |
|
Unable to reproduce either. |
| Comment by WolfieMario [ 12/May/13 ] |
|
I am unable to reproduce this in 13w19a singleplayer. |
| Comment by Tails [ 18/Mar/13 ] |
|
Is this still a concern in the current Minecraft version? If so, please update the affected versions in order to best aid Mojang ensuring bugs are still valid in the latest releases/pre-releases. |
| Comment by Hubertus Boos [ 12/Feb/13 ] |
|
I don't know if this is the right place to say this, but isn't it better the command block only gives a pulse when the command works correct? If you use testfor playername and the commandblock is activated once, he gives constantly a true signal, also if you logout and login, until you break the block. |
| Comment by Pvt_Meatshield [ 03/Feb/13 ] |
|
Thank you |
| Comment by GrygrFlzr [ 03/Feb/13 ] |
|
Confirmed. Reformatted and renamed the issue. |