mojira.dev

Phssthpok Pak

Assigned

No issues.

Reported

MC-126930 Sponges do not soak up flowing water Fixed MC-125799 Chests placed in earlier versions make no sound when opened Fixed MC-122726 Command execution position within a function not updated by tp command Works As Intended MC-122601 Command team join <team> [<members>] does not allow multiple members to be added at once Works As Intended MC-72950 Structures below ground level don't render at certain angles Duplicate MC-31383 Wrong particle colour when breaking tall ferns Incomplete MC-29503 Isolated stronghold portal room generated in ocean Works As Intended MC-27086 Zooming a map does not keep the position of the original (or the area already explored). Duplicate MC-7058 Brewing stand comparator output inconsistent Fixed MC-2604 Walking on non-solid blocks with no collision plays their respective walking sounds Fixed MC-1441 Ridden pig moves erratically on slab road Duplicate MC-1305 Iron Bar hit-boxes misaligned Fixed

Comments

I'm not sure if this will help as I'm working on a PaperMC server with various plugins but just in case it's of any use...

I was having this issue with testing a 1.16.5 world that I'm preparing to upgrade to 1.17.1. As part of my preparation I ran up the server with the --eraseCache option and it seems to have fixed the problem.

 

Edit: Or maybe not. It appeared to fix the issue when I first tried it but rerunning the upgrade from scratch with --eraseCache hasn't worked. Sorry if this is a red herring.

Confirmed in 20w51a

Confirmed for 1.15-pre3

I've set up a scoreboard and command block to continually display the Rotation[0] value of an armour stand in the sidebar and it appears that this is something to do with the animation of the armour stand being rotated as the internal data for Rotation[0] gets updated properly.

Using execute as @e[type=minecraft:armor_stand,distance=..5] at @s run tp @s ~ ~ ~ facing entity @p  to rotate the stand to face the nearest player seems to work when the command is being run every tick by a command block but doesn't work consistently when run manually in chat with the player moving a significant amount between executions.

Well that's mighty odd! I've done a ton of stuff with armour stands and never noticed the graphical glitch before but going back and running the same tests in 1.14.4 does indeed show the same graphical glitch.

I'll add my vote and a comment to MC-103800.

Many thanks.

I can confirm that there is still a problem here. Using this command:

/execute as @e[type=minecraft:armor_stand,distance=..3] at @s run tp @s ~ ~ ~ facing entity @p

the armour stand's Rotation data gets updated but is not always reflected in the displayed stand.

Unfortunately I have not been able to track down the exact circumstances that cause the problem (yet!)

Edit to add: If you have the command running continuously in a repeating command block (as in MC-166132) you may not be able to see the problem as it doesn't always occur and may work again the next tick. I suggest running the command manually and checking after each attempt.

I can confirm this. Similarly, trader llamas created with a summon command despawn instantly

Command used is /summon minecraft:trader_llama ~ ~1 ~ {NoAI:1b,Silent:1b,NoGravity:1b,Variant:3b}

Problem is still present in 1.14

I'm getting the "Unable to resolve BlockEntity for ItemStack: minecraft:light_gray_banner" message during world conversion to 1.14

Confirmed for 19w12b

I have noticed that many heads with textures from skins currently being used by players have also reverted to the default Steve skin on heads already placed in a world. Regenerating the give code for the same player gave a different URL for the skin. For example, the give code I used in the past to get a head with my own skin (Phssthpok), decoded from Base64 contained:

{"textures":{"SKIN":

{"url":"http://textures.minecraft.net/texture/49725d625a50497c6494f33fbb7015446ccad135e93152571e2a57926284053"}

}}

but regenerating the give code now returns:

{"textures":{"SKIN":

{"url":"http://textures.minecraft.net/texture/15ed33ea710912d0f90a7a1f0e30e40d421fcd7f962965ac191c7a478f3af0cf"}

}}

so it would appear that, rather than the skins having been removed from the database, they have been renumbered

I'm not sure if this relates to this problem, but I've noticed in the logs that the game seems to issue these warnings every time:

[09:25:39] [Client thread/ERROR]: Realms module missing
[09:25:43] [Client thread/WARN]: Ambiguity between arguments [teleport, destination] and [teleport, targets] with inputs: [Player, 0123, @e, dd12be42-52a9-4a91-a8a1-11c01849e498]
[09:25:43] [Client thread/WARN]: Ambiguity between arguments [teleport, location] and [teleport, destination] with inputs: [0.1 -0.5 .9, 0 0 0]
[09:25:43] [Client thread/WARN]: Ambiguity between arguments [teleport, location] and [teleport, targets] with inputs: [0.1 -0.5 .9, 0 0 0]
[09:25:43] [Client thread/WARN]: Ambiguity between arguments [teleport, targets] and [teleport, destination] with inputs: [Player, 0123, dd12be42-52a9-4a91-a8a1-11c01849e498]
[09:25:43] [Client thread/WARN]: Ambiguity between arguments [teleport, targets, location] and [teleport, targets, destination] with inputs: [0.1 -0.5 .9, 0 0 0]
[09:25:43] [Client thread/INFO]: Loaded 0 recipes

 

This example is from the 1.13-pre2 version but I've noticed it in previous snapshots as well.

Confirmed for 1.13-pre1

Confirmed for 18w20b

Confirmed for 18w14a (but can't add that version to the list for some reason)

Confirmed for 18w14a

Confirmed that the error message is now "Unable to summon entity"

Confirmed in 18w11a

Confirmed in 18w11a. Do you want me to keep checking this or is it generally accepted that it's going to eventually be marked as Works as Intended?

Confirmed for 18w11a

The lava bucket cannot be used to place lava in or against any block that can have the waterlogged state. Clicking and shift-clicking both do nothing.