Structures (witch huts, nether fortresses etc.) don't get saved with the world file

Yes, I did the same test in my world earlier this week with the same results. http://youtu.be/h_pq969sLro

He had a Farm Experience in the Nether, which succeeded in Wtiher Heads Of Skeletons, was very Useful, I was with this map from the 1.2 And now what? Over 8 million minced blocks, more than 8 million sand placed and removed by the lava and lose job over this .. Hope you solve Thank You for Your Attention

I was trying a Wther Skeletons and xp farm,but if in the 1.6, this bug still here, all my work is going to be ruined! And i can confir it aswell, in the snapshot, only the zombie-pigmens do spawn.

I think this is a big bug . I am exploring my old Nether Fort at Minecraft Snapshot 13w19a , There are only PigZombies and somes Blazes . I tried with minecraft 13w16a last weak and this worked fine .

I've Found A Blaze in lava, I think the wrong mobs spawn

Unable to find a Wither Skeleton or another mob than a Zombie Pigman on a Nether Fortress.

I see i'm not the only one who have the same problem in the Nether in the lastest snapshot

This is a terrible bug.I can´t find any Wither Skeleton in my world(I have a lot of Nether explored),and i don´t want to create another World to find them.I have been hours searching for another Nether fortress,and i can´t find one.Please,resolve this bug!(Sorry if my english isn´t good,i´m from Spain )

I hate this bug, if you do a wither skeleton xp farm in 1.5 it doesn't work in 1.6 snapshots, repair it pls

The following is result of experimentation:

The bug was introduced with the addition of chests to Nether Fort generation in 13w18a, and I can confirm it´s still happening in snapshot 13w22a.

The bounding boxes of Nether Forts are determined by the seed and the respective generation algorithm. Current Nether Forts are generated following beta 1.8 algorythm, but in 13w18a the algorythm changes so, as a general rule the bounding boxes are no more linked to the Nether Fort you see but to the Nether Forts that would have generated if the chunks weren´t already explored. As a general result you're unable to find any naturally spawned blaze or wither skeleton in old Nether Forts (except for lucky scenarios where old and new bounding boxes overlay), nor you´ll able to locate the new bounding boxes as they're basically untraceable without the new Nether Fort as a reference. Basically it forces you to explore new Nether which is quite annoying when you already have a 6000x6000 block area explored. Also to note this breaks nether fort mob farms, in which people usually invest hundreds of hours just to control the spawning.

I now explain the logic behind a possible fix, although I´m unable to provide actual code:
-Add an NBT tag to the chunk that stores which version was the chunk created in.
-If chunk was created pre-1.6 then use NetherFortGenAlgorythm from beta 1.8
-else use NetherFortGenAlgorythm from 13w18a

Hope this gets fixed soon.

i have a Nether Fortress generated on the 1.3.2 and i pased for the Snapshot 12w22a and i dont see Wither Skeletons anymore i just found Pigmans.

I don't do the snapshots, only the major updates but I've been seeing this since the last redstone update (nether quartz added). I found 2 new ruins and no wither skeletons or blazes (except at spawners) seem to be spawning. I went back to an old ruin where I had seen these mobs regularly and they no longer seemed to be spawning there either. In a way, it's comforting that this is a known issue but it IS rather a pain.

Mojan staff,

I'm writing to you to make you understand how bad this bug is.
First of all this bug is terrible because if you want to make a mob-farm and you were working hard in the 1.5 or older versions all your work is useless.
This bug is strange, so i wonder if you could eliminate this bug.

Best wishes,
Juan Pablo

Mojang Staff.

Please resolve the bug.
The bug is radical, my survival world is more important, please resolve.
Is strange and radical, my projects is a eliminated with the bug.

Thanx for read me.
Fernando San Miguel

Our multiplayer server that started on 1.4 is now at a stand still on 1.5.2 because this bug hit us a few days ago. There are no hostile mobs spawning in nether fortresses except from blaze spawners. Please relieve us of this bug.

I don't know if this is related but when I was wandering the nether in search of a ruin, I encountered a couple of wither skeletons and a few blazes in an area where there was no ruin to be found. I thought maybe there was a ruin buried in the netherrack but when I moved farther down I discovered the area where these mobs appeared was a thin shelf of netherrack above a lava lake. I could even see the blazes above through a hole. I wonder if there is an error in the code that is causing the spawning subroutine to misinterpret the location of the ruins.

I got this bug too, where my wither skeleton pads stopped working. I used the same seed and generated the world in the snapshot, went to where the fortress was, and found a fortress next to where the old one was, but no fortress in the area where the pre-13w18a fortress was.

That explains a lot. It seems like the snapshot changed where nether ruins generate but not where wither skeletons and blazes spawn, thus causing an offset between the ruins and the mobs. I had an experience that sort of matches up with Thomas'. I saw a couple of blazes and a wither skeleton just outside of an old ruin but far enough away that i doubt they could have wandered there. I would imagine that if I created a new world with the same seed, the ruin would be where I saw those mobs. I'm glad I found this out now because I was going to generate a world in creative to match the one my family uses in survival to be able to safely locate ruins. Now I know I've been foiled before I start and there would be no point. Serves me right for thinking about cheating. 😞

What I still don't understand is why I'm experiencing this when I don't download the snapshots. I only update when there is an official release, therefore I am still using 1.5.2. I have had the problem since that update.

I can confirm that the nether fortress generation has changed. We were experiencing the same symptoms on a SMP server. No Wither Skeletons in existing fortresses (generated in 1.3, no spawns in 1.4.7 or 1.5.2). However 1.5.2 fortresses generated wither skeletons in 1.5.2)

However In nether travels I encountered a fortress on the edge of newly generated chunks.
There fortress there was split along the 'chunk error' boundary, with bridges in different locations along those edges. Skeletons spawned in the new parts, but did not in the old parts.

To fix this problem for the SMP server without destroying the central hubs and tunnels. we simple deleted (after backup) all DIM-1 region files that had a number smaller than -2 or larger that 1. That deleted all chunks further than 1Km from 0,0 in the nether. (equivalent to roughly 8.5 K in overworld)

New fortresses found beyond those bounds since the reset are working just fine, players are happy to get Quartz and do Wither Skeleton Hunting.

For 1.6 with Horses tied to new chunks, we plan to do a similar reset of overworld for places further than 8Km from Spawn.

NOTE Region files are basically 1/2 Km square regions (actually 512x512 blocks) holding the equivalent of 32 chunks. Deleting the files is a lot simplier than using MCedit!

I discovered this bug when i actualizated my world with the snapshot and when i entered to the nether i can see that no one mob was in the netherfort, i started to investigate and i discovered that was a bug, so
Please guys of mojang eliminate this hateful bug because this change our worlds

This is still a concern in 13w25c. If mods can do something to give this some visibility would be great, it would be quite annoying if 1.6 launches with this, as they won't be able to fix it later. Also, the underlying problem is much bigger. Bounding boxes are not linked to the chunks, so witches' huts are also susceptible of suffering such problems. This should be fixed now to avoid present and future problems.

This problem persists in 13w25c. The old fortresses will not generate any wither skeletons. This needs to be fixed before 1.6 release.

Witnessed this on Multiplayer server. New fortress would have generated 7 blocks lower then the existing already generated fortress. As such wither skeletons and blaze or only able to spawn in lower areas of the existing fortress where the spawnable locations of the 'phantom' fortress overlaps with where the current one is. Still present in 13w25a/b/c

I have extreme doubts that this will be fixed.

Basically if you fix the mapping of nether fortress to wither skeleton spawning for older maps. You screw it up for newer maps.

The only way they could fix this is to include the generation code for the old minecraft with the new minecraft, and apply it on a chunk by chunk bases to the generated world. Remember worlds can be a mix of old and new generated chunks.

If they do this for this, then they will need to do it for many other things, such as horse spawning, witch huts, and whatever else is added in the future, that has specific world object attachments. I doubt they see that as a good move.

So My suggestion... just reset (delete) parts of the world as I detailed in a previous comment, and go to the new chunks.

NOTE: the fortress locations has not changed, just the way the fortress is generated, as such you will often get a few spots where wither skeletons will spawn, where the old and new coexist, providing blocks for the wither to spawn on. If you find a spot, expand the levels and look for where they are spawning. Remember crossroads provide a 19x10x19 spawn volume, and if you can find it. great.

Compare coords in a new world (with creative) you re-generated with the same seed, the locating those same coords in your old world is another solution to finding a good 'wither skeleton spawn volumes', without resetting the chunks.

There are solutions folks!

Actually I would not mind knowing the fortress differences myself, by exploring the same fortress in two such world generations. I mean is the 'seed' point the lava room? (just as the 'well' is the seed point for overworld villages). If so perhaps the lava rooms match up?

Can anyone provide more concrete difference information? Rather than simply winge that things have changed!

Hi Anthony, according to redditors some Nether Forts are completely gone. This is a problem with bounding boxes. Horses do spawn in previously generated chunks, just, as all other peaceful mobs they rarely spawn. I would like to see the bounding boxes stored into NBT data with the chunk or a similar solution. My problem is that I made a skull farm by hollowing a 17*16 chunk area in the Nether, so I'm losing hundreds of hours of work. Regeneration or deleteing chunks feels unconfortable (cheating).

Also, would like to note, that this is not at all like new additions only appearing in new generated world, your old world keep working the same. This is breaking something that we already had, and that will no longer work, or at least very badly in the next update, forcing yourself to go further to be able to enjoy it again.

Another victim of this huge issue. My old fortress is totally different from the "ghost fortress" the games sees in the current snapshots. They aren't just offset, some parts are totally new with new structures, some parts are totally gone. Needless to say that my wither skeleton spawning pads are now useless. And I can't even fix them...

As a player, I just can't understand why adding content to the game for chunks that haven't been generated has to break things in my old chunks and can't see how introducing ghost structures in old chunks is a good move (that's exactly what it is, I can't even see what the game sees, this is ridiculous). And no, telling people to use MCEdit isn't a solution. Just don't break my existing world with ghost structures....

So, at the end of the day, while I was initially happy to go do some exploration for new nether fortresses, I have to say that the changes around nether fortress are actually a really poor experience for me.

Would it be possible to have some official comment from Mojang on the situation? That would be highly appreciated.

By the way, I seem to have a similar problem with an "old" witch hut which seems to be offset vertically since 13w18a. Sweet...

This needs to be fixed before the release. Perhaps NOT have the game recalculate everything in old chunks.

What I'm having trouble understanding is why I have this problem when I don't download the snapshots, only the regular releases. Was 13w18a before 1.5.2?

Can we get this updated to still be an issue in the 1.6 PR?

If this is fixable or not should be answered by the mojang staff.

It would be a shame if every time there are terrain changes that location specific mobs such as the wither skeleton and witches have the potential to stop functioning.

I've run into this bug in my SP world as well as a SMP server I play on. If it is not fixable, it would be good to find that out as our wither skeleton farming platforms on the server will need to be relocated, but no point doing all that work if it does end up getting fixed and we'd have to adjust it again.

I heard in the latest GenerickB Video that Dinnerbone told him that 1.7 will have major terrain generator re-working. Probably adding more biomes. So I would expect some major differences then.

Hey Anthony, was unable to find that mention in GenerikB's videos from 26/6/2013 and 27/6/2013, I must have missed it though as I'm not a native English speaker. Could you please give me the link and time stamp for it, I would be interested as after seeing my skull farm broken I do not want my witch farm to be destroyed by 1.7 and I'm going to start quite an active campaign to see bounding boxes stored as chunk data. I need the mention so I can be sure 1.7 is a major terrain re-working (Jeb didn't confirm it in the Dreamhack interview).

The rules for fortress mob spawns have been changed to make them work better on old worlds, without breaking current worlds.

Alejandro...
It was in the GenerkB's 'Final Tour of MindCrack'. But as it was a passing comment of a passing comment I would not put too much faith in it yet.

Jeb...
The big question is..

What is this change? Spawn within a distance of a nether fort? Only spawn on nether brick? (the latter would be logical)

I'm still not seeing Wither skeletons or random blazes in my old ruins. Was the fix in 1.6.1 or is it in a snapshot for a future release?

It's fixed in the 1.6.2 (:

Or is it? Been playing on the 1.6.2 PR and been doing some testing. Went to our wither platforms on the server I play on, and if that fortress is generated post 13w18a it generates 7 blocks lower than that actual generated fortress(which was generated in 1.4.6 I believe). I am still seeing only pigman spawning on the top two platforms, and getting blaze and skeeltons only on the bottom two floors(which are in range of the phantom fortress 7 blocks lower.

I also loaded up a old test world in which I have mcedtited out all netherrack around a fortress to get the spawns in the fortress up. I have several test platforms there in which I am only getting pigman and ghasts spawning on. And I do believe ghasts aren't supposed to spawn in fortresses.

I would be interested in what exactly the fix was? As it would appear to be functioning the exact same in 1.6.2 as in 1.6.1

Or perhaps it's fixed from now on? so if any new nether generation changes occur it won't effect the fortresses generated post 13w18a? But fortresses prior to that will still be broken?

As of right now I would claim that this bug is still present in the 1.6.2 Pre-Release.

Just confirming, this is definitely not fixed in 1.6.2. I loaded a fortress that was generated in 1.5.2 and the fortress-only mobs are only spawning in the few areas that overlap with the 1.6 version of the fortress; which is the same behavior as in 1.6.1.

Maybe by Monday this will be fixed in the official release. I'm hoping, anyway. Moribus, obviously Ghasts aren't fortress-only mobs so this issue doesn't apply to them but they will spawn anywhere in the nether where there is room for them.
This includes inside ruins if the ceiling is high enough. I've been getting them in my enlarged nether fortress room since I built it. I consider it an advantage because with a little weaving, you can dodge the fire ball and kill the ghast with 2 hits with a diamond sword. If you're any good with a bow, it's an easy achievement get for "return to sender", not to mention that you always get the tear because it can't fall anywhere inaccessible.

Just tested this again in 1.6.2 snapshot and the issue still persists. Fortress mobs still only spawn in areas that overlap with the 1.6 version of the fortresses. Otherwise the fortress mobs are completely absent. As far as I can tell this bug has the same behavior as in 1.6.1.

Hopefully, as Donna stated above, this will be fixed with the official 1.6.2 release but in the snapshot version this issue is not resolved.

I make a test in a nether fortress of 1.4.5 and the spawn is perfect, the 1.6.2 don't destroy previously worlds. If you visited a previously visited nether fortress in 1.6.1, the 1.6.2 update don't fix this problem.

OK, it's nice to have a fix, but making a fix that only works when your nether hasn't been loaded into 1.6.1 still torpedoes a lot of player's big nether builds, like for instance mine.

So what are these changes to the fortress bounding boxes, and where are they saved? With access to some backed up worlds and moderate skill in MC edit, how can i get the nether bounding boxes back where they used to be, without simply reverting to a map state from months ago? Nether Chests and thus broken fortress mobs were added in the middle of April.

Basically... Just saying it is fixed is not enough... What was fixed?

match generation of new fortresses? match generation of old fortresses
What version? What will break?

Generation version VS Spawning version?

I didn't get a chance to test the "works when your nether hasn't been loaded into 1.6.1" observation because (as i'm sure many others did, I visited all of my fortresses to see if blazes and wither skeletons were spawning there. Of course they weren't and they still aren't. I may try the solution Anthony proposed in his June 9th post or I may just develop the new fortress I just found a few hundred meters farther out from the origin. This puts me about 1.5 k out but that's not all that bad and I kinda enjoy improving fortresses. Either way, I'm not agonizing over this one anymore. It is what it is and if it gets fixed, great, if not, oh well. Nothing is perfect and even Minecraft apparently has it's flaws. I'm building myself a bridge (probably of nether brick) and getting over it.

PS For those who haven't figured it out yet. It is possible to tunnel from one point to another UNDER the lava lakes in the nether as long as you have a known location with no lava at either end. It makes a kilometer or 2 across the nether not a really big deal, especially with a minecart track. Happy tunneling!

I went ahead and made another test. I created a world in 1.5.2, let's call it World_1, loaded some chunks and found a cross section in a 1.5.2 generated nether fortress. I marked the 19x19x10 area of the corresponding bounding box in 1.5.2 in the following screenshot

The next screenshot shows the previous area against the 1.6.2 generated fortress. I used the same seed in 1.6.2 to create World_2, went to the same spot in the nether and then reopened World_2 in 1.5.2 for the bounding box mod I'm using. As we can see, there is no overlap of any kind between the 1.5.2 and 1.6.2 fortresses for this area. That was the only purpose of World_2 that won't be used in the test.

Then, I took World_1, created spawning pads inside the bounding box from 1.5.2 and MCedited the nether to clear it around the pads (20x20 chunks area). I opened the 1.5.2 world with Minecraft 1.5.2 and I get wither skeletons (and blazes) on all pads, as expected :

Last screenshot shows the spawning pads from World_1 in 1.6.2 (I went straight for 1.6.2, didn't open the world in 1.6.1). We only get pigmens (and some magma cubes), no wither skeletons, no blazes. This is not the expected result.

I don't know what Mojang changed in 1.6.2 but it didn't "fix" anything in the above scenario, the game still doesn't see the old fortress. I also don't how Javier Diaz made his test but, again, given that going straight from 1.5.2 to 1.6.2 didn't change anything in my test, I didn't even bother going through 1.6.1 to see if that could break anything (there was nothing not broken to break).

So, without any details on the "fix", I'm not sure what to expect but it seems pretty obvious that the "fix" didn't improve the situation for "old" fortress structures with no overlapping with the new invisible ones. Where are we supposed to find improvements? What has been changed?

More generally, I can't say I noted any improvement of nether-only mobs spawns in my "old" fortress (maybe I'm not looking at the right place but without more details, how would I?) and would like to get this issue Re-Opened.

It looks to me (not confirmed) like the 'fix' was simply to map 1.6.2 spawning with how fortresses now generate in1.6, which is different to fortress generation in 1.5.2 (and 1.4.7)

What a pain. It changed from 1.3.2 to 1.4.7, and now it has changed again.
Note that village generation also changed between these two releases, but villagers breed based on doors (houses - if you really could call them that) and not on village structure so the changes have no impact on spawning.

Really what a nether fortress needs is something that defines the spawning area. This way when fortress generation change, spawns don't change in already generated structures.

Tying the generation with the spawn area, was I think a bad idea.

The only other such 'tie' between generation and spawning, that I know about, is between mooshrooms and mushroom biome. But mooshrums also breed, are not generally killed, But they can spawn, but only spawn if server cap allows, and then only if a grass area is placed in a mushroom biome. Not really a problem as they generally don't 'spawn'.

Really the ideal solution that mojang could make, would be.. Make fort mobs spawn around a special spot (lava room? - is this the seed point for forts?) and only on nether brick. That would solve almost all the current 'fort generation changed' problems, that we are seeing.

But what version did you run when you generated the original fortress?
Both bits of information is important! Generation version and 'not-spawning' version.

The fortress was generated in 1.5.2. There are no wither skeletons to be found in 1.6.2. I visited the area in 1.6.1.

Quick and Dirty method of mobspawning witherskeletons that would fix this issue.

on random tick, attempt spawn wither skeleton if room available, and block underneath is netherrackbrick in the nether.

with some crowd control checking, or say, anything else that they would want.

This would allow for, farming of wither skeletons using player made farms (possibly bad)
but fix the spawning of wither skeletons for maps made with any version of the map generation, even custom ones.

The other fix, would be to create nether "biomes" which are copies of the default nether settings that the withers could spawn in, and generate these around the fortresses on map generation.

this would at least allow versatile admins, to run a script over their nether, to re-enable wither skeleton spawning around nether fortresses.

Ok, I make The Mistake, my test was in a only fortress, some fortress are destroy for this bug but others no.

So i make the Big Test:

My first test, Nether Fortress generated in 1.2.5, now in 1.5.2: https://www.dropbox.com/s/1qloelqrfp6i0la/1.25%20To%201.52.png
Nothing happens.

1.2.5 in 1.5.2, now in 1.6.1: https://www.dropbox.com/s/85cmwgj03kwj0sy/1.25%20to%201.52%20to%201.61.png
Nothing happens, the bounding box change in background is for a unload chunk.

1.2.5 in 1.5.2, in 1.6.1, in 1.6.2: https://www.dropbox.com/s/x3oneo33sw4uim7/1.25%20to%201.52%20to%201.61%20to%201.6.2.png
Nothing Happens.

All this test: https://www.dropbox.com/sh/unkqe3794sckve2/w_XjExPi2B

Second test, nether fortress generated in 1.4.6 now in 1.5.2: https://www.dropbox.com/s/cyb8k1iwkr5djwo/1.46%20to%201.52.png
Nothing Happens.

1.4.6 in 1.5.2, now in 1.6.2: https://www.dropbox.com/s/76njo4r2d2ctdeb/1.46%20to%201.52%20to%201.6.2.png
The Bounding Box moves down, 1.6.2 destroy this fortress.

All this test: https://www.dropbox.com/sh/ye77fv7phnnyuxq/7xLGMVQC58

Third test, nether fortress generated in 1.4.7 now in 1.6.1: https://www.dropbox.com/s/rgi4kpl6470jhs3/1.47%20to%201.6.1.png
Nothing Happens.

1.47 in 1.6.1, now in 1.6.2: https://www.dropbox.com/s/tfwwn4g699d9def/1.47%20to%201.6.1%20to%201.6.2.png
Nothing Happens.

All this test: https://www.dropbox.com/sh/a3zktltpzbtbbwg/S2YlwS3kqM

Fourth test, nether fortress generated in 1.46 now in 1.6.2: https://www.dropbox.com/s/3oa7oqc2mt633rn/1.46%20to%201.6.2.png
The Boundig Box moves up and to the side, 1.6.2 destroy this fortress

Fifth test, nether fortress generated in 1.5.2: https://www.dropbox.com/s/w5unw0zckmkgcjx/1.5.2.png

Now in 1.6.1: https://www.dropbox.com/s/0h0dxcrchd0hqjr/1.5.2%20to%201.6.1.png
The bounding box disappears completely, 1.6.1 destroy this fortress.

1.5.2 in 1.6.1, now in 1.6.2: https://www.dropbox.com/s/hbrzzlfpc6w1hjm/1.5.2%20to%201.6.1%20to%201.6.2.png
1.6.2 don't repair this bounding box.

All this test: https://www.dropbox.com/sh/bee58ltmslrh59j/NnUc9Nt6fw

Sixth test, nether fortress generated in 1.5.2 now in 1.6.2: https://www.dropbox.com/s/1pu5c0c9p2z86g5/1.5.2%20to%201.6.2.png
The Boundig Box moves up and to the side, 1.6.2 destroy this fortress

Final test, nether fortress generated in 1.6.1: https://www.dropbox.com/s/683uw0fkir1f5d3/1.61.png

Now in 1.6.2: https://www.dropbox.com/s/bb95v6u9jijg6lu/1.6.1%20to%201.62.png
Nothing happens.

All this test: https://www.dropbox.com/sh/lmu118esheo58a7/owZO1UbYu3

Conclusion:

-1.6.2 does not solve this problem and also destroys some old fortress.
-Perhaps the nether fortress generated before the 1.4.6, be saved of this bug.

Notes:
-The mods used to see the bounding box are forge and bboutline
-The Nether Fortress in test 2, 3 and 4 are from the same world.

Addendum: Maybe Nether Fortress with more covered corridors are most affected.

So the only fortress that we know works in 1.6.2. had to be generated in 1.6.2

That really sucks!

Any news on the status of this bug?

Still marked as fixed, yet existing fortresses still don't all spawn the mobs correctly depending on the variance of the existing fortress and it's phantom counterpart and if there is an overlap.

As this bug is about whether nether fortress mobs will spawn in existing fortresses, and they do not (unless the generations of the fortresses overlap) I feel that this should be re-opened or marked as "won't fix" if it's not fixable.

Thank You,

Reopened.

Thank you!!! I had to open a new bug (MC-26857) to report this bug was not fixed!

I want to get wither skeletons heads in my vanilla minecraft world, where I spent unbelievable amounts of time. I dont want to cheat / mod etc. Is someone working on this bug and when will it be resolved?

The cause of this bug is that structures aren't saved with the worldfile
and when they introduced chests in the fortress generation, they accidently used the same random object which is used for the stronghold generatiobn
therefore the strongholds would generate slightly different
and since the structures aren't saved witherskeletons wouldn't spawn were the old fortress is, but where the game would now generate the fortress
the thing is that there is no way to fix this, since they don't save when the world was generated, and many people now have old and new fortresses in their game
no matter what generaton they decide on( and it will probably just stay how it is atm) either the old or the new fortresses will be broken

What is really important now that they save structures with the worlfile! Especially now when changes to the worldgenerator are about to be made. otherwise this could easily break everyones witchfarm!

Confirmed by doing the following: Found an existing witch hut, made sure it still spawned witches. Changed seed of the world in level.dat. Loaded the world, biomes were saved, but the witch hut no longer spawned witches, only normal hostile mobs.

@Tails Could you please add the information about other structures like witch huts to the description/title of the post?
I got the feeling in the comments it might not get the necessary attention. Thank you.

Come on! I want deal with wither but no skeletons 😞

Johann-Lukas is right regarding the cause.

When they added chests to nether fortresses, they used the same random object to stuff the chests as they used to generate the fortress. The result being that initially the fortress will generate the same as before... until it creates a chest, at which point the RNG will get thrown off, creating an entirely different fortress from that point on.

I also agree that there is no way to fix this. The damage has already been done, the best course of action now is to just move on.

Confirmed broken (again) in Snapshot 13w36a. Opened up a world save from 1.6.2 that contained a witch farm, witches were no longer spawning.

What about nether fortress mobs? Are wither skeleton grinders broken again?

Of course it's broken "again" since it has never been fixed. They changed the way the overworld generates, your witch hut isn't there anymore.

Pascal : I've heard from various sources (none of which have Mojang confirmation from what I understand) that a fix was being deployed in 1.7 to not break existing structures. I was just passing along the information that it has indeed NOT been fixed at this time.

John W Bjerk: I haven't checked that as of right now.

@Adien Alexander it was something they said they'd try to do but couldn't garuntee it (mentioned at one of the gaming conventions I beleive). The fact that the world generation changed so drastically tells me that it was probably an impossible thing to fix on old worlds just do to the scale of the world generation algarithms changing.

@Adien I didn't mean to sound rude or anything, sorry if it could be interpreted that way.

The key fix needed is....
In this snapshot, are structures now being saved in the world file? Not just location (which would be fine for a witch hut), but actual fortress elements? If that is now being done, then this should be the last time it breaks. Otherwise, all bets are off!

The problem is structures and spawning zones are independent. The game finds a place to put a structure, and the game itself says the area that structure is in can spawn things. If generation changes, the spawning area moves with it, even if the structure is still there, as the game dictates spawning zones. What you want is for spawning areas to save to files, which sounds complicated in the long run...

Tested the latest snapshot yesterday and loaded the map of the server I play on with it. The map was generated in 1.6.2. My Witch farm did not spawn Witches anymore, confirming what Louis A. Nani said. Shall I open a new ticket for the specific bug that spawning areas themselves are not saved on old worlds? I do not want to start a new map on my server because our Witch farm and our Wither Skeleton farm doesn't work anymore.

Th3F4114n0n3 : Thanks for the Mojang Confirmation.
Pascal: Not a problem, seems I came of a bit harsh myself when responding.

Anthony Thyssen, Louis A. Nani, and Marius D: It seems Kabo (From the ZipKrowd server), has been messing around in the game code and has "fixed" the issue it seems. Waiting to hear back from someone to see that it work/Mojang's going to implement it.

Source: https://twitter.com/docm77/status/375876176297738241

Is this limited to structures? I've a suspicion :yellow_star: that with the changing world generation there may be a similar problem with slime chunks moving around.

:yellow_star: can't test at the moment, my computer is broken - using a borrowed one

@Adrian The slime chunks are not part of the world generation. There is a method which tells if a mob can spawn at a certain locating or not for each mob. For slimes it's also doing some calculations with the chunk coordinates (and the seed) to determinate if it's a slime chunk or not. It's not connected to the world generation and there is no reason to change it. Just to make sure I also took a look at the latest snapshot. The slime spawning hasn't changed there.

This is not as simple a fix as people are saying. 1.6.2 is already out; any fix would only apply in the snapshots and future versions.

So while this could be fixed for 1.7, you will still not be able to keep the structures generated for 1.6.2 and before. All it means that when Minecraft changes in the future, structures generated in 1.7 will be preserved.

They could just bring out an update for 1.6.2 to save the structures, or ship the old generation algorithm with 1.7 and "convert" the chunks to add the data on first load with the new version.

Not really.

If they update 1.6.2 to 1.6.3, with a quick fix to save the structures, there are two problems. What if people skip 1.6.3, and go straight to 1.7? And even if they don't, what about the 1.6.2 maps that people don't open in 1.6.3, but they come back to it later?

If they "convert" the chunks on first load in 1.7: yes, technically they could do this, but this is neither a simple or a quick fix. It's probably a good idea to do it anyway, and it will need to be done at least once in preparation for the MCAPI, but unless Mojang is planning on doing much more extensive changes in 1.7 than they have already done, (and they have made some extensive changes,) it will most likely not be worth it.

they could not only save structures but biom data, too (in every chunk or block), so that there are not too drastic changes in the old part of the world 😉
btw. haven't they already made a change so that the biomdata gets saved somewhere (you can edit it in mcedit, I think)?

They do save the biome data; and as for the structures, I suppose that they could keep some sort of "version" tag attached to each chunk, which may help decrease the load when converting the world, but that's asking for trouble, don't you think? (Not only are there different world save formats, but now a single save can contain data in many different formats.)

Do to the complexity of the changes between 1.6.2 and 1.7 the best thing they could do is make a world converter so that it finds the information relating to structures and spawn items from 1.6.2 and converts them to the 1.7 world generation while holding there locations fixed. While its kind of an extra thing to do it would save from people having to do multiple updates or forgetting to let the consol update for them. although its bassically the same thing (needing to remember to do the converter before launching 1.7). Possibly just pushing a 1.6.2 hotfix (no number change just forced update) or making 1.7 automatically find these items and hold them true during updat to the world.

The problem is, that with all the world generation updates they've already done just in these 2 snapshots. Its not to far fetched to say they aren't done yet. The 2x2 spruce trees, 2x2 oak trees in roofed forest, and the Savana Acacias being a good example. Its not out there for them to create new tree coding and make these new trees uniquie (wood, leaves, saplings) instead of just reusing existing data and making them uncreatable on there own. So figuring out what they could do now may be pointless until more snapshots are released and the final version gets closer to completion.

Confirmed possible 1.6.3 to fix this issue, so we know it's high on the radar right now: https://twitter.com/Dinnerbone/status/377820228815949824

@Adien Alexander
In reply to this: http://bit.ly/1b9tSBz
Mojang no accept code of people that don't work on Mojang because Minecraft isn't open source. If not, see, Jeb is trying to repair the structures on their own before asking for help to Kabo. https://twitter.com/jeb_/status/378070921917239296

why shouldn't he take a look at Kabo's solution if he doesn't find one on his own!?
that's just more work for him and probably not the best solution if Kabo has an "easy" solution and he wants to make a "hard" one

Because of rights. Some people like to be paod for there work, and legality makes things hard on developers. They aren't Open source, like previously stated so if a second party finds a fix and the prmary wants to use it, it can cause an issue if the person is looking for it. Not saying Kabo is looking to cause an issue if Mojang did use it but companies try to stay away from those things if possible. Thats why Mojang doesn't just implement Mods the way they are. the colaborate with the mod maker and work on a happy medium for the addition.

An "easy" solution isn't necessarily the best one. Easy solutions to problems are what led us to this problem in the first place. Thinking ahead is hard, but worth it. I'm rather surprised they didn't think about structures back when they realized that they should store biomes, rather than recalculating them every time.

Particularly in programming, "easy" often means easy for the programmer, but hard for the system it's operating on: not efficient in terms of computing power or memory. There have been instances in the past, such as the lighting fixes, where Mojang has chosen to put it off and spend the necessary time to develop a more efficient fix, rather than push out something that fixes the problem, but at too high a cost in performance. They don't want to exclude a large number of their users, just so the ones with better computers can have a fix now, rather than later.

Also, as @unknown implied, there are certain legal complications to even looking at another person's code and then implementing it. To avoid hurt feelings or actual legal action, it has to be made very clear up front what, if anything, the person providing the code is owed. They've been able to work something out in the past in some cases (Hippoplatimus and the pistons mod, horses via DrZhark's Mo' Creatures), and not in others (sp614x's Optifine). Being too hasty is just looking for trouble.

@Th3F4114n0n3 good explanation, but Kabo has programmed it to implement it into Minecraft and not to cause an issue
" the colaborate with the mod maker and work on a happy medium for the addition" thats what Kabo wants to do: help Mojang to fix it -> they can write the code together 😃

@Torabi right but they could work together and set up a contract between Kabo and Mojang that Kabo gives them all the rights to using and modifying his code without naming him or something

I feel I should comment on this conversation.

The issue over whether or not this is "easy" is really a non-issue as it's easiness is really something to be determined by the Minecraft developers. What I mean is: even if my solution is "easy" in my mind, it might not fit well with the vision that the developers have for the way Minecraft is coded, thus, it may be difficult for them to implement especially if the have planned a huge reorganization of the code.

Also, since it seems like people are curious here, I'll also say a bit about the solution I developed - the idea is that structure data are saved exactly as they are in the game to a .dat file using the NBT classes in a similar way as the villages; this uses the existing methods that already exist in the code and tries to avoid as much as possible having to create something new just for saving structure data. When the data are loaded it creates objects for each structure, so ideally you could save and load a structure exactly as it was when it was first generated by the world. That was the idea when I developed it, anyway.

Also, as far as usage rights go, this is just my personal case, but I have no problem with Mojang using and distributing any or all parts of the code I developed for this solution without attribution (though, it would be nice of them if they did) and they are welcome to contact me if they need to go so far as to get something legally binding from me.

Edit: It looks like I might have misunderstood Torabi; it's good to make a point about efficiency, but in this case the saving and loading is quick and keeping the structures shouldn't put more load on the game than if the structures were loaded anyway (which isn't much ... they don't get ticked and only become an issue if you have so many structures loaded that they started needing too much RAM).

@unknown, have you actually tested this solution, and found it to be working? I'm inclined to believe there would be problems with using the existing code, considering MC-10841.

And considering just how much code has changed in the snapshot, I'm not sure it's safe to assume anything about reusing any currently existing code.

Without considering those two points, that does sound like a good solution – as you say, those structures are already created in memory when the chunk is loaded, so there shouldn't be much of a performance hit. It might actually be an improvement, depending on the cost of saving and loading those structures versus regenerating them. My comments were primarily intended to deter general arguments from ignorance, of the "I don't know anything about it so it must be easy", or "I don't understand why they're taking so long to do this obvious thing" variety. I hoped that explaining the sort of complications involved in this situation might encourage people to think a little more in the future, rather than yelling at people to hurry up and implement solutions that everyone may regret later.

My fix just uses the same method of saving to .dat files using NBT data used by the villages, but the data structure is actually handled differently and in my opinion a bit more carefully. I have indeed tested it, and did find it to be working; I did a couple of tests: the first involved completely disabling the regeneration call for structures and the second involved adding 1000000 to the seed for the random object used for nether fortress generation. In both cases, the previously generated nether fortress which I had saved was still generating it's mobs and was properly saved.

The village issue is actually related to something else; Tango and I have talked about it and the bug report does not exactly describe the reason that villages break. Another thing to note about villages is that they do not save data for the nether and the end - this is something that I discovered when writing my fix.

I see what you're saying about the discussion here, it can be hard to get a grasp on what is fact or fiction, especially since we have such limited interaction with Mojang with it actually comes down to the code.

Also, I, personally, have no problem if Mojang chooses to use a different, better solution from mine as long as it is functional, comprehensive, and planned for future development (I tried to make mine this way by saving all object details using NBTs so that they can be reloaded exactly as they were saved, but there's only so much you can do when you don't actually work for them.). I'd only be upset if they end up taking a half-serious approach.

I've been using the Skyblock 2.1 map (hardcore, of course) to test this. I still have not been able to get blazes to spawn at the nether coords where that seed produces a fortress. (Blaze rod -> potions -> villagers -> access to redstone, diamond gear, enchantment books, etc!)

Tim: Did you load the chunks in 1.6.3 first, then change over to 13w37B? 1.6.3 adds the save mechanic, and 37B is the first one that will read it.,

I haven't tried it yet, but I didn't get blazes spawning in 1.6.2 either, could your suggestion help in that case?

Also, would the save mechanic work on completely empty chunks that were originally created when Noobcrew designed that map (late 2011 or early 2012, I believe)?

@tim gunderson: that is probably a map issue and has nothing to do with this bug (because your problem existed also in 1.6.2)
and you have to load all structures you want to get saved in mc 1.6.3 by moving into the chunk/area
then they are working again in 1.7 (docm77 made a video that prooves: the fix is working)

This is an important point:

My understanding is this fix will preserve structures that work in 1.6.x in the transition to 1.7 snapshots – if you visit them in 1.6.3.

It doesn't fix structures that were broken in the transition between 1.5.x and 1.6.x.

Correct?

Forgive me if I'm getting this completely wrong, but I would assume that the 1.6.3 saves all the structures that the 1.6.3 world/biome generator considers to be structures, into a separate structures file, that the future versions will use to decide what areas are structures. So it can't know about any previous versions' structures, before the biome generation code in the 1.6.2/1.6.3 version.

TL;DR; Only the structures that would be generated (= are in the same place) in the 1.6.2 world gen (and are visited/loaded in 1.6.3) will be preserved in 1.7 and forwards.

But what I would also like to know, is that will 1.6.3 also mark all the loaded chunks into some kind of "structures marked" list, or maybe 13w37b and beyond will not add the structures from already generated chunks into the structures list anymore? The latter would still allow to mark the newly generated structures, but not add structures to old areas where those weren't previously present, but the new 1.7+ biome generation would place for example a witch hut. What I mean, is that I hope that none of the old areas suddenly become structures in 1.7+. I would hate if our stone brick and glass nether tunnels would start spawning blazes and wither skeletons inside them...

1.6.3 only saves structures for 1.6.3 generation. The implementation for saving structures, however, does allow for any properly formatted structure data to be loaded, so you can use a post-release mod for earlier versions to save their structures if you need to, and they will load into the 1.6.3 or later vanilla versions, OR if you know what you're doing, you can use an external tool to edit the structure data and create structures where you need them (many people would consider this cheating, but if you're trying to fix a structure it might be a different story).

It is not necessary to mark chunks as having generated structures. For several versions, there has already existed functionality to prevent generating structures in chunks that already have them. When they are loaded in, they should be associated with the chunk they are created by and no other structures of that type will try to appear.

I'd love to see such a mod to recover my pre 1.6 nether fortresses. Any chance you could write such a mod Kabo?

Its true I started a new world with a seed I knew the was a village at spawn and a jungle temple and when I started the world there was no village but the there was a temple...

I wonder why the issue is changed from:
"Nether-Fortress-Only" Mobs no longer spawning in previously generated Fortresses"
to:
"Structures (witch huts, nether fortresses etc.) don't get saved with the world file"
and then it is considered to be reasolved?
The iisue is that a map where huge amounts of time gone into is broken and should be fixed as they were. As I read these comments this is not fixed.
Is there a tool where these structure data of the old generation method can be restored without changing the work I put into the map?

• • PLEASE:

Backport this to the 1.4/1.5 worldgen as well.

In other words, since nether fortress/strongholds got messed up in the new version, give those of us that have not yet upgraded the ability to preserve our worlds as we move forward.

I would hate to upgrade to 1.6.4, only to find that the game now thinks that all my fortresses and strongholds are in different locations.

So, not only do we need a converter program (so we don't have to visit every chunk), we need to be able to tell it "This world had 1.5 generation" or "this world had 1.6 generation".

Or worse – do the 1.6 strongholds actually "move" depending on whether you went to the nether before finding them?

Strongholds are not effected, as they currently do not have any structure specific spawning. End portal and Feesh is handled by the specific blocks that exist in the world, and not the structure location.

Same is true for mooshrums on mushroom biomes. It is biome related which is already saved as part of the world.

The problems are with Witch Huts (for witched), and Nether Forts (wither skeleton and blaze). Blaze however is not a big issue are fortresses also have blaze spawners.

Back ports for 1.4 and 1.5 would be nice to allow updates for those older worlds.

The problem is that strongholds are "structure-specific" in being the target of eyes of ender.

Does the bug affect the locations of strongholds, or only the contents of strongholds? In other words, do the eyes of ender still work correctly? Is it possible for the error to result in old strongholds no longer targeted and new ones wanting to be generated?

What I don't really quite get here is why a 1.6 patch was needed–especially one so annoying (load up all my chunks? by walking? really?)
Look, structures are generated algorithmically. They are, in fact, going to be the same for a given version and given seed on a given world generator, because the seed is fed into the random number generator used to populate the world. Even if the algorithm itself is fundamentally broken.
Why can't 1.7 just keep a copy of the old (1.6) algorithm around and use it when newly-loaded anvil regions don't have 1.7 structure information? This would mean that users would no longer have to load up their worlds and remember to walk around over structures they might not even know exist (and would therefore forget and totally screw over for the 1.7 update.)

Dustin, I'll agree with you on one point. We shouldn't have had to worry about a patch here. Any object that you plan to use later and is generated based on a random seed should be saved rather than leaving it up to chance that it doesn't break between versions; this is something that was a development oversight from the beginning and should have been fixed much sooner.

Concerning the method you are suggesting, the first issue comes from deciding which version to use. How do you know that the chunks being loaded were from 1.6? Without patching 1.6 to add a tag to each chunk telling it which version generated it you would have no idea since these data do not currently exist. this leave the same problem of having to walk around and load the chunks you want to keep.

Next, how many differences are you going to track? Would you copy the structure generation for every version where it changes or would you try to do it by line items in the code? Either way you're either duplicating the code for each version OR having to branch the generation at every line where a different random call or set of random calls is made. Neither is a desirable solution.

If you are concerned about forgetting to load a structure that you desire to keep, my suggestion for you, depending on how close to vanilla you want to play, is to make backups before you change to the new world and retry, wait for a mod that will load them for you, or (possibly the best option) generate the structures in a backed up 1.6 version that saves them, then copy the structure data for the particular structure in question over to the 1.7 version (this is extremely easy and I've already given an explanation on how to understand the structure data in a video).

Kabo: "this is extremely easy and I've already given an explanation on how to understand the structure data in a video"

Here is is: http://www.youtube.com/watch?v=l_fsxwrPy34

Agreed with both Kabo and John.

@Dustin - while it seems simple, what you explained isn't. They rewrote the world generating algorithim. chunks don't look for the algorithim after they've been generated so they don't know what created them. they actually don't even know thier own seed (technically). The world file can check it self to the algorithim to see its seed. The problem is, again, they changed the algorithim which means your seed in 1.6 isn't the same as 1.7. The algorithim for sctructures rely's on the seed and since it changes in 1.7 the algorithim will change there locations. Again, remembering that chunks don't save the seed information to the chunk telling 1.7 to leave information in the chunks is possible only for newly generated chunks as the old ones woulnd't generate any new information until they are loaded in your world (this is what this patch does). The patch forces the chuncks with "structure data" in them in 1.6 to finally save themselves somewhere that 1.7 can read but only after loading, as the information wasn't there to begin with. They have to be loaded as they didn't previously save any information to anything. thy just ran themselves back through the algorithms on world load.

> Why can't 1.7 just keep a copy of the old (1.6) algorithm around and use it when newly-loaded anvil regions don't have 1.7 structure information?

We could just as easily ask, "why not keep a copy of the old biome generation around, and use that to decide which biome to assign to a block?". The answer is, as we have seen, that it is much better to keep that tracked in the map. It permits people to make custom maps, with custom biome information.

Moving forward, this will permit people to make custom maps with custom structure setups.

Imagine if everything were done this way:

• Slime spawning being tagged in the file, so map makers can control where slimes are hidden

• Mob spawning regions: Right now we have "skeletons and blazes can spawn here". "Witches can spawn here". "Nothing can spawn here (mushroom island)". What if all of this were map assigned?

• Village identification. Imagine if villagers were smart enough to know about the entire village, no matter how big it was, and actually use all of it. Now imagine if that village was split into two sections with a barren wasteland, or perhaps a quarry, between the two parts – such that the vanilla village code would consider it two separate villages, and not consider the center to be part of the village. (Why the wasteland? Ask the map-maker who made that split village part of the plotline).

There are still a few questions to ask:

1. Why was the obfuscation table changed? Instead of 95% of mods working unchanged, everything had to be adjusted.
2. Why not release a 1.5.3? This does affect all nether structures made up until now; you'll either have to regenerate your nether from scratch or have things off. (Given how big our nether got before 1.5 and quartz, this looks like the best option for our server – keep the hub and toss everything else.)
3. Why not have a patch program auto-load all existing chunks? We've seen converter programs in minecraft before – see .mca/.mcr
4. And as you mentioned, why not have 1.7, when it loads a world and sees no structure information, just assume it's 1.6 and stamp out the 1.6 structure information? That has the same affect as a patch program loading the world / a converter moving from .mca to .mcr, while still letting custom map makers make maps customized. Note that if this were done, doing it on a region by region basis is a BAD idea – do the whole map the first time it's loaded and found to be missing. The map should be in a single consistent state at all times.

Requiring manually visiting every spot? I can guarantee that people will miss spots. This has to be a ... brilliant idea, for some concept of brilliant that I don't quite understand.

Not sure if you comment is answering, asking, or stating. Basically why we don't have the 1.6 algorithim with the 1.7 algorithim has a very easy set of answers answer. One is the size of the algorithim. Its not as simple as y=3+c. It can be thousands and thousands of lines of code. Most of which requires other algorithims to draw from. Second having both Algorithims would also cause cross talk problems. So you have 1.6 algorthim running when you open an old world, then as you start loading new chunks and they use the 1.7. While it sounds easy, at what point does the 1.6 stop running? How many lines of code would be needed to make this transition happen seamlessly? The answer, a crap ton. And hoping the algorithims don't interfere with others since they both want priority at one point or another. Your bassically asking them to do more than you realize. you could potentially corupt your world generation and make your world unplayable. or your asking Mojang to extend the release date of 1.7 by months (like 6 months minimum to test on there end). We wouldn't see another snapshot or update for a long time. And in that time you could have already loaded the chunks and had 1.6.4 write the structure data.

Now, what would be useful is a world tool/program that you could put your world file in and it extracts the information without you having to load every chunk.I know programs like MCedit use to show you all chunks that have been loaded in the world file so I can't imagine MCedit couldn't be modified with less effort to create these files for you. At the same time if you've loaded 50 structures, do you actually visit all 50 structures on a regular basis? Can you deal with missing some that aren't important? You don't have to load every chunk, just the ones with structures. If you know where your structures are, then go load them. so it takes you an hour or two to load them (most structures aren't more than a few chunks with your biggest being nether fortresses) you can afford to spend one session of playing loading the specific chunks you want to save (not every chunk).

Me: > And as you mentioned, why not have 1.7, when it loads a world and sees no structure information, just assume it's 1.6 and stamp out the 1.6 structure information?

Th3F4114n0n3: > Basically why we don't have the 1.6 algorithim with the 1.7 algorithim has a very easy set of answers answer. ...

On the assumption that you were responding to me, I think you missed the point of what I was saying.

When the map save format changed, moving from .mcr (region format) to .mca (anvil format), the game would detect the old format, and stamp out new data, all at once.

There is no reason this same behavior cannot be placed into 1.7, even now – load up the existing world, stamp 1.6 structure information into the whole thing, and save that all out.

Equally, there's no reason not to have a 1.5.3 that only does this with 1.5.2 level data, for people who have not updated yet. Remember, 1.6 did change the nether fortresses, at least (all I know of).

> So you have 1.6 algorthim running when you open an old world, then as you start loading new chunks and they use the 1.7. While it sounds easy, at what point does the 1.6 stop running? How many lines of code would be needed to make this transition happen seamlessly? The answer, a crap ton.

No, you don't run both at the same time. You transition. The map is always in one consistent state, either the pre-structure or the post-structure.

> At the same time if you've loaded 50 structures, do you actually visit all 50 structures on a regular basis? Can you deal with missing some that aren't important?

Have you ever run into an empty village? Only to count, and find that it's about 120 blocks from your base? And realize that as you're moving around the area just outside your base, this village has come into and out of focus at night?

And with a little thought, realize: zombies loaded into memory will move around, see a villager, and chase. Even if only for 30 seconds, every time you leave the range and come back, it gets another 30 seconds.

(It actually had two surviving villagers, but it had buildings that clearly indicated other villagers had been alive at some point. Distance 120 is approximate, I could go back and actually check.)

Finding structures that don't work – whether villages ruined by the crime of being too far from you to be seen behind the hills but close enough to you to be killed by zombies, or swamp huts where nothing will ever spawn, or having no witch spawning zones at all within 3000 blocks of your base, or trying to find a new nether fortress only to find a bunch of nether brick that just sits there and does nothing but pigmen and ghasts, ...

Heck, just imagine if your ender pearls lead you to the middle of nothing because you never loaded the stronghold chunks because you didn't know where they were.

Now, is that all?

Here's a question I don't know the answer to: If you walk near a chunk, such that the chunk is loaded, but nothing in that chunk changes – it never gets dirty or altered – then does the chunk get saved back out, or not? If only modified chunks actually get written, then what? Yes, I know that a monster being generated, or moving in the chunk, will "modify" it, and I know that the likelyhood of the optimization being valuable is low, so it might not be done – but if the game does attempt to track dirty chunks and not write clean ones out, then are you sure you got all of them saved/marked?

I see your point through most of it but:

"There is no reason this same behavior cannot be placed into 1.7, even now – load up the existing world, stamp 1.6 structure information into the whole thing, and save that all out."

I'm not understanding tis sentence. It soulds like your saying on world start it would determine whats new and whats old and stamp them out to be set as structures. The problem is that the chunks aren't loaded for it to scan eveything on start up. You could theoretically have it load all discovered chunks at once but then you'd lag all to hell, if not crash on the lower end machines. As to your enderpearl statment. Enderpearls won't do squat when they hit an unloaded chunk They stop at the boader and wait for the chunk to load before detmerining where to place you so that argument doesn't work.

To the point of finding a villiage that now doesn't work cause you forgot to load it, I hate to say you'll have to deal with it, but you just might have to deal with it (not trying to be harsh or mean or anything of the sort) its the limitations of not just the World generating algorithim but several if not all the game mechanics and algorthims combined. The process there would be to have a back up of your world that your could go into to load the structure to file if you found one. Ik the argument of "what about all the work you've done thus far since you moved to 1.7", I'm not saying replace your world when you find it, just go back into the back up in 1.6.4 load the villiage, it'll write to the backed up structures files, then copy those over your exsiting structure files, in theory they should now work in your 1.7 world.

All of the changes to have 1.7 work and keeping old algorthims keeps back to what I said before.. the World Gen Algorithm is tied to several others (which some change between 1.6 and 1.7) meaning that they'd have to rewrite both 1.6 and 1.7 or most of the 1.7 algorithm again just to keep it from bugging out. what I was saying about the running the 1.6 algorithim then new stuff running the 1.7 was that they'd have to right either a new algorthim to handle the transitioning part from going from 1.6 chunks to 1.7 chunks or you get the issue now where suddenly the cliff drops off to ocean with no transition. They might even have to rework everything they've done to accomidate for the possiblility of people moving from 1.6 to 1.7 in a 1.6 world which can get messy. Theory and application don't always see eye to eye.

As to your question, my understanding when the chunk loads it forces a block update which should force the chunks to get saved out but I know it isn't always the case. Thats why the said to load the chunks, they should get loaded to the game memory and then right out to there proper files.

Yeah it sucks with losing everything and rebuilding is a pain in the rear, but sometimes starting new is the only option if your at that point. They aren't going to go back to 1.5 and make a 1.5.3 to accomidate people who haven't update since then. Its just not feasable for them to as they're resourses are in current releases. they gave a reasonable option for 85% of people wanting to bring there old world over by having people load the chunks they want brough over. again it doesn't help them when they want to find the new stuff as it's going to look messy. when they do a World Generation update to this scale, its kind of expected to start over, even if it might suck. You could alsways MCedit your house into a new world.

The best solution is someone making a program (or modifying one that already loads all visited chunks) to extract the information and save out the proper files.

OK, so a bit of misunderstanding here.

I'm not complaining about the decimated village. I know that's part of how things work. I know that if it had gone longer, it would have been completely wiped.

Point is, imagine going to some other structure you find, and find that it doesn't work – because you did not know about it until after you went to a 1.7 game engine.

Second, I mixed up ender pearls and "Eye of Ender". Eyes of ender are supposed to be the tool you use to find strongholds – what if their location changes and you never knew to visit their old location? Imagine this sort of thing happening to any structure.

The point is: "Players must visit the structure for it to work" is a bad idea.

> I'm not understanding tis sentence. It soulds like your saying on world start it would determine whats new and whats old and stamp them out to be set as structures. The problem is that the chunks aren't loaded for it to scan eveything on start up. You could theoretically have it load all discovered chunks at once but then you'd lag all to hell, if not crash on the lower end machines.

Nope. This was exactly what was done – and still done, as I understand it – when you load a region format world into an anvil format engine. It loads and converts the whole world.

> They aren't going to go back to 1.5 and make a 1.5.3 to accomidate people who haven't update since then. Its just not feasable for them to as they're resourses are in current releases. they gave a reasonable option for 85% of people wanting to bring there old world over by having people load the chunks they want brought over.

No. You mis-understood the issue here.

100% of all nether fortresses generated prior to 1.6 are ruined by 1.6!

Many people have nethers that are dominated by 1.5 generation; relatively few nethers are dominated by 1.6 generation.

If you had a 153 that could stamp out structure information, then all you have to do is load your world in 153 once; then, you have proper 153 structure definition in the nether, and 164 will work correctly with you pre-16 nether.

Nether fortresses were what, 142? So all the 14x and 15x fortresses would be fixed by a really simple update, and forward compatible.

As for keeping the old world generation algorithm: Last time I checked, you could use the 1.1 world gen, or the 123 world gen. Adding in the 1.7 world gen only means that the game has three of them instead of two of them.

Yes, you have to manually adjust flags to get the old gen – there is no GUI setting for it – but maintaining multiple world gens can be done, there is an internal API to select flat, standard, large; that can be extended to permit ATG, or BWG, or BOP; the same system permits unlisted but still present older versions.

Mixing two different systems is not being mentioned here.
Mixing two different systems will happen – but in the sense of "All your old chunks are 1.6, all your new chunks are 1.7" – and we've seen that happen before when jungles were added. Mixing the output of these two systems is not a problem.

And no one is talking about mixing both as live code at the same time.