I just set up a profile for 1.2.5 so that I could look at how some places a world of mine originally would have been. It was given its own directory. Besides my skin not working, which was expected, and some texture pack issues since MCPatcher no longer works, everything went well. Once I loaded into a world though, something immediately jumped out at me.
Leaves on large oak trees and jungle trees started rapidly deteriorating. I recognized this behavior for what it was. I recall that around one point, the way some trees would generate was changed (large oak trees and jungle trees at least), and this also changed their leaf decay. I can't remember the specifics, but from what I gather, certain leaves would be no longer valid (too far away from logs) by the new way of doing it. I recall that many leaves on older trees in my original world have this distinct pattern of lead decay as a result. But this happened many years/versions later. Trees generated in 1.2.5 originally would have been valid at the time, so this leaf decay didn't originally happen in 1.2.5.
I've also noticed that the sky seems to have smaller and and more numerous stars (like modern Minecraft). Previously, they were larger and fewer. I actually believe it may have been the version immediately after 1.2.5, that is 1.3, that changed this.
Why are these two things happening in 1.2.5 then? I'm imagining there's possibly other changes as well? I find that unusual that they actually changed the older versions since they don't usually do that, so I'm guessing there's something else to it. Are older versions not TRULY the original older version? Like is there something else to the equation that can throw them off from being entirely accurate, despite having the original .jar file?
A lot of variables factor into this, although this is just purely my speculation.
With every update of Java, some logic internally may be changed. For example, if the version of Minecraft was built on Java version- say, 7, and Java 8 was to be used instead, between that update from 7 to 8, the developers may have fixed a number bug. I'm not saying this happened exactly, but it could be a cause; although this is just speculation.
Older versions were silently given a hotfix at the same time I want to assume, but that may have just been coincidence and they really were just updating something else.
However, silent hotfixes like this cause issues like when someone wants to make a mod for 1.2.5 or 1.4.6 and MCP (the tool that decompiles Minecraft) just errors out because the jar files were updated and MCP has logic specifically for that unfixed version.
As far as I can tell Mojang has never retroactively updated older versions; I downloaded the jar for 1.2.5 and all the files have the same date as the original release (March 30, 2012; technically April 4 but they simply renamed a pre-release):
Also, the "security update" mentioned by master801 only pertains to 1.8.4 and later versions - this is precisely why Mojang always urges you to update and does not provide any support for older versions:
Update: Mojang has released a security update that takes Minecraft to version 1.8.4, which fixes the security vulnerability "in addition to some other minor bug fixes & performance tweaks." The update is fully compatible with all previous 1.8 releases, and Mojang strongly recommends that all players upgrade to the new version as soon as possible.
As for as updates to Java itself, the changes you mention are so fundamental that if a change to Java actually caused them the entire game would certainly not work at all (I'm not talking about changes to Java libraries but the most fundamental operations; addition, subtraction, bit masks, comparisons, etc). My first world is also still identical to the original world created a decade ago (well, not quite, due to MC-55596 and the removal of water lakes from deserts in 1.6), and I certainly would have found out if they had ever changed the original 1.6.4 jar since I've been working with the same MCP instance since late 2013, so any changes at all would likely cause mismatches between classes, given the sheer scale of my modding.
Also, I decompiled 1.2.5 and compared it to 1.6.4 and it seems that stars should be larger; a value that ranges from 0.15 to 0.25 in 1.6.4 is instead set to 0.25 to 0.5 in 1.2.5 (the last line in each code block, the rest appears to be the same):
I don't know why you didn't have issues with leaf decay until a later version since the exact same code is used in 1.2.5 and 1.6.4 and as mentioned above it is exceedingly unlikely that any changes to the Java version would have an effect; the Wiki seems to indicate that the last change to the leaf decay algorithm (before 1.13 increased the range from 4 to 6 blocks) was in Beta 1.1, with "permanent" player-placed leaves added in Beta 1.8 (presumably just the addition of a new block state).
Also, I found a thread from before the full release of 1.2 (filed under 1.1 update discussion) that mentions leaves decaying on jungle trees:
In addition, I know what causes this; while leaves placed during world generation do not have the "check decay" bit set anytime a leaf or log is broken (or replaced) it will check for leaves nearby and set their check decay bit, which frequently happens in forests because trees can overlap (leaf blocks can replace leaf blocks, even of the same type. This includes the individual leaf clusters and branches of big oaks and jungle trees). I was able to eliminate leaf decay by simply disabling the adjacent leaf checks during world generation (I added extra logs to trees in TMCW but not in my first world to keep it "vanilla", prior to extending the maximum range from 4 to 6 blocks).
Example MCEdit analysis from vanilla 1.6.4 (not all the leaves marked as "decaying" will actually decay, I don't actually see that many trees with obvious signs of decay, mostly big oaks, as big jungle tree canopies are generally separated enough to not be overwritten by trees nearby and most of the "decaying" leaves are adjacent to branches, which generate after the leaves do and thus trigger adjacent leaves to check for decay, but they are always within range. Likewise, big oaks by themselves, common in Extreme Hills, show no signs of decay):
With block notification disabled during world generation (yes, not a single leaf block was marked as "decaying" over a much larger area, both worlds had been loaded for only a short time, as random block updates will cause "decaying" leaves to either decay or clear their check decay bit):
Some examples of "decaying" leaves from the vanilla world which will not actually decay:
This shows how overlapping trees will cause leaves to be marked as decaying due to leaf blocks being overwritten, but they will not actually decay due to being close enough to a log (after a random block update they will revert to "normal"):
An example of how jungle trees cause large numbers of leaves to be marked as decaying without actually doing so, due to the branches being generated after the leaves, but only leaves adjacent to the leaf blocks that were replaced are marked and since they are next to a log it doesn't propagate, thus the main issue is leaf blocks being replaced with other leaves:
Some in-game screenshots I took within the jungle after I waited about 5 minutes; very few, if any, of the big jungle trees had any signs of decay while I found multiple big oaks that had decayed into a conical shape (if you are wondering, yes, jungle trees are supposed to look "ragged" in 1.6.4; since 1.7 they were changed to a perfect circular shape, which IMO looks too uniform):
A couple big oaks; the one on the right decayed (notice that a small jungle tree grew into it):
Another intact big oak with several that had decayed nearby (to the left):
In addition, this is a comparison of my first world to a newly created world, 10 years and one version later; the differences are mostly due to player interaction (besides what I built, I covered up a ravine and cave openings and cut down/replanted trees), and the removal of water lakes from deserts in 1.6 (the area in the lower-right is due to chunks not being fully generated in the new world). Other differences can be attributed to changes to chest loot in 1.6, which will alter the state of the decorator RNG in chunks with mineshaft or dungeon chests, and even the direction the world was explored in (as described here). There are also lines in the taiga where snow doesn't cover leaves that extended outside of populated chunks, which will be covered after the first snowfall, otherwise, the trees all appear to be identical:
Huh? Maybe it was my memory that had changed with the leaves decaying then. I recognized what this was, but I thought this was something that came later. Then again, I guess I would have been far less attention to this stuff when I was new in 1.2.5. I guess that explains that one.
And I'm not sure what's up with the stars. I just let it go to night and checked, and indeed they are the correct way for the version (larger and less numerous than they are in more recent versions). I guess I was just presuming they would be different since when I tried going back to 1.2.5 at one point in the past, I recall the smaller and more numerous stars were showing up. But apparently my memory is in question on this one, given the leaf example above.
You're mentioning differences that you claim were always there and then questioning if they really were; anyhow, I can say that even in 1.6 tree leaves could break on big trees' edges because of the formula used for calculating them.
If anecdotal recollections mean anything, I recall that whenever I would enter new areas in late Alpha/Beta and also in Tekkit Classic worlds (1.2.5) there would be saplings scattered from freshly decayed leaves. Jungles in Tekkit Classic were particularly prolific.
I don't know about leaf decay but I do know other things change somehow when running an older version on the new setup. One that comes to mind specifically because I tried it once is the old seed "Glacier" on one of the beta versions (I think, might have been alpha). It was a popular seed back then. You spawn near a floating island, and in the original version, that island would have a water spring flowing from it. In subsequent versions, that spring would no longer spawn. The island and the rest of the landscape would be exactly the same, just water springs and as I recall, tree positions would also be different. I put it down to something in the random number generator outside the Minecraft code was causing it, but then I'm no Java expert.
Rollback Post to RevisionRollBack
D_B
To tell them how to live is to prevent them living.
I put it down to something in the random number generator outside the Minecraft code was causing it, but then I'm no Java expert.
If this were the case then worlds would be totally different, including biomes and terrain, you may as well have used an entirely different seed, and it is highly unlikely that they would make such a change to the built-in RNG, even as old and low-quality as it is, as far as I can tell the last change made to it was all the way back in Java 5, the oldest version any version of Minecraft can run on (up to 1.5.2) and that only changed how a random seed is obtained (it used to use the system time but now uses a more complicated formula):
This is mostly theoretical. But if you were to generate a new Minecraft world, with a random seed, in a really old Java-version (e.g. Java 1.4.2), around Sun Jul 06 10492 04:47:30 GMT-0500 (Central Daylight Time), in the right millisecond it would get your seed. With Java 1.5 being released long before Minecraft existed, it is unlikely that this ever happened though.
(the "one of 65536 similar seeds part" is a direct consequence of Java's Random only using 48 out of 64 bits; while the biome generator used since Beta 1.8 uses a custom 64 bit RNG everything used Random before then)
The documentation for Random indicates that they changed how nextFloat() and nextDouble() work internally in an "early version of Java", likely long before Java 5, since again, even such a small change would drastically alter the values returned and affect a lot more than just water springs or trees:
The method nextFloat is implemented by class Random as if by:
return next(24) / ((float)(1 << 24));
In early versions of Java, the result was incorrectly calculated as:
It may be that you need a very specific version of the game to get the "original" version, as any number of changes to world generation, no matter how minor, may have affected them since a single RNG is used to place all decorations and it is only seeded once per chunk, thus any changes will cascade down the line, as I noted for my first world; even the direction you travel in can matter since features like trees overlap outside of the chunks they were placed in (this is also the cause of weird world generation like flowers placed on sand, which is placed first within a given chunk but since it is more than 1x1 blocks in size it can extend into adjacent chunks, replacing the blocks below flowers, which themselves also generate in patches more than 1x1 in size so they extend into unpopulated chunks at the edge of the world).
For example, this is a comparison of the same seed in the "original" version of TMCWv5, at its initial release, and a recently recreated copy in the "current" version (which is the same release/download as I do not release incremental updates as new versions; 5.0.0, 5.0.1, 5.0.2, etc; only for major updates; 3, 4, 5, etc); many decorations and a few caves are different butt he world itself is the same (I don't consider such changes to be significant, except where larger changes to caves might occur along existing chunk boundaries, which can be avoided by pregenerating or trimming the area, as I did once):
This also shows how even two worlds recreated in the same version, with no changes, can result in differences in world generation, as seen near the bottom of the "new" worlds (in this case only trees were affected since in TMCW I reseed the decorator RNG after each set of features to help minimize changes like this). Part of this was due to changes to trees, specifically, the addition of "dead/fallen trees" (a typical update post which included these changes; the changes I made to lakes was minimal enough to make no difference, except where a tree might have tried generating on a block next to one which was since removed):
If you look closely you'll notice that only the 1.8 stone types changed in most areas, since I generate them after other ores, which were unchanged. A large cave near the lower-left increases in size due to a change I made to bring them closer to ravines in terms of the frequency/size distribution; likewise, I increased the chance of larger circular rooms, as seen near the left side (this also affected the position of the tunnels associated with them, but not the rest of the cave system since in either case no changes to the RNG sequence occurred):
These are biome maps that show the effect of another change I made, which made some small-scale biome features remain the same size on all world types (the Large Biomes maps are actually 4x the width of the default maps so features that were unchanged appear much smaller), with local differences even on Default because I moved them to a separate layer:
You're mentioning differences that you claim were always there and then questioning if they really were
Other way around. I was originally claiming I recognized something occurring in 1.2.5 that I thought should have come later and thus not be in 1.2.5, but I was mistaken and it was already there in 1.2.5.
I was also claiming the smaller stars seemed to have been "back-ported" as well, but they weren't when I checked so I was mistaken here too.
So this whole thread is sort of answered now and the explanation is simply "my memory was off" (lead decay) and "I was wrong, as it's actually using the proper one" (star size and amount).
If this were the case then worlds would be totally different, including biomes and terrain, you may as well have used an entirely different seed, and it is highly unlikely that they would make such a change to the built-in RNG, even as old and low-quality as it is, as far as I can tell the last change made to it was all the way back in Java 5, the oldest version any version of Minecraft can run on (up to 1.5.2) and that only changed how a random seed is obtained (it used to use the system time but now uses a more complicated formula):
<snipped for brevity sake>
Yeah not sure what exactly is the cause. I know from screenshots at the time that everyone who posted about the Glacier seed ( I think it was beta 1.7.3? Seems to be about the right era) that certain trees and the water spring on the floating island spawned in the same spot for everyone, or at least everyone who posted screenshots. I haven't tried generating that seed in beta 1.7.3 on the most recent install of Minecraft but I know generating it on the "new" install where you can pick whatever version you want didn't generate that water spring and trees were different. So at that time and place it seemed that it was always the same but then never again after that.
But I also know that some things generate differently within the same version. I was playing on a world where a pond generated just below the ground surface with a small opening to the air. I was in the pond mining coal or something when the game crashed and either corrupted that chunk or didn't save it, but did save my player position. Opening the world again, I was where the pond had been but it didn't generate this time when the chunk was created again and I was stuck underground inside the dirt.
Rollback Post to RevisionRollBack
D_B
To tell them how to live is to prevent them living.
I always wondered if some decorator stuff might be a bit variable and possibly different every time on the same seed, but I just looked at a given seed and everything down to the spot, tree type, and even exact way they generated (same leaf placement, same large oak generation) was the same. I at least expected the latter two might be variable, but no, it's the same even down to that (any differences you notice in leaves are from leaf decay).
Same seed, different world (vanilla 1.2.5).
I know that terrain can sometimes generate a bit differently depending on the order in which the chunk was loaded (as some things may be different depending on nearby factors).
If OptiFine is involved, it has an option (I think it is Fast Math) which can alter some terrain generation aspects too.
I know that terrain can sometimes generate a bit differently depending on the order in which the chunk was loaded (as some things may be different depending on nearby factors).
If OptiFine is involved, it has an option (I think it is Fast Math) which can alter some terrain generation aspects too.
This is correct, as this demonstration shows you do need to explore the world in a different order and the spawn chunks will always be created in the same order:
However, I can think of at least once case where decorations can still vary, even within the spawn chunks - big oak trees; due to a bug in the code the height is not set properly and can only be lowered, and this will persist across worlds; the biggest sign of this is that they lack size variation in a given biome, per game instance (e.g. they may all be the small "balloon oak" or all very large):
This also appears to have been a bug for a very long time; I found source code for 1.0.0 and it is the same as the (bugged) code in 1.6.4 (the bug tracker only goes back to 1.4 since that was when it was created. I've also seen bugs reported for very recent versions which are much older than even 1.0.0):
This is a combination of two issues; a single permanent instance of WorldGenBigTree is created for each biome and its height range is instantiated only once, since it is never reset to 0; I fixed this by removing "if (heightLimit == 0)" so it is always set (the alternative is to create a new instance for every tree generated but unnecessary object creation is the "root of all evil" in a garbage-collected language; I actually made it and other feature generators static so a single instance is shared among all biomes, no matter how many I've added, substantially reducing the live object count, which the garbage collector also has to sort through (this is partly why TMCW only uses half as much memory, minus loaded chunks, as vanilla 1.6.4).
Fast Math also does affect world generation, mainly cave generation, which uses a ton of sine/cosine operations, though the benefit on even an ancient Athlon 64 X2 (2005) was so small as to be negligible and I always had it turned off (by contrast, replacing or overriding Java's Random to not use a thread-safe "AtomicLong", which is unnecessary, doubled the speed)*, and in TMCWv4 I actually used my own lookup table in my cave generator to ensure they remained the same in the case anybody installed Optifine (the way it claims to optimize math is by reducing the size of a lookup table so it can better fit in the CPU cache, which sacrifices precision).
*This is how much "faster" Fast Math is, based on the time taken to trace out a single cave tunnel (16384 tunnels per run, excluding the actual carving of blocks); the difference is more noticeable with TMCW's cave generator but my own optimizations far outweigh any advantage Fast Math offers (as noted above, Java's Random is the real bottleneck); the sum is based on the end coordinates of each tunnel and its branches:
Vanilla's math lookup table (65536):
Vanilla took 12212 nanoseconds per tunnel; sum is 4783230.767408579
Vanilla took 12204 nanoseconds per tunnel; sum is 4783230.767408579
Vanilla took 12210 nanoseconds per tunnel; sum is 4783230.767408579
TMCW took 2407 nanoseconds per tunnel; sum is 4720336.475503749
TMCW took 2410 nanoseconds per tunnel; sum is 4720336.475503749
TMCW took 2408 nanoseconds per tunnel; sum is 4720336.475503749
Optifine's Fast Math lookup table (4096):
Vanilla took 12089 nanoseconds per tunnel; sum is 4789016.090742257
Vanilla took 12088 nanoseconds per tunnel; sum is 4789016.090742257
Vanilla took 12084 nanoseconds per tunnel; sum is 4789016.090742257
TMCW took 2182 nanoseconds per tunnel; sum is 4725516.7647140855
TMCW took 2181 nanoseconds per tunnel; sum is 4725516.7647140855
TMCW took 2181 nanoseconds per tunnel; sum is 4725516.7647140855
(technically, TMCW doesn't use vanilla's math table, I reduced it to 16384 as a compromise between size and precision, which results in a speed between these values)
Interesting, could the direction travelled answer why that one time the game crashed and the water pond disappeared? Since the first time I approached from a certain direction, the pond was generated, but after the crash and respawning, I didn't "approach" at all, but spawned directly in the chunk, and there was no pond.
Rollback Post to RevisionRollBack
D_B
To tell them how to live is to prevent them living.
Interesting, could the direction travelled answer why that one time the game crashed and the water pond disappeared? Since the first time I approached from a certain direction, the pond was generated, but after the crash and respawning, I didn't "approach" at all, but spawned directly in the chunk, and there was no pond.
This was most likely because the chunk was corrupted and regenerated, which will not recreate features correctly even if you "approached" it from the same direction because the surrounding chunks did not "populate" correctly.
In other words, when a chunk gets populated the area is actually offset by half a chunk to the southeast, centering it in the middle of a 2x2 chunk area, as explained in this thread under "the cause" (many modders do no understand this, or why features cannot be more than +/- 8 blocks in size, unless you just don't randomly offset them, then the limit is 32x32 blocks. Notably, vanilla's "BiomeDecorator" will actually crash the game if it detects recursive chunk decoration, via an "already decorating" error; I've seen mods that bypass/disable this but that is only hiding the underlying issue (my own mod has code that can be enabled at development time to catch any issues with a stacktrace instead of crash); very large features, like villages, use an entirely different generation method that places them in chunk-sized pieces from a map of all the pieces; caves also work in a similar manner):
The issue with a chunk regenerating is that the neighboring 3 chunks (to the west and north) have their "TerrainPopulated" flags set to true so they do not call the decoration routine when the regenerated chunk is regenerated, which only decorates itself, or rather, a quarter of itself, and a quarter of each of the chunks to its south and east, which also already have decorations that were placed before and many features have specific generation criteria (e.g. trees and most plants can only be placed on grass or dirt. If you find them on other blocks, such as the sand that generates underwater and on nearby shores, that is because it replaced the grass/dirt after they were placed, which in turn is due to the fact that features more than 1x1 blocks in size can spill outside of their populated areas, by up to 8 blocks (for a given chunk the game places sand before trees and grass; lakes are also placed before most features but can often be found under floating trees since again they overlap with adjacent populated areas).
You can see this in this map, where I'd copied a region file from an existing world to a new world and generated more terrain around it (the mismatch is because the new world was modded); you can see a strip of bare grass around the southern and eastern edges of the central region (easiest to see to the south where there is a snowy biome in new chunks), which was not decorated for the reason mentioned above (conversely, chunks along the western and northern sides were decorated twice but this is less apparent due to the existence of features placed before; repopulating a forest will not double the number of trees since they can only generate on grass/dirt with a direct view of the sky and many of the locations chosen will land on exiting trees):
A post I made a few years ago with more examples (interestingly enough, in reply to you; the first image shows what happens when single chunks regenrate):
Incidentally, there is a bug in the game, mostly affecting versions since 1.13, where you may come across areas missing decorations in various quarter-chunk combinations, even without a game crash (I suspect it is caused by a race condition in the threaded chunk loader, which does in fact have some issues which I fixed with a patch posted on another bug report; Mojang also claims to have fixed this particular issue so the 1.13 decoration bug may be different. Prior to fixing it I'd occasionally, only when flying around in Creative, come across weird "cutouts" missing decorations, always in the shape of an "L"):
In another case I've come across chunks with entirely incorrect biomes (very rarely, once in a Survival world and once in a test world), but otherwise they seamlessly matched surrounding chunks (i.e. not a case where a chunk was mislocated, another common issue in newer versions, even without a crash/power outage/etc, which is certainly a major factor in many cases), caused by another race condition due to multithreaded access of a global static "IntCache" used to cache arrays used by the biome generator (singleplayer runs on an integrated server, with the client thread accessing some of the same global data. I fixed this issue by only allowing the client to read biomes from chunks, with the biome generator itself only created server-side):
Wow. This is the first time I'm hearing of "worldgen runaway" but I figure it explains why I would sometimes find random chunks generated out and away from where I have explored?
It was never excessive. I seldom play with much in the way of mods, but Forge and Optifine (I've used one or both in the past), or maybe even just the vanilla game, may sometimes cause it to a very slight extent I guess? I've definitely noticed these lonesome chunks in UnMined at times, and I always wondered what was causing them.
Wow. This is the first time I'm hearing of "worldgen runaway" but I figure it explains why I would sometimes find random chunks generated out and away from where I have explored?
It was never excessive. I seldom play with much in the way of mods, but Forge and Optifine (I've used one or both in the past), or maybe even just the vanilla game, may sometimes cause it to a very slight extent I guess? I've definitely noticed these lonesome chunks in UnMined at times, and I always wondered what was causing them.
It does happen to an extent in vanilla, particularly in the Nether, or used to:
This was caused by an omission of + 8 from the code that placed hidden lava blocks; there is another report regarding the same for emerald ore but it didn't actually cause any issues (the hidden lava blocks checks is the adjacent blocks are solid, hence it can go into unloaded chunks but emerald ore does not; at the same time, this made emerald generation less respectful of biome boundaries, though in either case a chunk is only decorated according to the biome at the center of the 2x2 chunk area).
This was particularly an issue with fires in the Nether, which would also often cause chunks to remain loaded indefinitely, causing lag (the Nether in vanilla 1.6.4 is quite laggy in general, with frequent freezes as you explore new terrain, and even existing terrain due to a buggy lighting system which would constantly relight chunks on the client in an attempt to fix the infamous "black spots" issue):
Here is a comparison of the Nether from one of my old worlds (vanilla Nether, no optimizations or bugfixes) and TMCWv5; the ragged northern/western edges in the vanilla Nether are due to worldgen runaway, which is absent from TMCWv5, which also shows no lighting errors, except in the outermost chunks (light updated only occur if a 3x3 chunk area is loaded around a chunk; and yes, vanilla 1.6.4 is that bad at properly lighting chunks, especially block light; I'd often come across villages, mineshafts, etc with torches that emitted no light):
Vanilla:
TMCWv5, with fixes to worldgen runaway and lighting:
While not happening during world generation flowing liquids (springs) can also load new chunks (after they are ticked) since the game didn't check if chunks were loaded around a block before ticking it, but this is generally limited (the previous report also mentions blocks like leaves and farmland but they aren't normally an issue because they are/were only ticked within +/- 7 chunks, so a view distance of at least 8 will ensure that chunks are always loaded around them). This is also visible in the Nether comparison as chunks loaded along the eastern and southern edges (less often than to the north and west).
Also, a significant cause of the lag caused by zombie pathfinding in 1.6 was due to the pathfinding code loading new chunks as the search range went outside of the player-loaded area; this is actually the cause of most of the uneveness seen in this rendering, which was mostly straight to the south, except around the island a third of the way down (at this point I'd only applied a fix from Forge, and some others, which did help a lot by reducing the rate of pathfinding attempts when they couldn't find a path to the target; later on I added a new "getChunk" method which defaults to an "empty" chunk if the chunk in question isn't loaded):
Worldgen runaway is also much less likely in the Overworld because the "BiomeDecorator" class, which places most decorations in the Overworld (the Nether does not use it and liquids are only ticked after world generation), has this bit of code which will cause the game to crash if it is called again while in the process of decorating a chunk (if bypassed the fields that store the chunk coordinates will no longer point to the previous chunk (the "world" field may also now point to a different world), so when it returns from decorating the current chunk it will continue decorating it from where the previous chunk caused runaway):
public void decorate(World par1World, Random par2Random, int par3, int par4)
{
if (this.currentWorld != null)
{
throw new RuntimeException("Already decorating!!");
}
else
{
this.currentWorld = par1World;
this.randomGenerator = par2Random;
this.chunk_X = par3;
this.chunk_Z = par4;
this.decorate();
this.currentWorld = null;
this.randomGenerator = null;
}
}
I fixed this by removing the fields and merging the main "decorate" method (with no parameters in vanilla) with the one shown; my "WorldGenChunkCache" also stores the 2x2 chunk area being decorated and any accesses that go outside of it will simply be ignored or even wrap around to the other side, with code that can be enabled during development that checks if a coordinate was out of bounds:
// WorldGenChunkCache (chunkArray is 4x4 chunks to enable the use of simple bit operations; the loaded area is 2x2 during
// world generation and 3x3 when saplings grow into trees, with unused chunks being "empty" to avoid null checks)
public final Chunk getChunkFromChunkCoords(int posX, int posZ)
{
if (DebugHelper.RUNAWAY_CHECK) this.checkBounds(posX << 4, posZ << 4);
return this.chunkArray[(posX & 3) | (posZ & 3) << 2];
}
// Checks that the provided coordinates are within bounds and prints a stacktrace and returns true if not. Note that due to
// design of cache going out of bounds will not give any error (coordinates will wrap around). Limited to one error at a time
// to avoid log spam
private final boolean checkBounds(int posX, int posZ)
{
if (hasGoneOutOfRange != BlocksMined.getDisplayMode() && !this.isInBounds(posX, posZ))
{
hasGoneOutOfRange = BlocksMined.getDisplayMode();
new Exception("Coordinate out of bounds: " + posX + ", " + posZ + " (bounds: " + this.minCacheX + ", " + this.minCacheZ + " to " + this.maxCacheX + ", " + this.maxCacheZ + ")").printStackTrace();
return true;
}
else
{
return false;
}
}
// ChunkProviderTMCW
public Chunk provideChunk(int chunkX, int chunkZ)
{
if (this.isDecorating == true) this.printError(chunkX, chunkZ, "generated");
public void populate(IChunkProvider par1IChunkProvider, int chunkX, int chunkZ)
{
if (this.isDecorating == true) this.printError(chunkX, chunkZ, "decorated");
this.isDecorating = true;
// Code that places structures, features, calls BiomeDecorator, etc
this.isDecorating = false;
}
// Prints out an error message and stacktrace if another chunk gets loaded during chunk population. Limited to one error
// per world load unless BlocksMined.getDisplayMode has changed to avoid mass spam in the case of severe runaway
private void printError(int x, int z, String stage)
{
if (DebugHelper.RUNAWAY_CHECK && this.hasRunaway != BlocksMined.getDisplayMode())
{
this.hasRunaway = BlocksMined.getDisplayMode();
new Exception("Error - chunk at " + (x << 4 | 8) + ", " + (z << 4 | 8) + " was " + stage + " while decorating chunk " + (this.prevChunkX << 4 | 8) + ", " + (this.prevChunkZ << 4 | 8) + "!").printStackTrace();
}
}
(BlocksMined.getDisplayMode() is normally used to change the display of the "inventory stats" when the "R" key (default) is pressed and can be changed while outside of the inventory when in debug mode)
There is also another cause of chunks being generated outside of the player-loaded area and spawn chunks which has nothing to do with any form of inadvertent chunk loading - the algorithm that searches for a valid spawn point, particularly before 1.7, where the area within 256 blocks of 0,0 could be entirely ocean and/or invalid spawn biomes (no grass blocks); if it doesn't find a valid biome (plains, forest, jungle, taiga) it then begins a random walk which checks each location for an exposed grass block at the highest coordinate above sea level, performing up to 1000 steps with a step size of up to +/- 63 blocks (mostly closer to 0) before it gives up; here is a particularly dramatic example (seed "-1984348358409562691" in 1.6.4) where it failed (it did hit a few Mushroom Islands but they are not valid as there is no grass, otherwise, the small islands found in oceans before 1.7 where the seafloor rises above the surface can be a valid spawn point. 0,0 is near the right side so it traveled quite a distance to the west).
I'm guessing the last thing you mention is what is going on here...
But the original example I'm thinking of this occurring in had it creating chunks so far from spawn that I don't think that was it. While 0,0 in that world is indeed ocean, and spawn is ~240, 256 in that world, I don't know if that's what was happening there because it didn't happen all over but just around ocean trails I had generated.
Unfortunately, I don't have that particular save of that world anymore to show it though. From what I recall, I explored a long trail over the ocean from a trip I made in a boat, and I noticed in Unmined, there would be chunks off that trail. Sometimes they would just be off on their own, not touching the already generated chunks. I can't recall the exact version, but it was definitely 1.3 or later and it was definitely before 1.7.
Sorry for the poor image but I'm thinking it looked something like this in Unmined (so from overhead, Blue would generated chunks and White would be nothing generated).
That's going off memory so it's not exact, but that's the idea. There would be a somewhat consistent row of them (with gaps) not attached but following each side. It was strange to see.
I just set up a profile for 1.2.5 so that I could look at how some places a world of mine originally would have been. It was given its own directory. Besides my skin not working, which was expected, and some texture pack issues since MCPatcher no longer works, everything went well. Once I loaded into a world though, something immediately jumped out at me.
Leaves on large oak trees and jungle trees started rapidly deteriorating. I recognized this behavior for what it was. I recall that around one point, the way some trees would generate was changed (large oak trees and jungle trees at least), and this also changed their leaf decay. I can't remember the specifics, but from what I gather, certain leaves would be no longer valid (too far away from logs) by the new way of doing it. I recall that many leaves on older trees in my original world have this distinct pattern of lead decay as a result. But this happened many years/versions later. Trees generated in 1.2.5 originally would have been valid at the time, so this leaf decay didn't originally happen in 1.2.5.
I've also noticed that the sky seems to have smaller and and more numerous stars (like modern Minecraft). Previously, they were larger and fewer. I actually believe it may have been the version immediately after 1.2.5, that is 1.3, that changed this.
Why are these two things happening in 1.2.5 then? I'm imagining there's possibly other changes as well? I find that unusual that they actually changed the older versions since they don't usually do that, so I'm guessing there's something else to it. Are older versions not TRULY the original older version? Like is there something else to the equation that can throw them off from being entirely accurate, despite having the original .jar file?
-
View User Profile
-
View Posts
-
Send Message
ModeratorA lot of variables factor into this, although this is just purely my speculation.
With every update of Java, some logic internally may be changed. For example, if the version of Minecraft was built on Java version- say, 7, and Java 8 was to be used instead, between that update from 7 to 8, the developers may have fixed a number bug. I'm not saying this happened exactly, but it could be a cause; although this is just speculation.
A long-long-long time older versions of Minecraft (for servers specifically, I think?) were given a hotfix due to some vulnerability. https://www.pcgamer.com/minecraft-vulnerability-leaves-servers-exposed-to-forced-crashes/
Older versions were silently given a hotfix at the same time I want to assume, but that may have just been coincidence and they really were just updating something else.
However, silent hotfixes like this cause issues like when someone wants to make a mod for 1.2.5 or 1.4.6 and MCP (the tool that decompiles Minecraft) just errors out because the jar files were updated and MCP has logic specifically for that unfixed version.
As far as I can tell Mojang has never retroactively updated older versions; I downloaded the jar for 1.2.5 and all the files have the same date as the original release (March 30, 2012; technically April 4 but they simply renamed a pre-release):
Also, the "security update" mentioned by master801 only pertains to 1.8.4 and later versions - this is precisely why Mojang always urges you to update and does not provide any support for older versions:
As for as updates to Java itself, the changes you mention are so fundamental that if a change to Java actually caused them the entire game would certainly not work at all (I'm not talking about changes to Java libraries but the most fundamental operations; addition, subtraction, bit masks, comparisons, etc). My first world is also still identical to the original world created a decade ago (well, not quite, due to MC-55596 and the removal of water lakes from deserts in 1.6), and I certainly would have found out if they had ever changed the original 1.6.4 jar since I've been working with the same MCP instance since late 2013, so any changes at all would likely cause mismatches between classes, given the sheer scale of my modding.
Also, I decompiled 1.2.5 and compared it to 1.6.4 and it seems that stars should be larger; a value that ranges from 0.15 to 0.25 in 1.6.4 is instead set to 0.25 to 0.5 in 1.2.5 (the last line in each code block, the rest appears to be the same):
// 1.2.5 private void f() { Random localRandom = new Random(10842L); adz localadz = adz.a; localadz.b(); for (int i1 = 0; i1 < 1500; i1++) { double d1 = localRandom.nextFloat() * 2.0F - 1.0F; double d2 = localRandom.nextFloat() * 2.0F - 1.0F; double d3 = localRandom.nextFloat() * 2.0F - 1.0F; double d4 = 0.25F + localRandom.nextFloat() * 0.25F; // 1.6.4 private void renderStars() { Random var1 = new Random(10842L); Tessellator var2 = Tessellator.instance; var2.startDrawingQuads(); for (int var3 = 0; var3 < 1500; ++var3) { double var4 = (double)(var1.nextFloat() * 2.0F - 1.0F); double var6 = (double)(var1.nextFloat() * 2.0F - 1.0F); double var8 = (double)(var1.nextFloat() * 2.0F - 1.0F); double var10 = (double)(0.15F + var1.nextFloat() * 0.1F);I don't know why you didn't have issues with leaf decay until a later version since the exact same code is used in 1.2.5 and 1.6.4 and as mentioned above it is exceedingly unlikely that any changes to the Java version would have an effect; the Wiki seems to indicate that the last change to the leaf decay algorithm (before 1.13 increased the range from 4 to 6 blocks) was in Beta 1.1, with "permanent" player-placed leaves added in Beta 1.8 (presumably just the addition of a new block state).
Also, I found a thread from before the full release of 1.2 (filed under 1.1 update discussion) that mentions leaves decaying on jungle trees:
https://www.minecraftforum.net/forums/archive/forum-1-1-update-discussion/953885-jungles-slowly-degrading
In addition, I know what causes this; while leaves placed during world generation do not have the "check decay" bit set anytime a leaf or log is broken (or replaced) it will check for leaves nearby and set their check decay bit, which frequently happens in forests because trees can overlap (leaf blocks can replace leaf blocks, even of the same type. This includes the individual leaf clusters and branches of big oaks and jungle trees). I was able to eliminate leaf decay by simply disabling the adjacent leaf checks during world generation (I added extra logs to trees in TMCW but not in my first world to keep it "vanilla", prior to extending the maximum range from 4 to 6 blocks).
Example MCEdit analysis from vanilla 1.6.4 (not all the leaves marked as "decaying" will actually decay, I don't actually see that many trees with obvious signs of decay, mostly big oaks, as big jungle tree canopies are generally separated enough to not be overwritten by trees nearby and most of the "decaying" leaves are adjacent to branches, which generate after the leaves do and thus trigger adjacent leaves to check for decay, but they are always within range. Likewise, big oaks by themselves, common in Extreme Hills, show no signs of decay):
With block notification disabled during world generation (yes, not a single leaf block was marked as "decaying" over a much larger area, both worlds had been loaded for only a short time, as random block updates will cause "decaying" leaves to either decay or clear their check decay bit):
Some examples of "decaying" leaves from the vanilla world which will not actually decay:
An example of how jungle trees cause large numbers of leaves to be marked as decaying without actually doing so, due to the branches being generated after the leaves, but only leaves adjacent to the leaf blocks that were replaced are marked and since they are next to a log it doesn't propagate, thus the main issue is leaf blocks being replaced with other leaves:
Some in-game screenshots I took within the jungle after I waited about 5 minutes; very few, if any, of the big jungle trees had any signs of decay while I found multiple big oaks that had decayed into a conical shape (if you are wondering, yes, jungle trees are supposed to look "ragged" in 1.6.4; since 1.7 they were changed to a perfect circular shape, which IMO looks too uniform):
A couple big oaks; the one on the right decayed (notice that a small jungle tree grew into it):
Another intact big oak with several that had decayed nearby (to the left):
In addition, this is a comparison of my first world to a newly created world, 10 years and one version later; the differences are mostly due to player interaction (besides what I built, I covered up a ravine and cave openings and cut down/replanted trees), and the removal of water lakes from deserts in 1.6 (the area in the lower-right is due to chunks not being fully generated in the new world). Other differences can be attributed to changes to chest loot in 1.6, which will alter the state of the decorator RNG in chunks with mineshaft or dungeon chests, and even the direction the world was explored in (as described here). There are also lines in the taiga where snow doesn't cover leaves that extended outside of populated chunks, which will be covered after the first snowfall, otherwise, the trees all appear to be identical:
TheMasterCaver's First World - possibly the most caved-out world in Minecraft history - includes world download.
TheMasterCaver's World - my own version of Minecraft largely based on my views of how the game should have evolved since 1.6.4.
Why do I still play in 1.6.4?
Huh? Maybe it was my memory that had changed with the leaves decaying then. I recognized what this was, but I thought this was something that came later. Then again, I guess I would have been far less attention to this stuff when I was new in 1.2.5. I guess that explains that one.
And I'm not sure what's up with the stars. I just let it go to night and checked, and indeed they are the correct way for the version (larger and less numerous than they are in more recent versions). I guess I was just presuming they would be different since when I tried going back to 1.2.5 at one point in the past, I recall the smaller and more numerous stars were showing up. But apparently my memory is in question on this one, given the leaf example above.
Well... I guess that solves that, then.
You're mentioning differences that you claim were always there and then questioning if they really were; anyhow, I can say that even in 1.6 tree leaves could break on big trees' edges because of the formula used for calculating them.
If anecdotal recollections mean anything, I recall that whenever I would enter new areas in late Alpha/Beta and also in Tekkit Classic worlds (1.2.5) there would be saplings scattered from freshly decayed leaves. Jungles in Tekkit Classic were particularly prolific.
Journals - Gregtech New Horizons | Tree Spirit Challenge [current]
I don't know about leaf decay but I do know other things change somehow when running an older version on the new setup. One that comes to mind specifically because I tried it once is the old seed "Glacier" on one of the beta versions (I think, might have been alpha). It was a popular seed back then. You spawn near a floating island, and in the original version, that island would have a water spring flowing from it. In subsequent versions, that spring would no longer spawn. The island and the rest of the landscape would be exactly the same, just water springs and as I recall, tree positions would also be different. I put it down to something in the random number generator outside the Minecraft code was causing it, but then I'm no Java expert.
D_B
To tell them how to live is to prevent them living.
If this were the case then worlds would be totally different, including biomes and terrain, you may as well have used an entirely different seed, and it is highly unlikely that they would make such a change to the built-in RNG, even as old and low-quality as it is, as far as I can tell the last change made to it was all the way back in Java 5, the oldest version any version of Minecraft can run on (up to 1.5.2) and that only changed how a random seed is obtained (it used to use the system time but now uses a more complicated formula):
The documentation for Random indicates that they changed how nextFloat() and nextDouble() work internally in an "early version of Java", likely long before Java 5, since again, even such a small change would drastically alter the values returned and affect a lot more than just water springs or trees:
It may be that you need a very specific version of the game to get the "original" version, as any number of changes to world generation, no matter how minor, may have affected them since a single RNG is used to place all decorations and it is only seeded once per chunk, thus any changes will cascade down the line, as I noted for my first world; even the direction you travel in can matter since features like trees overlap outside of the chunks they were placed in (this is also the cause of weird world generation like flowers placed on sand, which is placed first within a given chunk but since it is more than 1x1 blocks in size it can extend into adjacent chunks, replacing the blocks below flowers, which themselves also generate in patches more than 1x1 in size so they extend into unpopulated chunks at the edge of the world).
For example, this is a comparison of the same seed in the "original" version of TMCWv5, at its initial release, and a recently recreated copy in the "current" version (which is the same release/download as I do not release incremental updates as new versions; 5.0.0, 5.0.1, 5.0.2, etc; only for major updates; 3, 4, 5, etc); many decorations and a few caves are different butt he world itself is the same (I don't consider such changes to be significant, except where larger changes to caves might occur along existing chunk boundaries, which can be avoided by pregenerating or trimming the area, as I did once):
If you look closely you'll notice that only the 1.8 stone types changed in most areas, since I generate them after other ores, which were unchanged. A large cave near the lower-left increases in size due to a change I made to bring them closer to ravines in terms of the frequency/size distribution; likewise, I increased the chance of larger circular rooms, as seen near the left side (this also affected the position of the tunnels associated with them, but not the rest of the cave system since in either case no changes to the RNG sequence occurred):
These are biome maps that show the effect of another change I made, which made some small-scale biome features remain the same size on all world types (the Large Biomes maps are actually 4x the width of the default maps so features that were unchanged appear much smaller), with local differences even on Default because I moved them to a separate layer:
TheMasterCaver's First World - possibly the most caved-out world in Minecraft history - includes world download.
TheMasterCaver's World - my own version of Minecraft largely based on my views of how the game should have evolved since 1.6.4.
Why do I still play in 1.6.4?
Other way around. I was originally claiming I recognized something occurring in 1.2.5 that I thought should have come later and thus not be in 1.2.5, but I was mistaken and it was already there in 1.2.5.
I was also claiming the smaller stars seemed to have been "back-ported" as well, but they weren't when I checked so I was mistaken here too.
So this whole thread is sort of answered now and the explanation is simply "my memory was off" (lead decay) and "I was wrong, as it's actually using the proper one" (star size and amount).
<snipped for brevity sake>
Yeah not sure what exactly is the cause. I know from screenshots at the time that everyone who posted about the Glacier seed ( I think it was beta 1.7.3? Seems to be about the right era) that certain trees and the water spring on the floating island spawned in the same spot for everyone, or at least everyone who posted screenshots. I haven't tried generating that seed in beta 1.7.3 on the most recent install of Minecraft but I know generating it on the "new" install where you can pick whatever version you want didn't generate that water spring and trees were different. So at that time and place it seemed that it was always the same but then never again after that.
But I also know that some things generate differently within the same version. I was playing on a world where a pond generated just below the ground surface with a small opening to the air. I was in the pond mining coal or something when the game crashed and either corrupted that chunk or didn't save it, but did save my player position. Opening the world again, I was where the pond had been but it didn't generate this time when the chunk was created again and I was stuck underground inside the dirt.
D_B
To tell them how to live is to prevent them living.
I always wondered if some decorator stuff might be a bit variable and possibly different every time on the same seed, but I just looked at a given seed and everything down to the spot, tree type, and even exact way they generated (same leaf placement, same large oak generation) was the same. I at least expected the latter two might be variable, but no, it's the same even down to that (any differences you notice in leaves are from leaf decay).
Same seed, different world (vanilla 1.2.5).
I know that terrain can sometimes generate a bit differently depending on the order in which the chunk was loaded (as some things may be different depending on nearby factors).
If OptiFine is involved, it has an option (I think it is Fast Math) which can alter some terrain generation aspects too.
This is correct, as this demonstration shows you do need to explore the world in a different order and the spawn chunks will always be created in the same order:
https://imgur.com/a/hkCz5t4
However, I can think of at least once case where decorations can still vary, even within the spawn chunks - big oak trees; due to a bug in the code the height is not set properly and can only be lowered, and this will persist across worlds; the biggest sign of this is that they lack size variation in a given biome, per game instance (e.g. they may all be the small "balloon oak" or all very large):
MC-11208 The big tree generator handles tree height variable incorrectly
This also appears to have been a bug for a very long time; I found source code for 1.0.0 and it is the same as the (bugged) code in 1.6.4 (the bug tracker only goes back to 1.4 since that was when it was created. I've also seen bugs reported for very recent versions which are much older than even 1.0.0):
This is a combination of two issues; a single permanent instance of WorldGenBigTree is created for each biome and its height range is instantiated only once, since it is never reset to 0; I fixed this by removing "if (heightLimit == 0)" so it is always set (the alternative is to create a new instance for every tree generated but unnecessary object creation is the "root of all evil" in a garbage-collected language; I actually made it and other feature generators static so a single instance is shared among all biomes, no matter how many I've added, substantially reducing the live object count, which the garbage collector also has to sort through (this is partly why TMCW only uses half as much memory, minus loaded chunks, as vanilla 1.6.4).
Fast Math also does affect world generation, mainly cave generation, which uses a ton of sine/cosine operations, though the benefit on even an ancient Athlon 64 X2 (2005) was so small as to be negligible and I always had it turned off (by contrast, replacing or overriding Java's Random to not use a thread-safe "AtomicLong", which is unnecessary, doubled the speed)*, and in TMCWv4 I actually used my own lookup table in my cave generator to ensure they remained the same in the case anybody installed Optifine (the way it claims to optimize math is by reducing the size of a lookup table so it can better fit in the CPU cache, which sacrifices precision).
Bug: "Fast Math" option changes world generation #1530
*This is how much "faster" Fast Math is, based on the time taken to trace out a single cave tunnel (16384 tunnels per run, excluding the actual carving of blocks); the difference is more noticeable with TMCW's cave generator but my own optimizations far outweigh any advantage Fast Math offers (as noted above, Java's Random is the real bottleneck); the sum is based on the end coordinates of each tunnel and its branches:
(technically, TMCW doesn't use vanilla's math table, I reduced it to 16384 as a compromise between size and precision, which results in a speed between these values)
TheMasterCaver's First World - possibly the most caved-out world in Minecraft history - includes world download.
TheMasterCaver's World - my own version of Minecraft largely based on my views of how the game should have evolved since 1.6.4.
Why do I still play in 1.6.4?
Interesting, could the direction travelled answer why that one time the game crashed and the water pond disappeared? Since the first time I approached from a certain direction, the pond was generated, but after the crash and respawning, I didn't "approach" at all, but spawned directly in the chunk, and there was no pond.
D_B
To tell them how to live is to prevent them living.
This was most likely because the chunk was corrupted and regenerated, which will not recreate features correctly even if you "approached" it from the same direction because the surrounding chunks did not "populate" correctly.
In other words, when a chunk gets populated the area is actually offset by half a chunk to the southeast, centering it in the middle of a 2x2 chunk area, as explained in this thread under "the cause" (many modders do no understand this, or why features cannot be more than +/- 8 blocks in size, unless you just don't randomly offset them, then the limit is 32x32 blocks. Notably, vanilla's "BiomeDecorator" will actually crash the game if it detects recursive chunk decoration, via an "already decorating" error; I've seen mods that bypass/disable this but that is only hiding the underlying issue (my own mod has code that can be enabled at development time to catch any issues with a stacktrace instead of crash); very large features, like villages, use an entirely different generation method that places them in chunk-sized pieces from a map of all the pieces; caves also work in a similar manner):
https://www.reddit.com/r/feedthebeast/comments/5x0twz/investigating_extreme_worldgen_lag/
The issue with a chunk regenerating is that the neighboring 3 chunks (to the west and north) have their "TerrainPopulated" flags set to true so they do not call the decoration routine when the regenerated chunk is regenerated, which only decorates itself, or rather, a quarter of itself, and a quarter of each of the chunks to its south and east, which also already have decorations that were placed before and many features have specific generation criteria (e.g. trees and most plants can only be placed on grass or dirt. If you find them on other blocks, such as the sand that generates underwater and on nearby shores, that is because it replaced the grass/dirt after they were placed, which in turn is due to the fact that features more than 1x1 blocks in size can spill outside of their populated areas, by up to 8 blocks (for a given chunk the game places sand before trees and grass; lakes are also placed before most features but can often be found under floating trees since again they overlap with adjacent populated areas).
You can see this in this map, where I'd copied a region file from an existing world to a new world and generated more terrain around it (the mismatch is because the new world was modded); you can see a strip of bare grass around the southern and eastern edges of the central region (easiest to see to the south where there is a snowy biome in new chunks), which was not decorated for the reason mentioned above (conversely, chunks along the western and northern sides were decorated twice but this is less apparent due to the existence of features placed before; repopulating a forest will not double the number of trees since they can only generate on grass/dirt with a direct view of the sky and many of the locations chosen will land on exiting trees):
A post I made a few years ago with more examples (interestingly enough, in reply to you; the first image shows what happens when single chunks regenrate):
https://www.minecraftforum.net/forums/minecraft-java-edition/discussion/2986122-has-anyone-come-across-this-before?comment=18
Incidentally, there is a bug in the game, mostly affecting versions since 1.13, where you may come across areas missing decorations in various quarter-chunk combinations, even without a game crash (I suspect it is caused by a race condition in the threaded chunk loader, which does in fact have some issues which I fixed with a patch posted on another bug report; Mojang also claims to have fixed this particular issue so the 1.13 decoration bug may be different. Prior to fixing it I'd occasionally, only when flying around in Creative, come across weird "cutouts" missing decorations, always in the shape of an "L"):
MC-125007 World fails to generate decorations on seemingly random quarter chunks
In another case I've come across chunks with entirely incorrect biomes (very rarely, once in a Survival world and once in a test world), but otherwise they seamlessly matched surrounding chunks (i.e. not a case where a chunk was mislocated, another common issue in newer versions, even without a crash/power outage/etc, which is certainly a major factor in many cases), caused by another race condition due to multithreaded access of a global static "IntCache" used to cache arrays used by the biome generator (singleplayer runs on an integrated server, with the client thread accessing some of the same global data. I fixed this issue by only allowing the client to read biomes from chunks, with the biome generator itself only created server-side):
https://forums.minecraftforge.net/topic/29165-181710-discuss-about-intcache/
TheMasterCaver's First World - possibly the most caved-out world in Minecraft history - includes world download.
TheMasterCaver's World - my own version of Minecraft largely based on my views of how the game should have evolved since 1.6.4.
Why do I still play in 1.6.4?
Wow. This is the first time I'm hearing of "worldgen runaway" but I figure it explains why I would sometimes find random chunks generated out and away from where I have explored?
It was never excessive. I seldom play with much in the way of mods, but Forge and Optifine (I've used one or both in the past), or maybe even just the vanilla game, may sometimes cause it to a very slight extent I guess? I've definitely noticed these lonesome chunks in UnMined at times, and I always wondered what was causing them.
It does happen to an extent in vanilla, particularly in the Nether, or used to:
MC-117810 Nether Lava Trap generation often loads new chunks
This was caused by an omission of + 8 from the code that placed hidden lava blocks; there is another report regarding the same for emerald ore but it didn't actually cause any issues (the hidden lava blocks checks is the adjacent blocks are solid, hence it can go into unloaded chunks but emerald ore does not; at the same time, this made emerald generation less respectful of biome boundaries, though in either case a chunk is only decorated according to the biome at the center of the 2x2 chunk area).
This was particularly an issue with fires in the Nether, which would also often cause chunks to remain loaded indefinitely, causing lag (the Nether in vanilla 1.6.4 is quite laggy in general, with frequent freezes as you explore new terrain, and even existing terrain due to a buggy lighting system which would constantly relight chunks on the client in an attempt to fix the infamous "black spots" issue):
MC-119994 Fires in the nether cause chunks to permanently load and cause lag
Here is a comparison of the Nether from one of my old worlds (vanilla Nether, no optimizations or bugfixes) and TMCWv5; the ragged northern/western edges in the vanilla Nether are due to worldgen runaway, which is absent from TMCWv5, which also shows no lighting errors, except in the outermost chunks (light updated only occur if a 3x3 chunk area is loaded around a chunk; and yes, vanilla 1.6.4 is that bad at properly lighting chunks, especially block light; I'd often come across villages, mineshafts, etc with torches that emitted no light):
TMCWv5, with fixes to worldgen runaway and lighting:
While not happening during world generation flowing liquids (springs) can also load new chunks (after they are ticked) since the game didn't check if chunks were loaded around a block before ticking it, but this is generally limited (the previous report also mentions blocks like leaves and farmland but they aren't normally an issue because they are/were only ticked within +/- 7 chunks, so a view distance of at least 8 will ensure that chunks are always loaded around them). This is also visible in the Nether comparison as chunks loaded along the eastern and southern edges (less often than to the north and west).
Also, a significant cause of the lag caused by zombie pathfinding in 1.6 was due to the pathfinding code loading new chunks as the search range went outside of the player-loaded area; this is actually the cause of most of the uneveness seen in this rendering, which was mostly straight to the south, except around the island a third of the way down (at this point I'd only applied a fix from Forge, and some others, which did help a lot by reducing the rate of pathfinding attempts when they couldn't find a path to the target; later on I added a new "getChunk" method which defaults to an "empty" chunk if the chunk in question isn't loaded):
Worldgen runaway is also much less likely in the Overworld because the "BiomeDecorator" class, which places most decorations in the Overworld (the Nether does not use it and liquids are only ticked after world generation), has this bit of code which will cause the game to crash if it is called again while in the process of decorating a chunk (if bypassed the fields that store the chunk coordinates will no longer point to the previous chunk (the "world" field may also now point to a different world), so when it returns from decorating the current chunk it will continue decorating it from where the previous chunk caused runaway):
public void decorate(World par1World, Random par2Random, int par3, int par4) { if (this.currentWorld != null) { throw new RuntimeException("Already decorating!!"); } else { this.currentWorld = par1World; this.randomGenerator = par2Random; this.chunk_X = par3; this.chunk_Z = par4; this.decorate(); this.currentWorld = null; this.randomGenerator = null; } }I fixed this by removing the fields and merging the main "decorate" method (with no parameters in vanilla) with the one shown; my "WorldGenChunkCache" also stores the 2x2 chunk area being decorated and any accesses that go outside of it will simply be ignored or even wrap around to the other side, with code that can be enabled during development that checks if a coordinate was out of bounds:
// WorldGenChunkCache (chunkArray is 4x4 chunks to enable the use of simple bit operations; the loaded area is 2x2 during // world generation and 3x3 when saplings grow into trees, with unused chunks being "empty" to avoid null checks) public final Chunk getChunkFromChunkCoords(int posX, int posZ) { if (DebugHelper.RUNAWAY_CHECK) this.checkBounds(posX << 4, posZ << 4); return this.chunkArray[(posX & 3) | (posZ & 3) << 2]; } // Checks that the provided coordinates are within bounds and prints a stacktrace and returns true if not. Note that due to // design of cache going out of bounds will not give any error (coordinates will wrap around). Limited to one error at a time // to avoid log spam private final boolean checkBounds(int posX, int posZ) { if (hasGoneOutOfRange != BlocksMined.getDisplayMode() && !this.isInBounds(posX, posZ)) { hasGoneOutOfRange = BlocksMined.getDisplayMode(); new Exception("Coordinate out of bounds: " + posX + ", " + posZ + " (bounds: " + this.minCacheX + ", " + this.minCacheZ + " to " + this.maxCacheX + ", " + this.maxCacheZ + ")").printStackTrace(); return true; } else { return false; } } // ChunkProviderTMCW public Chunk provideChunk(int chunkX, int chunkZ) { if (this.isDecorating == true) this.printError(chunkX, chunkZ, "generated"); public void populate(IChunkProvider par1IChunkProvider, int chunkX, int chunkZ) { if (this.isDecorating == true) this.printError(chunkX, chunkZ, "decorated"); this.isDecorating = true; // Code that places structures, features, calls BiomeDecorator, etc this.isDecorating = false; } // Prints out an error message and stacktrace if another chunk gets loaded during chunk population. Limited to one error // per world load unless BlocksMined.getDisplayMode has changed to avoid mass spam in the case of severe runaway private void printError(int x, int z, String stage) { if (DebugHelper.RUNAWAY_CHECK && this.hasRunaway != BlocksMined.getDisplayMode()) { this.hasRunaway = BlocksMined.getDisplayMode(); new Exception("Error - chunk at " + (x << 4 | 8) + ", " + (z << 4 | 8) + " was " + stage + " while decorating chunk " + (this.prevChunkX << 4 | 8) + ", " + (this.prevChunkZ << 4 | 8) + "!").printStackTrace(); } }(BlocksMined.getDisplayMode() is normally used to change the display of the "inventory stats" when the "R" key (default) is pressed and can be changed while outside of the inventory when in debug mode)
There is also another cause of chunks being generated outside of the player-loaded area and spawn chunks which has nothing to do with any form of inadvertent chunk loading - the algorithm that searches for a valid spawn point, particularly before 1.7, where the area within 256 blocks of 0,0 could be entirely ocean and/or invalid spawn biomes (no grass blocks); if it doesn't find a valid biome (plains, forest, jungle, taiga) it then begins a random walk which checks each location for an exposed grass block at the highest coordinate above sea level, performing up to 1000 steps with a step size of up to +/- 63 blocks (mostly closer to 0) before it gives up; here is a particularly dramatic example (seed "-1984348358409562691" in 1.6.4) where it failed (it did hit a few Mushroom Islands but they are not valid as there is no grass, otherwise, the small islands found in oceans before 1.7 where the seafloor rises above the surface can be a valid spawn point. 0,0 is near the right side so it traveled quite a distance to the west).
TheMasterCaver's First World - possibly the most caved-out world in Minecraft history - includes world download.
TheMasterCaver's World - my own version of Minecraft largely based on my views of how the game should have evolved since 1.6.4.
Why do I still play in 1.6.4?
It was in the overworld where I saw this.
I'm guessing the last thing you mention is what is going on here...
But the original example I'm thinking of this occurring in had it creating chunks so far from spawn that I don't think that was it. While 0,0 in that world is indeed ocean, and spawn is ~240, 256 in that world, I don't know if that's what was happening there because it didn't happen all over but just around ocean trails I had generated.
Unfortunately, I don't have that particular save of that world anymore to show it though. From what I recall, I explored a long trail over the ocean from a trip I made in a boat, and I noticed in Unmined, there would be chunks off that trail. Sometimes they would just be off on their own, not touching the already generated chunks. I can't recall the exact version, but it was definitely 1.3 or later and it was definitely before 1.7.
Sorry for the poor image but I'm thinking it looked something like this in Unmined (so from overhead, Blue would generated chunks and White would be nothing generated).
That's going off memory so it's not exact, but that's the idea. There would be a somewhat consistent row of them (with gaps) not attached but following each side. It was strange to see.