Sl1mJ1m
- Sl1mJ1m
- JIRAUSER503625
- Europe/Stockholm
- Yes
- No
MC-188520
Low![[Mojang] Gegy](../../../data/avatars/users/10122.svg){kind=small}
The tag HandDropChances is " [0.085f, 0.0f] " instead of " [0.085f, 0.085f] on any mobs updated directly from 1.8.9 or before to 20w21a or later. This effects all mobs. Related to https://bugs.mojang.com/browse/MC-195789
The tag HandDropChances is " [0.085f, 0.0f] " instead of " [0.085f, 0.085f] on any mobs updated directly from 1.8.9 or before to 20w21a or later. This effects all mobs. Related to
MC-195789The tag HandDropChances is " [0.085f, 0.0f] " instead of " [0.085f, 0.085f] on any mobs updated directly from 1.8.9 or before to 20w21a or later. This effects all mobs.
Similarly, The tag HandDropChances is " [2.0f, 0.0f] " instead of " [0.085f, 0.085f] and the tag ArmorDropChances is " [2.0f, 2.0f, 2.0f, 2.0f] " instead of " [0.085f, 0.085f, 0.085f, 0.085f] on certain mobs updated directly from 1.8.9 or before to 20w30a. This only seems to effect certain mobs.
The tag HandDropChances is " [2.0f, 0.0f] " instead of " [0.085f, 0.085f] on any mobs updated directly from 1.8.9 or before to 20w30a. Similarly, the tag ArmorDropChances is " [2.0f, 2.0f, 2.0f, 2.0f] " instead of " [0.085f, 0.085f, 0.085f, 0.085f] ". This
effects all mobs (except for horses). Related toMC-195743The tag HandDropChances is " [2.0f, 0.0f] " instead of " [0.085f, 0.085f] on any mobs updated directly from 1.8.9 or before to 20w30a. Similarly, the tag ArmorDropChances is " [2.0f, 2.0f, 2.0f, 2.0f] " instead of " [0.085f, 0.085f, 0.085f, 0.085f] ". This only seems to effect certain mobs. Related to https://bugs.mojang.com/browse/MC-195743
The tag HandDropChances is " [2.0f, 0.0f] " instead of " [0.085f, 0.085f] on
anymobs updated directly from 1.8.9 or before to 20w30a. Similarly, the tag ArmorDropChances is " [2.0f, 2.0f, 2.0f, 2.0f] " instead of " [0.085f, 0.085f, 0.085f, 0.085f] ". This only seems to effect certain mobs. Related toMC-195743The tag HandDropChances is " [2.0f, 0.0f] " instead of " [0.085f, 0.085f] on certain mobs updated directly from 1.8.9 or before to 20w30a. Similarly, the tag ArmorDropChances is " [2.0f, 2.0f, 2.0f, 2.0f] " instead of " [0.085f, 0.085f, 0.085f, 0.085f] ". This only seems to effect certain mobs. Related to https://bugs.mojang.com/browse/MC-195743
Currently, curing a baby zombie villager jockey does not cause it to dismount, creating a villager chicken jockey. The villager can also grow up, and it functions exactly as a normal villager, however, it does not dismount the chicken. This is likely caused by the fix of
MC-163767To reproduce:
- Find a baby zombie villager jockey, or spawn one in via commands: /summon chicken ~ ~ ~ {Passengers:[ {id:zombie_villager,IsBaby:1,}
]}
- Cure the baby zombie villager as you would a normal zombie villager
- Wait until it is cured
- Observe the fact the zombie villager is still riding the chicken
Currently, curing a baby zombie villager jockey does not cause it to dismount, creating a villager chicken jockey. The villager can also grow up, and it functions exactly as a normal villager, however, it does not dismount the chicken. This is likely caused by the fix of
MC-163767To reproduce:
- Find a baby zombie villager jockey, or spawn one in via commands: /summon chicken ~ ~ ~ {Passengers:[ {id:zombie_villager,IsBaby:1,}
]}
- Cure the baby zombie villager as you would a normal zombie villager
- Wait until it is cured
- Observe the fact the
zombievillager is still riding the chickenCurrently, curing a baby zombie villager jockey does not cause it to dismount, creating a villager chicken jockey. The villager can also grow up, and it functions exactly as a normal villager, however, it does not dismount the chicken. This is likely caused by the fix of
MC-163767To reproduce:
- Find a baby zombie villager jockey, or spawn one in via commands: /summon chicken ~ ~ ~ {Passengers:[ {id:zombie_villager,IsBaby:1,}
]}
- Cure the baby zombie villager as you would a normal zombie villager
- Wait until it is cured
- Observe the fact the villager is still riding the chicken
Currently, curing a baby zombie villager jockey does not cause it to dismount, creating a villager chicken jockey. The villager can also grow up, and it functions exactly as a normal villager, however, it does not dismount the chicken. This is likely caused by the fix of
MC-163767To reproduce:
- Find a baby zombie villager jockey, or spawn one in via commands:
/summon chicken ~ ~ ~ {Passengers:[{id:zombie_villager,IsBaby:1}]}
- Cure the baby zombie villager as you would a normal zombie villager
- Wait until it is cured
- Observe the fact the villager is still riding the chicken
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.
Yes, sorry, poor wording
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.
Should probably be marked as Works As Intended, since the behavior did not actually change in 20w46a
latest.log
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.
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
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
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
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"
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 fixedThis is likely due to suspicious sand requiring a loot table assigned to it to drop. Any user placed suspicious sand has no loot table.
Attached screenshot shows creative mode. I also tested in survival, unable to reproduce. Safe to assume this is an invalid bug report.
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
Can confirm, tested updating a world from 23w45a to 1.20.3 Pre-Release 1 and grass items were deleted
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)