If we update to 1.2.2 do we get new terrain in new chunks if we are using an old map.
Originally, I had heard the answer was NO, unless you did some editing to make the world seem like it was a new 1.2 generated world...
Has that changed? Can I just use my pre-1.2 world and go to new areas to get jungle?
Can anyone confirm this? The answer is YES (see below)
New question can anyone confirm that SMP is also getting new terrain in new chunks?
I have no reason to assume that it is different, but want to be sure...
Thanks.
(old out dated information about how to get new terrain
I can't confirm anything, but that's the way it was planned...
People keep complaining about new terrain features destroying old maps, so Jeb made it so new terrain wouldn't change old map algorithms.
Yeah, old worlds now get new terrain. Originally it was planned to preserve the old world's generation but that was before the Anvil format which solves the biome shifting. Since the worst that happens now because of new terrain is uneven borders they apparently took the limitation out.
Rollback Post to RevisionRollBack
My Spigot/CraftBukkit plugins: TallNether - Generate a 256-block high nether
Yep, I can also confirm that an old world.. (pre 1.0 even...) has jungle in new chunks.. I saw desert wells before that, but kept walking until I found jungle..
the only other question is are SMP maps also including the new features in new chunks..?
yep, went searching on my main 1.3 world in unexplored territory and found jungles after a long search. then using my compass to make a straight line back to base, I came across a second one! I am glad I did not do any mcediting or file altering to get them .
How does the transition from old to new chunks/biomes look? Is it the same as with prior terrain generation changes?
I can't speak for certainty about 1.2 meshing with 1.1 (I did a much older world (pre-1.0).. but I think the landmass water boundary is supposed to be uniform between 1.1 and 1.2 so it might not make for rough transitions..
Sweet! I'll check it out when I get home. My plan is to delete all chunks from my world that I don't have anything built on (with mcedit) and then update to 1.2 and convert my save. I'll post how it goes.
Haven't checked in 1.2 yet, but in the snapshots there were a few sharp chunk borders - some biomes such as swamps and extreme hills affect terrain generation, so that can lead to some jagged chunk boundaries.
Yeah, I got some pretty sharp chunk borders after deleting chunks with mcedit and letting them regenerate in 1.2.
I went exploring to find a jungle and i found a jagged chunk boundry between a forest and an extreme hills biome. It was a sheer wall nearly 40 blocks high.
But, to repeat, yes, you can find jungles in pre 1.2 worlds, in new chunks. I found one not very far from my explored world.
Glad people know that you can do this now, But once again people are complaining about sheer clifs.
If you keep complaining about the sheer clifs, jens will have no choice but to remove new blomies from old worlds again.
And you don't want that again do you?
No I don't want them to do that. That would just be skirting the actual problem. I'd rather them actually FIX the problem.
We complain about this because it's a legitimate complaint. Converting from one terrain generation version to the next SHOULD account for this imo. Terrain already generates randomly based on some parameters. Adding in parameters to extend unexplored terrain in current maps out X distance, graduating that newly extended terrain down to sea level, and adding a river/lake inbetween the two terrain types, or something akin to this, really should have been implemented well before full release. I've yet to hear a justified reason why something like this isn't or couldn't be possible.
Having said that, I really appreciate Jeb's efforts in correcting the map issues thus far. Getting the biomes stable between terrain types was huge (and btw, one of those things people were also saying was impossible, and something we should just accept. It was the complaints of people like me who don't accept it as a necessary evil that prompted Mojang to fix it.)
I don't want to sound like I'm jumping on the Notch hate around here either. Notch did a great job on this game and I have much respect for what he started, and what Jeb is continuing. But that shouldn't prevent me and others from voicing opinion and making recommendations on how the game could be improved.
We complain about this because it's a legitimate complaint. Converting from one terrain generation version to the next SHOULD account for this imo. Terrain already generates randomly based on some parameters. Adding in parameters to extend unexplored terrain in current maps out X distance, graduating that newly extended terrain down to sea level, and adding a river/lake inbetween the two terrain types, or something akin to this, really should have been implemented well before full release. I've yet to hear a justified reason why something like this isn't or couldn't be possible.
Well I can take a stab as explaining why doing this would be clunky... (maybe not as clunky as the current system, but I'll get to that)...
You generate a mountain at the edge of your map. Then you update to a new version. How much space should the system feather it to give you a smooth transition? 16 blocks (one chunk?) Should it always drop it to sea level? What if the next biome say 2 chunks over is another mountain biome? Or what if the next chunk still is a mountain biome?
The current system is stupid. By that I mean it just follows one rule. If chunk is generated use that data, if not use current rules to generate a new chunk.
Your system would require a very smart system (or a very complex system).
The real alternative is YOU fix the boundary. A machine is not able to look at the land and decide the best flow to fix the problem. With a minimal amount of time you can alter it to look however you want. And even if the system made this change for you, who is to say that YOU would like the look (or if you did like it, who is to say that someone else would like it)....
You also don't have to spend anytime at the boundary.. just go past it...
That all being said, I am totally in favor of talking about things to fix or improve this great game...
Who knows maybe someday we will have some boundary smoothing feature
Well it is by no means impossible to fix. I will go as far to say it isn't really that hard to fix the issue as it's only smoothing. It wouldn't be hard to find the height values of biome A and the going to be generated biome B biome height values. (Biome height A will always be the same when produced in algorithm A and the same goes for biome B in algorithm B. Once you have these two values along with the biome types you create a proper terrain mesh over the border until, biome A terrain height and biome B terrain height at chunk edge is smooth. It would take recalculating, which would make the transition very performance intensive, but after the initial application the result should be even.
This would work for most small generations. The extreme generations are unfortunately harder to code. The transition for any biome to biome would probably need particular seed elements. For example, if the old biome terrain would make an extreme mountain biome with algorithm A, then it would need to render that biome using algorithm A until algorithm B which is less extreme terrain can take over. It would then have to check all of the biome borders. A seed check for algorithm B can efficiently bring up biome types. The biome types don't need to form in order for identification since seeds form identically. A terrain edge is mapped around the border and then the game attempts to recalculate transitioning without the need to write those chunks to file, and the entire chunk border that would touch the transition biome would be sent to an array(list). Game will then attempt to calculate a block mesh that can match up with the height properties of the border within a margin of error. Algorithm A will take priority over algorithm B, and the transition mesh made by algorithm C will take priority over algorithm B. Any values that are too extreme will be eroded to fit.
The method of erosion can be simple or complex. It all depends on the degree of detail of the transition.
This probably could not fix 100 percent of cases, but every bit counts. It doesn't need to be as complicated as my idea above. It's just how I would attempt to tackle it. I would give algorithm A priority, and then use a separate algorithm to calculate a match and anything that cannot be matched I would erode to look like it matched.
They could also add a transitional biome, that would form between two types of biomes during a transition. Basically it would form according to average height 1 and average height 2, and them form to make the difference.
Well it is by no means impossible to fix. I will go as far to say it isn't really that hard to fix the issue as it's only smoothing. It wouldn't be hard to find the height values of biome A and the going to be generated biome B biome height values. (Biome height A will always be the same when produced in algorithm A and the same goes for biome B in algorithm B. Once you have these two values along with the biome types you create a proper terrain mesh over the border until, biome A terrain height and biome B terrain height at chunk edge is smooth. It would take recalculating, which would make the transition very performance intensive, but after the initial application the result should be even.
OK so say you built an new generation software that could generate new biomes (A) and basically had the previous biome code (B ).
So every time it went to generate a new chunk it would use biome A. But how would it know when to blend the code for B?
The current system doesn't read the loaded chunk, it just makes new chunks when needed.
So everytime a new chunk was needed it would have to see if the last chunk was B biome. And if it was it would try to blend.
But if you were deep inside of A biome it would be wasting time checking chunks to see if they were old.
And what if some of these chunks were from C or D biome code?
Your suggestion about having it check all the borders would be done when? On conversion?
So you load an old map.. it spends a LONG time going all the way around your world, building a smooth transition (I would think this would take say twice as long as Anvil conversion took.. and people are having issues doing that conversion.
And then if you don't walk to a particular boarder (say the north side of the map), and then a new new biome system comes out.. what will it assume the north edge of your map looks like? Biome A? A blend of A&B?
It is easy for humans to fill in the gaps, it is not so easy to build a software model that does it for you..
No I don't want them to do that. That would just be skirting the actual problem. I'd rather them actually FIX the problem.
We complain about this because it's a legitimate complaint. Converting from one terrain generation version to the next SHOULD account for this imo. Terrain already generates randomly based on some parameters. Adding in parameters to extend unexplored terrain in current maps out X distance, graduating that newly extended terrain down to sea level, and adding a river/lake inbetween the two terrain types, or something akin to this, really should have been implemented well before full release. I've yet to hear a justified reason why something like this isn't or couldn't be possible.
Really? Every time this comes up, many people try to explain it .. and yet people still insist on believing what they want to believe.
What you expect of the map generator in this regard is not just difficult. It's a gargantuan undertaking. It's just difficult to explain to people who don't understand how a map gen like this works. You are doing a lot of general theorizing there, but it's clearly just conjecture from limited experience.
These worlds are sort of 3d noise maps generate off of a seed, and when the generator changes, the seeds yield different results.. often wildly different results.. completely unexpected results.
The type of "checking" you think is going on is not actually going on at all. The game just generates chunks that don't exist, when they are needed. And if new ones border old ones, those vast differences in terrain generation are readily apparent.
The idea of it then going further and continually checking for major differences, and attempting to smooth them out.. You are asking for mini terrain generation (to fill the gap) in a system that is all one large world generation.. Look I just don't know how else to say it.. it's just dumb. It can't work.
Please try to accept that. It's one or the other. Frankly. it's lucky we are able to use the worlds with old maps in new generation. Many game companies wouldn't even allow it to begin with, because of exactly these kind of inherent problems.. Mojang at least does what it can to give us some backwards compatability.. but you are wishing for the moon!!
OK so say you built an new generation software that could generate new biomes (A) and basically had the previous biome code (B ).
So every time it went to generate a new chunk it would use biome A. But how would it know when to blend the code for B?
The current system doesn't read the loaded chunk, it just makes new chunks when needed.
So everytime a new chunk was needed it would have to see if the last chunk was B biome. And if it was it would try to blend.
My thoughts were that upon game join, the map would have data indicating when it was created, and that would initiate the check . The check could be done in many ways. I think I would try mapping out the terrain of the new terrain gen without showing the terrain as loaded with the new terrain and if biome B of terrain gen B doesn't match what it would be if it were biome A, then adjust to smooth the terrain. It would keep in mind the height ranges of each level in the border generation.
After it has been written to file, the game shouldn't care about what gen it is when it has to load it, because the terrain doesn't need to be generated. Only new chunks require generation procedures.
But if you were deep inside of A biome it would be wasting time checking chunks to see if they were old.
If old chunks surround an area too small to mesh, it will generate old gen terrain or attempt to erode the area to fit. You can't really expect miracles in this situation.
And what if some of these chunks were from C or D biome code?
I hadn't really considered multiple gens. My thought is that it would mesh according to the terrain heights along the border and according to the biome somewhat. This would be present in multiple gens.
Your suggestion about having it check all the borders would be done when? On conversion?
So you load an old map.. it spends a LONG time going all the way around your world, building a smooth transition (I would think this would take say twice as long as Anvil conversion took.. and people are having issues doing that conversion.
Nope. I would make it happen during the new chunk loading process. It would be as if the chunks were taking an excessive time to generate.
And then if you don't walk to a particular boarder (say the north side of the map), and then a new new biome system comes out.. what will it assume the north edge of your map looks like? Biome A? A blend of A&B?
Good question. It all depends. This mesh would be fully dynamic. It would go through several checks that will ultimately tell whether it will mesh an incomplete biome, or map out the rest of the biome with the proper gen.
It is easy for humans to fill in the gaps, it is not so easy to build a software model that does it for you..
I realize that, but it isn't impossible to get a mesh within a decent margin of error. Minecraft's chunk system provides a good basis to make it happen. Imagine an unloaded chunk, surrounded by loaded chunks. Each chunk side is completely flat, only the block heights matter. I would implement some way to determine which side(s) the chunk would be meshing from and take the opposite border heights and then check whether the mesh can mesh at 16 blocks, if not go to 32 blocks. I would probably check so many blocks outward. I'm a little unsure about how it would handle a loaded chunk x number of blocks out, but I imagine in that case I would just have it use gen A. If it can't mesh then it will just generate the first detected gen. It will create a chunk border, but that's because there was nothing the mesh could do to fix it. But anyways my point is as long as I have two points of reference the points in between can be adjusted. It maybe not look pretty, but the larger the mesh, the easier it is to create realistic terrain.
Oh and yes I plan to tamper with the generator when the API comes out. I want to at least get this idea started with simple block meshes, and then include unloaded(as in blocks aren't visible in game) seed gen arrays, and work from there.
The real alternative is YOU fix the boundary. A machine is not able to look at the land and decide the best flow to fix the problem. With a minimal amount of time you can alter it to look however you want. And even if the system made this change for you, who is to say that YOU would like the look (or if you did like it, who is to say that someone else would like it)....
This is true, and a risk with anything that changes existing features. But I'd argue that nearly any alternative would be an improvement over the current system, whether perfect or not.
And yes, fixing this would necessarily make the terrain generation code more complex but I believe it could be handled in a way that wouldn't radically change the actual terrain generation code. For example, a map converter or importer function could be added, allowing a one time process of updating an existing map for the next version, which would keep the terrain generation code itself separate and unpolluted.
Ofcourse these are just my ideas on how it might could be rectified. I have full confidence that Mojang is competent enough to figure out a decent way of working out this issue.
The true problem is that each chunk isn't tagged with the world generator type when it is generated, or the seed for that matter (in case of corruption). So there is no way to know why a chunk needs blending, and it's not limited to the surface either, which is what everyone seems to be focusing on. Caves would need proper blending as well, and structures... the list goes on. This isn't as trivial a task as it may sound.
If they cannot come to some sort of damage control resolution they need to hammer down and finish the terrain gen code once and for all! They can worry about new content later but having to make a new map every update is a game breaker for large scale builders and people who like to build dynamic worlds and servers. 1.0 was suppose to be the last time we needed to change, and me and my friends carefully copied and pasted our massive structures and spend many painstaking hours manually fixing the boarders to make it all blend in! now its changing again with no promise of it being the final time and its daunting. i know of two people who left the game pecause they didnt like their ssp worlds getting messed up and 1 person I know is still waiting to fully play and create new stuff because he dosent want to deal with it until his world can be safe from being torn up.
If we update to 1.2.2 do we get new terrain in new chunks if we are using an old map.
Originally, I had heard the answer was NO, unless you did some editing to make the world seem like it was a new 1.2 generated world...
Has that changed? Can I just use my pre-1.2 world and go to new areas to get jungle?
Can anyone confirm this? The answer is YES (see below)
New question can anyone confirm that SMP is also getting new terrain in new chunks?
I have no reason to assume that it is different, but want to be sure...
Thanks.
(old out dated information about how to get new terrain
http://www.minecraft...enerated-world/ )
People keep complaining about new terrain features destroying old maps, so Jeb made it so new terrain wouldn't change old map algorithms.
My Spigot/CraftBukkit plugins:
TallNether - Generate a 256-block high nether
FarLandsAgain - Restores the Far Lands
User: *BOOM* You're dead.
Cleverbot: I divide by zero and come back as an angel ninja.
the only other question is are SMP maps also including the new features in new chunks..?
I can't speak for certainty about 1.2 meshing with 1.1 (I did a much older world (pre-1.0).. but I think the landmass water boundary is supposed to be uniform between 1.1 and 1.2 so it might not make for rough transitions..
I went exploring to find a jungle and i found a jagged chunk boundry between a forest and an extreme hills biome. It was a sheer wall nearly 40 blocks high.
But, to repeat, yes, you can find jungles in pre 1.2 worlds, in new chunks. I found one not very far from my explored world.
No I don't want them to do that. That would just be skirting the actual problem. I'd rather them actually FIX the problem.
We complain about this because it's a legitimate complaint. Converting from one terrain generation version to the next SHOULD account for this imo. Terrain already generates randomly based on some parameters. Adding in parameters to extend unexplored terrain in current maps out X distance, graduating that newly extended terrain down to sea level, and adding a river/lake inbetween the two terrain types, or something akin to this, really should have been implemented well before full release. I've yet to hear a justified reason why something like this isn't or couldn't be possible.
Having said that, I really appreciate Jeb's efforts in correcting the map issues thus far. Getting the biomes stable between terrain types was huge (and btw, one of those things people were also saying was impossible, and something we should just accept. It was the complaints of people like me who don't accept it as a necessary evil that prompted Mojang to fix it.)
I don't want to sound like I'm jumping on the Notch hate around here either. Notch did a great job on this game and I have much respect for what he started, and what Jeb is continuing. But that shouldn't prevent me and others from voicing opinion and making recommendations on how the game could be improved.
Much love for Mojang
Well I can take a stab as explaining why doing this would be clunky... (maybe not as clunky as the current system, but I'll get to that)...
You generate a mountain at the edge of your map. Then you update to a new version. How much space should the system feather it to give you a smooth transition? 16 blocks (one chunk?) Should it always drop it to sea level? What if the next biome say 2 chunks over is another mountain biome? Or what if the next chunk still is a mountain biome?
The current system is stupid. By that I mean it just follows one rule. If chunk is generated use that data, if not use current rules to generate a new chunk.
Your system would require a very smart system (or a very complex system).
The real alternative is YOU fix the boundary. A machine is not able to look at the land and decide the best flow to fix the problem. With a minimal amount of time you can alter it to look however you want. And even if the system made this change for you, who is to say that YOU would like the look (or if you did like it, who is to say that someone else would like it)....
You also don't have to spend anytime at the boundary.. just go past it...
That all being said, I am totally in favor of talking about things to fix or improve this great game...
Who knows maybe someday we will have some boundary smoothing feature
This would work for most small generations. The extreme generations are unfortunately harder to code. The transition for any biome to biome would probably need particular seed elements. For example, if the old biome terrain would make an extreme mountain biome with algorithm A, then it would need to render that biome using algorithm A until algorithm B which is less extreme terrain can take over. It would then have to check all of the biome borders. A seed check for algorithm B can efficiently bring up biome types. The biome types don't need to form in order for identification since seeds form identically. A terrain edge is mapped around the border and then the game attempts to recalculate transitioning without the need to write those chunks to file, and the entire chunk border that would touch the transition biome would be sent to an array(list). Game will then attempt to calculate a block mesh that can match up with the height properties of the border within a margin of error. Algorithm A will take priority over algorithm B, and the transition mesh made by algorithm C will take priority over algorithm B. Any values that are too extreme will be eroded to fit.
The method of erosion can be simple or complex. It all depends on the degree of detail of the transition.
This probably could not fix 100 percent of cases, but every bit counts. It doesn't need to be as complicated as my idea above. It's just how I would attempt to tackle it. I would give algorithm A priority, and then use a separate algorithm to calculate a match and anything that cannot be matched I would erode to look like it matched.
They could also add a transitional biome, that would form between two types of biomes during a transition. Basically it would form according to average height 1 and average height 2, and them form to make the difference.
http://www.minecraftforum.net/viewtopic.php?f=1&t=155932
Crates
http://www.minecraftforum.net/viewtopic.php?f=1&t=239467
Item Scrolling
http://www.minecraftforum.net/viewtopic.php?f=1&t=174539
OK so say you built an new generation software that could generate new biomes (A) and basically had the previous biome code (B ).
So every time it went to generate a new chunk it would use biome A. But how would it know when to blend the code for B?
The current system doesn't read the loaded chunk, it just makes new chunks when needed.
So everytime a new chunk was needed it would have to see if the last chunk was B biome. And if it was it would try to blend.
But if you were deep inside of A biome it would be wasting time checking chunks to see if they were old.
And what if some of these chunks were from C or D biome code?
Your suggestion about having it check all the borders would be done when? On conversion?
So you load an old map.. it spends a LONG time going all the way around your world, building a smooth transition (I would think this would take say twice as long as Anvil conversion took.. and people are having issues doing that conversion.
And then if you don't walk to a particular boarder (say the north side of the map), and then a new new biome system comes out.. what will it assume the north edge of your map looks like? Biome A? A blend of A&B?
It is easy for humans to fill in the gaps, it is not so easy to build a software model that does it for you..
Really? Every time this comes up, many people try to explain it .. and yet people still insist on believing what they want to believe.
What you expect of the map generator in this regard is not just difficult. It's a gargantuan undertaking. It's just difficult to explain to people who don't understand how a map gen like this works. You are doing a lot of general theorizing there, but it's clearly just conjecture from limited experience.
These worlds are sort of 3d noise maps generate off of a seed, and when the generator changes, the seeds yield different results.. often wildly different results.. completely unexpected results.
The type of "checking" you think is going on is not actually going on at all. The game just generates chunks that don't exist, when they are needed. And if new ones border old ones, those vast differences in terrain generation are readily apparent.
The idea of it then going further and continually checking for major differences, and attempting to smooth them out.. You are asking for mini terrain generation (to fill the gap) in a system that is all one large world generation.. Look I just don't know how else to say it.. it's just dumb. It can't work.
Please try to accept that. It's one or the other. Frankly. it's lucky we are able to use the worlds with old maps in new generation. Many game companies wouldn't even allow it to begin with, because of exactly these kind of inherent problems.. Mojang at least does what it can to give us some backwards compatability.. but you are wishing for the moon!!
I realize that, but it isn't impossible to get a mesh within a decent margin of error. Minecraft's chunk system provides a good basis to make it happen. Imagine an unloaded chunk, surrounded by loaded chunks. Each chunk side is completely flat, only the block heights matter. I would implement some way to determine which side(s) the chunk would be meshing from and take the opposite border heights and then check whether the mesh can mesh at 16 blocks, if not go to 32 blocks. I would probably check so many blocks outward. I'm a little unsure about how it would handle a loaded chunk x number of blocks out, but I imagine in that case I would just have it use gen A. If it can't mesh then it will just generate the first detected gen. It will create a chunk border, but that's because there was nothing the mesh could do to fix it. But anyways my point is as long as I have two points of reference the points in between can be adjusted. It maybe not look pretty, but the larger the mesh, the easier it is to create realistic terrain.
Oh and yes I plan to tamper with the generator when the API comes out. I want to at least get this idea started with simple block meshes, and then include unloaded(as in blocks aren't visible in game) seed gen arrays, and work from there.
http://www.minecraftforum.net/viewtopic.php?f=1&t=155932
Crates
http://www.minecraftforum.net/viewtopic.php?f=1&t=239467
Item Scrolling
http://www.minecraftforum.net/viewtopic.php?f=1&t=174539
This is true, and a risk with anything that changes existing features. But I'd argue that nearly any alternative would be an improvement over the current system, whether perfect or not.
And yes, fixing this would necessarily make the terrain generation code more complex but I believe it could be handled in a way that wouldn't radically change the actual terrain generation code. For example, a map converter or importer function could be added, allowing a one time process of updating an existing map for the next version, which would keep the terrain generation code itself separate and unpolluted.
Ofcourse these are just my ideas on how it might could be rectified. I have full confidence that Mojang is competent enough to figure out a decent way of working out this issue.