One of the things that discourages me immensly about MCX360 is that eventually there will be a new spawned block type, or a new biome added, or new spawned structures, or the map dimensions will be expanded in some future TU. This makes my original game somewhat obsolete and I have to take all my hard work and scrap it and start over if I want to play with the new addition to the game from the latest TU, or leave survival mode (I like playing in survival mode).
If the saved game files were marked with the TU version they were created as compatible with, then an option can be added to the game to update the map and change some blocks by using an out of game update feature on the saved game file to make these new features available into the current game file.
So this is a basic out of game updater recommendation to bring your older MCX360 file current with the most recent TU.
Alternatively, focusing on finishing all new spawned block types, new biomes, spawned structures, & map dimensions as a priority first (even if the block functionality/usefullness has not been added yet).
I really would like to be able to continue playing with my current game and still be able to experience the new additions as they occur in future TU's.
Hmm, usually the problem is that the title update changes the map too much, not changing at all. I wouldn't know how 4J could fix this at all. It ain't as easy as the 'Reset Nether' option could be.
Rollback Post to RevisionRollBack
Just 'cause my name's MasterHalo, don't expect me to be GOOD at Halo.
I'm sure you'd just love it when the updater updates your castle build out of existence. The game just can't tell what you might want to keep and what you might be willing to let go of in order to "insert" a new biome or game-generated structure.
Guys, the original map is created with a seed through a known seed generator.... the program can easily determine what zones have been modified and which ones haven't (unless you are the type to put nature back as you found it and replaced all the blocks you mined with the exact same blocks in the exact same locations).
As far as new block types goes, the algorithm could be quite simple in that it will only insert the new resource/vein if it can replace a common material block (ie. stone, dirt, gravel, sand, sandstone)
As to new biomes added in, that could be more programatically challenging, but again, the computer could look for surface areas that remain unchanged in the map before replacing, or for areas of unchanged large body of water areas as well.
The algorithm doesn't have to be so dumb as to wipe out structures that were built after the fact....
Sure, that could mean that there are maps with too much changed in order to adequately inject new content without being potentially destructive,..and perhaps a warning could be issued before proceeding if that is the case to allow the player to back out, or even, copy it over as a new game file (leaving the original file intact.
I'm sure you'd just love it when the updater updates your castle build out of existence. The game just can't tell what you might want to keep and what you might be willing to let go of in order to "insert" a new biome or game-generated structure.
Even if this were the case.... I've already deleted entire game worlds where my large constructs existed, just because I couldn't get new content into my game any other way.
Even if this were the case.... I've already deleted entire game worlds where my large constructs existed, just because I couldn't get new content into my game any other way.
So, tell me then how you propose to let the game know the difference between a stone or wood block that is part of your castle sitting on a biome who want changed to new terrain as opposed to a stone or wood block that is part of your castle sitting on a biome that you don't want changed as opposed to a stone or wood block that's just been placed in the course of terraforming and is part of the terrain itself and is completely expendable and can be replaced (with, say, a colored clay block). So, if your option is going to wind up accidentally deleting player builds, why have it at all? As you said, you can currently change worlds and rebuild your structures in a new world to get the new blocks.
So, tell me then how you propose to let the game know the difference between a stone or wood block that is part of your castle sitting on a biome who want changed to new terrain as opposed to a stone or wood block that is part of your castle sitting on a biome that you don't want changed as opposed to a stone or wood block that's just been placed in the course of terraforming and is part of the terrain itself and is completely expendable and can be replaced (with, say, a colored clay block). So, if your option is going to wind up accidentally deleting player builds, why have it at all? As you said, you can currently change worlds and rebuild your structures in a new world to get the new blocks.
i just did explain it.... but if you need me to explain it again.... since you didn't get what I was saying above... allow me to slip into programmer mode to explain some basic programmatic concepts to basic world gen.
Each world has a seed that is used in a psuedo-randomizer algorithm to create the seemingly random lay of the land when a world is first created... but it isn't true random, because if you use the same seed, you will generate the same world map with that particular TU map build algorithm.
Since the seed of a world is saved with each world that is built, I can always take a look at what it looked like originally and see which blocks are different, which ones are the same block type. In fact, I can be very accurate about areas that have been player modded as opposed to areas that have not been player modded just by a general original map comparison against the current map.
This same seed would be used in adding new content...
Adding new block types is mind numbingly easy and would minimally impact player builds at best... all it would have to look for is common blocks to replace, in the right zones for placement, that are completely surrounded on all sides by other blocks (only hidden common blocks could be replaced under this schema, and no holes would be made, nothing removed, just replaced block for block).
New Biomes is by far the trickiest, and they may not get added due to no available unchanged space to add. Basically, the map comparison would be looking for sections of the surface world that have not been altered (surface being above water to below water to the top blocks, (does nothing to subterranean blocks). If ANY change was made to the surface (and above), it would exclude this area as a potential insert for a New Biome... and that's ok, some worlds don't have every biome as it is when they are randomly generated anyway ... as I rudely discovered under this latest TU that gave my first 2 worlds in TU 12/13 as nearly 98% land coverage, and of that, nearly 98% winterland coverage, the second being nearly 96% water covered... (I thought I entered water world)... But I do have a Jungle biome (Yeah me...) It consists of exactly 1 jungle tree on a very small deserted island in the NE corner of the map
but I digress....my problems with my clock generated world seeds are my own.
Anyway... IF and ONLY IF the surface remains unchanged, a new Biome could be inserted on top of the existing surface (additional common land blocks may need to be added to build up the land if inserted over a water zone).
The Game would have to keep track of the TU map generator that was originally used in the world creation, and a change file that keeps track of the changes that were made (since an updated map from a previous TU cannot be recreated under the current TU mapper, either with or without the original world seed). This allows it to be able to address future update/inserts.
i just did explain it.... but if you need me to explain it again.... since you didn't get what I was saying above... allow me to slip into programmer mode to explain some basic programmatic concepts to basic world gen.
Each world has a seed that is used in a psuedo-randomizer algorithm to create the seemingly random lay of the land when a world is first created... but it isn't true random, because if you use the same seed, you will generate the same world map with that particular TU map build algorithm.
Since the seed of a world is saved with each world that is built, I can always take a look at what it looked like originally and see which blocks are different, which ones are the same block type. In fact, I can be very accurate about areas that have been player modded as opposed to areas that have not been player modded just by a general original map comparison against the current map.
This same seed would be used in adding new content...
Adding new block types is mind numbingly easy and would minimally impact player builds at best... all it would have to look for is common blocks to replace, in the right zones for placement, that are completely surrounded on all sides by other blocks (only hidden common blocks could be replaced under this schema, and no holes would be made, nothing removed, just replaced block for block).
New Biomes is by far the trickiest, and they may not get added due to no available unchanged space to add. Basically, the map comparison would be looking for sections of the surface world that have not been altered (surface being above water to below water to the top blocks, (does nothing to subterranean blocks). If ANY change was made to the surface (and above), it would exclude this area as a potential insert for a New Biome... and that's ok, some worlds don't have every biome as it is when they are randomly generated anyway ... as I rudely discovered under this latest TU that gave my first 2 worlds in TU 12/13 as nearly 98% land coverage, and of that, nearly 98% winterland coverage, the second being nearly 96% water covered... (I thought I entered water world)... But I do have a Jungle biome (Yeah me...) It consists of exactly 1 jungle tree on a very small deserted island in the NE corner of the map
but I digress....my problems with my clock generated world seeds are my own.
Anyway... IF and ONLY IF the surface remains unchanged, a new Biome could be inserted on top of the existing surface (additional common land blocks may need to be added to build up the land if inserted over a water zone).
The Game would have to keep track of the TU map generator that was originally used in the world creation, and a change file that keeps track of the changes that were made (since an updated map from a previous TU cannot be recreated under the current TU mapper, either with or without the original world seed). This allows it to be able to address future update/inserts.
Thank you for explaning it more clearly. I still see issues with it - For example - How large an area would have to remain unchanged for it to get replaced? Would replacing a grass block moved by an enderman disqualify 10 blocks square or 100? If 10 blocks and you didn't remove and replace some grass blocks in your castle yard, for example, would the game suddenly insert a bunch of jungle trees there?
Also, my basic point - The player may have "plans" for some areas without physically changing them.. and likewise they may not have plans for other areas at all. This, however, risks having the game change the areas they don't want changed and not changing the areas they do. There is no way for the game to accurately read the player's "desires" for what the player wants changed and what they don't. Your proposal is working on the assumption that whatever the player changes they want to keep and what they don't change they're OK with losing. This, however, is not really the case. It also doesn't solve the whether issues over biomes that they want to keep but for which the seed indicates a different biome should exist in that spot (which, for me and many other people, is a more serious hassle because it disrupts the weather over pre-existing builds - e.g. snowing on a beach resort).
The Xbox worlds aren't very large, so I really don't understand the hassle with shelving an old build world and starting a new one with different ideas and themes to suit the new biomes as they are added. You can still keep the old file and re-visit it occasionally to reminisce over your old builds. As for just adding some of the new blocks, I think there are other suggestions out there that can do the trick with far fewer complications (like merely adding the newer saplings into a bonus chest of some sort). Of course, the simplest solution to adding in some new blocks is to just forget the leaderboards in that world and add them using creative mode.
Thank you for explaining it more clearly. I still see issues with it - For example - How large an area would have to remain unchanged for it to get replaced? Would replacing a grass block moved by an enderman disqualify 10 blocks square or 100? If 10 blocks and you didn't remove and replace some grass blocks in your castle yard, for example, would the game suddenly insert a bunch of jungle trees there?
Yes, it isn't perfect, but it isn't mandatory either, at the onset I had outlined this as an option up to the end user.
Unfortunately...under this scheme, yes, and Enderman moving a block could nullify an area, or mark it as an area to warn the player. A tree being cut or a sapling planted growing into a tree could nullify an area. If the area were as small as 10x10, and you have an area that happens to fit the mold where the surface remains in the original block positions/types in their (not tilled/farmed) mostly original state. It is technically potentially possible that the new biome could be inserted into that space, thus creating additional work for the player to clear it out and potentially have to adapt. In minecraft, as a player, you often have to learn to play with the hand you are dealt.
Also, my basic point - The player may have "plans" for some areas without physically changing them.. and likewise they may not have plans for other areas at all. This, however, risks having the game change the areas they don't want changed and not changing the areas they do. There is no way for the game to accurately read the player's "desires" for what the player wants changed and what they don't. Your proposal is working on the assumption that whatever the player changes they want to keep and what they don't change they're OK with losing. This, however, is not really the case. It also doesn't solve the whether issues over biomes that they want to keep but for which the seed indicates a different biome should exist in that spot (which, for me and many other people, is a more serious hassle because it disrupts the weather over pre-existing builds - e.g. snowing on a beach resort).
Taking over a zone that has no development into it, basically means that it is at the least not undoing hours of invested time and energy.
The Xbox worlds aren't very large, so I really don't understand the hassle with shelving an old build world and starting a new one with different ideas and themes to suit the new biomes as they are added. You can still keep the old file and re-visit it occasionally to reminisce over your old builds. As for just adding some of the new blocks, I think there are other suggestions out there that can do the trick with far fewer complications (like merely adding the newer saplings into a bonus chest of some sort). Of course, the simplest solution to adding in some new blocks is to just forget the leaderboards in that world and add them using creative mode.
I tend not to play Creative Mode, and only go there to test an idea out or work out some plans.... I don't want to go back and reminisce over a world I abandoned that was only partially built. Adding saplings and things that grow into a chest is an ok suggestion for a patch ... but doesn't work so well when you start talking new ores and minerals... and no... I'm not going to jump into creative mode just to add them to my game.
Honestly, I don't like the chest idea in the Netherworld idea. It feels like a 'hand out' ... I suppose if they placed it somewhere inside the Nether Fortress instead of right next to the spawned nether portal, I might be in more support of it.
------------------------------
A potential solution is to make a new world Save File and allow you to rename the new file, that way you can retain the old map and the new map and keep the one you prefer.... or both, if you really want too.
If the saved game files were marked with the TU version they were created as compatible with, then an option can be added to the game to update the map and change some blocks by using an out of game update feature on the saved game file to make these new features available into the current game file.
So this is a basic out of game updater recommendation to bring your older MCX360 file current with the most recent TU.
Alternatively, focusing on finishing all new spawned block types, new biomes, spawned structures, & map dimensions as a priority first (even if the block functionality/usefullness has not been added yet).
I really would like to be able to continue playing with my current game and still be able to experience the new additions as they occur in future TU's.
As far as new block types goes, the algorithm could be quite simple in that it will only insert the new resource/vein if it can replace a common material block (ie. stone, dirt, gravel, sand, sandstone)
As to new biomes added in, that could be more programatically challenging, but again, the computer could look for surface areas that remain unchanged in the map before replacing, or for areas of unchanged large body of water areas as well.
The algorithm doesn't have to be so dumb as to wipe out structures that were built after the fact....
Sure, that could mean that there are maps with too much changed in order to adequately inject new content without being potentially destructive,..and perhaps a warning could be issued before proceeding if that is the case to allow the player to back out, or even, copy it over as a new game file (leaving the original file intact.
Even if this were the case.... I've already deleted entire game worlds where my large constructs existed, just because I couldn't get new content into my game any other way.
So, tell me then how you propose to let the game know the difference between a stone or wood block that is part of your castle sitting on a biome who want changed to new terrain as opposed to a stone or wood block that is part of your castle sitting on a biome that you don't want changed as opposed to a stone or wood block that's just been placed in the course of terraforming and is part of the terrain itself and is completely expendable and can be replaced (with, say, a colored clay block). So, if your option is going to wind up accidentally deleting player builds, why have it at all? As you said, you can currently change worlds and rebuild your structures in a new world to get the new blocks.
i just did explain it.... but if you need me to explain it again.... since you didn't get what I was saying above... allow me to slip into programmer mode to explain some basic programmatic concepts to basic world gen.
Each world has a seed that is used in a psuedo-randomizer algorithm to create the seemingly random lay of the land when a world is first created... but it isn't true random, because if you use the same seed, you will generate the same world map with that particular TU map build algorithm.
Since the seed of a world is saved with each world that is built, I can always take a look at what it looked like originally and see which blocks are different, which ones are the same block type. In fact, I can be very accurate about areas that have been player modded as opposed to areas that have not been player modded just by a general original map comparison against the current map.
This same seed would be used in adding new content...
Adding new block types is mind numbingly easy and would minimally impact player builds at best... all it would have to look for is common blocks to replace, in the right zones for placement, that are completely surrounded on all sides by other blocks (only hidden common blocks could be replaced under this schema, and no holes would be made, nothing removed, just replaced block for block).
New Biomes is by far the trickiest, and they may not get added due to no available unchanged space to add. Basically, the map comparison would be looking for sections of the surface world that have not been altered (surface being above water to below water to the top blocks, (does nothing to subterranean blocks). If ANY change was made to the surface (and above), it would exclude this area as a potential insert for a New Biome... and that's ok, some worlds don't have every biome as it is when they are randomly generated anyway ... as I rudely discovered under this latest TU that gave my first 2 worlds in TU 12/13 as nearly 98% land coverage, and of that, nearly 98% winterland coverage, the second being nearly 96% water covered... (I thought I entered water world)... But I do have a Jungle biome (Yeah me...) It consists of exactly 1 jungle tree on a very small deserted island in the NE corner of the map
but I digress....my problems with my clock generated world seeds are my own.
Anyway... IF and ONLY IF the surface remains unchanged, a new Biome could be inserted on top of the existing surface (additional common land blocks may need to be added to build up the land if inserted over a water zone).
The Game would have to keep track of the TU map generator that was originally used in the world creation, and a change file that keeps track of the changes that were made (since an updated map from a previous TU cannot be recreated under the current TU mapper, either with or without the original world seed). This allows it to be able to address future update/inserts.
Thank you for explaning it more clearly. I still see issues with it - For example - How large an area would have to remain unchanged for it to get replaced? Would replacing a grass block moved by an enderman disqualify 10 blocks square or 100? If 10 blocks and you didn't remove and replace some grass blocks in your castle yard, for example, would the game suddenly insert a bunch of jungle trees there?
Also, my basic point - The player may have "plans" for some areas without physically changing them.. and likewise they may not have plans for other areas at all. This, however, risks having the game change the areas they don't want changed and not changing the areas they do. There is no way for the game to accurately read the player's "desires" for what the player wants changed and what they don't. Your proposal is working on the assumption that whatever the player changes they want to keep and what they don't change they're OK with losing. This, however, is not really the case. It also doesn't solve the whether issues over biomes that they want to keep but for which the seed indicates a different biome should exist in that spot (which, for me and many other people, is a more serious hassle because it disrupts the weather over pre-existing builds - e.g. snowing on a beach resort).
The Xbox worlds aren't very large, so I really don't understand the hassle with shelving an old build world and starting a new one with different ideas and themes to suit the new biomes as they are added. You can still keep the old file and re-visit it occasionally to reminisce over your old builds. As for just adding some of the new blocks, I think there are other suggestions out there that can do the trick with far fewer complications (like merely adding the newer saplings into a bonus chest of some sort). Of course, the simplest solution to adding in some new blocks is to just forget the leaderboards in that world and add them using creative mode.
Yes, it isn't perfect, but it isn't mandatory either, at the onset I had outlined this as an option up to the end user.
Unfortunately...under this scheme, yes, and Enderman moving a block could nullify an area, or mark it as an area to warn the player. A tree being cut or a sapling planted growing into a tree could nullify an area. If the area were as small as 10x10, and you have an area that happens to fit the mold where the surface remains in the original block positions/types in their (not tilled/farmed) mostly original state. It is technically potentially possible that the new biome could be inserted into that space, thus creating additional work for the player to clear it out and potentially have to adapt. In minecraft, as a player, you often have to learn to play with the hand you are dealt.
Taking over a zone that has no development into it, basically means that it is at the least not undoing hours of invested time and energy.
I tend not to play Creative Mode, and only go there to test an idea out or work out some plans.... I don't want to go back and reminisce over a world I abandoned that was only partially built. Adding saplings and things that grow into a chest is an ok suggestion for a patch ... but doesn't work so well when you start talking new ores and minerals... and no... I'm not going to jump into creative mode just to add them to my game.
Honestly, I don't like the chest idea in the Netherworld idea. It feels like a 'hand out' ... I suppose if they placed it somewhere inside the Nether Fortress instead of right next to the spawned nether portal, I might be in more support of it.
------------------------------
A potential solution is to make a new world Save File and allow you to rename the new file, that way you can retain the old map and the new map and keep the one you prefer.... or both, if you really want too.
??? I'm not understanding this statement...... or was that supposed to be a question ???