mojira.dev

Machine Maker

Assigned

No issues.

Reported

MC-277736 Clearing banner patterns with commands doesn't update the banner block Community Consensus MC-276961 Boat spawners count boats of the wrong wood type against MaxNearbyEntities Community Consensus MC-273617 Arrows that are "deflected" suddenly allow being picked up Duplicate MC-272105 Decorated Pot is missing the "contents" implicit data component type Fixed MC-272008 Unable to hide attributes without setting attributes Invalid MC-269161 Stonecutter does not support multiple recipes with the same result item type Fixed MC-267438 Translatable component argument boolean serialization mismatch Works As Intended MC-264986 Item count of fuel slot affects the way smelting recipe book moves ingredients Fixed MC-264285 Unbreakable flint and steels are completely consumed when igniting a creeper Confirmed MC-264274 Lily pad and frogspawn do not increment "used" statistic like other placeables Confirmed MC-264081 Enchanted Book with non "StoredEnchantments" does not give XP from grindstone Works As Intended MC-263999 Zombies breaking doors do not show break particles Confirmed MC-263123 Mending incorrectly calculates overflow after full repair Fixed MC-254089 Chat Preview components allow server to "hide" content Fixed MC-235045 Entity type tags suggestions don't work in target selectors Confirmed

Comments

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.

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. 

@Adam, it looks like height requirements are WAI as suggested here in MC-238526

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.

Can still reproduce this behavior on 1.18.1