(updated 9/10, originally written before 1.7 was released concerning customizing cave generation only; now expanded for all structures, plus some other suggestions for the customized world type)
The "customized" world type added in 1.8 is pretty good, allowing you to customize many aspects of world generation - but has some glaring omissions; for one, there are only "yes/no" options for many features that should otherwise be configurable, in particular, cave and structure generation, even as the Superflat world type allows you to change the generation of structures like villages (size and distance); oddly enough, you can make dungeons more/less common despite no prior way of changing their frequency.
Because many structures already allow customization in Superflat and the coding otherwise required (basically replacing hard-coded values with variables) is easy to add it would be trivial to add in some sliders to change their parameters, perhaps as a separate customization screen, similar to ores (leaving the on/off toggles as-is), with the following options, which are the same as Superflat unless mentioned below:
Villages:
Size (0 for default, 1 for Superflat village size, range unknown, if only two values just a button to toggle between "default" and "large")
Distance (chunks between villages, default is 32, suggested range is 9 (minimum allowed)-100)*
Mineshafts:
Chance (default is 0.004; suggested range 0.001-0.1, or one every 1000-10 chunks; Superflat allows up to 1.0 but that practically crashes the game)
Uniform distribution: yes/no (default is no, with fewer mineshafts within 80 chunks of the origin, decreasing to none at 0,0; setting this to "yes" makes them generate at the chance set everywhere)
Strongholds:
Distance (default is 32, suggested range 1-100; not the same as village, etc distance)
Count (default is 3, suggested range 1-10, possibly more depending on how the settings interact)
Spread (default is 3, suggested range 1-10, see above)
Temples/Witch Huts (these all generate the same way so can't be separated):
Distance (default is 32, same range as villages)*
Ocean Monuments:
Distance (default is 32(?), same range as villages/temples)*
Caves:
Size (default is 15, suggested range is 2-100; higher means bigger cave systems, note that minimum is 2 or no caves generate)
Chance (default is 7, suggested range is 1-100; higher means fewer cave systems, a chance of 7 means one cave system every 7 chunks)
Diameter (default is 1, suggested range is 0-5; sets the value of a multiplier used to make caves larger, with a size range so a higher value makes bigger caves but small caves still generate)
Ravines:
Chance (default is 50, suggested range is 10-1000; higher chance means fewer ravines, a chance of 50 means one ravine every 50 chunks)
Width (default is 1, suggested range is 0-5; similar to caves, is a multiplier used for a randomly generated "width" value)
Most of this is the same as in Superflat, with the exception of mineshafts, ocean monuments, caves, and ravines, which are explained as follows, and how easy it would be to change the code to allow the changes needed to adjust their parameters (spoilered due to long detailed content):
Mineshaft uniform distribution: By default, abandoned mineshafts are less common within 80 chunks (1,280 blocks) of the origin because in addition to a random number being compared to a "chance" parameter it also compares the maximum of the absolute values of the x/z chunk coordinates to a random number between 0-79 and only generates a mineshaft if both values meet the conditions; as a result, the chance linearly decreases to zero at the origin. Setting "Uniform distribution" to "yes" would bypass the second test so mineshafts are just as common near the origin as elsewhere; this only requires a "true/false" variable added so if the first test is true and "uniformDistribution" is true or the second test is true it will generate a mineshaft.
Ocean Monument distance: Presumably, ocean monuments use a distance algorithm similar to villages and temples and would be set in a similar manner, basically copying the code the other two already use to set their parameters, which should be straightforward if they do indeed use the same algorithm (a minimum distance of 9 is required due to how it works, equivalent to 9 chunks or 144 blocks between structures, with a minimum distance of 8 chunks or 128 blocks).
*An additional idea would be to have two distances; minimum distance and maximum distance, for all structures it applies to (villages, temples, ocean monuments(?)), which could be set independent of each other, as long as max is greater than min; the default minimum distance is 8 for villages/temples and a range of 8-99 could be used, corresponding to one less than the range of the maximum distance slider.
Cave size: "Size" controls the size of cave systems; the only thing necessary to allow this value to be changed is to replace a hard-coded value with a variable that defaults to 15, the size used in 1.7 and later versions. A range of 2 to 100 is suggested; the minimum is 2 because random will only return 0 if the size is 1 (random(1) = 0, random(2) = 0,1; random(3) = 0,1,2; etc) and a maximum of 100 is suggested to avoid excessive lag when the game generates a maximum size cave system (though that would be very rare; because of how the game randomizes the size with a size of 100 there is a 1-in-1 million chance of a maximum size cave system; 100^3; the default size of 15 gives a chance of only 1-in-3375; the average size of a cave system is 1/8 of "Size").
Cave chance: Similar to "Size", "Chance" controls cave generation by controlling how often a cave system attempts to generate in a chunk; the default of 7 results in one attempt every 7 chunks (not always generating caves because the result of "Size" can be, and often is, zero). The suggested range of 1 to 100 would correspond to one attempt every chunk to every 100 chunks, which together with "Size" allows for a great amount of variability in local cave density to be produced; for example, setting both to a low value would result in a relatively uniform distribution of caves while high values would result in caves clustered together in dense cave systems with large amounts of open space. Here are a couple examples of cave generation set to the defaults for 1.7+ and 1.6.4 and earlier, which uses values of 40/15:
As you can see, the 1.6.4 settings results in noticeably larger, denser cave systems, beyond what the increase in overall cave density would suggest (15 / 8 / 70 = 0.268 caves per chunk for 1.7+ and 40 / 8 / 15 = 0.33 caves per chunk for 1.6.4, about 24% more caves overall but cave systems average 40/15 = 2.67 times larger).
Cave diameter: "Diameter" is a multiplier which is multiplied by a random value that control the diameter of caves; the default of 1 means caves generate as they normally do, with size variation; a suggested range of 0.0-5.0 (decimal value) is suggested, which means you can remove all size variation from caves (they have a minimum diameter so setting this to 0 doesn't eliminate caves) or make them get up to 5 times bigger than normal, with normal sized caves still generating due to the size variation.
Ravine chance: This is basically the same as for cave systems and requires the same basic code changes to implement, replacing a hard-coded value of 50 with a variable defaulting to this value; a suggested range of 10-1000 results in one ravine every 10-1000 chunks, with reasonable limits on how rare or common they can get.
Ravine width: Similar to caves, "Width" controls the width of ravines; this works in the same way as "Diameter" for caves, renamed because "width" makes more sense (though it does also affect the depth).
Also, the display of the "chance" values could be altered to display as a range from 0-100% to make it more user-friendly; for example, for mineshafts multiply the actual value by 100 for display (0.001-0.1 becomes 0.1-10%); for caves and ravines, 100 / chance (the default of 7 would display as 14.28%). Note that the preset string would use the actual values.
Additional parameters that could be set concerning caves/ravines (affecting both at once) are "Cave Lava Level", which controls the height to which caves and ravines are flooded with lava; the default would be 10, perhaps with a range from 0-64; and "Bedrock Type" toggling between "Default" and "One Layer" of bedrock; this is related to the first because if you removed all lava from caves the lower layers would be filled with bedrock unless it was made one layer (a quirk of cave generation is that they only go down to y=2, so there is always at least one layer of stone left before hitting bedrock if it is one layer thick).
In addition, the way ores generates makes it impossible to have less than one spawn attempt per chunk; a slider that enables you to set a count lower than 1 would be useful; for example, to get one vein every 10 chunks you might set the "spawn count" slider to 0.1, incrementing in steps of 0.1 between 0 and 1, then in whole units; when less then 1 and greater than zero the game will assume one vein per chunk but an additional random value compared to the spawn count will reduce the chance accordingly (no effect when 1 or higher since a random number between 0-1 will always be less than the count, thus always pass true; this could be added with no effect on existing worlds).
The settings like "main noise scale" should also be renamed to make them more user-friendly, so the average user knows that one setting makes terrain higher, another more rugged, and so on; of course, there would still be an "expert users" page with more technical settings.
You can already up cave gen in 1.8 using customize...
No you can't and I have absolute proof; here is the decompiled source for the cave generator class in 1.8:
See the values 15 and 7 in the first few lines? Those are the same values I mentioned that change the size of cave systems and their frequency (40 and 15 respectively in 1.6.4 and earlier) - as you can see, they are hard-coded, otherwise you'd see some variables there. Not only that, you can see all the other variables that are hard-coded as well, such as line 220 ("double d2..."), which can be used to change the range caves generate over (in this case, a random number between 0-119 has 8 added, then that in turn is used to output a random number between 0 and 126, with an average of about 34). Another value that can be changed is the constant 3.0F on line 234, which is a size multiplier for bigger individual caves (10% chance of multiplying a base size (which can be adjusted by adding a multiplier (default 1) to line 232) by 1-4, with an average multiplier of 1.75 due to multiplying 3 by two random numbers averaging 0.5 each).
Also, you can use Unmined to look underground yourself and see if any settings affect cave generation - they don't, unless you enable or disable them entirely, or count a few extra caves above sea level from making more mountains (the majority of caves are well below sea level; see above; so this has little effect).
No you can't and I have absolute proof; here is the decompiled source for the cave generator class in 1.8:
See the values 15 and 7 in the first few lines? Those are the same values I mentioned that change the size of cave systems and their frequency (40 and 15 respectively in 1.6.4 and earlier) - as you can see, they are hard-coded, otherwise you'd see some variables there. Not only that, you can see all the other variables that are hard-coded as well, such as line 220 ("double d2..."), which can be used to change the range caves generate over (in this case, a random number between 0-119 has 8 added, then that in turn is used to output a random number between 0 and 126, with an average of about 34). Another value that can be changed is the constant 3.0F on line 234, which is a size multiplier for bigger individual caves (10% chance of multiplying a base size (which can be adjusted by adding a multiplier (default 1) to line 232) by 1-4, with an average multiplier of 1.75 due to multiplying 3 by two random numbers averaging 0.5 each).
Also, you can use Unmined to look underground yourself and see if any settings affect cave generation - they don't, unless you enable or disable them entirely, or count a few extra caves above sea level from making more mountains (the majority of caves are well below sea level; see above; so this has little effect).
Er... Can you dumb that down a bit o-O
Rollback Post to RevisionRollBack
Yes. cause I totally spread gold bars on my toast...
What I'm saying is that there is no evidence that you can change any of the parameters which change how caves generate; for example, this line (213 in the screenshot):
int i = this.b.nextInt(this.b.nextInt(this.b.nextInt(15) + 1) + 1);
The 15 that I bolded is what can be adjusted to make cave systems bigger or smaller; if they truly added the ability to change it it would look something like this:
int i = this.b.nextInt(this.b.nextInt(this.b.nextInt(caveSize + 1) + 1) + 1);
In this case, "caveSize" would be set to a default value of 15 and you'd be able to use a slider to change it, say from 1 to 100; setting it to 39 would generate cave systems that are on average as large as the ones in 1.6.4 and older versions. Or you could set it down to 1 and only single caves would generate (some with a few branches). Or go all-out and set it to 100 (which should be the maximum you can set it to; actually, I'd recommend 50 unless additional code was added after that line to limit it to 50).
(note that I add one to caveSize because Random requires at least 1 or it crashes the game and 2 to produce an output that is nonzero; Random(2) returns 0 or 1, Random(3) returns 0, 1, and 2, and so on, so this allows 1 to be used to generate cave systems with a maximum size of 1. Also, my suggestion for the frequency of cave systems wouldn't fit so much now that 1.7 has been released; I made this suggestion when it was still in snapshots, so the less intuitive "inverse chance" used would have to be used, where 7 means a 1-in-7 chance per chunk of a cave system; see this more recent suggestion for a method that would be compatible with existing worlds).
Yeah, but that is the whole problem - what if you wanted caves like they were before 1.7, without mods? That is, here is a comparison of 1.7 and later (left) to 1.6.4, all the way back to Beta (right); the difference is very obvious:
Customizable cave generation can also get much more than that; you can get small single caves randomly scattered around the map, huge but isolated (a major gripe is how caves are too interconnected) cave systems, and so on:
(note that you can still get smaller cave systems, down to single caves, even with the size set very high because it is randomized, less evident when the frequency is higher like in vanilla)
Same goes for ravines; what if you wanted only ravines, and lots of them? Sure:
(The last three examples were made with my Superflat Caves mod, which adds them to Superflat with configurable options)
It is even possible to add more options, such as the size and length of individual caves and ravines (which are randomized so you'd still get smaller ones as well for more variety).
I hate ravines only because along with caves I end up with this massive endless cave/ravine system that NEVER ends! I now use customized maps that have 0 ravines. I'd be cool if they did exist, but were rare. Even then I'd make them rare and huge. I'm fine with the way caves are now, but the ability to customize their rarity (and size) would be nice. That's why I supported to begin with.
Now this idea along with that other one floating around about specialized caves based on biome plus other cave types (like giant open chasms underground) would be fantastic.
I hate ravines only because along with caves I end up with this massive endless cave/ravine system that NEVER ends! I now use customized maps that have 0 ravines. I'd be cool if they did exist, but were rare. Even then I'd make them rare and huge. I'm fine with the way caves are now, but the ability to customize their rarity (and size) would be nice. That's why I supported to begin with.
Now this idea along with that other one floating around about specialized caves based on biome plus other cave types (like giant open chasms underground) would be fantastic.
I know what you mean; there are threads about how cave systems became huge and never-ending in Beta 1.8 (which I actually like) but they actually didn't change the number of caves, but did add in mineshafts and ravines; the former at a frequency that is a bit ridiculous, with one every 100 chunks, when they can cover up to a similarly sized area (they did make it so they are less common near the origin of the world, but once you get more than 80 chunks out you basically get endless mineshaft complexes (gotta love this, from a world I made in 1.5-1.6; I think there are more mineshafts than caves there...); even the reduced frequency in 1.7 (one per 250 chunks) is still rather high).
It is also odd that while they reduced the size of cave systems and mineshafts in 1.7, both by about the same percentage (around 40% of before), they didn't do anything to ravines, which still have a 1 in 50 chance per chunk, which is also rather high since the average ravine is about 6 chunks long and 50 chunks is about 7x7 chunks. In any case, if they allowed it I'd set caves to pre-1.7 levels while setting mineshafts to use the same structure spacing code as other structures, so they can't overlap each other, with about the same frequency as 1.7 (see this example (an area about 1200 blocks across) of what I mean, which is how I place them in my mods, with the 1.7 frequency uniformly distributed over the world, including near the origin so they aren't too rare near it; you can also see they are still pretty common).
It is actually even possible to use a similar spacing for cave systems and ravines, as I've also done in my mods (with some regular caves scattered around), which helps prevent very large complexes from forming (I intentionally generate some very large cave systems and individual caves, at a controlled rarity, so there are occasional large complexes/caves, but something you'd rarely find, not everywhere; generating multiple layers of caves like this is a bit complex though for simple customization).
One of the things I do for other players on my server is to specifically create really... really... big caves to fight thru and explore.
Big caves are cool. I wish we had more of them. I want at least one cave with an underground sea like in journey to the center of the earth. Monumentally big--- with a subterranean ocean.
You have the source!? Where, where!? Do you work at Mojang now?
I assume you aren't serious; I used Minecraft Coder Pack which allows you to decompile the game and edit the source; for 1.8 I was able to find the class file by using Java Decompiler (JD-GUI) to decompile the jar (though not editable/recompilable), then used Windows grep (or an equivalent) to search for a string (2.0F / 8.0F) I knew to exist in the cave generator class (also the ravine and Nether cave generators, which are based off the Overworld cave generator, but no other classes, so easy to figure out which one it is; the equivalent class in MCP is MapGenCaves).
Also, it is possible to make some simple code edits with Java Bytecode Editor, such as changing hard-coded values when the source is available:
Here is what the cave generator code corresponding to the part I mention looks like for 1.8:
Even if you don't really understand bytecode (I don't) you can see that lines 7 "bipush 15" and 18 "bipush 7" contain the values that affect cave system size/frequency; the calls to Random make it easy to find as well. For comparison, here is the Java Decompiler output again, with lines 213 and 214 being the ones of interest here:
You could even try this yourself; extract the 1.8 jar with a zip utility (or even just rename it as a zip file and extract), then use Java Bytecode Editor to open bgs.class and try changing the aforementioned lines to "bipush 40" and "bipush 15", save and then insert the modified class into the 1.8 jar (following the steps here), then compare the same seed in 1.6.4 and 1.8, which should have the same caves in the same locations (as long as terrain allows, such as not being under a ocean or in a mountain in one version but not the other).
You could even try changing some other values; for example, referring to the JAD output, notice lines 233-234, which multiples a variable by a couple random numbers and 3.0 and adding one; this is a multiplier for the size of caves that is applied 10% of the time and makes caves up to 4 times bigger than usual. Here is the JBE output corresponding to those lines; you can see that line 119 is "bipush 10", corresponding to the 10 in line 233 in JAD and line 130 is "ldc 3.0", corresponding to the 3.0F in line 234 in JAD:
Try changing the 3.0 on line 130 to 6.0, or even 12.0, which will produce caves up to two or four times bigger, subject to the usual size variance (as eash nextFloat() averages 0.5 and they are multiplied together the average is 0.25 for an average multiplier of 1.25 including the 1 added; for 6.0 and 12.0 the average becomes 1.5 and 2.0 respectively). As a quick test I changed it to 12.0 and this was the result (using 1.6.4 cave system size/frequency and the seed -123775873255737467; I was near -220, 12, 500; in this thread you can see what the cave in the screenshot normally looks like):
NB: You can figure out how big the largest caves can get by multiplying the value plus one by three, adding 1.5, then doubling it; in other words, most caves have a radius variance of 0-3 to which 1.5 is added for a maximum diameter of 3-9 blocks, with most caves near the middle of that range; for vanilla the additional multiplier of 1-4 means the largest possible cave can be up to (3 * 4 + 1.5) * 2 = 27 blocks wide; with 12 instead of 3 for a range of 1-13 for the additional multiplier the maximum size becomes (3 * 13 + 1.5) * 2 = 81 blocks wide. In addition, with a total of four random values, each averaging 0.5, the chances of a cave reaching half that size is 0.5^4 = 6.25%, or 0.625% of all caves including the 1/10 chance of an additional multiplier; with an average of 0.325 caves per chunk with the 1.6.4 cave distribution on average there will be one half-maximum size cave per 492 chunks; larger sizes are exponentially rarer (a cave in the top 10% size range has an approximately one in 300,000 chunk chance).
Also of interest, the chance of the largest possible single cave system with the 1.6.4 distribution is 40^3 * 15 = one per 960,000 chunks. For the 1.7 distribution it is much lower; 15^3 * 7 = one per 23,625 chunks.
Tbh, I haven't noticed any real difference. Caves are still all over the place, it's just that they don't litter the world as much. But effectively, it just means that you need to search more. It's kinda like finding coal, it's super-common in the world but if you start in a bad seed, finding coal early can be a real pain.
I support, though. Having a simple "more/less caves" option would be a win-win for the community.
Tbh, I haven't noticed any real difference. Caves are still all over the place, it's just that they don't litter the world as much. But effectively, it just means that you need to search more. It's kinda like finding coal, it's super-common in the world but if you start in a bad seed, finding coal early can be a real pain.
I support, though. Having a simple "more/less caves" option would be a win-win for the community.
I'd rather have a slider (actually, two) though than just "more/less" because that is just too limited; why should we be able to fine-tune all the other stuff (terrain, ores) but only have a couple fixed presets for caves? Note that the differences between pre 1.7 and 1.7+ are more than just more/less caves, as these maps show, with 1.7 on the left and 1.6.4 on the right (same area of the same seed; you can even see a few caves that are the same, I just modified the 1.7+ generation to the 1.6.4 one; real 1.6.4 has more mineshafts as well, including several in this area):
With sliders to change the size/density and frequency of cave systems you could even have big cave systems like before 1.7 but rare enough so they aren't all over the place. For example, here is the same seed as above with the size set to double the 1.6.4 value and frequency at 1/4 of 1.6.4 (cave systems average twice as big but are four times rarer), which might be chosen by somebody who wants some good cave systems but not too many caves in general (you'll also still get small cave systems for a variety in size):
As you can see, you can get almost unlimited variety with just a couple sliders, which can be placed on a general page for structure generation (other structures should have the Superflat customization options as well as sliders; for example, villages have size and distance; mineshafts chance; strongholds, count, distance and spread)
(I'll update the OP with a better description, like what I posted in another thread, also reflecting the fact that 1.7 was released and as a result my method for changing the frequency should be changed to ensure compatibility with existing worlds)
It is the same as what Minecraft Coder Pack gives though; sure, it isn't the ORIGINAL never-obfuscated source but it is functionally identical; as MCP says themselves:
* There are currently no known bugs in the recompiled game or server, except those that were already in the original game
In other words, MCP's source replicates what the original source does so that is good enough to call it "source code" (indeed, MCP acts like that too when they say you can't distribute it).
Again, if you can't believe me why don't you check for yourself? Get MCP for 1.7.10 and check the MapGenCaves class (method func_151538_a) and see if you don't find a couple lines that look like the ones I pointed out; do the same for 1.6.4 (method recursiveGenerate) and see how they are different (failing that, use Unmined to look at the underground cave generation using 1.6.4, 1.7/8, and ideally also 1.7/8 with a mod I made to replicate 1.6.4 cave generation ("old caves" in the second link in my signature) by editing the code as I described).
Really, i don't know what is up with some people...
The "customized" world type added in 1.8 is pretty good, allowing you to customize many aspects of world generation - but has some glaring omissions; for one, there are only "yes/no" options for many features that should otherwise be configurable, in particular, cave and structure generation, even as the Superflat world type allows you to change the generation of structures like villages (size and distance); oddly enough, you can make dungeons more/less common despite no prior way of changing their frequency.
Because many structures already allow customization in Superflat and the coding otherwise required (basically replacing hard-coded values with variables) is easy to add it would be trivial to add in some sliders to change their parameters, perhaps as a separate customization screen, similar to ores (leaving the on/off toggles as-is), with the following options, which are the same as Superflat unless mentioned below:
Most of this is the same as in Superflat, with the exception of mineshafts, ocean monuments, caves, and ravines, which are explained as follows, and how easy it would be to change the code to allow the changes needed to adjust their parameters (spoilered due to long detailed content):
Ocean Monument distance: Presumably, ocean monuments use a distance algorithm similar to villages and temples and would be set in a similar manner, basically copying the code the other two already use to set their parameters, which should be straightforward if they do indeed use the same algorithm (a minimum distance of 9 is required due to how it works, equivalent to 9 chunks or 144 blocks between structures, with a minimum distance of 8 chunks or 128 blocks).
*An additional idea would be to have two distances; minimum distance and maximum distance, for all structures it applies to (villages, temples, ocean monuments(?)), which could be set independent of each other, as long as max is greater than min; the default minimum distance is 8 for villages/temples and a range of 8-99 could be used, corresponding to one less than the range of the maximum distance slider.
Cave size: "Size" controls the size of cave systems; the only thing necessary to allow this value to be changed is to replace a hard-coded value with a variable that defaults to 15, the size used in 1.7 and later versions. A range of 2 to 100 is suggested; the minimum is 2 because random will only return 0 if the size is 1 (random(1) = 0, random(2) = 0,1; random(3) = 0,1,2; etc) and a maximum of 100 is suggested to avoid excessive lag when the game generates a maximum size cave system (though that would be very rare; because of how the game randomizes the size with a size of 100 there is a 1-in-1 million chance of a maximum size cave system; 100^3; the default size of 15 gives a chance of only 1-in-3375; the average size of a cave system is 1/8 of "Size").
Cave chance: Similar to "Size", "Chance" controls cave generation by controlling how often a cave system attempts to generate in a chunk; the default of 7 results in one attempt every 7 chunks (not always generating caves because the result of "Size" can be, and often is, zero). The suggested range of 1 to 100 would correspond to one attempt every chunk to every 100 chunks, which together with "Size" allows for a great amount of variability in local cave density to be produced; for example, setting both to a low value would result in a relatively uniform distribution of caves while high values would result in caves clustered together in dense cave systems with large amounts of open space. Here are a couple examples of cave generation set to the defaults for 1.7+ and 1.6.4 and earlier, which uses values of 40/15:
As you can see, the 1.6.4 settings results in noticeably larger, denser cave systems, beyond what the increase in overall cave density would suggest (15 / 8 / 70 = 0.268 caves per chunk for 1.7+ and 40 / 8 / 15 = 0.33 caves per chunk for 1.6.4, about 24% more caves overall but cave systems average 40/15 = 2.67 times larger).
Cave diameter: "Diameter" is a multiplier which is multiplied by a random value that control the diameter of caves; the default of 1 means caves generate as they normally do, with size variation; a suggested range of 0.0-5.0 (decimal value) is suggested, which means you can remove all size variation from caves (they have a minimum diameter so setting this to 0 doesn't eliminate caves) or make them get up to 5 times bigger than normal, with normal sized caves still generating due to the size variation.
Ravine chance: This is basically the same as for cave systems and requires the same basic code changes to implement, replacing a hard-coded value of 50 with a variable defaulting to this value; a suggested range of 10-1000 results in one ravine every 10-1000 chunks, with reasonable limits on how rare or common they can get.
Ravine width: Similar to caves, "Width" controls the width of ravines; this works in the same way as "Diameter" for caves, renamed because "width" makes more sense (though it does also affect the depth).
Also, the display of the "chance" values could be altered to display as a range from 0-100% to make it more user-friendly; for example, for mineshafts multiply the actual value by 100 for display (0.001-0.1 becomes 0.1-10%); for caves and ravines, 100 / chance (the default of 7 would display as 14.28%). Note that the preset string would use the actual values.
Additional parameters that could be set concerning caves/ravines (affecting both at once) are "Cave Lava Level", which controls the height to which caves and ravines are flooded with lava; the default would be 10, perhaps with a range from 0-64; and "Bedrock Type" toggling between "Default" and "One Layer" of bedrock; this is related to the first because if you removed all lava from caves the lower layers would be filled with bedrock unless it was made one layer (a quirk of cave generation is that they only go down to y=2, so there is always at least one layer of stone left before hitting bedrock if it is one layer thick).
In addition, the way ores generates makes it impossible to have less than one spawn attempt per chunk; a slider that enables you to set a count lower than 1 would be useful; for example, to get one vein every 10 chunks you might set the "spawn count" slider to 0.1, incrementing in steps of 0.1 between 0 and 1, then in whole units; when less then 1 and greater than zero the game will assume one vein per chunk but an additional random value compared to the spawn count will reduce the chance accordingly (no effect when 1 or higher since a random number between 0-1 will always be less than the count, thus always pass true; this could be added with no effect on existing worlds).
The settings like "main noise scale" should also be renamed to make them more user-friendly, so the average user knows that one setting makes terrain higher, another more rugged, and so on; of course, there would still be an "expert users" page with more technical settings.
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?
Support.
Is there a way I can manually edit the files to achieve this effect? I didn't fully understand from the OP.
I want
ocean content(thanks Möjang!),nether biomes(again thanks!!), and savanna passive mobs (meerkats incoming!?).Ropes: Leads, just better -Deonyi
Yes. cause I totally spread gold bars on my toast...
No you can't and I have absolute proof; here is the decompiled source for the cave generator class in 1.8:
See the values 15 and 7 in the first few lines? Those are the same values I mentioned that change the size of cave systems and their frequency (40 and 15 respectively in 1.6.4 and earlier) - as you can see, they are hard-coded, otherwise you'd see some variables there. Not only that, you can see all the other variables that are hard-coded as well, such as line 220 ("double d2..."), which can be used to change the range caves generate over (in this case, a random number between 0-119 has 8 added, then that in turn is used to output a random number between 0 and 126, with an average of about 34). Another value that can be changed is the constant 3.0F on line 234, which is a size multiplier for bigger individual caves (10% chance of multiplying a base size (which can be adjusted by adding a multiplier (default 1) to line 232) by 1-4, with an average multiplier of 1.75 due to multiplying 3 by two random numbers averaging 0.5 each).
Also, you can use Unmined to look underground yourself and see if any settings affect cave generation - they don't, unless you enable or disable them entirely, or count a few extra caves above sea level from making more mountains (the majority of caves are well below sea level; see above; so this has little effect).
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?
Er... Can you dumb that down a bit o-O
Yes. cause I totally spread gold bars on my toast...
What I'm saying is that there is no evidence that you can change any of the parameters which change how caves generate; for example, this line (213 in the screenshot):
int i = this.b.nextInt(this.b.nextInt(this.b.nextInt(15) + 1) + 1);
The 15 that I bolded is what can be adjusted to make cave systems bigger or smaller; if they truly added the ability to change it it would look something like this:
int i = this.b.nextInt(this.b.nextInt(this.b.nextInt(caveSize + 1) + 1) + 1);
In this case, "caveSize" would be set to a default value of 15 and you'd be able to use a slider to change it, say from 1 to 100; setting it to 39 would generate cave systems that are on average as large as the ones in 1.6.4 and older versions. Or you could set it down to 1 and only single caves would generate (some with a few branches). Or go all-out and set it to 100 (which should be the maximum you can set it to; actually, I'd recommend 50 unless additional code was added after that line to limit it to 50).
(note that I add one to caveSize because Random requires at least 1 or it crashes the game and 2 to produce an output that is nonzero; Random(2) returns 0 or 1, Random(3) returns 0, 1, and 2, and so on, so this allows 1 to be used to generate cave systems with a maximum size of 1. Also, my suggestion for the frequency of cave systems wouldn't fit so much now that 1.7 has been released; I made this suggestion when it was still in snapshots, so the less intuitive "inverse chance" used would have to be used, where 7 means a 1-in-7 chance per chunk of a cave system; see this more recent suggestion for a method that would be compatible with existing 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?
Ropes: Leads, just better -Deonyi
Yeah, but that is the whole problem - what if you wanted caves like they were before 1.7, without mods? That is, here is a comparison of 1.7 and later (left) to 1.6.4, all the way back to Beta (right); the difference is very obvious:
Customizable cave generation can also get much more than that; you can get small single caves randomly scattered around the map, huge but isolated (a major gripe is how caves are too interconnected) cave systems, and so on:
(note that you can still get smaller cave systems, down to single caves, even with the size set very high because it is randomized, less evident when the frequency is higher like in vanilla)
Same goes for ravines; what if you wanted only ravines, and lots of them? Sure:
(The last three examples were made with my Superflat Caves mod, which adds them to Superflat with configurable options)
It is even possible to add more options, such as the size and length of individual caves and ravines (which are randomized so you'd still get smaller ones as well for more variety).
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?
Now this idea along with that other one floating around about specialized caves based on biome plus other cave types (like giant open chasms underground) would be fantastic.
Ropes: Leads, just better -Deonyi
I know what you mean; there are threads about how cave systems became huge and never-ending in Beta 1.8 (which I actually like) but they actually didn't change the number of caves, but did add in mineshafts and ravines; the former at a frequency that is a bit ridiculous, with one every 100 chunks, when they can cover up to a similarly sized area (they did make it so they are less common near the origin of the world, but once you get more than 80 chunks out you basically get endless mineshaft complexes (gotta love this, from a world I made in 1.5-1.6; I think there are more mineshafts than caves there...); even the reduced frequency in 1.7 (one per 250 chunks) is still rather high).
It is also odd that while they reduced the size of cave systems and mineshafts in 1.7, both by about the same percentage (around 40% of before), they didn't do anything to ravines, which still have a 1 in 50 chance per chunk, which is also rather high since the average ravine is about 6 chunks long and 50 chunks is about 7x7 chunks. In any case, if they allowed it I'd set caves to pre-1.7 levels while setting mineshafts to use the same structure spacing code as other structures, so they can't overlap each other, with about the same frequency as 1.7 (see this example (an area about 1200 blocks across) of what I mean, which is how I place them in my mods, with the 1.7 frequency uniformly distributed over the world, including near the origin so they aren't too rare near it; you can also see they are still pretty common).
It is actually even possible to use a similar spacing for cave systems and ravines, as I've also done in my mods (with some regular caves scattered around), which helps prevent very large complexes from forming (I intentionally generate some very large cave systems and individual caves, at a controlled rarity, so there are occasional large complexes/caves, but something you'd rarely find, not everywhere; generating multiple layers of caves like this is a bit complex though for simple customization).
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?
Big caves are cool. I wish we had more of them. I want at least one cave with an underground sea like in journey to the center of the earth. Monumentally big--- with a subterranean ocean.
I assume you aren't serious; I used Minecraft Coder Pack which allows you to decompile the game and edit the source; for 1.8 I was able to find the class file by using Java Decompiler (JD-GUI) to decompile the jar (though not editable/recompilable), then used Windows grep (or an equivalent) to search for a string (2.0F / 8.0F) I knew to exist in the cave generator class (also the ravine and Nether cave generators, which are based off the Overworld cave generator, but no other classes, so easy to figure out which one it is; the equivalent class in MCP is MapGenCaves).
Also, it is possible to make some simple code edits with Java Bytecode Editor, such as changing hard-coded values when the source is available:
Even if you don't really understand bytecode (I don't) you can see that lines 7 "bipush 15" and 18 "bipush 7" contain the values that affect cave system size/frequency; the calls to Random make it easy to find as well. For comparison, here is the Java Decompiler output again, with lines 213 and 214 being the ones of interest here:
You could even try this yourself; extract the 1.8 jar with a zip utility (or even just rename it as a zip file and extract), then use Java Bytecode Editor to open bgs.class and try changing the aforementioned lines to "bipush 40" and "bipush 15", save and then insert the modified class into the 1.8 jar (following the steps here), then compare the same seed in 1.6.4 and 1.8, which should have the same caves in the same locations (as long as terrain allows, such as not being under a ocean or in a mountain in one version but not the other).
You could even try changing some other values; for example, referring to the JAD output, notice lines 233-234, which multiples a variable by a couple random numbers and 3.0 and adding one; this is a multiplier for the size of caves that is applied 10% of the time and makes caves up to 4 times bigger than usual. Here is the JBE output corresponding to those lines; you can see that line 119 is "bipush 10", corresponding to the 10 in line 233 in JAD and line 130 is "ldc 3.0", corresponding to the 3.0F in line 234 in JAD:
Try changing the 3.0 on line 130 to 6.0, or even 12.0, which will produce caves up to two or four times bigger, subject to the usual size variance (as eash nextFloat() averages 0.5 and they are multiplied together the average is 0.25 for an average multiplier of 1.25 including the 1 added; for 6.0 and 12.0 the average becomes 1.5 and 2.0 respectively). As a quick test I changed it to 12.0 and this was the result (using 1.6.4 cave system size/frequency and the seed -123775873255737467; I was near -220, 12, 500; in this thread you can see what the cave in the screenshot normally looks like):
NB: You can figure out how big the largest caves can get by multiplying the value plus one by three, adding 1.5, then doubling it; in other words, most caves have a radius variance of 0-3 to which 1.5 is added for a maximum diameter of 3-9 blocks, with most caves near the middle of that range; for vanilla the additional multiplier of 1-4 means the largest possible cave can be up to (3 * 4 + 1.5) * 2 = 27 blocks wide; with 12 instead of 3 for a range of 1-13 for the additional multiplier the maximum size becomes (3 * 13 + 1.5) * 2 = 81 blocks wide. In addition, with a total of four random values, each averaging 0.5, the chances of a cave reaching half that size is 0.5^4 = 6.25%, or 0.625% of all caves including the 1/10 chance of an additional multiplier; with an average of 0.325 caves per chunk with the 1.6.4 cave distribution on average there will be one half-maximum size cave per 492 chunks; larger sizes are exponentially rarer (a cave in the top 10% size range has an approximately one in 300,000 chunk chance).
Also of interest, the chance of the largest possible single cave system with the 1.6.4 distribution is 40^3 * 15 = one per 960,000 chunks. For the 1.7 distribution it is much lower; 15^3 * 7 = one per 23,625 chunks.
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 support, though. Having a simple "more/less caves" option would be a win-win for the community.
May the force be without you.
I'd rather have a slider (actually, two) though than just "more/less" because that is just too limited; why should we be able to fine-tune all the other stuff (terrain, ores) but only have a couple fixed presets for caves? Note that the differences between pre 1.7 and 1.7+ are more than just more/less caves, as these maps show, with 1.7 on the left and 1.6.4 on the right (same area of the same seed; you can even see a few caves that are the same, I just modified the 1.7+ generation to the 1.6.4 one; real 1.6.4 has more mineshafts as well, including several in this area):
With sliders to change the size/density and frequency of cave systems you could even have big cave systems like before 1.7 but rare enough so they aren't all over the place. For example, here is the same seed as above with the size set to double the 1.6.4 value and frequency at 1/4 of 1.6.4 (cave systems average twice as big but are four times rarer), which might be chosen by somebody who wants some good cave systems but not too many caves in general (you'll also still get small cave systems for a variety in size):
As you can see, you can get almost unlimited variety with just a couple sliders, which can be placed on a general page for structure generation (other structures should have the Superflat customization options as well as sliders; for example, villages have size and distance; mineshafts chance; strongholds, count, distance and spread)
(I'll update the OP with a better description, like what I posted in another thread, also reflecting the fact that 1.7 was released and as a result my method for changing the frequency should be changed to ensure compatibility with existing 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?
It is the same as what Minecraft Coder Pack gives though; sure, it isn't the ORIGINAL never-obfuscated source but it is functionally identical; as MCP says themselves:
In other words, MCP's source replicates what the original source does so that is good enough to call it "source code" (indeed, MCP acts like that too when they say you can't distribute it).
Again, if you can't believe me why don't you check for yourself? Get MCP for 1.7.10 and check the MapGenCaves class (method func_151538_a) and see if you don't find a couple lines that look like the ones I pointed out; do the same for 1.6.4 (method recursiveGenerate) and see how they are different (failing that, use Unmined to look at the underground cave generation using 1.6.4, 1.7/8, and ideally also 1.7/8 with a mod I made to replicate 1.6.4 cave generation ("old caves" in the second link in my signature) by editing the code as I described).
Really, i don't know what is up with some people...
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?
Also Support being able to edit caves would be great and simple great idea
Full support