TorteShui
- TorteShui
- torteshui
- Europe/Stockholm
- Yes
- No
5 issues
Key
Summary
Status
Reporter
Assignee
Created
MC-149783![[Mojang] Chi Wong](../../../data/avatars/users/18941.svg){kind=small}
Low
Changed Description:
With the new textures (which are greatbtw), cactus bottom has not been updated and still shows the old darker green.Also, the bark ring around dark oak log top hasn't been updated together with dark oak log between 18w46a and 18w47a and the following versions incl. 1.14 release, so it is a little darker than the side bark and doesn't fit as well to the log side than for the other wood types (see attached image, left 18w46a, right 18w47a+).
The bark ring around dark oak log top hasn't been updated together with dark oak log between 18w46a and 18w47a and the following versions incl. 1.14 release, so it is a little darker than the side bark and doesn't fit as well to the log side than for the other wood types (see attached image, left 18w46a, right 18w47a+).
Changed Summary:
Updated textures issuesDark oak log top texture bark ring not updated
Added Affects Versions: 1.16.2-pre1
Added Attachments:
2019-05-01_17.43.29.png
Removed Attachments:
Changed Description:
Villager demand values decrease indefinitely over time, some reaching minus 3 million in my Realms world. This makes it pretty much impossible to ever reach positive values again (except by underflow). New villagers or new trades start with zero or low values like -24, but over time they go into negative thousands, hundred thousands and so on. Villagers from 1.13.2 which haven't been traded with in 1.14.x or have not restocked, have a demand value of 0.
Also, according to MerchantOffer.java, the following code (MCP mappings) doesn't seem to have an underflow protection, so I expect very high positive values after reaching minus 2 billion and some, potentially leading to very high prices (clamped to max. stack size):
this.demand = this.demand + this.uses - (this.maxUses - this.uses);
Relates to
MC-156574which has been marked as fixed.Example for an 1.13.2 butcher that has been traded with in 1.14.x:
{Brain: {memories: {"minecraft:home": {pos: [I; -192, 69, -155], dimension: "minecraft:overworld"}, "minecraft:last_slept": 59095829L, "minecraft:last_worked_at_poi": 58818687L}}, HurtByTimestamp: 0, Attributes: [{Base: 20.0d, Name: "generic.maxHealth"}, {Base: 0.0d, Name: "generic.knockbackResistance"}, {Base: 0.5d, Name: "generic.movementSpeed"}, {Base: 0.0d, Name: "generic.armor"}, {Base: 0.0d, Name: "generic.armorToughness"}, {Base: 16.0d, Modifiers: [{UUIDMost: -1878018487258559006L, UUIDLeast: -9174853231443965336L, Amount: 0.07413098408231238d, Operation: 1, Name: "Random spawn bonus"}], Name: "generic.followRange"}, {Base: 0.0d, Name: "generic.attackKnockback"}], FoodLevel: 0b, Invulnerable: 0b, FallFlying: 0b, ForcedAge: 0, Gossips: [], PortalCooldown: 0, AbsorptionAmount: 0.0f, LastRestock: 2906L, FallDistance: 0.0f, DeathTime: 0s, Xp: 18, LastGossipDecay: 59084674L, HandDropChances: [0.085f, 0.085f], PersistenceRequired: 0b, Age: 0, Motion: [0.0d, -0.0784000015258789d, 0.0d], UUIDLeast: -6538277718517827106L, Health: 20.0f, LeftHanded: 0b, Air: 300s, OnGround: 1b, Dimension: 0, Offers: {Recipes: [{maxUses: 14, buyB: {id: "minecraft:air", Count: 0b}, buy: {id: "minecraft:porkchop", Count: 15b}, sell: {id: "minecraft:emerald", Count: 1b}, xp: 1, uses: 0, priceMultiplier: 0.0f, specialPrice: 0, demand:{color:#FF0000}-502220{color}, rewardExp: 1b}, {maxUses: 25, buyB: {id: "minecraft:air", Count: 0b}, buy: {id: "minecraft:chicken", Count: 15b}, sell: {id: "minecraft:emerald", Count: 1b}, xp: 1, uses: 0, priceMultiplier: 0.0f, specialPrice: 0, demand:{color:#FF0000}-896806{color}, rewardExp: 1b}, {maxUses: 7, buyB: {id: "minecraft:air", Count: 0b}, buy: {id: "minecraft:coal", Count: 21b}, sell: {id: "minecraft:emerald", Count: 1b}, xp: 1, uses: 0, priceMultiplier: 0.0f, specialPrice: 0, demand: -251106, rewardExp: 1b}, {maxUses: 7, buyB: {id: "minecraft:air", Count: 0b}, buy: {id: "minecraft:emerald", Count: 1b}, sell: {id: "minecraft:cooked_porkchop", Count: 6b}, xp: 1, uses: 0, priceMultiplier: 0.0f, specialPrice: 0, demand: -251114, rewardExp: 1b}, {maxUses: 7, buyB: {id: "minecraft:air", Count: 0b}, buy: {id: "minecraft:emerald", Count: 1b}, sell: {id: "minecraft:cooked_chicken", Count: 6b}, xp: 1, uses: 0, priceMultiplier: 0.0f, specialPrice: 0, demand: -251116, rewardExp: 1b}]}, Rotation: [179.12813f, 0.0f], HandItems: [{}, {}], RestocksToday: 0, ArmorDropChances: [0.085f, 0.085f, 0.085f, 0.085f], UUIDMost: -4706437458691471725L, Pos: [-196.49274613473273d, 72.0d, -165.24950263469773d], Fire: -1s, ArmorItems: [{}, {}, {}, {}], CanPickUpLoot: 1b, VillagerData: {profession: "minecraft:butcher", level: 9, type: "minecraft:plains"}, HurtTime: 0s, Inventory: [{id: "minecraft:wheat_seeds", Count: 24b}, {id: "minecraft:wheat", Count: 24b}, {id: "minecraft:carrot", Count: 6b}, {id: "minecraft:wheat", Count: 21b}]}Example for an 1.14.x toolsmith:
{Brain: {memories: {"minecraft:meeting_point": {pos: [I; -205, 72, -144], dimension: "minecraft:overworld"}, "minecraft:home": {pos: [I; -213, 71, -161], dimension: "minecraft:overworld"}, "minecraft:last_slept": 59095924L, "minecraft:last_worked_at_poi": 59092641L, "minecraft:job_site": {pos: [I; -196, 68, -144], dimension: "minecraft:overworld"}}}, HurtByTimestamp: 0, Attributes: [{Base: 20.0d, Name: "generic.maxHealth"}, {Base: 0.0d, Name: "generic.knockbackResistance"}, {Base: 0.5d, Name: "generic.movementSpeed"}, {Base: 0.0d, Name: "generic.armor"}, {Base: 0.0d, Name: "generic.armorToughness"}, {Base: 48.0d, Modifiers: [{UUIDMost: -73376431933667821L, UUIDLeast: -6176652968726733404L, Amount: 0.033869891415886366d, Operation: 1, Name: "Random spawn bonus"}], Name: "generic.followRange"}, {Base: 0.0d, Name: "generic.attackKnockback"}], FoodLevel: 0b, Invulnerable: 0b, FallFlying: 0b, ForcedAge: 0, Gossips: [], PortalCooldown: 0, AbsorptionAmount: 0.0f, LastRestock: 0L, FallDistance: 0.0f, DeathTime: 0s, Xp: 154, LastGossipDecay: 59084674L, HandDropChances: [0.085f, 0.085f], PersistenceRequired: 0b, Age: 0, Motion: [1.5069371136687602E-4d, -0.0784000015258789d, 0.07366114333699925d], UUIDLeast: -6511835637120788481L, Health: 20.0f, LeftHanded: 1b, Air: 300s, OnGround: 1b, Dimension: 0, Offers: {Recipes: [{maxUses: 16, buyB: {id: "minecraft:air", Count: 1b}, buy: {id: "minecraft:coal", Count: 15b}, sell: {id: "minecraft:emerald", Count: 1b}, xp: 2, uses: 0, priceMultiplier: 0.05f, specialPrice: 0, demand:{color:#FF0000}-860128{color}, rewardExp: 1b}, {maxUses: 12, buyB: {id: "minecraft:air", Count: 1b}, buy: {id: "minecraft:emerald", Count: 1b}, sell: {id: "minecraft:stone_hoe", Count: 1b, tag: {Damage: 0}}, xp: 1, uses: 0, priceMultiplier: 0.2f, specialPrice: 0, demand:{color:#FF0000}-645096{color}, rewardExp: 1b}, {maxUses: 12, buyB: {id: "minecraft:air", Count: 1b}, buy: {id: "minecraft:iron_ingot", Count: 4b}, sell: {id: "minecraft:emerald", Count: 1b}, xp: 10, uses: 0, priceMultiplier: 0.05f, specialPrice: 0, demand: -209664, rewardExp: 1b}, {maxUses: 12, buyB: {id: "minecraft:air", Count: 1b}, buy: {id: "minecraft:emerald", Count: 36b}, sell: {id: "minecraft:bell", Count: 1b}, xp: 5, uses: 0, priceMultiplier: 0.2f, specialPrice: 0, demand: -209664, rewardExp: 1b}, {maxUses: 3, buyB: {id: "minecraft:air", Count: 1b}, buy: {id: "minecraft:emerald", Count: 13b}, sell: {id: "minecraft:iron_axe", Count: 1b, tag: {Enchantments: [{lvl: 1s, id: "minecraft:fortune"}, {lvl: 2s, id: "minecraft:efficiency"}], Damage: 0}}, xp: 10, uses: 0, priceMultiplier: 0.2f, specialPrice: 0, demand: -20880, rewardExp: 1b}, {maxUses: 3, buyB: {id: "minecraft:air", Count: 1b}, buy: {id: "minecraft:emerald", Count: 19b}, sell: {id: "minecraft:iron_pickaxe", Count: 1b, tag: {Enchantments: [{lvl: 1s, id: "minecraft:fortune"}, {lvl: 2s, id: "minecraft:efficiency"}, {lvl: 2s, id: "minecraft:unbreaking"}], Damage: 0}}, xp: 10, uses: 0, priceMultiplier: 0.2f, specialPrice: 0, demand: -20880, rewardExp: 1b}]}, Rotation: [359.74698f, 0.0f], HandItems: [{}, {}], RestocksToday: 0, ArmorDropChances: [0.085f, 0.085f, 0.085f, 0.085f], UUIDMost: 5094727900297841637L, Pos: [-205.50368003352455d, 69.0d, -142.2608681928114d], Fire: -1s, ArmorItems: [{}, {}, {}, {}], CanPickUpLoot: 1b, VillagerData: {profession: "minecraft:toolsmith", level: 3, type: "minecraft:plains"}, HurtTime: 0s, Inventory: [{id: "minecraft:wheat", Count: 64b}, {id: "minecraft:wheat_seeds", Count: 24b}, {id: "minecraft:potato", Count: 4b}, {id: "minecraft:wheat", Count: 1b}]}Villager demand values decrease indefinitely over time, some reaching minus 3 million in my Realms world. This makes it pretty much impossible to ever reach positive values again (except by underflow). New villagers or new trades start with zero or low values like -24, but over time they go into negative thousands, hundred thousands and so on. Villagers from 1.13.2 which haven't been traded with in 1.14.x or have not restocked, have a demand value of 0.
Also, according to MerchantOffer.java, the following code (MCP mappings) doesn't seem to have an underflow protection, so I expect very high positive values after reaching minus 2 billion and some, potentially leading to very high prices (clamped to max. stack size):
this.demand = this.demand + this.uses - (this.maxUses - this.uses);
Relates to
MC-156574which has been marked as fixed.Example for an 1.13.2 butcher that has been traded with in 1.14.x:
{Brain: {memories: {"minecraft:home": {pos: [I; -192, 69, -155], dimension: "minecraft:overworld"}, "minecraft:last_slept": 59095829L, "minecraft:last_worked_at_poi": 58818687L}}, HurtByTimestamp: 0, Attributes: [{Base: 20.0d, Name: "generic.maxHealth"}, {Base: 0.0d, Name: "generic.knockbackResistance"}, {Base: 0.5d, Name: "generic.movementSpeed"}, {Base: 0.0d, Name: "generic.armor"}, {Base: 0.0d, Name: "generic.armorToughness"}, {Base: 16.0d, Modifiers: [{UUIDMost: -1878018487258559006L, UUIDLeast: -9174853231443965336L, Amount: 0.07413098408231238d, Operation: 1, Name: "Random spawn bonus"}], Name: "generic.followRange"}, {Base: 0.0d, Name: "generic.attackKnockback"}], FoodLevel: 0b, Invulnerable: 0b, FallFlying: 0b, ForcedAge: 0, Gossips: [], PortalCooldown: 0, AbsorptionAmount: 0.0f, LastRestock: 2906L, FallDistance: 0.0f, DeathTime: 0s, Xp: 18, LastGossipDecay: 59084674L, HandDropChances: [0.085f, 0.085f], PersistenceRequired: 0b, Age: 0, Motion: [0.0d, -0.0784000015258789d, 0.0d], UUIDLeast: -6538277718517827106L, Health: 20.0f, LeftHanded: 0b, Air: 300s, OnGround: 1b, Dimension: 0, Offers: {Recipes: [{maxUses: 14, buyB: {id: "minecraft:air", Count: 0b}, buy: {id: "minecraft:porkchop", Count: 15b}, sell: {id: "minecraft:emerald", Count: 1b}, xp: 1, uses: 0, priceMultiplier: 0.0f, specialPrice: 0, demand: -502220, rewardExp: 1b}, {maxUses: 25, buyB: {id: "minecraft:air", Count: 0b}, buy: {id: "minecraft:chicken", Count: 15b}, sell: {id: "minecraft:emerald", Count: 1b}, xp: 1, uses: 0, priceMultiplier: 0.0f, specialPrice: 0, demand: -896806, rewardExp: 1b}, {maxUses: 7, buyB: {id: "minecraft:air", Count: 0b}, buy: {id: "minecraft:coal", Count: 21b}, sell: {id: "minecraft:emerald", Count: 1b}, xp: 1, uses: 0, priceMultiplier: 0.0f, specialPrice: 0, demand: -251106, rewardExp: 1b}, {maxUses: 7, buyB: {id: "minecraft:air", Count: 0b}, buy: {id: "minecraft:emerald", Count: 1b}, sell: {id: "minecraft:cooked_porkchop", Count: 6b}, xp: 1, uses: 0, priceMultiplier: 0.0f, specialPrice: 0, demand: -251114, rewardExp: 1b}, {maxUses: 7, buyB: {id: "minecraft:air", Count: 0b}, buy: {id: "minecraft:emerald", Count: 1b}, sell: {id: "minecraft:cooked_chicken", Count: 6b}, xp: 1, uses: 0, priceMultiplier: 0.0f, specialPrice: 0, demand: -251116, rewardExp: 1b}]}, Rotation: [179.12813f, 0.0f], HandItems: [{}, {}], RestocksToday: 0, ArmorDropChances: [0.085f, 0.085f, 0.085f, 0.085f], UUIDMost: -4706437458691471725L, Pos: [-196.49274613473273d, 72.0d, -165.24950263469773d], Fire: -1s, ArmorItems: [{}, {}, {}, {}], CanPickUpLoot: 1b, VillagerData: {profession: "minecraft:butcher", level: 9, type: "minecraft:plains"}, HurtTime: 0s, Inventory: [{id: "minecraft:wheat_seeds", Count: 24b}, {id: "minecraft:wheat", Count: 24b}, {id: "minecraft:carrot", Count: 6b}, {id: "minecraft:wheat", Count: 21b}]}Example for an 1.14.x toolsmith:
{Brain: {memories: {"minecraft:meeting_point": {pos: [I; -205, 72, -144], dimension: "minecraft:overworld"}, "minecraft:home": {pos: [I; -213, 71, -161], dimension: "minecraft:overworld"}, "minecraft:last_slept": 59095924L, "minecraft:last_worked_at_poi": 59092641L, "minecraft:job_site": {pos: [I; -196, 68, -144], dimension: "minecraft:overworld"}}}, HurtByTimestamp: 0, Attributes: [{Base: 20.0d, Name: "generic.maxHealth"}, {Base: 0.0d, Name: "generic.knockbackResistance"}, {Base: 0.5d, Name: "generic.movementSpeed"}, {Base: 0.0d, Name: "generic.armor"}, {Base: 0.0d, Name: "generic.armorToughness"}, {Base: 48.0d, Modifiers: [{UUIDMost: -73376431933667821L, UUIDLeast: -6176652968726733404L, Amount: 0.033869891415886366d, Operation: 1, Name: "Random spawn bonus"}], Name: "generic.followRange"}, {Base: 0.0d, Name: "generic.attackKnockback"}], FoodLevel: 0b, Invulnerable: 0b, FallFlying: 0b, ForcedAge: 0, Gossips: [], PortalCooldown: 0, AbsorptionAmount: 0.0f, LastRestock: 0L, FallDistance: 0.0f, DeathTime: 0s, Xp: 154, LastGossipDecay: 59084674L, HandDropChances: [0.085f, 0.085f], PersistenceRequired: 0b, Age: 0, Motion: [1.5069371136687602E-4d, -0.0784000015258789d, 0.07366114333699925d], UUIDLeast: -6511835637120788481L, Health: 20.0f, LeftHanded: 1b, Air: 300s, OnGround: 1b, Dimension: 0, Offers: {Recipes: [{maxUses: 16, buyB: {id: "minecraft:air", Count: 1b}, buy: {id: "minecraft:coal", Count: 15b}, sell: {id: "minecraft:emerald", Count: 1b}, xp: 2, uses: 0, priceMultiplier: 0.05f, specialPrice: 0, demand: -860128, rewardExp: 1b}, {maxUses: 12, buyB: {id: "minecraft:air", Count: 1b}, buy: {id: "minecraft:emerald", Count: 1b}, sell: {id: "minecraft:stone_hoe", Count: 1b, tag: {Damage: 0}}, xp: 1, uses: 0, priceMultiplier: 0.2f, specialPrice: 0, demand: -645096, rewardExp: 1b}, {maxUses: 12, buyB: {id: "minecraft:air", Count: 1b}, buy: {id: "minecraft:iron_ingot", Count: 4b}, sell: {id: "minecraft:emerald", Count: 1b}, xp: 10, uses: 0, priceMultiplier: 0.05f, specialPrice: 0, demand: -209664, rewardExp: 1b}, {maxUses: 12, buyB: {id: "minecraft:air", Count: 1b}, buy: {id: "minecraft:emerald", Count: 36b}, sell: {id: "minecraft:bell", Count: 1b}, xp: 5, uses: 0, priceMultiplier: 0.2f, specialPrice: 0, demand: -209664, rewardExp: 1b}, {maxUses: 3, buyB: {id: "minecraft:air", Count: 1b}, buy: {id: "minecraft:emerald", Count: 13b}, sell: {id: "minecraft:iron_axe", Count: 1b, tag: {Enchantments: [{lvl: 1s, id: "minecraft:fortune"}, {lvl: 2s, id: "minecraft:efficiency"}], Damage: 0}}, xp: 10, uses: 0, priceMultiplier: 0.2f, specialPrice: 0, demand: -20880, rewardExp: 1b}, {maxUses: 3, buyB: {id: "minecraft:air", Count: 1b}, buy: {id: "minecraft:emerald", Count: 19b}, sell: {id: "minecraft:iron_pickaxe", Count: 1b, tag: {Enchantments: [{lvl: 1s, id: "minecraft:fortune"}, {lvl: 2s, id: "minecraft:efficiency"}, {lvl: 2s, id: "minecraft:unbreaking"}], Damage: 0}}, xp: 10, uses: 0, priceMultiplier: 0.2f, specialPrice: 0, demand: -20880, rewardExp: 1b}]}, Rotation: [359.74698f, 0.0f], HandItems: [{}, {}], RestocksToday: 0, ArmorDropChances: [0.085f, 0.085f, 0.085f, 0.085f], UUIDMost: 5094727900297841637L, Pos: [-205.50368003352455d, 69.0d, -142.2608681928114d], Fire: -1s, ArmorItems: [{}, {}, {}, {}], CanPickUpLoot: 1b, VillagerData: {profession: "minecraft:toolsmith", level: 3, type: "minecraft:plains"}, HurtTime: 0s, Inventory: [{id: "minecraft:wheat", Count: 64b}, {id: "minecraft:wheat_seeds", Count: 24b}, {id: "minecraft:potato", Count: 4b}, {id: "minecraft:wheat", Count: 1b}]}
Added Affects Versions: 1.16.2-pre1
@TorteShui I cannot see any situation where a changing of the search radius to 1024 in overworld would break anything.
If somebody likes to be linked to a portal in a 128 range this would still work like now, cause if multple portals are in range, the closest matching portal is choosen as link partner.
So the only thing what would be changed, that no useless portals are created.
Your said it yourself, nether distances must be multiplied by 8 do get the correct overworld values.
So it would be logical that portal search radius in nether is 128 and search radius in overworld should be 1024 (128 multiplied by 8)
![[Mod] violine1101](../../../data/avatars/users/92858.png){kind=small}
I have the same problem: villagers saw the beds in my house next to the village, could not get there, but kept on trying, so I destroyed the beds, but they still try and get there. Sounds exactly what Tim described (thank you for that excellent description!).
Updated to only cover one issue, so could be reopened, thank you.
Probably more likely to duplicate
MC-145758(which is fixed already) instead ofMC-145863(both of those are marked as related, but not duplicates)?I found it worth mentioning that it is updated villagers from 1.13, not new ones (which seem to be ok) and they all started doing that without any prior interaction after the update.
If it is indeed the same issue as
MC-145758, then it's all good, thoFor the golems,
MC-145766also is marked as fixed already, butMC-149443is not - they are also shown as related, but not duplicates.I see. Thank you for the explanation
Copying from
MC-149783because it might have additional info:World was created in 1.13.2 in MC Realms. As preparation for 1.14, lots of beds were placed (more than existing villagers). After updating to 1.14, all villagers were in love mode without any prior interaction after the update. A handful of children spawned (probably up to the number of beds), but most villagers have been staying in love mode ever since. Work stations have been placed now, but this issue appeared before. New village(r)s (created in 1.14) seem to be ok for me.
Same thing happens on Windows. You actually can move forward sometimes if you press W over and over again, but not always. Maybe I was turning slightly sideways when I succeeded (what Yuma suggested)...
Could it be that accepting string names for difficulty in server.properties now can lead to a problem? Like failed conversion from string to integer for non-default strings, ending up with 0 (peaceful)?
It happens in both teleport directions - you end up in the destination dimension, but at the source dimension's coordinates.
In my world, I always get my home base's beacon effects when entering a portal in the overworld (far from my base) and entering the nether, assuming I was at the nether coordinates, but in the overworld for a brief moment.
Same issue happens with parrots when walking into a portal, keeping the overworld chunk loaded by a 2nd player to enable the parrot teleporting to the player when exiting the nether. Parrot should stay there when player enters the nether, but often vanishes and can be found again in the overworld at the nether coordinates of the portal. I assume it tries to teleport to the player in between changing dimension and coordinates. Could be related to
MC-123147.Potentially related to
MC-98153See comment https://bugs.mojang.com/browse/MC-98153?focusedCommentId=558285&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-558285
@Jim: Could you provide your coordinates? Maybe you have an edge case where one side of the portal is still in range and the other is not...
Hm, the x coordinate is almost an edge case: -174*8 is -1392 and it would find portals in a distance of 128 from that - which covers the range from -1264 to -1520, so your -1513 is very close to the edge (and it could well be that only a distance of 127 is still in range and 128 is already out).
Edit: According to the source code, coordinates from -128 to 128 (inclusive) are checked.
Your x coordinate in the nether is the same for both sides, but I don't know what coordinate exactly is used (the one from the portal or the one of the player), so maybe it depends on where you are standing when entering it. The z coordinates are nowhere near an edge case.
Edit: According to the source code, the player position is used, so it really may depend where exactly you are standing in the portal.
I assume that if you moved one portal a bit closer to the other (1 block in the nether or 8 blocks in the overworld), they should link reliably. As for the "bug" itself, my understanding is that it is probably working as intended (search distance always being 128 in the destination dimension), even if that leads to an asymmetric linking. At least it's always been like that...
Edit: "It has always been like that" is probably no good reason,
but this behavior is used for one-way fast travel, so changing it now would break existing content.@Radon8472 You are right because the one-way fast travel relies on a 2nd portal in the overworld already being there (where the "useless" portal would be created otherwise) - so this would not break. I am however not sure if there are other usecases that rely on this behavior - but it's not my decision anyway
Try using a hopper minecart instead of a hopper, because it sucks in items faster. I think, the lava burns the drops faster now. Not sure if it's a bug, intended or side-effect from changed mechanics, but this should help, at least.
Could you provide the world before and after the update, please, together with logs and what you did apart from upgrading with --forceUpgrade (if you did anything else before it happened)? This might be a good example to reproduce the issue which would help the devs lots, I guess...
Could this be related to https://bugs.mojang.com/browse/MC-146360 and https://bugs.mojang.com/browse/MC-147174, even though the latter is marked as Fixed? Were the beds of disappeared villagers next to walls?
One report was that skipping night by sleeping caused disappearances. Maybe that could make it worse, but not being the only cause...
There have been issues with mobs glitching into walls when the world loads and suffocating there, maybe caused by starting to wander before the blocks have loaded. Maybe another potential reason (not sleep-related).
Could it be that the RegionFileCache is still valid and filled when switching worlds or reloading the same world in case of a slow computer or heavy lag? Maybe clearing the cache inside RegionFileCache.close() after closing all RegionFiles could help then?
The skin is probably made for the Alex player model with thinner arms and you got the Steve model. You could try editing the texture or just change the player model.
Bedrock Edition seems to have a similar problem (see
MCPE-46064), maybe one or two of these issues are happening in Java Edition as well:Can anyone who is having this problem confirm if any of this is the case in their world? I have not been able to reproduce it in a village with 68 villagers - each and every one of them is fine. I have slept through the night and stayed awake, was alone on the (Realms) server and with other players. I keep track of the villagers using the command output of their NBT data and only noticed that some of them (who have not been traded with) keep changing professions or trades, making it appear as if one special villager is gone while he only changed profession. I haven't experienced any real vanishing, but from the reports, others have. Not that I am complaining that it does not happen for me, but I don't want to login one day and find them all gone.
Right, that's true. I did some tests yesterday, incl. relogging quite a few times at night with lots of sleeping villagers around, and while I did see them move around and their heads going further and further into the wall, none did suffocate. Immediately after relogging they were all perfectly aligned on their beds (not standing) and then shifted back into their previous position. I didn't test a 2-block high ceiling.
Both of our villages are in the spawn chunks as well, and both are completely fine. The world was created in 1.13.2, updated to 1.14 and then to 1.14.4 directly (we skipped .1-.3 because of the bugs). So some villagers are the 1.13.2 ones, all leveled up, most were born in 1.14 due to
MC-145863and one in 1.14.4. Most have been traded with at least once, the remaining few sometimes change trades or profession. (Maybe this info can help seeing a pattern, although I doubt it.)The z coords should be fine, but 56*8+128=576 is smaller than 581, so it doesn't connect on the way back. The difference is very small, tho, so maybe entering in a certain way and standing a little closer towards the coordinate that is just enough seems to have worked before (since it uses the player coords)...
Would it be possible to add a short description when an issue is resolved, so we could know what caused it and maybe how to prevent it until the fix gets rolled out? Thank you!
But if we knew some more details, we could maybe avoid certain situations that are more likely to trigger it, e.g. if the race condition only happens on server shutdown or start, on dimension change etc., what log output to look out for if there is any and so on. Not just for this bug report, but in general. I don't know how many would be interested in such more detailed information and if you can provide it, and I know this is not the right place for a discussion about it, but it would be cool if that could be considered where appropriate. Thank you ^^
That's good to know, thank you, also for taking the time to fix so many things for the next update!
I have this issue, especially with chicken and villagers, in 1.14.4. Chicken just escape a fenced off area, while villagers somehow even manage to escape a village that is fenced off twice, with a cobblestone wall and another 2.5 high block wall 2 blocks outside the first one. The village is partly inside spawn chunks and some players also have their bases in a distance that might keep only half of the village loaded.
I attached 2 screenshots that show the part that is not inside spawn chunks anymore, but closer to players' bases. This is one of the parts where villagers seemd to have gotten out. There are no beds anywhere near the walls and no baby villagers growing up. One of the villagers was unemployed, one was a nitwit (in the screenshot), but also employed villagers have gone missing and some even vanished (probably died).
I don't think it's related to MC-153904 since the villagers and chicken usually don't vanish, but can be found outside the fenced-off area. Only 2 villagers have gone so far and they probably died (and not just vanished) because I witnessed one being chased by a zombie at night who would have died as well if I hadn't been there. I can't be 100% sure because I can't see the server logs on Realms, but I keep track of all the villagers and of over 50 villagers in this village only 2 have gone, but several more have been found outside and brought back in.
Villagers being on the other side of the wall sounds like
MC-2025.I have the same issue. Launcher updated today, to version 2.1.9616. Trying to start it, it pops up briefly in task manager, but vanishes after one second. No entries in debug.log, no log file created in .minecraft/logs folder.
Windows 7 for me, JRE 1.8.0_51 (in MC's runtime folder). Trying to run MC 1.14.4, but the launcher doesn't even get there.
There was a Windows update as well: KB4525235 and KB4523206, in case that's relevant.
Edit: launcher_log.txt says:
See
MCL-12539(incl. comments).Not sure. Moving the .minecraft folder "fixed" it and the launcher also loaded launcher_skins.json. Copying that to the original .minecraft folder and using that again still didn't work. Renaming launcher_profiles.json, so it created a new one, helped, but not sure what was wrong with the old one.
Might work for the reporter and others too, but of course I don't know.
I think, Mojang changed something with Nether portals for 1.15 to make lookup faster. They might be caching the coordinates of already found portals and maybe there still is a bug. I read something similar a while ago which was supposed to be fixed, tho. I don't remember the issue number, tho. The 128 block thing is not just a theory, it is in the (1.14) code - it always looks at every block in that range to find a portal block (in the target dimension) and then takes the closest one.
Yes, I have, like many others here. I just use Forge for that because it's easy, but there are other methods as well.
I don't know if it's a bug or intentional (probably, for performance reasons - checking 1024x256x1024 blocks is much heavier than 128x256x128). It is surprising behavior for sure, especially for new people, so I agree that it should be changed, whether it's a bug or not (unless there really is a useful usecase for this). Maybe the performance improvements Mojang did for 1.15 (maybe caching or keeping all portal coords stored) are a first step into that direction. Maybe it will be done in 1.16, the Nether Update - but that's just speculation and I think this is not the right place to discuss that since this is a bugtracker and not a discussion forum (and I don't want the Mods to smack us with a portal block or so ^^).
It is not a bug for me, just surprising behavior. And I never said it was wrong in the code, I just stated how it is implemented. Whether it is a bug or WAI is for Mojang to decide. Many of the other tickets are actual bugs, like new portals being generated right next to an existing one, even being within range, happening after changes had been made for 1.15 (not necessarily related to this ticket, maybe just performance optimizations like storing portal coords so the search is faster, potentially allowing a bigger search radius). The issue here is debatable and since my opinion doesn't help the developers, I won't post any more comments, because this is not a discussion forum.
Older comments suggested that the villagers didn't die (no death message), but just vanished. Is that still the case or are the missing villagers now just dying? Not sure if there is a death message for unnamed villagers...
I've had no disappearances in any of my villages at all. They are all lit up and fenced in. Not all villagers sleep because some forgot their beds (and workstations) which is another known bug. Some of them roam around the edge of the village, searching for POIs, and I've had occurences of them glitching through a double fence-wall combination (see
MC-2025), ending up outside the safe area (luckily none got killed recently). That might explain why villagers who don't sleep are affected.Glitching through walls can also happen when getting out of bed (see MC-152945), maybe even glitching into walls and suffocating? That might explain why villagers who do sleep are affected. The ones in my villages sometimes sleep near walls, but not in tight spaces and often with glass (panes) at the walls. They also slide off, with their heads sometimes dangerously far inside the wall, but nothing happened (yet).
In the screenshot Maria Lemón sent, it seems as if the villages of one chunk all vanished, without any walls next to their beds (if I interpreted it correctly). This is not explained by my speculation above, so I also think it is actually several possible reasons. One question is what I asked first, whether they die or just vanish/despawn. Has anyone observed it happening in current versions?
I brought back most of the bees that flew north-west and put them into an enclosed area with empty beehives inside. They did not use the new beehives, only newly bred bees did. However, when I took the outside beehives and the bee nest (with silk touch, in case it matters) and put them back, they suddenly used the new beehives inside the enclosed area.
This seems to indicate that they still considered the outside beehives as theirs, but couldn't get in because they were full (not anymore, but they were probably full when they tried to get into them) and thus flew away. As soon as they noticed they were gone, they stopped seeing them as theirs and were free to find a new one.
So, when bees try to find a beehive, that code should probably be synchronized (mutex, critical section), so that it's impossible that 2 bees get assigned the last free spot in the beehive when actually only one can get it. (I don't think it's multi-threaded, but it can also happen in single-threaded code if all bees check for a free slot first before getting assigned to one.)
As a side note, this is a similar behavior like for villagers and beds/workstations as described in
MC-150806, so these issues might be related and the faulty code could be in a parent class of bees and villagers, probably some general POI assignment code.Possibly related to
MC-166980beecause bees seem to beehave similar with beehives: bees can stay attached to a beehive they can't use anymore (potentially by breaking and replacing or just over time) and then get stuck wandering to the north-west and refuse to get into another beehive until the original one is broken. See this comment: https://bugs.mojang.com/browse/MC-166980?focusedCommentId=632081&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-632081Villagers who lost their workstation also tend to wander to the edge of the village (many also accumulate in the north-west corner, but not all and it might be a coincidence), and combined with
MC-2025that makes them glitch through walls surrounding the village and then can't get back in, this makes it quite difficult to work with villagers (and bees).I have the same issue in a microfarm where I press left and right mouse button continously - left to break crops, right to place new ones which are then bonemealed by dispensers. The block behind the crops gets destroyed after a while (you can see the damage accumulating over time), only when I release the left mouse button every once in a while and allow the right click to hit the block behind, it becomes undamaged. Realms world in vanilla 1.15.2.
Sounds like duplicate of
MC-173100(which shouldn't be resolved as invalid).Affects 1.15.2 as well, had a glass block more than 10 blocks above the beacon and it only activated once I removed that block and placed the beacon again.
It also seems to happen when you load one world, exit it and load the next world immediately after, without waiting (jokubas' comments), probably while the first world is still being saved or internal data structures not cleared yet. Also when players logged into the same world twice at the same time, at least once via singleplayer, e.g.
MC-173080.Will the fix for 20w19a and later 1.16 also fix already existing naturally generated villagers-,-
i.e. is the follow range something in their NBT data or in the game code itself?Edit: Ok, found in
MC-166764that it's in their NBT data, but my original question kind of remains: Will that value be updated when updating the world to 1.16?This patch would clamp it to zero, but negative values are possible - they just shouldn't go that much into the negative...
I agree that it is for Mojang to decide and to find a correct fix.
Negative demand does something: it increases the necessary amount of trading before reaching positive demand again, so it does make sense to have it - but surely not below a certain level.
I think, MC now caches portal locations, and it seems that the cache did not get invalidated when destroying portal O1, so any attempt to go through N1 would always dump you at the old O1 location because it is still in the cache. If that's the case, it sounds like an actual bug and the ticket should be reopened.
Apparently, 1.16.2 (or earlier) fixes existing villagers, too. I updated the other day and wanted to fix them manually with "data modify entity", but they all had their values changed from 16 to 48 already. Thank you
We've been plagued with this bug on our Realms server for a while. We had over 80 villagers in one village and the number of golems got that high as well, so I had to regularly purge them. After updating to 1.16.2, I did my last purge so far and the number of golems has been stable at 32 since then (with a villager count of 91). This is the only village that is pretty much permanently loaded (next to my base, used to be in spawn chunks before I moved spawn). I didn't check the other villages, but at least in the next village that is at least sometimes loaded, there doesn't seem to be a crazy amount of golems spawning anymore either.
So for me this bug seems to be fixed and it doesn't happen in all villages anymore. Providing the (or a) world where this still happens could thus be helpful...
(In case it matters: world was created in 1.13.2 and subsequently updated to 1.14, 1.14.4, 1.15.2 and 1.16.2, skipping the in-between versions.)
The texture is different to the one before the texture update, that is correct. However, it is the same as the one in the New Default Betapack V2 (which is an older version of the updated textures) and still has the darker green outer ring which doesn't match the different side texture now (see the attached image). The inside is fine, just the ring should be updated in my opinion.
Easiest way to see the issue is just looking at assets\minecraft\textures\block\cactus_bottom.png in the client jar file.
It's not resolved yet, as of 1.18.2. I am constantly getting chunks loaded and the region/poi/entities files created/updated at the coordinates of the wrong dimension. Running on a vanilla server.
I noticed I had lost a villager in a village I haven't even been to since 1.17.1. Playing on a 1.18.2 vanilla server currently.
The region of the village was briefly loaded due to
MC-98153when going to or returning from the nether. The server created an entities file for this region and updated the poi and region files. This has happened with other regions as well, but this is the first time a villager vanished (replacing the affected files from the backup brought him back). There was nothing in the server or client logs.Whether or not
MC-98153is the root cause is unclear, but it was at least the trigger in this case. Commented on there as well.Please contact me if you need the world downloads (before and after it happened) - they're big, so I might have to strip them down first. Not sure if it would help, though, as I have done the same as today for quite some time and only today the issue happened, so it seems pretty sporadic.
I had the same issue as described before again and there seems to be a pattern. It might not be related to
MC-98153. This time a whole village has been wiped out.I have been working in the Nether and some nearby chunks with portals were loaded. I assume a piglin or it's zombified variant spawned close by and walked into the portal. The portals are in enclosed rooms with doors, but piglins can open doors and zombified ones can spawn in portals.
When (if that is what happened) they entered the portal, they caused the counterpart in the overworld to be loaded, but then probably instantly despawned because no player was around there. These regions were in villages and last loaded in 1.17.1 - the issue happened in 1.18.2. So upon loading this overworld region, the game attempts to convert the affected chunks, which you can see that the new caves are generated below zero (but only in a few chunks, not as much as you'd expect), and sometimes also a file in the entities/ folder if it didn't exist yet, otherwise it shows as changed.
My guess is that the chunks weren't loaded long enough for the conversion to be successfully completed (because the mob despawned), thus letting villagers (and potentially other mobs) disappear.
Not sure if this is a separate issue - if necessary, I can create an own bug report for this. I can also provide the world with and without the issue (I restored the affected entities/poi/region files from a backup), but the worlds are big and in principle this should happen to any 1.17.1 world with a portal in a village where a (hostile?) mob enters the portal in the nether in 1.18.2 without a player being in the overworld - probably not every time, though.