MC-55510@p not targetting closest player correctly.
@p target selector would select the closest player.
So when you run it through an execute command for example:
/execute @a ~ ~ ~ scoreboard player option @p <score> *= @p <score>'
You'd expect everyone to be mutiplying a score for itself.
But what turns out to happen is that if another player stands over the middle of your hitbox and on the negative coordinate side, it will actually target them instead of yourself.
I believe it should make more sense if a player would always, no matter what, see himself as the closest player if preforming an execute command or a command by hand using @p.
Created Issue:
@p not targetting closest player correctly.
@p target selector would select the closest player.
So when you run it through an execute command for example:
/execute @a ~ ~ ~ scoreboard player option @p <score> *= @p <score>'
You'd expect everyone to be mutiplying a score for itself.But what turns out to happen is that if another player stands over the middle of your hitbox and on the negative coordinate side, it will actually target them instead of yourself.
I believe it should make more sense if a player would always, no matter what, see himself as the closest player if preforming an execute command or a command by hand using @p.
![[Mojang] Searge (Michael Stoyke)](../../../data/assets/gravatar/searge.png){kind=small}
[Mojang] Searge (Michael Stoyke)
relates to
relates to
relates to
Then maybe MC-55510 relates to it because it was probably caused by the same issue
closest player = the player that executed the command
Well not so if another player is standing inside you over the middle of you hitbox on the negative side.
It's difficult to make sense of your issue, without and example. But @p doesn't necessarily target the closest player and get a result. @p will fail IF the closest player doesn't match the criteria in your selectors. Better to use @a and add your selectors - then only the player that has the specific criteria, will gain the output.
I'd wager, there's an easier way you can do what you want to do with the scoreboard stats.
Well, I've made a thing that calculates scores with operations for the player itself.
So for example /execute @a ~ ~ ~ scoreboard player option @p <score> *= @p <score>
Which means that all players should power the closest players score by the closest players score.
So the problem is that if people walk inside eachother one of the players will not calculate this score for himself but for the other, if stood on negative coordinates of the player.
And I know a lot about command blocks so I don't need explanation, I'm sure it shouldn't be like this, since the failure occurs in stange situations you wouldn't expect it to.
And @p does mean closest player, if you add extra criteria it still means closest player but only targets the players with those criteria, obviously.
But I don't have any extra criteria.
I think how it works is that when useing a selector the game starts looking from the most negative point of your hitbox. When used @p, without specification of the number is should look for (c=...) it will only have to find one person, but if another person stands in your hitbox, and the middle of his hitbox is more negative then yours, it will find that player as the closest player.
If so, this wouldn't necessarily be a bug, more just the way the code works, but I think you should be able to assume that the closest player to yourself should be youself instead of the player closest to the nagative corner of your hitbox.
Fair enough. I still don't understand enough of your specific report to do a test and confirm. But I was trying to explain that @p will only target the nearest player to the command. It won't target the nearest player that matches criteria. So if the nearest player doesn't match the criteria of your command, the command wont move on to someone who does. But I suppose you know that. Hopefully, someone else can verify your bug.
Maybe this might make more sense to you qmagnet.
http://i.imgur.com/WVOv4S2.png
Is it possible @p is already being triggered and so it cannot produce another result (as in it's powered)? What are you trying to achieve with this command?
It's being powered every tick with a clock, I basically made a system that can calculate level-xp ratio and if your xp is high enough it levels you up.
I do this with the formula: xp next level = (L+1)³-L². In which L means your current level.
I'm using this to create for example a fishing level, a combat level or a cooking level.
The only way I can achieve this is by using the operation system in scoreboard, this mean I am using a load of += *= /= -=, for example to get the power of 3 to work I have to have a lot of scores doing *= .
The system works sublime, but once there is another player standing inside your hitbox on the negative side, they start leveling like crazy, this is because your @p is targeting them + themselves, and vice versa.
I already sort of fixed this by taking a detour, but it still bugs out, but really rarely. I know how to probably further fix this. But I still think this is a thing that should be fixed, because it's just causing trouble.
Oh hey, this bug. This was fixed in 14w27a. They added a special case where @p checks yourself first, and if you're not valid (due to arguments in brackets, it checks all players to see who's the closest person.
So this is fixed.
Edit: they fixed this for entities now too. If entities execute a command using @e[r=0,c=1] they will execute it on themselves. Here's a screenshot of this working: http://i.imgur.com/ms2LfTn.png