Coordinate math error causes structure not to generate and possibly other issues
The bug
A mistake in coordinate conversion math reduces the likelihood of structures spawning in negative coordinates. This might also cause the /locate command and cartographer maps to direct you to a non-existent structure. It may also be causing other glitches with structures (and other things) along chunk boundaries.
The correct way to find out which structure region a chunk belongs to requires special handling for negative numbers. E.g. for temples with a region size of 32 (pseudocode):
offsetChunk = chunk < 0 ? chunk - 32 + 1 : chunk; region = offsetChunk / 32;
That puts chunks -32 to -1 in region -1. This is how it's been computed in previous Minecraft versions.
But the new code flipped that +1 to a -1. But then when converting back after selecting the random chunk for structure spawning, it does it the same way it did before.
chunkForStructure = region*32 + random(24);
So, let's say you're chunk -31, 0. You end up in region -2, 0 instead of -1, 0. If the RNG had picked 1, you should have been the lucky chunk and gotten an igloo or something. But instead, it thinks it should put the igloo in chunk -63. But chunk -63 is part of region -3. Any time the RNG ever picks 0 or 1, it cannot generate a structure.
The other changes to structure generation are clearly deliberate, so this appears to be inadvertent.
I believe this was introduced in 18w06a.
Linked Issues
is duplicated by1
relates to6
MC-109311Woodland mansion failed to generateFixedMC-124915/locate and eye of ender find strongholds in invalid placesFixedMC-131436Stronghold structure failed to generateAwaiting ResponseMC-108801/locate command returns offset or incorrect mineshaft locationsCannot ReproduceMC-129767Dungeons not generating at same positions anymoreWorks As IntendedMC-134729End City failed to generateAwaiting Response
Created Issue:
Coordinate math error causes structure not to generate and possibly other issues
A mistake in coordinate conversion math reduces the likelihood of structures spawning in negative coordinates. It may be causing other glitches with structures (and other things) along chunk boundaries.
The correct way to find out which structure region a chunk belongs to requires special handling for negative numbers. E.g. for temples with a region size of 32 (pseudocode):
offsetChunk = chunk < 0 ? chunk - 32 + 1 : chunk; region = offsetChunk / 32;That puts chunks -32 to -1 in region -1. This is how it's been computed in previous Minecraft versions.
But the new code flipped that +1 to a -1. But then when converting back after selecting the random chunk for structure spawning, it does it the same way it did before.
chunkForStructure = region*32 + random(24);So, let's say you're chunk -31, 0. You end up in region -2, 0 instead of -1, 0. If the RNG had picked 1, you should have been the lucky chunk and gotten an igloo or something. But instead, it thinks it should put the igloo in chunk -63. But chunk -63 is part of region -3. Any time the RNG ever picks 0 or 1, it cannot generate a structure.
The other changes to structure generation are clearly deliberate, so this appears to be inadvertent.
I believe this was introduced in 18w06a.
Environment
Windows 10, Java, 1.13 snapshots and prerelease.
A mistake in coordinate conversion math reduces the likelihood of structures spawning in negative coordinates. This might also cause the /locate command and cartographer maps to direct you to a non-existent structure. It may also be causing other glitches with structures (and other things) along chunk boundaries.
The correct way to find out which structure region a chunk belongs to requires special handling for negative numbers. E.g. for temples with a region size of 32 (pseudocode):
offsetChunk = chunk < 0 ? chunk - 32 + 1 : chunk; region = offsetChunk / 32;That puts chunks -32 to -1 in region -1. This is how it's been computed in previous Minecraft versions.
But the new code flipped that +1 to a -1. But then when converting back after selecting the random chunk for structure spawning, it does it the same way it did before.
chunkForStructure = region*32 + random(24);So, let's say you're chunk -31, 0. You end up in region -2, 0 instead of -1, 0. If the RNG had picked 1, you should have been the lucky chunk and gotten an igloo or something. But instead, it thinks it should put the igloo in chunk -63. But chunk -63 is part of region -3. Any time the RNG ever picks 0 or 1, it cannot generate a structure.
The other changes to structure generation are clearly deliberate, so this appears to be inadvertent.
I believe this was introduced in 18w06a.
![[Mod] Michael Wobst](../../../data/avatars/users/37868.png){kind=small}
A mistake in coordinate conversion math reduces the likelihood of structures spawning in negative coordinates. This might also cause the /locate command and cartographer maps to direct you to a non-existent structure. It may also be causing other glitches with structures (and other things) along chunk boundaries.
The correct way to find out which structure region a chunk belongs to requires special handling for negative numbers. E.g. for temples with a region size of 32 (pseudocode):
offsetChunk = chunk < 0 ? chunk - 32 + 1 : chunk; region = offsetChunk / 32;That puts chunks -32 to -1 in region -1. This is how it's been computed in previous Minecraft versions.
But the new code flipped that +1 to a -1. But then when converting back after selecting the random chunk for structure spawning, it does it the same way it did before.
chunkForStructure = region*32 + random(24);So, let's say you're chunk -31, 0. You end up in region -2, 0 instead of -1, 0. If the RNG had picked 1, you should have been the lucky chunk and gotten an igloo or something. But instead, it thinks it should put the igloo in chunk -63. But chunk -63 is part of region -3. Any time the RNG ever picks 0 or 1, it cannot generate a structure.
The other changes to structure generation are clearly deliberate, so this appears to be inadvertent.
I believe this was introduced in 18w06a.
The bug
A mistake in coordinate conversion math reduces the likelihood of structures spawning in negative coordinates. This might also cause the /locate command and cartographer maps to direct you to a non-existent structure. It may also be causing other glitches with structures (and other things) along chunk boundaries.
The correct way to find out which structure region a chunk belongs to requires special handling for negative numbers. E.g. for temples with a region size of 32 (pseudocode):
offsetChunk = chunk < 0 ? chunk - 32 + 1 : chunk; region = offsetChunk / 32;That puts chunks -32 to -1 in region -1. This is how it's been computed in previous Minecraft versions.
But the new code flipped that +1 to a -1. But then when converting back after selecting the random chunk for structure spawning, it does it the same way it did before.
chunkForStructure = region*32 + random(24);So, let's say you're chunk -31, 0. You end up in region -2, 0 instead of -1, 0. If the RNG had picked 1, you should have been the lucky chunk and gotten an igloo or something. But instead, it thinks it should put the igloo in chunk -63. But chunk -63 is part of region -3. Any time the RNG ever picks 0 or 1, it cannot generate a structure.
The other changes to structure generation are clearly deliberate, so this appears to be inadvertent.
I believe this was introduced in 18w06a.
Windows 10, Java, 1.13 snapshots and prerelease.
![[Mojang] Adrian Östergård](../../../data/assets/gravatar/nighter.jpeg){kind=small}
ProfMobius (Thomas Guimbretiere)![[Mod] Neko](../../../data/avatars/users/92901.png){kind=small}
![[Mod] tryashtar](../../../data/avatars/users/41963.png){kind=small}
is duplicated by
relates to
relates to
relates to
relates to
Please check to see if this is still an issue in 1.13-pre4. Possibly fixed alongside MC-131462.
![[Helper] Michał](../../../data/avatars/users/43368.png){kind=small}
Witch hut can not generate in 1.13 snapshots/prereleases.
Seed: 5178019746038571832
Coords: /tp @s 1779 69 -3979
In 1.12 you've been teleported on top of witch hut. In 1.13 there's no witchhut nearby. Structures as far as i know should stay close to old locations, just with different variants, like villages.
This bug might be related to MC-131436 and MC-131462
Side note: Ocean monument appeared at 1700 70 -3850 which didn't exist in 1.12.
Please reopen MC-131462
The bug
A mistake in coordinate conversion math reduces the likelihood of structures spawning in negative coordinates. This might also cause the /locate command and cartographer maps to direct you to a non-existent structure. It may also be causing other glitches with structures (and other things) along chunk boundaries.
The correct way to find out which structure region a chunk belongs to requires special handling for negative numbers. E.g. for temples with a region size of 32 (pseudocode):
offsetChunk = chunk < 0 ? chunk - 32 + 1 : chunk; region = offsetChunk / 32;
That puts chunks -32 to -1 in region -1. This is how it's been computed in previous Minecraft versions.
But the new code flipped that +1 to a -1. But then when converting back after selecting the random chunk for structure spawning, it does it the same way it did before.
chunkForStructure = region*32 + random(24);
So, let's say you're chunk -31, 0. You end up in region -2, 0 instead of -1, 0. If the RNG had picked 1, you should have been the lucky chunk and gotten an igloo or something. But instead, it thinks it should put the igloo in chunk -63. But chunk -63 is part of region -3. Any time the RNG ever picks 0 or 1, it cannot generate a structure.
The other changes to structure generation are clearly deliberate, so this appears to be inadvertent.
This was reintroduced in 1.13-pre7.
Reopened MC-131462.
MC-131462 was fixed for next version (probably 1.13.1), that issue may be the cause of this.
Is this related to MC-131462 by any chance?
Might this be related to MC-131462 by any chance?
This is unlikely to be related to MC-131462
Please check if this is still an issue in new worlds now that MC-131462 is fixed.
You're being pedantic. Neko said "Please check if this is still an issue in new worlds now that MC-131462 is fixed.", hence why I said "fixed."
My questions all still stand. Do I need to download a new jar for multiplayer or do I just update my client? Would this affect only generated chunks or will it affect all chunks in the game and would require a completely new world?
I don't have the ability to run two multiplayer servers right now nor do I have the ability to wipe my current one or temporarily take it down while others are playing, so the more information given the more likely I will be able to do some actual testing.
Using seed in the description and coor given by /locate.
Once teleported there I die (in creative mode) due to being out of the world.
Relates to MC-131462
Linked to wrong one @Kumasasa
Here is the exact change.
The 1.12 code is:
The 1.13 code is (ignoring some irrelevant differences in where the constants come from):
Subtle!
Put another way:
chunkX -= this.maxDistanceBetweenScatteredFeatures - 1;is the equivalent of:
which when simplified is:
Really good catch and very subtle error.
This bug was reintroduced in 1.13-pre7.
I was already wondering why some shipwrecks and ocean ruins I knew from older snapshots seemed to be gone lately. I hope this severe world generation problem doesn't get forgotten before we get 1.13 and people all around the globe start new worlds with no updates around for months.
I implore Mojang to consider that a working world generator is essential, especially since it just got a major overhaul and many people will restart at least parts of their world. When a chunk is generated, you can't repair it anymore. Having this working in the proper release and not be touched for a significant amount of time is more important than keeping exactly to some arbitrarily chosen release date.
Yes, unless coordinates for the new structures are handled separately, shipwrecks and ocean ruins would be impacted more greatly because of their smaller region size. There would be ~25% fewer shipwrecks and ocean ruins overall (and all the missing ones would be in negative X or Z coordinates).
This is a nasty regression. Thanks for catching it up. It is now fixed again.
I apologize for not noticing until literally the last minute.
The question is when 1.13.1 is scheduled for, seeing how this is a major world generation fix preferable to be out as soon as possible.
Yes this correct. I can confirm this is the case. i too am getting this problem in my world. far less dungeons are being generated and this is also the case for guardian temples.
I am using the 1.13 release and when i look at the 1.12.2 for every 1 dungeons in 1.13 there is 4 in 1.12.2 this from me looking at my seed and writing down the locations then flying to those chunks and looking around
It's already fixed. Confirm for 18w30a when it is released.
thanks Matthew For info
Please were can i see the problems that have been fixed with the next roll out and the date we can expect them.
Again many thanks for replying so quickly.
Right now. It just came out right now!
@simon - This bug does not affect dungeons or strongholds at all.
It has a relatively small effect on guardian temples (maybe 1.5% are missing compared with ~25% of shipwrecks and ocean ruins, and about ~8% of villages, witch huts, etc).
1.13 naturally has a lot fewer guardian temples than 1.12 because of the changes in ocean generation. They require deep ocean (any kind of deep ocean) and there is less deep ocean now. There is no such thing as warm deep ocean, so you'll get shallow warm ocean where you might have gotten deep ocean before. Also there is less deep ocean near shorelines for somewhat complicated reasons. So fewer guardian temples is mostly WAI.
Hmm, the ocean ruins I missed seem to be back, but the two shipwrecks I lost are still gone. I guess they just changed the shipwreck algorithm in some previous snapshot.
I've verified that this is fixed in 18w30a.
It hasn't fixed /locate
MC-108801