When loading a world from any previous version, the save data of the new Nether biomes (soul sand valleys, crimson forests, warped forests, basalt deltas) is ignored and the biome that would generate there according to natural world generation is used instead. For all other biomes, the save data is respected.
How to reproduce
This way to reproduce by @unknown uses custom worlds, however this can just as well be reproduced by editing the world save data so that a new Nether biome appears where it shouldn't naturally generate (this edit will be removed when upgrading the world to 20w28a or above), or by using a world from the earlier 1.16 snapshots in which biome distribution was different.
Create a new world in 1.16.1 with cheats enabled
Download the
data pack and add it to the world
Close and reopen the world
Teleport to the dimension
194273:zoo
and wait for the surrounding terrain to be generated:/execute in 194273:zoo run teleport 0 100 0
Close the world and remove the "
checkerboard
" data packDownload the
data pack and add it to the world
Open the world in the latest snapshot/version
Travel through the previously generated terrain, noting the biome names displayed on the debug screen
→ ❌ Soul sand valleys, crimson forests, warped forests and basalt deltas all report "the_void
" as the current biome
→ ✔ All other biomes are reported correctly
Linked issues
is duplicated by 11
relates to 1
Attachments
Comments


This can be reproduced easily in any Nether terrain generated in an early 1.16 snapshot such as 20w06a. For example:
Create a new world in 20w06a with seed
194273
Run the following command:
/execute in the_nether run teleport -300 34 150
→ ✔ You should find yourself in a warped forest
Save the world and open it in the latest version
→ ❌ You are still in the warped forest, but the debug screen displays "soul_sand_valley
"

Notably, the nether_wastes
biome seems to be saved correctly, so as far as I can tell this issue does not affect any terrain generated in 1.15.2 or earlier. In other words, only worlds that have been opened in an early 1.16 snapshot can experience this issue. However, although upgrading from snapshots is not supported, it is likely that if this bug is left in the game, any future changes to Nether generation (specifically the placement of biomes) would cause the issue to appear in worlds upgraded from 1.16.1.
I found this also, its a pretty bad issue and needs to be resolved. worlds generated from an older version of 1.16 before 20w28a should have a fix in 1.16.2 so that running the world in 1.16.2 will fix the biome switch. Really hope this is possible, or we lose our nether survival world
What Noah said is right.I hope mojang can fix this as possible as they could.

The biome distribution was not expected to be stable during the snapshot cycle.
If this hasn't changed from the release of 1.16, there is no bug.
So what you are saying Adrian is that our worlds biomes are officially forever messed up and switched?
😞?
Well,if you choosed a snapshot to create your world,you have to take the risk of biome switched.And I think that's much more exciting(Actually I can build the hoglin farm nearer🙂)
@@unknown so, this will occur even worlds that weren't open in 28a, but will be opened in, for example, 20w29a?

@Devu: Based on the information provided, this only occurred in worlds first generated in the early 1.16 snapshots (i.e. 20w06a) - future compatibility for worlds from early development versions is never guaranteed, and issues like these can always occur - this is why, over and over again, a warning is given that snapshots are unstable.
@[Mod] Galaxy_2Alex I understand, but if this started to happen without changes in biome distribution, I asked if it'll still happen in worlds that skipped 20w28a

I'm not sure, but I assume it happens in 20w29a as well, though no reports have been received so far (to be fair, it took a full day for the nether biome issue to appear on the tracker in the first place since it only affects a very small amount of users).
Ok. Here's some extra info I have on the bug. It only happens when opening worlds in 20w28a or above so far. So for now, just run a backup of your nether save and play in 20w27a or earlier. 20w29a still expeiriences the bug, and from what it looks like, the issue might not end up getting fixed. Best option, I suppose is to learn how to use WorldEdit tools to change biomes around again, at least to preserve some builds.

@Yonas: Please read the moderator note, thanks.
Thank you Yonas K
world edit might be the fix

To clarify what the issue is here, the saved biome data for soul sand valleys, crimson forests, warped forests and basalt deltas is lost upon upgrading a world from before 20w28a to 20w28a or later. This includes worlds created in supported versions such as 1.16.1.
The locations of the biomes are then recalculated using the world seed. Since the biome locations haven't changed since 1.16.1, the biome data that is generated after upgrading matches the previously generated terrain. In other words, even when upgrading a world created in 1.16.1, the bug is still present, since the saved biome data is erased upon upgrading (for the biomes listed above). However, the bug is not apparent in this case, since the biome data that is subsequently recalculated will match the previously generated terrain.
Hence, as I mentioned in a previous comment, if this bug remains in the game and the biome distribution ever changes in a future version, then worlds created in 1.16.1 will be corrupted upon upgrading to that version. However, in case that isn't enough to justify reopening this ticket, here is a method to reproduce the issue using a world created in 1.16.1:
Create a new world in 1.16.1 with cheats enabled
Download the
data pack and add it to the world
Close and reopen the world
Teleport to the dimension
194273:zoo
and wait for the surrounding terrain to be generated:/execute in 194273:zoo run teleport 0 100 0
Close the world and remove the "
checkerboard
" data packDownload the
data pack and add it to the world
Open the world in the latest snapshot/version
Travel through the previously generated terrain, noting the biome names displayed on the debug screen
→ ❌ Soul sand valleys, crimson forests, warped forests and basalt deltas all report "the_void
" as the current biome
→ ✔ All other biomes are reported correctly
What Jacob smith says is correct. This is a bug, and if not reopened and dealt with then worlds even created in 1.16.1 and updated to 1.16.2 will have this issue, as the bug also applies now to 20w29a, and will progress through the snapshots to the release.
I am releasing a YouTube video about this next week and I will link it when it is out.
So, if the bug works by the biome distribution info not being saved when updating, does that mean you could fix the bug by copying that information from an earlier version pre 20w28a, saving it, and replacing the rewritten biome data with the older biome data?
I'm just asking, bc I genuinely don't know too well how this stuff works
You are all right,and Adrian said the biome distribution is not stable during the snapshots,so this might change.I also saw the biome distribution in the nether of my world onhttps://www.chunkbase.com/apps/biome-finder.And I choosed the option'Java 1.16 and above' .I saw that the biome distribution is the changed one,so we can know the biome distribution in the nether had changed in the versions before the release of 1.16. According to this,the REAL BUG is the biome distrbution has already changed in the snapshots or pre-release of 1.16.AND NOW IT IS APPERED IN 20W28A,BUT IN THE VERSION BEFORE IT IS NOT.
I've reopened this bug report since it is reproducible without using earlier 1.16 snapshots. I've confirmed the ticket and edited it with the new findings (thanks a lot @unknown!)
And if you open a world created in early 1.16 snapshots in 20w28a(make sure you have entered the nether),then open it in 1.16.1,the biomes are also switched.

This will be fixed in the next snapshot. However, if your world already has corrupt areas (from being opened in 20w28a or 20w29a) those areas will unfortunately stay corrupted. This is because the original biome information has been overwritten.
Alright. Firstly, a huge thanks to the mojang staff and Jacob Smith for listening to and helping fix this bug. 20w30a does not appear to be experiencing the problem anymore. However, many people reporting this bug believe that they may have lost their nether forever when updating to 20w28a. I want to offer a solution for them. Provided you haven't built anything in your corrupted nether, there is a way to undo the biome update. Go to your minecraft backups file and find a world save from 20w27a or earlier, and copy the DIM-1 file from it. That is the nether terrain for your minecraft world, old biome data included. take it and replace the DIM-1 file on your current world and you should have your nether before it was corrupted. (Note that it MUST be DIM-1, not DIM1, because that's your data for the End in your minecraft world)
Yonas K is there any way to only copy over where the biomes were in the world? Not just the terrain, as we actually made a ziglin farm in the nether and don’t want to lose it. If the data for the biomes were lost during updating to 20w28a, is there a way to manually move over only the biome locations? Say, from a earlier backup or from A new 1.16.1 world with the same seed?
Noah
not that I know of, and generally speaking you should be fine with resetting the nether to a pre 20w28a version of it. If you built anything in the nether during 20w28a and 20w29a, that work will be undone, unfortunately. It Might be possible to look for biome data within a backup file of an older version, but I have no idea how to access that, and even then, I'd want to be extremely careful with those types of files. In summary, you ((might)) be able to transfer older biome data to a newer version, but i don't know how it would be done, and toying around with the files of a survival world you invested a ton of time into can be very risky.
Yonas K thank you, I hope there is a way🙂
Please provide seed and coordinates of this occurring.