I came across a very strange seed on Reddit which exposes a quirk in the way the game derives a unique seed for each chunk when generating mineshafts and caves; what the game does is multiply two random numbers based on the world seed with the chunk coordinates to create a unique seed for every chunk ("chunk seed"). However, what happens if one of those two random numbers is zero? Then the chunk seed will only vary according to one set of coordinates - and will be the same for any coordinate in the other set, meaning that any structures that generate in those chunks will all be exactly the same and generate in rows stretching across the entire map.
That's exactly what happens when you enter the seed "107038380838084":
That's right - the game is generating abandoned mineshafts in rows along the x-coordinate, with mineshafts generating in every single chunk from -30000000 to +30000000 - with 3.75 million mineshafts in each row, all interconnected (aside from some breaks near the origin, which is caused by code that makes them rarer there). Not only that (the above example was taken from the Reddit thread using a 1.8 world) the same thing happens to caves; here is the same seed in 1.6.4 (the version does not matter but 1.6.4 produces MUCH more interesting results when it comes to caves!):
Here are maps of the surface and underground; the surface doesn't look that unusual, just an ordinary 1.6.4 world:
But underground it is a different story:
Following are screenshots taken from in-game:
An infinite mineshaft:
This is certainly the biggest cave system that I've ever seen - 60 million blocks long! (with some searching much larger/denser ones could be found; the chance of the largest possible single cave system in a chunk in 1.6.4 is 1 in 960,000):
The same ravine (and mineshafts) over and over, aside from surface differences and where they intersect water:
The following code explains what is happening with this seed:
The variables var7 and var9 are being set to two random numbers based on the world seed, then are multiplied by two more numbers which are offsets from the coordinates (par3 and par4) of the current chunk (this is how the game generates large structures that span multiple chunks; it checks a "range" of chunks around every chunk being generated so it can tell if a structure of being generated in a nearby chunk, thus any part that intersects the current chunk can be generated in it). If one or both (which appears to be impossible) are zero then the corresponding coordinate will not have any effect on the chunk seed. In this case, var7, multiplied with the x-coordinate, is zero. Both values can't be zero due to how Random works, but if they could it would be entirely possible to have a seed that crashes the game or is unplayable if it happened to generate enough caves in every single chunk (it is possible to see what mineshafts would be like).
From further testing villages do not appear to be affected because they use another random value (as seen in the code) when calculating where they should generate, which uses a more complex algorithm than caves or mineshafts (a Superflat world did not have repeating villages, whether at 1 chunk intervals or at their "spacing" of 8-32 chunks). However, they could possibly still be generating exactly the same way if their z-coordinates match. Mineshafts have breaks close to the origin because a random number between 0-79 has to be less than the absolute value of the larger chunk coordinate (e.g. -30, 40 will result in 40, and a 50% chance that a mineshaft will generate); this number is constant so only one break is seen when the chunk coordinates (only the x-coordinate here) becomes less.
As an aside, there is another bug (an actual bug) that is related - certain chunks at oppositely-signed x and z coordinates (e.g. -100, 300 and 100, -300) will have the same seed and result in the same caves, mineshafts, and ravines in those chunks - this is actually quite common, as indicated by this map only showing caves that generated in such chunks, but normally it is hidden by the presence of other caves, as well as individual cave systems being reversed relative to each other (two cave systems at -1, -1 and -3, -1 will be located at 1, 1 and 3, 1 with the second cave system moving from the west to the east of the first). I've noticed this bug before (the caves mentioned there can be seen in the lower-left and upper-right corners) but didn't realize it was this prevalent (here is another instance where this bug is quite apparent):
*Since the game uses Random to get a random seed when you create a new world without one this means that you must manually enter a numerical seed to get every possible world, or replicate the following, since it can only generate 2^48 unique numbers, even if they are 64 bit "longs".
I think it's an World generating error, not the seed:
Actually, it IS the seed - you can check out the Reddit link for an explanation of what is happening; the other things I've mentioned are also not "world generating errors" but due to limitations of Java's random number generator or flaws with the way the game generates seeds for each chunk.
Here's an explanation of just what is going on linked to in the Reddit thread, which mentions the very same seed:
Yes, it really can be. Math.random() creates a global java.util.Random-generator with seed (System.currentTimeMillis() ^ 0x5DEECE66DL) & ((1L << 48) - 1) and calls nextDouble() for it. If its seed reaches state 107048004364969L (and it will, since java.util.Random has full period), the next double generated will be 0.0. Though with bad luck you could end up with the wrong parity in the cycle, because Random.nextDouble() advances the state twice. With little less bad luck you could have to generate 2^47 random numbers before the loop terminates, as I didn't find any other seeds that give 0.0.
The seed advances as if by seed = (seed * 0x5DEECE66DL + 0xBL) & ((1L << 48) - 1); and doubles are generated using 26 and 27 upper bits of two consecutive seed values. In the example the two next seed values will be 0L and 11L.
If you manage to create the global generator with System.currentTimeMillis()==107038380838084L, your code returns immediately. You can simulate this with:
java.util.Random k = new java.util.Random(107038380838084L);
System.out.println(k.nextDouble()==0);
BTW, that was posted 5 years ago; the fact that somebody only found out what it does to Minecraft 4 days ago is because nobody tried it until then (actually, I've wondered what this would do myself, and even modded one of the values to always be 0 and got the same results - but I had no idea you could actually enter a seed to get it, since I thought that Java's Random.nextLong() could never return a 0 value since it internally calls the Random method twice to make a 64 bit number from two 32 bit values. Random.nextDouble() is also the same, so not surprising that this also affects Minecraft).
I tryed it out, i didn't get that result that you got. I got the exact result like your result, but everything seems and is normal. No multiple Mineshafts, etc.
Did you check out the Reddit link? Note that I used 1.6.4, while they used 1.8, and stuff will be in different places (1.6.4 also makes it much easier to find stuff since they are more common). You also must copy the seed without quotes; do /seed in game and make sure it shows 107038380838084. In 1.8 you should spawn on an island in a deep ocean biome.
I did. Same result, but without the multiple Mineshafts, etc. Just an normal Minecraft World.
Well, then I'm at a complete loss as to why you aren't experiencing this - though the world does in fact appear perfectly normal until you look underground; have you tried teleporting to the coordinates given on the AMIDST screenshot (-216, 200). Also, are you on the PC version? This has to do with Java's Random - and that is not used on the Console or Pocket Editions and may not work on those unless they use a similar random number generator.
Anybody else around to confirm this (I don't see anybody saying that it is fake on the Reddit thread, and my own computer says it is real)?
If you want to see something truly crazy, use this seed with 1.6.4 and teleport to 69112, 1524319 and you'll find a cave system of the likes of, well, you'll just have to see for yourself (the x-coordinate doesn't actually matter, I teleported at 4000 block intervals until I finally found land. Note that in 1.8 you can use Customized to eliminate oceans or change biome size (also affects landmasses) to get land over an area):
A side view though unloaded chunks (a LOT of lag; chunk loading was very slow and it would freeze a lot, especially under the ocean due to all the water flowing down, which is why I wanted to find land):
This was the result of analyzing layers 11-62 with MCEdit to find the chunk with the highest air volume - over 76% of all blocks between those layers are air, and this extends across the world:
I found this by scanning though the y-coordinates (using code) until I found a coordinate that resulted in the largest possible single-chunk cave system being generated (this was one of three within 1 million chunks of the origin). Even in 1.7 you'll be able to find mind-blowing cave systems (they are about 36% of the size, which is probably close to the first example in the OP). Not that I'd want to explore any of these even if they did not repeat (Elytras (1.9) would be useful). It is also possible to find endless ravines if they line up east-west.
ETA: I decided to go a bit further and searched for the highest number of caves within +/- 4 chunks of a chunk along the z-axis, at z=10257440, which was about twice as high as the previous example...
A couple maps taken with Unmined...
(I noticed that flowing water appears to cause chunks to load past what is normally loaded)
I would not advise checking this out yourself; I've never had so much lag:
(this was from within MCP, which I'd used to find where these caves were located)
There are no dangerous weapons. There are only dangerous people. R.A. Heinlein
If you aren't part of the solution, then you obviously weren't properly dissolved.
Wow this is fascinating. So....just have the randomizer avoid using zero for the multipliers? Must be pretty rare though. Wonder if anyone ever legitimately got one of these.
Endless huge mineshaft sounds pretty crazy.
Just had a thought. Customize the seed and turn oceans way up to force mobs to spawn underground.
With the near-infinite world generation possibilities.... one would have to believe this will happen more than once. I wonder what other #'s would potentially give you this phenomenon.
So....just have the randomizer avoid using zero for the multipliers?
It is interesting to note that they did something like this with the code that decorates chunks with ores and trees and stuff, possibly not with this bug in mind - they made it so the two random multipliers can never be zero, or any even number actually:
Since integer division always rounds down the division and multiplication by two does not cancel out and you'll always end up with an even number, then one is added.
Also, there should be a seed that causes the same thing to happen along the z-axis. Actually, there are a total of 131072 such seeds (65536 for each axis) since Java's Random only uses the lower 48 bits of a 64 bit seed, thus the upper 16 bits (2^16 = 65536) have no effect on the parts of world generation (aside from biomes) that use it, allowing you to create worlds that are different on the surface but have the same caves and mineshafts, and even the same villages and other features provided that the biome they are in is the same (even height variation is unchanged since the Perlin noise generator is initialized with random values using Java's Random).
Of interest, this is what happens when you use this seed with my mod TMCW; mineshafts do not generate in continuous rows but are identical at the same z-coordinate. The exclusion of larger caves, ravines, and mineshafts within 512 blocks of the origin is also evident, as well as the influence of certain biomes (the line of ravines below the middle has a short discontinuity where it passes through a mesa biome):
This was caused by a large cave generating over and over. In the most extreme case they can exceed 80 blocks across; ravines can reach 40:
An infinite ravine (actually, it is only like this close to the origin, though after it changes to a longer variant they are still linked together):
So are there exactly 1/2/65536/131072 seeds that will produce this result or at least that many?
Is each 48 bit seed guaranteed to produce a different starting value from every other one or could there be another set of 65536 seeds that will also produce repeats along the x-axis?
So are there exactly 1/2/65536/131072 seeds that will produce this result or at least that many?
Is each 48 bit seed guaranteed to produce a different starting value from every other one or could there be another set of 65536 seeds that will also produce repeats along the x-axis?
As far as I know there should be exactly 2^48 unique seeds since Java's Random has a full period, using every single state possible (some RNGs have odd cycle lengths; the number of unique seeds is the same as the cycle length). Also, as for seeds that have the same underground but are otherwise different worlds, you can easily manipulate the seed by adding or subtracting multiples of 2^48; for example, the seed 388513357548740 should give you a different world with the same bugged underground generation as the one in this thread since the lower 48 bits are the same; this is 107038380838084 plus 281474976710656 (2^48). You can also add any multiple of 2^48, or subtract if the seed is already greater than 2^48 - 1 (e.g. the seeds 0 and 281474976710656 have the same lower 48 bits).
Note that if you enter a string into the seed box there are only 2^32 unique seeds and the seed in this thread is larger than a 32 bit integer allows so it is impossible to get this to occur when entering a seed this way, and the game uses Random to get a random seed when it is left blank, meaning there are only 2^48 unique seeds (the chances of somebody getting a bugged world (two "bad" seeds) are one in 140737488355328; I doubt that anybody has ever actually created a random world with one) unless you manually enter a numeric seed (these seeds are full 64 bit values since Random combines two 32 bit values but that does not get around the 2^48 limitation since there are only 2^48 unique calls to the internal random number generator).
If it works for the X-axis, and the Z-axis, what's not to say it wouldn't work for the Y-axis as well?
That would only be possible with Cubic Chunks, since the "chunk seed" currently only takes the x and z coordinates into account because chunks cover the entire y-axis, and by then you'd think they would have fixed the bug that makes this possible (a very simple fix which was already applied to the biome decorator by ensuring the two seed-dependent multipliers can never be zero, although that solution means there are only half as many unique seeds).
I know this thread is old but I am wondering if generation is affected by the world seed or the seed that MapGenBase gives out? Seems like it is the entire world seed, correct me if I am wrong. I've went through code on version 1.11 and I've seen a lot of function calls looking something like "random.setSeed(var1 ^ var2 ^ world.getSeed())"
I know this thread is old but I am wondering if generation is affected by the world seed or the seed that MapGenBase gives out? Seems like it is the entire world seed, correct me if I am wrong. I've went through code on version 1.11 and I've seen a lot of function calls looking something like "random.setSeed(var1 ^ var2 ^ world.getSeed())"
MapGenbase is only used to generate caves, ravines, and "large" structures (ones which span multiple chunks, not small features like dungeons), and many of those structures use another method to set the seed for the RNG which determines where they will spawn (which happens to be the RNG that the World class uses, and also used by sheep to determine their wool color, while most entities use their own RNG which is based on the time they were spawned, hence MC-2788).
This does not affect minor chunk features like ores and trees because the game makes sure that the two coordinate multipliers can never be zero by dividing them by two, then multiplying by two and adding one, so the result is always an odd number:
In ChunkproviderGenerate.populate() (chunk x/z variables renamed for legibility):
this.rand.setSeed(par2World.getSeed());
long var7 = this.rand.nextLong();
long var9 = this.rand.nextLong();
long var13 = (long)chunkX * var7;
long var15 = (long)chunkZ * var9;
this.rand.setSeed(var13 ^ var15 ^ par2World.getSeed());
Structures like villages call this bit of code in the World class, which is also immune to the bug that affects MapGenBase:
public Random setRandomSeed(int chunkX, int chunkZ, int par3)
{
long var4 = (long)chunkX * 341873128712L + (long)chunkZ * 132897987541L + this.getWorldInfo().getSeed() + (long)par3;
this.rand.setSeed(var4);
return this.rand;
}
Likewise, biome generation uses yet another method to set the seed which is also unaffected (a combination of additions and multiplications).
Also, as I mentioned later in the OP the method used to set the chunk seed in MapGenBase is so poor that it results in many chunks at sign-reversed signed coordinate pairs to have the same seed, and same caves and structures (mostly only observed with mineshafts due to the aforementioned additional code most other structures use); from more extensive testing I've found that as many as a third of all chunks can be affected, while the seed I used in the example had 1/6 of chunks affected (1/3 and 1/6 were most common), while others may have 1/12, 1/24, etc, and only very rarely will a seed be unaffected at all. This appears to be caused by the XORs canceling bits out, although I'm not sure why only certain chunks are affected and not always the same proportion; here is a simple map of the chunks affected in the seed I used.
I came across a very strange seed on Reddit which exposes a quirk in the way the game derives a unique seed for each chunk when generating mineshafts and caves; what the game does is multiply two random numbers based on the world seed with the chunk coordinates to create a unique seed for every chunk ("chunk seed"). However, what happens if one of those two random numbers is zero? Then the chunk seed will only vary according to one set of coordinates - and will be the same for any coordinate in the other set, meaning that any structures that generate in those chunks will all be exactly the same and generate in rows stretching across the entire map.
That's exactly what happens when you enter the seed "107038380838084":
That's right - the game is generating abandoned mineshafts in rows along the x-coordinate, with mineshafts generating in every single chunk from -30000000 to +30000000 - with 3.75 million mineshafts in each row, all interconnected (aside from some breaks near the origin, which is caused by code that makes them rarer there). Not only that (the above example was taken from the Reddit thread using a 1.8 world) the same thing happens to caves; here is the same seed in 1.6.4 (the version does not matter but 1.6.4 produces MUCH more interesting results when it comes to caves!):
But underground it is a different story:
Following are screenshots taken from in-game:
An infinite mineshaft:
This is certainly the biggest cave system that I've ever seen - 60 million blocks long! (with some searching much larger/denser ones could be found; the chance of the largest possible single cave system in a chunk in 1.6.4 is 1 in 960,000):
The same ravine (and mineshafts) over and over, aside from surface differences and where they intersect water:
The following code explains what is happening with this seed:
The variables var7 and var9 are being set to two random numbers based on the world seed, then are multiplied by two more numbers which are offsets from the coordinates (par3 and par4) of the current chunk (this is how the game generates large structures that span multiple chunks; it checks a "range" of chunks around every chunk being generated so it can tell if a structure of being generated in a nearby chunk, thus any part that intersects the current chunk can be generated in it). If one or both (which appears to be impossible) are zero then the corresponding coordinate will not have any effect on the chunk seed. In this case, var7, multiplied with the x-coordinate, is zero. Both values can't be zero due to how Random works, but if they could it would be entirely possible to have a seed that crashes the game or is unplayable if it happened to generate enough caves in every single chunk (it is possible to see what mineshafts would be like).
From further testing villages do not appear to be affected because they use another random value (as seen in the code) when calculating where they should generate, which uses a more complex algorithm than caves or mineshafts (a Superflat world did not have repeating villages, whether at 1 chunk intervals or at their "spacing" of 8-32 chunks). However, they could possibly still be generating exactly the same way if their z-coordinates match. Mineshafts have breaks close to the origin because a random number between 0-79 has to be less than the absolute value of the larger chunk coordinate (e.g. -30, 40 will result in 40, and a 50% chance that a mineshaft will generate); this number is constant so only one break is seen when the chunk coordinates (only the x-coordinate here) becomes less.
As an aside, there is another bug (an actual bug) that is related - certain chunks at oppositely-signed x and z coordinates (e.g. -100, 300 and 100, -300) will have the same seed and result in the same caves, mineshafts, and ravines in those chunks - this is actually quite common, as indicated by this map only showing caves that generated in such chunks, but normally it is hidden by the presence of other caves, as well as individual cave systems being reversed relative to each other (two cave systems at -1, -1 and -3, -1 will be located at 1, 1 and 3, 1 with the second cave system moving from the west to the east of the first). I've noticed this bug before (the caves mentioned there can be seen in the lower-left and upper-right corners) but didn't realize it was this prevalent (here is another instance where this bug is quite apparent):
Also related (in this case due to Java's Random only using the lower 48 bits of a seed*): Can two different seeds produce identical worlds? Yes - at least partially
*Since the game uses Random to get a random seed when you create a new world without one this means that you must manually enter a numerical seed to get every possible world, or replicate the following, since it can only generate 2^48 unique numbers, even if they are 64 bit "longs".
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?
Actually, it IS the seed - you can check out the Reddit link for an explanation of what is happening; the other things I've mentioned are also not "world generating errors" but due to limitations of Java's random number generator or flaws with the way the game generates seeds for each chunk.
Here's an explanation of just what is going on linked to in the Reddit thread, which mentions the very same seed:
BTW, that was posted 5 years ago; the fact that somebody only found out what it does to Minecraft 4 days ago is because nobody tried it until then (actually, I've wondered what this would do myself, and even modded one of the values to always be 0 and got the same results - but I had no idea you could actually enter a seed to get it, since I thought that Java's Random.nextLong() could never return a 0 value since it internally calls the Random method twice to make a 64 bit number from two 32 bit values. Random.nextDouble() is also the same, so not surprising that this also affects Minecraft).
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?
Did you check out the Reddit link? Note that I used 1.6.4, while they used 1.8, and stuff will be in different places (1.6.4 also makes it much easier to find stuff since they are more common). You also must copy the seed without quotes; do /seed in game and make sure it shows 107038380838084. In 1.8 you should spawn on an island in a deep ocean biome.
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?
Well, then I'm at a complete loss as to why you aren't experiencing this - though the world does in fact appear perfectly normal until you look underground; have you tried teleporting to the coordinates given on the AMIDST screenshot (-216, 200). Also, are you on the PC version? This has to do with Java's Random - and that is not used on the Console or Pocket Editions and may not work on those unless they use a similar random number generator.
Anybody else around to confirm this (I don't see anybody saying that it is fake on the Reddit thread, and my own computer says it is real)?
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?
You need AmidstExporter, as mentioned in the Reddit thread - AMIDST does not even show mineshafts:
https://github.com/Treer/AmidstExporter/releases
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?
If you want to see something truly crazy, use this seed with 1.6.4 and teleport to 69112, 1524319 and you'll find a cave system of the likes of, well, you'll just have to see for yourself (the x-coordinate doesn't actually matter, I teleported at 4000 block intervals until I finally found land. Note that in 1.8 you can use Customized to eliminate oceans or change biome size (also affects landmasses) to get land over an area):
A side view though unloaded chunks (a LOT of lag; chunk loading was very slow and it would freeze a lot, especially under the ocean due to all the water flowing down, which is why I wanted to find land):
This was the result of analyzing layers 11-62 with MCEdit to find the chunk with the highest air volume - over 76% of all blocks between those layers are air, and this extends across the world:
I found this by scanning though the y-coordinates (using code) until I found a coordinate that resulted in the largest possible single-chunk cave system being generated (this was one of three within 1 million chunks of the origin). Even in 1.7 you'll be able to find mind-blowing cave systems (they are about 36% of the size, which is probably close to the first example in the OP). Not that I'd want to explore any of these even if they did not repeat (Elytras (1.9) would be useful). It is also possible to find endless ravines if they line up east-west.
ETA: I decided to go a bit further and searched for the highest number of caves within +/- 4 chunks of a chunk along the z-axis, at z=10257440, which was about twice as high as the previous example...
A couple maps taken with Unmined...
(I noticed that flowing water appears to cause chunks to load past what is normally loaded)
I would not advise checking this out yourself; I've never had so much lag:
(this was from within MCP, which I'd used to find where these caves were located)
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?
I created a world in PCMCv1.8.8 and teleported to 512, -936 which AmidstExporter showed as being land over a line of mines.
I then opened that world file with Minutor v2.0.1 and took a look at what was there.
The mineshafts exists from about y=20 up to y=42.
Here's what y=37 looks like.
Note the row of identical shaped ravines along the north edge of the created chunks.
There are no dangerous weapons. There are only dangerous people. R.A. Heinlein
If you aren't part of the solution, then you obviously weren't properly dissolved.
The latest release of Amidst, version 4.6 can be found here:
https://github.com/toolbox4minecraft/amidst/releases
You should probably also read this:
https://www.minecraftforum.net/forums/mapping-and-modding-java-edition/minecraft-tools/2970854-amidst-map-explorer-for-minecraft-1-14
You can find me on the Minecraft Forums Discord server.
https://discord.gg/wGrQNKX
Man, this is gnarly!
Wow, that's nuts lol. Pretty cool looking.
What are the chances!
I'm going to try this out when I get home.
Game of Trones: A New World - A Minecraft Fan Fiction ebook on Amazon: USA | Canada
Follow me on Twitter! twitter.com/DaneBlox
Wow this is fascinating. So....just have the randomizer avoid using zero for the multipliers? Must be pretty rare though. Wonder if anyone ever legitimately got one of these.
Endless huge mineshaft sounds pretty crazy.
Just had a thought. Customize the seed and turn oceans way up to force mobs to spawn underground.
by c0yote
I tried it with terrible results. I gave my wife my glasses for a second, a creeper showed up and now my wife is pregnant.
Stupid 3D..
Mass transit.
Putting the CENDENT back in transcendent!
Probably won't try it... but this really is cool.
With the near-infinite world generation possibilities.... one would have to believe this will happen more than once. I wonder what other #'s would potentially give you this phenomenon.
It is interesting to note that they did something like this with the code that decorates chunks with ores and trees and stuff, possibly not with this bug in mind - they made it so the two random multipliers can never be zero, or any even number actually:
Since integer division always rounds down the division and multiplication by two does not cancel out and you'll always end up with an even number, then one is added.
Also, there should be a seed that causes the same thing to happen along the z-axis. Actually, there are a total of 131072 such seeds (65536 for each axis) since Java's Random only uses the lower 48 bits of a 64 bit seed, thus the upper 16 bits (2^16 = 65536) have no effect on the parts of world generation (aside from biomes) that use it, allowing you to create worlds that are different on the surface but have the same caves and mineshafts, and even the same villages and other features provided that the biome they are in is the same (even height variation is unchanged since the Perlin noise generator is initialized with random values using Java's Random).
Of interest, this is what happens when you use this seed with my mod TMCW; mineshafts do not generate in continuous rows but are identical at the same z-coordinate. The exclusion of larger caves, ravines, and mineshafts within 512 blocks of the origin is also evident, as well as the influence of certain biomes (the line of ravines below the middle has a short discontinuity where it passes through a mesa biome):
This was caused by a large cave generating over and over. In the most extreme case they can exceed 80 blocks across; ravines can reach 40:
An infinite ravine (actually, it is only like this close to the origin, though after it changes to a longer variant they are still linked together):
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?
Very interesting!
So are there exactly 1/2/65536/131072 seeds that will produce this result or at least that many?
Is each 48 bit seed guaranteed to produce a different starting value from every other one or could there be another set of 65536 seeds that will also produce repeats along the x-axis?
Just testing.
As far as I know there should be exactly 2^48 unique seeds since Java's Random has a full period, using every single state possible (some RNGs have odd cycle lengths; the number of unique seeds is the same as the cycle length). Also, as for seeds that have the same underground but are otherwise different worlds, you can easily manipulate the seed by adding or subtracting multiples of 2^48; for example, the seed 388513357548740 should give you a different world with the same bugged underground generation as the one in this thread since the lower 48 bits are the same; this is 107038380838084 plus 281474976710656 (2^48). You can also add any multiple of 2^48, or subtract if the seed is already greater than 2^48 - 1 (e.g. the seeds 0 and 281474976710656 have the same lower 48 bits).
Note that if you enter a string into the seed box there are only 2^32 unique seeds and the seed in this thread is larger than a 32 bit integer allows so it is impossible to get this to occur when entering a seed this way, and the game uses Random to get a random seed when it is left blank, meaning there are only 2^48 unique seeds (the chances of somebody getting a bugged world (two "bad" seeds) are one in 140737488355328; I doubt that anybody has ever actually created a random world with one) unless you manually enter a numeric seed (these seeds are full 64 bit values since Random combines two 32 bit values but that does not get around the 2^48 limitation since there are only 2^48 unique calls to the internal random number generator).
Here is a thread I made about these "same lower 48 bits" seeds: http://www.minecraftforum.net/forums/minecraft-discussion/seeds/2229720-can-two-different-seeds-produce-identical-worlds
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?
If it works for the X-axis, and the Z-axis, what's not to say it wouldn't work for the Y-axis as well?
That would only be possible with Cubic Chunks, since the "chunk seed" currently only takes the x and z coordinates into account because chunks cover the entire y-axis, and by then you'd think they would have fixed the bug that makes this possible (a very simple fix which was already applied to the biome decorator by ensuring the two seed-dependent multipliers can never be zero, although that solution means there are only half as many unique seeds).
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?
I know this thread is old but I am wondering if generation is affected by the world seed or the seed that MapGenBase gives out? Seems like it is the entire world seed, correct me if I am wrong. I've went through code on version 1.11 and I've seen a lot of function calls looking something like "random.setSeed(var1 ^ var2 ^ world.getSeed())"
MapGenbase is only used to generate caves, ravines, and "large" structures (ones which span multiple chunks, not small features like dungeons), and many of those structures use another method to set the seed for the RNG which determines where they will spawn (which happens to be the RNG that the World class uses, and also used by sheep to determine their wool color, while most entities use their own RNG which is based on the time they were spawned, hence MC-2788).
This does not affect minor chunk features like ores and trees because the game makes sure that the two coordinate multipliers can never be zero by dividing them by two, then multiplying by two and adding one, so the result is always an odd number:
In ChunkproviderGenerate.populate() (chunk x/z variables renamed for legibility):
Contrast to MapGenBase.generate():
Structures like villages call this bit of code in the World class, which is also immune to the bug that affects MapGenBase:Likewise, biome generation uses yet another method to set the seed which is also unaffected (a combination of additions and multiplications).
Also, as I mentioned later in the OP the method used to set the chunk seed in MapGenBase is so poor that it results in many chunks at sign-reversed signed coordinate pairs to have the same seed, and same caves and structures (mostly only observed with mineshafts due to the aforementioned additional code most other structures use); from more extensive testing I've found that as many as a third of all chunks can be affected, while the seed I used in the example had 1/6 of chunks affected (1/3 and 1/6 were most common), while others may have 1/12, 1/24, etc, and only very rarely will a seed be unaffected at all. This appears to be caused by the XORs canceling bits out, although I'm not sure why only certain chunks are affected and not always the same proportion; here is a simple map of the chunks affected in the seed I used.
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?