When using set with the /stats command, the selector doesn't work with anything other than UUIDs or usernames.
Example:
Formatting: /stats entity <selector> set <stat> <selector> <objective>
Command: /stats entity @e[c=1] set SuccessCount @e[c=1] DummyObjective
The first selector works with usernames (blockerlocker) UUIDS (2e7c2061-704d-4993-b452-22347b899246) and selectors (@p, @a, @r, @e, [data tags]) However the second selector only works with usernames and UUIDs, selectors don't work. Likewise, block selectors don't work either.
Formatting: /stats block <x> <y> <z> set <stat> <selector> <objective>
Command: /stats block ~ ~ ~ set SuccessCount @p[type=FallingSand] DummyObjective
There's only one selector in this command, and it doesn't actually work with selectors, again only UUIDs and usernames. Some sort of bug, I dunno, fix it please.
Comments 7
Make sure the intended target has a score in the objective first as well, otherwise it will not work.
Also keep in mind that there is a player bias on top of the sender bias for c=1 with CommandStats. If a player exists, they will be targeted first before non-player entities. You can change the selector to @e[type=!Player,c=1] to avoid the player bias while retaining the sender bias.
@redstonehelper I did mean @e[FallingSand] however I used that only as an example. The EXACT thing I'm doing is making an armorstand run the command
"/stats entity @e[c=1] set SuccessCount @e[c=1] CraftMBoots"
It get's the first @e[c=1] (the nearest 1 entity) but the second one it does not understand. And I find it a bit odd that the second selector has to resolve to a single entity, as it IS possible for multiple entities to track stats, so the second selector SHOULD allow @p, @r, @a, and @e.
@Skylinerw I do so, yet it still does not work. And the problem does not have to do with problems in Player bias or formatting, as much as it has to do with the command registering "@e[type=!Player,c=1]" as a name rather than a selector. So maybe this isn't a bug, as much as it is a missing feature.
"/stats entity @e[c=1] set SuccessCount @e[c=1] CraftMBoots"
The second selector has a player bias. You must use @e[type=!Player,c=1] to get around it. It's trying to set your score, not the armor stand's score.
@Skylinerw I already tried that, it's trying to set "@e[type=!Player,c=1]'s" score. c=1 doesn't have a player bias, it works with the nearest entity, but even if i remove players, that doesn't fix the fact that the command reads @e[type=!Player,c=1] as a username rather than a selector.
c=1 doesn't have a player bias
That is simply incorrect. In the latest snapshot, do the following (preferably in a fresh world where you have no other commands running):
1. Create objective and set display.
/scoreboard objectives add NUM dummy
/scoreboard objectives setdisplay sidebar NUM2. Summon an armor stand with the necessary CommandStats already applied, using @e[c=1] as its target.
/summon ArmorStand ~ ~1 ~ {CommandStats:{SuccessCountName:"@e[c=1]",SuccessCountObjective:"NUM"}}3. Set both the armor stand and your score to 0.
/scoreboard players set @e[r=10] NUM 04. Cause the armor stand to activate its stored trigger. Your score is changed, not its own, because there is a player bias with CommandStats.
/execute @e[type=ArmorStand] ~ ~ ~ testfor @pI am experiencing no other issues in using /stats or CommandStats in general. There is something else interfering with your setup.
See MC-80400 for information concerning player bias in specific functions, as well as a spreadsheet detailing type biases.
@p[type=FallingSand] - are you sure this works? Did you mean @e[type=FallingSand]? In either case, the second selector has to resolve to a single entity.