MC-52036using testfor in execute command failure
What I did: I used the command
execute @e[name="name"] ~ ~ ~ testfor @a[team=B]
What I expected to happen: It would output a redstone energy signal depending on the amount of players in that team around the entity.
What actually happened: It would only output because the testfor command succeeded, not because it had detected multiple players. It had not given a different redstone energy level (2 instead of 1).
Linked Issues
Created Issue:
using testfor in execute command failure
What I did: I used the command "execute @e[name="name"] ~ ~ ~ testfor @a[team=B].
What I expected to happen: It would output a redstone energy signal depending on the amount of players in that team around the entity.
What actually happened: It would only output because the testfor command succeeded, not because it had detected multiple players. It had not given a different redstone energy level (2 instead of 1).Environment
Creative, testing a domination point for a pvp map
![[Mod] Ezekiel (ezfe)](../../../data/assets/gravatar/ezekielelin.jpeg){kind=small}
What I did: I used the command "execute @e [name="name"] ~ ~ ~ testfor @a [team=B] .
What I expected to happen: It would output a redstone energy signal depending on the amount of players in that team around the entity.
What actually happened: It would only output because the testfor command succeeded, not because it had detected multiple players. It had not given a different redstone energy level (2 instead of 1).What I did: I used the command
execute @e[name="name"] ~ ~ ~ testfor @a[team=B]What I expected to happen: It would output a redstone energy signal depending on the amount of players in that team around the entity.
What actually happened: It would only output because the testfor command succeeded, not because it had detected multiple players. It had not given a different redstone energy level (2 instead of 1).
![[Mod] Torabi](../../../data/assets/gravatar/torabi.png){kind=small}
relates to
Yeah, it seems to output a signal based on how many time the execute command succeeded, instead of how many times the testfor succeeded, so it only outputs a power of 1, because only one entity executed the testfor command. I don't know if this is intended or not.
Yeah, I was making a domination point system, but then I discovered that it would only go up one at a time instead of two, which meant that it would've only output a signal of 1.
Why're you using an entity as a domination point, can't you use coords, you won't need an execute command then, just add the coords to the command. Unless you want the domination point to move, then entities would be useful.
The reason I'm using entities is because when I want to copy/paste the domination point, all I have to do is replace all entity names and player names in the whole build with the new ones, instead of using all kind of different coords.
Works as intended, the command block bases its output on the command it does, /execute in this case. That /execute triggers a command from another entity is not important.Also: The comparator output of a /execute command is based on how many entities it selects at the first parameter, @e[name="name"] in this case. This means that if 2 entities are found that are called "name", the comparator will give a signal strength of 2.Yes, but when using /execute @e[name="name"] ~ ~ ~ testfor @a[r=10]", shouldn't it output based on the testfor command. If it does (and it probably does), it should output based on the actual testfor command, so a power of two for two people, three for three, etc..
Can confirm. When a /testfor command is run via /execute and the /testfor fails, the originating command block will not provide an output (the issue concerning /execute's output superseding its contained /testfor's output was resolved). If the /testfor succeeds, it will provide an output, but only with a signal strength of 1 at max. What's expected is the signal strength to match the number of players/entities found, which it currently only outputs a max of 1, or 0 if no players/entities are found.
Is this still a concern in the current Minecraft version 14w30c 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.
Yes, this occurs in 14w30c. For those looking for a work-around, you can use assign a "SuccessCount" CommandStat to the target of the /execute before using /testfor, but that won't be too helpful if you're already using the stats for something else.
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. If this has been done, we can reopen the issue.
Keep in mind that the "Resolved"-Status on this ticket just means "Answered", and that we are waiting for further information on whether this issue still exists or not. We will reopen it as soon as the requested information has been delivered.
Confirmed in 1.8.3, however this behavior is intended. The success count for an execute command is equal to the number of entities the execute command executed at, not the success count of the executed command.
@Isaac King: see
MC-48449which details that /execute works differently than that. The issue here is the incorrect signal strength as a result of the fix for the other bug report.Oh. In that case, isn't this a dupe of
MC-48449?They cover two different things, though of a related topic (so "related" rather than "duplicate").
MC-48449covers /execute even providing an output from the command it had run to begin with, while this one covers the signal strength of the way /execute outputs afterMC-48449was resolved. This report couldn't have been made withoutMC-48449being resolved.EDIT: Fixed links, thanks Marcono1234.
[Mod] Skylinerw I think you had some typos, it is 484 4 9 not
MC-48499The enviroment is supposed to contain pc details.
Is this still an issue in the latest snapshot 16w44a? If so please update the affected versions.
This is an automated comment on any open or reopened issue with out-of-date affected versions.
i think this issue is unworthy to fix.
/stats and /scoreboard can return a correct number of selected entities/players.
also,it's powerless to test more than 15 entities/blocks.
/testfor is gone in 1.13 so this is no longer an issue.
Probably rather fixed if the issue was really that /execute did not properly pass the success count.
A 18w03b equivalent should be the following command which works as expected, passing the success count of spreadplayers.
/execute as @e run spreadplayers ~ ~ 0.0 10.0 false @e