mojira.dev

Sl1mJ1m

Assigned

No issues.

Reported

MC-270391 Changing the mob type of an ominous trial spawner with a spawn egg causes spawned mobs to wear armor irrespective of the mob type Confirmed MC-262550 Outdated Translations Strings in Language File (Pottery Sherds & Sniffer Subtitles) Duplicate MC-257224 Hoppers Do Not Interact With Jukeboxes [Bedrock Parity Issue] Invalid MC-249746 Allays Can Equip Armor Duplicate MC-213805 Skeletons converting to strays allows for stray jockeys Works As Intended MC-206628 Emptied Bundles have an empty Item Tag Fixed MC-200418 Cured baby zombie villagers stay as jockey variant Confirmed MC-195789 HandDropChances and ArmorDrop Chances tags are incorrect on mobs updated from pre 1.9 worlds Duplicate MC-195743 HandDropChances tag is incorrect on mobs updated from pre 1.9 worlds Awaiting Response MC-189525 Armored entities from pre-1.9 worlds upgrade to dual wielding armor Fixed MC-188520 Ghost item can be created using the new inventory function Confirmed

Comments

Tested with sheep, you have to set the spawn egg after the spawner switches to ominous, and make sure there are valid spawning requirements for the respective mob (so grass for the pigs to spawn on)

Can confirm, tested updating a world from 23w45a to 1.20.3 Pre-Release 1 and grass items were deleted

Due to a presumed shift of item ids, as of the latest full release (1.19.70) the item in the chest is now a leather tunic instead

Attached screenshot shows creative mode. I also tested in survival, unable to reproduce. Safe to assume this is an invalid bug report.

This is likely due to suspicious sand requiring a loot table assigned to it to drop. Any user placed suspicious sand has no loot table.

This bug was inadvertently fixed during 1.16.3 Release Candidate 1, likely as a result of the fix of MC-198678. Should be marked as fixed

Can confirm, the biomes also appear to remain as null when switching to older datapacks. When generating new null biome chunks it spams the console log with "Received invalid biome id: -1"

I was able to create a level##########.dat, however it was not kept in the folder. I did capture the exact moment it occured though - https://www.youtube.com/watch?v=gFXMC6DG56o

Yes, and that was my thought as well. Somebody else has been able to replicate it without using an external program, but they are unsure how

To replicate, you simply need to open either level.dat or level.dat_old with NBTExplorer (unsure if similar programs effect it the same), and then open the world. This causes the level##################.dat to generate, meaning it occurs on world load, not on world save. Also this is on a Windows environment

[media]

Just occurred to me in 1.16.4, I will attach the console log from the time of the error. It appears to not be related to tile entities, as during the short period of time I was in the world prior to the level.dat error no tile entities were interacted with.

Should probably be marked as Works As Intended, since the behavior did not actually change in 20w46a

And I don't believe this is intentional behavior, since I don't think there is any practicality of a villager riding a chicken. I also haven't seen any mention of this as a feature in any patch notes.

Yes, sorry, poor wording

This still effects the current snapshot, updating a tamed horse from 1.7.4 to 20w29a does not convert the player name, thus leaving the horse without a owner tag.