I have the solution for backwards compatibility of the worlds in Caves & Cliffs,
They are doing a good job adding from above and below and leaving the middle normal but with the new cave biomes it will not be possible to do so easily unless an algorithm is added that detects the constructions made by the world and by the Player to So rebuild the world without touching them, I myself could make a Mod that would do this but I only program in C # and well Minecraft is my favourite game, I don't know if Mojang's have already thought about this if they already do it right now or if this forum Only people who do not work there will read it like that, please send it to Mojang, Elmisterioso spoke to them.
Rollback Post to RevisionRollBack
I am El Misterioso also known as Elmisterioso or Elmisteriosoytz or Elmisteriosoxyz
in Minecraft I am Elmisterioso
Due to the way world generation works (even the same seed in the same version will not be exactly the same every time you recreate it, this is most noticeable when you explore the world in a different pattern) and the range of versions supported (there are even players who have played on the same world since Alpha, over 10 years ago), and random events that occur naturally (fires, endermen moving blocks, sheep eating grass, mushrooms and vines spreading, etc) it is simply not practical to try to detect player-made changes, and even less practical to try to seamlessly integrate them into very different terrain.
Also, players have had to go though updates like 1.18 many times before, even more minor updates like 1.13 (new ocean types) will leave borders between old and new terrain, and in the case of 1.18 they can simply add 1.18 terrain below y=0, converting the existing bedrock layer to stone but otherwise not touching existing terrain; sure, caves and structures will suddenly cut off at y=0 but did you know that they completely changed the underground generation in 1.13 without even telling anybody, in an update that wasn't even supposed to make any changes to it? Same thing in 1.7, even if it was a "world-changing" update, but they never made any mention of it and surface biome changes would of had no impact. Strongholds also appear to have changed as recently as 1.16 based on the fact that Chunkbase includes a separate version for it so there is already plenty of precedent for chunk borders underground even in relatively new worlds.
As for higher terrain, that only seems to be in "mountain" biomes and if they are simply replacing/changing the original biomes (much like recent revamps to other biomes) then the overall biome layout will not change and the only chunk borders will be where existing mountain biomes are. The height limit itself is of little importance; they increased it from 128 to 256 in 1.2 with no issues since terrain itself did not change (the chunk format was changed but they built in a converter for it; a much bigger change in save format occurred in 1.13 but again the game recognizes and coverts older worlds; since 1.9 every chunk has a version tag so the game can know exactly what version it was last saved in - even relatively minor updates, such as 1.15, have made such large changes to save data that downgrading a world ruins it entirely). 1.7 did increase the height limit of terrain from 128 to 256 but such high terrain was limited to a few biomes (mostly Savanna Plateau M) and the changes to the overall biome map were far more disruptive.
This is also likely why Mojang is adding negative y-coordinates instead of simply raising sea level, as I did in my own "double/triple height" terrain mods, but even then they could simply raise old terrain by 64 blocks when converting worlds to the latest version (personally, I think this would be much easier given how much code depends on y=0 being the lowest point in a chunk, plus without negative y-coordinates you don't need to worry about properly flooring them; e.g. if simply cast to an int the range from -0.999...9 to -0.000...1 rounds up to 0 when it should round down to -1).
This is also likely why Mojang is adding negative y-coordinates instead of simply raising sea level, as I did in my own "double/triple height" terrain mods, but even then they could simply raise old terrain by 64 blocks when converting worlds to the latest version (personally, I think this would be much easier given how much code depends on y=0 being the lowest point in a chunk, plus without negative y-coordinates you don't need to worry about properly flooring them; e.g. if simply cast to an int the range from -0.999...9 to -0.000...1 rounds up to 0 when it should round down to -1).
Players may have made systems based on existing coordinates (e.g. books and signs referring to level 63 as sea level). Shifting the y coordinate would disrupt this, even though other things like diamonds at 11 and lava at 10 and bedrock at 5 are all getting shifted anyway due to new generation.
I have the solution for backwards compatibility of the worlds in Caves & Cliffs,
They are doing a good job adding from above and below and leaving the middle normal but with the new cave biomes it will not be possible to do so easily unless an algorithm is added that detects the constructions made by the world and by the Player to So rebuild the world without touching them, I myself could make a Mod that would do this but I only program in C # and well Minecraft is my favourite game, I don't know if Mojang's have already thought about this if they already do it right now or if this forum Only people who do not work there will read it like that, please send it to Mojang, Elmisterioso spoke to them.
I am El Misterioso also known as Elmisterioso or Elmisteriosoytz or Elmisteriosoxyz
in Minecraft I am Elmisterioso
I own company Elmisterioso Team Games (ETG)
Due to the way world generation works (even the same seed in the same version will not be exactly the same every time you recreate it, this is most noticeable when you explore the world in a different pattern) and the range of versions supported (there are even players who have played on the same world since Alpha, over 10 years ago), and random events that occur naturally (fires, endermen moving blocks, sheep eating grass, mushrooms and vines spreading, etc) it is simply not practical to try to detect player-made changes, and even less practical to try to seamlessly integrate them into very different terrain.
Also, players have had to go though updates like 1.18 many times before, even more minor updates like 1.13 (new ocean types) will leave borders between old and new terrain, and in the case of 1.18 they can simply add 1.18 terrain below y=0, converting the existing bedrock layer to stone but otherwise not touching existing terrain; sure, caves and structures will suddenly cut off at y=0 but did you know that they completely changed the underground generation in 1.13 without even telling anybody, in an update that wasn't even supposed to make any changes to it? Same thing in 1.7, even if it was a "world-changing" update, but they never made any mention of it and surface biome changes would of had no impact. Strongholds also appear to have changed as recently as 1.16 based on the fact that Chunkbase includes a separate version for it so there is already plenty of precedent for chunk borders underground even in relatively new worlds.
As for higher terrain, that only seems to be in "mountain" biomes and if they are simply replacing/changing the original biomes (much like recent revamps to other biomes) then the overall biome layout will not change and the only chunk borders will be where existing mountain biomes are. The height limit itself is of little importance; they increased it from 128 to 256 in 1.2 with no issues since terrain itself did not change (the chunk format was changed but they built in a converter for it; a much bigger change in save format occurred in 1.13 but again the game recognizes and coverts older worlds; since 1.9 every chunk has a version tag so the game can know exactly what version it was last saved in - even relatively minor updates, such as 1.15, have made such large changes to save data that downgrading a world ruins it entirely). 1.7 did increase the height limit of terrain from 128 to 256 but such high terrain was limited to a few biomes (mostly Savanna Plateau M) and the changes to the overall biome map were far more disruptive.
This is also likely why Mojang is adding negative y-coordinates instead of simply raising sea level, as I did in my own "double/triple height" terrain mods, but even then they could simply raise old terrain by 64 blocks when converting worlds to the latest version (personally, I think this would be much easier given how much code depends on y=0 being the lowest point in a chunk, plus without negative y-coordinates you don't need to worry about properly flooring them; e.g. if simply cast to an int the range from -0.999...9 to -0.000...1 rounds up to 0 when it should round down to -1).
TheMasterCaver's First World - possibly the most caved-out world in Minecraft history - includes world download.
TheMasterCaver's World - my own version of Minecraft largely based on my views of how the game should have evolved since 1.6.4.
Why do I still play in 1.6.4?
Players may have made systems based on existing coordinates (e.g. books and signs referring to level 63 as sea level). Shifting the y coordinate would disrupt this, even though other things like diamonds at 11 and lava at 10 and bedrock at 5 are all getting shifted anyway due to new generation.