Yes seems to be fixed in 1.8.3
Why is this marked as invalid?
If it is invalid then please inform me about what I am doing wrong.
It's a miracle
You can place them, but they disappear instantly, so you see the block for a split second and then it gets reversed.
Instead of not being placeable at all like with other entities.
I think this is because the client let's you place it but then server doesn't agree with that.
I'm not using a command, I am placing them by hand.
Summoned ghast balls don't leave fire though.
Summoned blaze balls I should add, sorry.
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.
Maybe this might make more sense to you qmagnet.
http://i.imgur.com/WVOv4S2.png
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.
Well not so if another player is standing inside you over the middle of you hitbox on the negative side.
I know everyone has a lot of workarounds as solutions but that's not really the point.
When killing or teleporting an armorstand in the nether using c=1 I dont want my perfectly positioned armorstands in the overworld to be ruined. Of course there are reasons but it working like this is not intuietive at all. Especially if you get feedback of an armorstand being teleported without seeing your armorstand teleporting.