Yes, that looks like my issue. Must've missed that when searching for an issue.
You can just use /data get entity @s SelectedItem
to view the data component structure serialized to NBT while holding each item and see the difference
Using the toggle_tooltips
item modifier does succesfully hide the attribute modifiers (I've linked a datapack with such a function), but it still behaves as described above. It has to manually copy over the default values into the stack's data (use /data get entity @s SelectedItem
to see the stack's components in NBT). This violates the 2nd of what I consider incorrect solutions because the itemstack no longer has the "default" attributes for a specific item type and any changes to those defaults would no longer be reflected in the itemstack.
Ok, I added clearer reproduction steps
Can confirm in 1.20.4.
This also affects Brewing Stands dropping items in the world. It seems to affect all uses of Containers#dropItemStack which happen while the block is still present in the world. All the other uses of it other than Campfire and Brewing Stand happen when the block is being broken.
I find it hard to believe its "works as intended" to have 2 starkly different behaviors for singleplayer and multiplayer. I don't see how that text bit in the minecraft changelog is at all indicative of this being WAI, just because they aren't converted to strings means that the behavior is different for singleplayer and multiplayer? How is that at all related.
To clarify (since the title could be misleading to anyone looking for the cause), the issue isn't caused by the "angle" argument being ignored, it's that in the constructor for the ServerPlayer
object, the angle is overriden by the call to fudgeSpawnLocation
which happens after the super constructor sets the spawn yaw to the yaw from the ServerLevel
.
A fix could be to make the fudgeSpawnLocation
method respect the level's yaw. Would solve the issue on initial spawn and respawn (without a "home" location).
That is not a good fix. There are items that should be consumed and only have a stack size of 1, but are also not damageable. The correct fix is to change that conditional to instead check if them stack's item type has durability. If it does not have durability, consume the item, if it does, run the hurtAndBreak logic which has its own check for "Unbreakable". You can see how we fixed this issue on Paper.
This still happens in 1.20.1.
Still affects 1.20-rc1
Can confirm this is still an issue in 1.20-rc1
This issue also affects jukeboxes in 1.19.4.
I think there are problems with always signing and including the original text in the message. What if a server wanted to hide information in that message? Like a bad word filter? The original message would still be sent to all the players. And what about the text-filtering-config system already in vanilla? That exists to filter words out of text, and so you wouldn’t want the exact original being sent to all clients, that completely defeats the purpose of it.
Drowned spawned just fine for me in water in a desert. They just require a water block below the block where they spawned. create a pool of water around the spawner and they'll spawn. I don't know if they should or not, there seems to be conflicting information on this tracker about that. MC-175110 suggests that its a bug if water mobs spawn outside of water, but MC-250054 suggests its OK if water mobs spawn outside of water. I don't know what the correct answer is.
Still an issue in 1.18.1
Can still reproduce this behavior on 1.18.1
Still happens in 1.21.1