mojira.dev

Logstone

Assigned

No issues.

Reported

MC-93996 Commands executed in one dimension do not prefer entities from that dimension (not sorted with execution dimension first) Confirmed MC-79097 Dropping items from the inventory gui doesn't count as dropping them to statistics Duplicate MC-78690 Scoreboard operations not being able to find UUID Invalid MC-76687 Block breaking sound under Friendly creatures Duplicate MC-76321 Spectator sound location Duplicate MC-76131 Cannot set weapon slot of a mob/armor stand with armour or player/mob head (/replaceitem) Cannot Reproduce MC-75785 Sound repeats when closing GUI Duplicate MC-75784 Pickblock not working with certain items Duplicate MC-75523 Small armorstands and baby zombie's hitboxes don't scale Duplicate MC-75460 Entity shadows do not render on upsidedown stairs Duplicate MC-75351 Armorstand not killable in adventure mode Duplicate MC-74686 Marker armorstand block placing issue Fixed MC-74685 Marker armorstand colision issue Duplicate MC-74508 Boat riding marker armorstand rubberbanding Fixed MC-73761 Entity rotation not rendering correctly after load Duplicate MC-70251 Gamerule mobGriefing doesn't prevent blaze fire. Invalid MC-69430 Switching between third and first person mode disables shaders. Duplicate MC-63874 /particle command centers particle on middle of block when executed trough entity. Duplicate MC-59418 Standing exactly on .0 of coordinate causes blocks unbreakable Duplicate MC-55510 @p not targetting closest player correctly. Fixed

Comments

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.

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.

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.