Well, things so far: The game hasn't crashed yet, everything seems to be generating properly, and there appears to be minimal if any performance impact, and the lava (Probably the ores also) is still at the lower level! Overall, everything seems to be working at expected.
That addition was great; and it's not even dependent on forge? I guess java's pretty great for things like this!
I've been tinkering with my private modpack lately. It has total custom ore generation powered by Cofh Core - I play on 1.7.10.
I have been receiving some rather weird crash logs. The program often mentions ChunkProvider. Did you by any chance tweak/modify ChunkProvider? Thank you in advance!
I'm just trying to pinpoint what exactly causes my worlds to load for too long. Hell, they generated faster when I had that ridiculous Geostrata around. I suspect WildCaves3 is to blame as it decorates cave systems with stuff.
I've been tinkering with my private modpack lately. It has total custom ore generation powered by Cofh Core - I play on 1.7.10.
I have been receiving some rather weird crash logs. The program often mentions ChunkProvider. Did you by any chance tweak/modify ChunkProvider? Thank you in advance!
I'm just trying to pinpoint what exactly causes my worlds to load for too long. Hell, they generated faster when I had that ridiculous Geostrata around. I suspect WildCaves3 is to blame as it decorates cave systems with stuff.
I only modified the following classes (for the mod proper, not the extra stuff):
aqs - MapGenRavine
aqw - MapGenCaves
ase - WorldGenMinable
asj - WorldGenSand
asw - MapGenMineshaft
aug - MapGenStronghold
auh - MapGenStronghold$Start (MapGenStronghold was reobfuscated as two classes)
If you are using mods that modify ore generation I'd suggest removing ase.class (WorldGenMinable) as I override the default ranges of most vanilla ores by overriding the y-coordinate passed in (I recently updated the download to fix a bug with Eyes of Ender not locating strongholds from extreme distances from the origin and included a note about this. The only class that really matters (for the caves) is aqw / MapGenCaves and none of them depend on another class, except for the two stronghold classes; aqs / MapGenRavine was only modified to disable vanilla ravines). Otherwise, the mod shouldn't have any noticeable impact on world generation time (at least for the 1.6.4 version cave generation takes around 20% of the total time, which is not to say that it will be that much slower since it replaces vanilla caves) and I suspect that one of your other mods has issues with runaway world gen (a very common cause of slow generation; this can be checked by looking at a newly generated world with a mapping utility like Minutor, you should see a square of generated terrain with no more than an extra chunk or two outside of it).
That said, what is the exact crash that you get? Does it reference any of the classes mentioned above?
Well, to be honest, it doesn't even crash. It just freezes completely during world generation after a player character is spawned and I walk a bit - and I have to kill the process. I have log opened at all times so I partially look at its window.
I had severe issues with runaway world gen in earlier versions of RTG, but then they killed that bug. Now I have COFH Core screaming that it cannot generate geodes when I tell it to. This is new, and I haven't understood why it appeared in the first place - this wasn't a thing a week ago.
As I understand a lot of errors write about failed attempts of loading the chunks that are being loaded or already loaded. They are in yellow color but still looks bad. Yesterday MultiMC told me it stopped logging the errors cause the game was creating too many.
Thank you for your broad answer, I will surely reinstall your mod without highlighted things. It may actually cause some of the ore gen error mayhem I have But still, I will need to pinpoint mod that causes error showers by good old take-one-out-run-game-see-what-happens routine
Making an "old caves" mod for 1.13 is going to be very difficult because it looks like I'd have to modify 58 separate classes, each of which appears to be for individual biomes (they are all nearly the same, including the lines shown below; the one with 0.004 is mineshafts, 0.142857 is caves, and 0.02 is ravines), in order to change the chance of caves, which is passed in as an argument in the constructor instead of being hardcoded into the cave generator class itself (as it was in an earlier 1.13 snapshot):
I could just modify the cave generator itself to override the argument but that is beyond the scope of a simple bytecode edit to change a number, as I did for earlier versions, so MCP would be required, and I'm not sure if I can run MCP on newer versions as it apparently requires more memory than a 32 bit OS can allocate. The "size" of cave systems is still hardcoded into the cave generator class but simply changing this to 40 (as in 1.6.4 and earlier) would more than double the cave density over 1.6.4:
(IMO this also does not look good for being able to customize caves if they have only made the "chance" alterable by changing the value of a parameter - the "size" is more important as far as the size/density/variation of individual cave systems go)
If 1.13 is out of the question, what about 1.12? I saw versions in the OP for 1.7/1.8.
In particular, if I said I wanted the "unlikely to overlap" mineshafts, and the new variety of caves that you have, but that I hated the "you can go anywhere underground forever because all the cave systems overlap each other and mineshafts and ravines" behavior of 1.6.4, can you help? I like the idea of a sense of "done" when an underground region is fully explored and lit, rather than continuing on into infinity. I just don't think the modern "worm tunnels" are really decent sized caves.
(In regard to a mod that gives realistic animal genetics):
Would you really rather have bees that make diamonds and oil with magical genetic blocks?
... did I really ask that?
If 1.13 is out of the question, what about 1.12? I saw versions in the OP for 1.7/1.8.
In particular, if I said I wanted the "unlikely to overlap" mineshafts, and the new variety of caves that you have, but that I hated the "you can go anywhere underground forever because all the cave systems overlap each other and mineshafts and ravines" behavior of 1.6.4, can you help? I like the idea of a sense of "done" when an underground region is fully explored and lit, rather than continuing on into infinity. I just don't think the modern "worm tunnels" are really decent sized caves.
The "old caves" mod that I was referring to is updated through 1.12.2; it reverts the changes they made in 1.7, which decreased the variation in the size/density of cave systems (many denser ones are so dense there are no recognizable "worm tunnels" (which still do exist in less dense regions), just a lot of random-looking formations and chambers) as well as regional-scale variation:
1.6.4:
1.7:
Some examples of "large" cave systems I've found in vanilla 1.6.4:
(that is actually sunlight nearing reaching lava level, with no ravine above it, just a very dense cave system)
If you mean the other mods, like the "better mineshafts" mod, I don't even know if I can run MCP for 1.12.2 since I've seen several mentions that it needs more memory than an x86 operating system can allocate (for comparison, MCP only uses around 256 MB of memory when decompiling 1.6.4, and that's the total memory usage used by the Java process that decompiles it, which is more than the heap usage, especially for such a low value).
That said, the mineshaft mod is very simple, I just replaced the code in "canSpawnStructureAtCoords" with the following:
TMCW uses this same basic method but I add a random offset of 0-3 to each point so they aren't so perfectly aligned to a grid, which is also randomly offset based on the world seed (replacing the additions of 2000000 with random offsets; I add 2000000 here to ensure that the coordinates are always positive so modulo doesn't return negative values) plus the base chance is fixed at 1/98 with the local density of caves and certain variants of caves reducing the frequency by about 40% (the code above multiplies the base chance by 98 to give the same frequency as vanilla, and enables you to change it in Superflat up to a maximum of 1.02 (1/98, close to the frequency in vanilla 1.6.4, which is 1/100). Also, this removes a reduction in their frequency within 80 chunks of the origin (as base chance * distance/80), making them much more common close to spawn.
TMCW Underground would be more complicated to update since it involves major changes and is far more complex (the in-development version of TMCW currently has well over 200 KB of cave generation code with the only resemblance to vanilla being the code that controls how tunnels snake around); it would also likely be far slower due to unfortunate changes in 1.8+ (e.g. each access to the array that holds the raw terrain data prior to initializing a chunk is now encapsulated behind a "ChunkPrimer" object. If I actually ever updated TMCW to 1.8+ (only out of absolute necessity, e.g. 1.6.4 no longer running on some newer version of Java/OS) I'd completely rewrite large parts of the game (not that TMCW, especially the in-development TMCWv5, hasn't already) to remove such nonsense, especially BlockPos and IBlockState and all their wrappers and getters/setters and conversions. To get some idea of how bad just vanilla 1.12 and 1.13 (despite claimed optimizations) are, they are about 5 times slower at world generation than TMCWv5, which is in turn up to 3 times faster (in biomes with giant trees, 1.5-2x otherwise) than TMCWv4 due to major optimizations, like a 3-4x faster lighting engine, largely due to reducing the number of method calls and get/sets by directly accessing chunk data and efficient use of caching and minimizing object allocation).
After some trial and error I was able to successfully edit the cave generator class for 1.13 to produce what appears to be the same general cave generation as 1.6.4 (it is hard to confirm for certain due to changes in the layout of caves and a lack of map viewers but I certainly found what look like "1.6.4" type cave systems):
These changes were much more involved than before, where I only had to edit a couple numbers; I had to modify the bytecode in a method to override a chance parameter with my own value (I had class verify errors, which appear to be due to the method not being the exact same size as the original, so I added in nop bytecodes to make it the same size. The bytecode itself was derived by compiling a simple class file with the desired code and looking at the bytecode; this is pretty much the most complicated bytecode editing that I've done so far. I also tried the same thing with mineshafts but JBE kept corrupting it (it appears to be for Java 5 and earlier based on warnings to this effect in its console window; mineshafts use more complicated code in its "canSpawn" method and even older versions, compiled with Java 6, cause JBE to error on anything but the simplest methods):
Also, while I was not able to (for now) change mineshafts they are effectively more common than earlier versions unless you travel far from spawn due to a removal of a reduction in their frequency closer to the origin (prior to 1.13 there was code that made mineshafts less common within 80 chunks of the origin along either axis, down to none at chunk 0,0 but I have not seen any evidence of this in the code for 1.13; it now only compares a random double to a value; and I saw quite a few mineshafts close to spawn; for comparison, in 1.6.4 they are less common within 32 chunks of the origin than the 1.7+ base chance).
Hi there! I'm sorry if this has been answered but im having a rly hard time getting these to work for 1.7.10.... trying to install old caves and more ravines and all that, but when I add them to the .jar nothing seems to happen. Would someone be willing to walk me through the process, and where exactly the jar im looking for is etc? Is it the original jar or the forge jar? thanks ahead of time!!
Hi there! I'm sorry if this has been answered but im having a rly hard time getting these to work for 1.7.10.... trying to install old caves and more ravines and all that, but when I add them to the .jar nothing seems to happen. Would someone be willing to walk me through the process, and where exactly the jar im looking for is etc? Is it the original jar or the forge jar? thanks ahead of time!!
You have to install them in the jar for the version that you are modding, so it would be the Forge jar if you are using Forge, and otherwise you have to make a new version by copying and renaming the 1.7.10 folder inside of .minecraft\versions\ (much as Forge itself has its own folder).
Here is a reply in another thread where I describe the installation process in more detail, and in particular, what you have to edit inside the json so the launcher does not redownload a clean jar:
In addition to that, you have to add "-Dfml.ignorePatchDiscrepancies=true -Dfml.ignoreInvalidMinecraftCertificates=true" (without quotes) to the JVM arguments so that Forge ignores the modified jar.
Also, you can verify if "old caves" is working by creating a world with the seed "-123775873255737467" and teleporting to -220, 14, 490, which should be in a cave that looks like this, with a very large lava-filled cave past the opening (IIRC the mineshaft is not present; I added a mineshaft mod later on which makes them as common as in 1.6.4):
The Meaning of Life, the Universe, and Everything.
Join Date:
2/13/2014
Posts:
53
Location:
United States of America
Minecraft:
Vediis
Member Details
Hey there, I'm considering using your double ravines mod on 1.7.10 and was wondering if it will take significantly more memory during the worldgen process? I'm running 1.7.10 KCauldron with several mods so RAM is especially tight.
Hey there, I'm considering using your double ravines mod on 1.7.10 and was wondering if it will take significantly more memory during the worldgen process? I'm running 1.7.10 KCauldron with several mods so RAM is especially tight.
The only impact it would have is slightly increased world generation time but that probably wouldn't be noticeable (a fraction of a second for new world creation), memory usage is identical to vanilla as I only changed a single value.
Quick question, as I am returning to modpacking.
Can the Light version of World Underground work with forge version 1558 or maybe 1400-something?
I remember forge version 1387 was the required version for your mod, but the Streams mod won't work with that..
Thanks
Quick question, as I am returning to modpacking.
Can the Light version of World Underground work with forge version 1558 or maybe 1400-something?
I remember forge version 1387 was the required version for your mod, but the Streams mod won't work with that..
Thanks
There is no required Forge version; it isn't even a Forge mod (the correct name is also "TheMasterCaver's World" or "TMCW", not "World") and should continue working as long as Forge doesn't add any of its own changes to any of the classes I modified (I did patch one class using Forge documentation, which adds a metadata parameter to the constructor for WorldGenMinable so it can use ores with metadata (presumably, as I did not see the actual code, just the constructor; it was reported to work without any issues), but I kind of doubt that they would make any new changes for such an old version, and this class is optional anyway as it just adjusts ore generation for the changes in caves and if you use other mods that add/change ores you'd want to use them instead; the main difference is that cave lava level is at y=4 instead of y=11 so if unadjusted ores like diamond will be more common. Note that I'm referring to the TMCWv4 version, which is equivalent to the "light" version of the original mod and does not have any other version).
I am quite suprised it was so easy to install. I could have sworn it was way more tricky last time..
I just added the .zip to Minecraft.jar via "Add to Minecraft.jar" button in MultiMC, and put in the JVM arguments. Easy!
Anything special to be aware of when using on server?
Overjay's here. Writing from this weird account, that appeared from nowhere when I logged at work.
Just wanted to ask about TMCWv4_Underground - did you make any updates for it? I know there are no bugs, but maybe there are some new features?
Also I am curious about the cave generator you modify - does it work in all dimensions? Or do you change only Overworld's cave generator? The reason I am asking this is that I also run DeeperCaves mod, which adds dimensions that you mine into, beneath level 0. And I am curious if TMCW will be applied to cave generation in modded dimensions (generally)?
Overjay's here. Writing from this weird account, that appeared from nowhere when I logged at work.
Just wanted to ask about TMCWv4_Underground - did you make any updates for it? I know there are no bugs, but maybe there are some new features?
Also I am curious about the cave generator you modify - does it work in all dimensions? Or do you change only Overworld's cave generator? The reason I am asking this is that I also run DeeperCaves mod, which adds dimensions that you mine into, beneath level 0. And I am curious if TMCW will be applied to cave generation in modded dimensions (generally)?
Thanks in advance!
I've been working on a new update for TMCW which includes additional cave and ravine variations, though much of it has focused on other things like enhancing underground biomes and adding more underground decorations (here is a full changelog) with relatively little change to the overall generation of caves, and adding any of this would be highly impractical given that not only would I need to change core worldgen classes and add new blocks and items, making Forge compatibility impossible, I'd also have to completely rewrite them since I'm basically working with my own game engine at this point with large parts of vanilla code rewritten, including the entire world generator (the actual cave generator is still relatively easy to separate with the main changes being changing the data type of the chunk data array; IIRC, the vanilla generator does not support metadata and I had to add in a special case for red sand, which is normally converted to sandstone if left floating, so I specifically check for a mesa biome which has caused some odd block replacements in modded biomes).
As far as other dimensions go, they will work as long as they use the Overworld cave generator; vanilla uses a separate cave generator for the Nether which differs in that caves are more scattered and evenly distributed across the full height range instead of being more common deeper down (in any case they do not generate caves starting higher than y=126, very rarely extending above), but custom dimensions may use either, or their own generator (it should be easy to determine which one is being used, the "CaverFinder" utility can be used to locate non-vanilla caves; at least in vanilla all dimensions use the same seed). I know that DeeperCaves uses its own generators, at least for some dimensions (e.g. this screenshot of the "drop" level is clearly modded).
One potential issue is that I disabled the vanilla ravine generator as my generator generates both caves and ravines at the same time due to how they interact with one another, so any dimension that uses it won't have ravines unless they also use the Overworld cave generator (you could omit "aqs.class" but then the Overworld would have twice as many ravines, though that can be useful if you really want more (post #260 shows what this would be like); if there is a mod that can selectively enable/disable features (like 1.8's Customized) for specific dimensions this could be used as a workaround).
Also, there is a bug with TMCWv4, including both the original mod and this one, with Eyes of Ender finding strongholds more than 46340 chunks away from the origin, although I don't consider it to be a major bug and haven't backported the fix since few players will likely search for a stronghold, much less travel, that far out (it is due to integer overflow when squaring coordinates to find the distance; 46341^2 = -2147479015, and this value allows them to generate when it is 1600 or higher; the code that actually determines if they can generate is not affected as this is only calculated within +/- 40 chunks of the origin).
I am impressed you do all this as a base edit. I looked into Java Bytecode Editor, and it looked more complicated than Java itself, which I recently started to learn.
>integer overflow
Ha, there's where they should've used "long" type. I know stuff now, haha!
>"drop" level is clearly modded
Yeah, it looks epic actually. 250 block high and 10-20 block wide ravines. But other than that the mod isn't polished, from what I felt. Which is no surprise, since creator rarely shows up around here. But there is an open GitHub for that mod, and I am seriously tempted to make my version of the mod because there is sooo much to do there! Like I could try integrating other cave feature mod into this, Shrooms! from 1.6.4, which wasn't properly ported into 1.7.10
I am also having ridiculous mineshaft spawning in DeeperCaves. Like 1500 blocks deep, in nether-like generation dimension, mineshaft structure spawn in thin air. Which shouldn't be around, according to the lore. I think this might happen due to RTG mineshaft generation since it appears to control mineshaft gen in my worlds. But I suspect poorly written dimension code in Deeper caves even stronger since I haven't seen any mineshafts in the nether.
I actually only use JBE to make the simple edits needed to change cave generation to that in 1.6.4, which involves changing only a couple hardcoded values, and otherwise I have hardly any experience with working with bytecode (I just find the class by using Java Decompiler, then I search for particular strings, then in JBE I look for the right sequence of instructions; there are three consecutive calls Random.nextInt where the "size" of a cave system is determined (line 213, with the "chance" being on line 214; the values of 15 and 7 are 40 and 15 in 1.6.4) and this is not obfuscated so it is pretty easy to spot in the bytecode).
Everything else, including TMCW, is ordinary Java code with MCP used as a development environment (it decompiles and deobfuscates the entire game so you have access to everything; most of my code is in my own classes with the appropriate vanilla base classes modified to call them; e.g. WorldProvider sets up the chunk generator (changed from ChunkProviderGenerate to ChunkProviderTMCW) which in turn calls most other worldgen classes (the vanilla cave generator is MapGenCaves and MapGenRavine; I replaced both with MapGenCavesRavines, which also merges code in a base class, MapGenBase).
For example, here is my "MapGenStronghold" class (from the latest version) which is basically copied from vanilla's with changes to "canSpawnStructureAtCoords" and "getNearestInstance" (the latter method is the one where the overflow occurred; I fixed it by not doing the calculation unless it was within 256 chunks of 0,0 or the result was less than 65536, which is well outside of a 128 + 40 (168) chunk radius). The 1.7.10 version uses all original MCP named classes while I renamed many of the classes in TMCW but they are functionally the same (calling a new class requires editing or replacing the class(es) that call it, which in this case would require editing the "main" class used for generating chunks in the Overworld). For the 1.7.10 version I also had to duplicate some code between the cave/mineshaft/stronghold classes as in TMCW I pass in references to the generators into the constructors so their spawning methods can be called; e.g. caves and mineshafts check for strongholds nearby and mineshafts also check for caves nearby.
Well, things so far: The game hasn't crashed yet, everything seems to be generating properly, and there appears to be minimal if any performance impact, and the lava (Probably the ores also) is still at the lower level! Overall, everything seems to be working at expected.
That addition was great; and it's not even dependent on forge? I guess java's pretty great for things like this!
Dear MasterCaver,
I've been tinkering with my private modpack lately. It has total custom ore generation powered by Cofh Core - I play on 1.7.10.
I have been receiving some rather weird crash logs. The program often mentions ChunkProvider. Did you by any chance tweak/modify ChunkProvider? Thank you in advance!
I'm just trying to pinpoint what exactly causes my worlds to load for too long. Hell, they generated faster when I had that ridiculous Geostrata around. I suspect WildCaves3 is to blame as it decorates cave systems with stuff.
I only modified the following classes (for the mod proper, not the extra stuff):
aqs - MapGenRavine
aqw - MapGenCaves
ase - WorldGenMinable
asj - WorldGenSand
asw - MapGenMineshaft
aug - MapGenStronghold
auh - MapGenStronghold$Start (MapGenStronghold was reobfuscated as two classes)
If you are using mods that modify ore generation I'd suggest removing ase.class (WorldGenMinable) as I override the default ranges of most vanilla ores by overriding the y-coordinate passed in (I recently updated the download to fix a bug with Eyes of Ender not locating strongholds from extreme distances from the origin and included a note about this. The only class that really matters (for the caves) is aqw / MapGenCaves and none of them depend on another class, except for the two stronghold classes; aqs / MapGenRavine was only modified to disable vanilla ravines). Otherwise, the mod shouldn't have any noticeable impact on world generation time (at least for the 1.6.4 version cave generation takes around 20% of the total time, which is not to say that it will be that much slower since it replaces vanilla caves) and I suspect that one of your other mods has issues with runaway world gen (a very common cause of slow generation; this can be checked by looking at a newly generated world with a mapping utility like Minutor, you should see a square of generated terrain with no more than an extra chunk or two outside of it).
That said, what is the exact crash that you get? Does it reference any of the classes mentioned above?
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, to be honest, it doesn't even crash. It just freezes completely during world generation after a player character is spawned and I walk a bit - and I have to kill the process. I have log opened at all times so I partially look at its window.
I had severe issues with runaway world gen in earlier versions of RTG, but then they killed that bug. Now I have COFH Core screaming that it cannot generate geodes when I tell it to. This is new, and I haven't understood why it appeared in the first place - this wasn't a thing a week ago.
As I understand a lot of errors write about failed attempts of loading the chunks that are being loaded or already loaded. They are in yellow color but still looks bad. Yesterday MultiMC told me it stopped logging the errors cause the game was creating too many.
Thank you for your broad answer, I will surely reinstall your mod without highlighted things. It may actually cause some of the ore gen error mayhem I have
But still, I will need to pinpoint mod that causes error showers by good old take-one-out-run-game-see-what-happens routine 
Making an "old caves" mod for 1.13 is going to be very difficult because it looks like I'd have to modify 58 separate classes, each of which appears to be for individual biomes (they are all nearly the same, including the lines shown below; the one with 0.004 is mineshafts, 0.142857 is caves, and 0.02 is ravines), in order to change the chance of caves, which is passed in as an argument in the constructor instead of being hardcoded into the cave generator class itself (as it was in an earlier 1.13 snapshot):
I could just modify the cave generator itself to override the argument but that is beyond the scope of a simple bytecode edit to change a number, as I did for earlier versions, so MCP would be required, and I'm not sure if I can run MCP on newer versions as it apparently requires more memory than a 32 bit OS can allocate. The "size" of cave systems is still hardcoded into the cave generator class but simply changing this to 40 (as in 1.6.4 and earlier) would more than double the cave density over 1.6.4:
(IMO this also does not look good for being able to customize caves if they have only made the "chance" alterable by changing the value of a parameter - the "size" is more important as far as the size/density/variation of individual cave systems go)
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?
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumIf 1.13 is out of the question, what about 1.12? I saw versions in the OP for 1.7/1.8.
In particular, if I said I wanted the "unlikely to overlap" mineshafts, and the new variety of caves that you have, but that I hated the "you can go anywhere underground forever because all the cave systems overlap each other and mineshafts and ravines" behavior of 1.6.4, can you help? I like the idea of a sense of "done" when an underground region is fully explored and lit, rather than continuing on into infinity. I just don't think the modern "worm tunnels" are really decent sized caves.
* Promoting this week: Captive Minecraft 4, Winter Realm. Aka: Vertical Vanilla Viewing. Clicky!
* My channel with Mystcraft, and general Minecraft Let's Plays: http://www.youtube.com/user/Keybounce.
* See all my video series: http://www.minecraftforum.net/forums/minecraft-editions/minecraft-editions-show-your/2865421-keybounces-list-of-creation-threads
(In regard to a mod that gives realistic animal genetics):
Would you really rather have bees that make diamonds and oil with magical genetic blocks?
... did I really ask that?
The "old caves" mod that I was referring to is updated through 1.12.2; it reverts the changes they made in 1.7, which decreased the variation in the size/density of cave systems (many denser ones are so dense there are no recognizable "worm tunnels" (which still do exist in less dense regions), just a lot of random-looking formations and chambers) as well as regional-scale variation:
1.7:
Some examples of "large" cave systems I've found in vanilla 1.6.4:
(that is actually sunlight nearing reaching lava level, with no ravine above it, just a very dense cave system)
If you mean the other mods, like the "better mineshafts" mod, I don't even know if I can run MCP for 1.12.2 since I've seen several mentions that it needs more memory than an x86 operating system can allocate (for comparison, MCP only uses around 256 MB of memory when decompiling 1.6.4, and that's the total memory usage used by the Java process that decompiles it, which is more than the heap usage, especially for such a low value).
That said, the mineshaft mod is very simple, I just replaced the code in "canSpawnStructureAtCoords" with the following:
int chunkModX = ((chunkX + 2000000) % 14); int chunkModZ = ((chunkZ + 2000000) % 14); if ((chunkModX == 0 && chunkModZ == 0) || (chunkModX == 7 && chunkModZ == 7)) { return this.rand.nextDouble() < chance * 98.0D; } return false;TMCW uses this same basic method but I add a random offset of 0-3 to each point so they aren't so perfectly aligned to a grid, which is also randomly offset based on the world seed (replacing the additions of 2000000 with random offsets; I add 2000000 here to ensure that the coordinates are always positive so modulo doesn't return negative values) plus the base chance is fixed at 1/98 with the local density of caves and certain variants of caves reducing the frequency by about 40% (the code above multiplies the base chance by 98 to give the same frequency as vanilla, and enables you to change it in Superflat up to a maximum of 1.02 (1/98, close to the frequency in vanilla 1.6.4, which is 1/100). Also, this removes a reduction in their frequency within 80 chunks of the origin (as base chance * distance/80), making them much more common close to spawn.
TMCW Underground would be more complicated to update since it involves major changes and is far more complex (the in-development version of TMCW currently has well over 200 KB of cave generation code with the only resemblance to vanilla being the code that controls how tunnels snake around); it would also likely be far slower due to unfortunate changes in 1.8+ (e.g. each access to the array that holds the raw terrain data prior to initializing a chunk is now encapsulated behind a "ChunkPrimer" object. If I actually ever updated TMCW to 1.8+ (only out of absolute necessity, e.g. 1.6.4 no longer running on some newer version of Java/OS) I'd completely rewrite large parts of the game (not that TMCW, especially the in-development TMCWv5, hasn't already) to remove such nonsense, especially BlockPos and IBlockState and all their wrappers and getters/setters and conversions. To get some idea of how bad just vanilla 1.12 and 1.13 (despite claimed optimizations) are, they are about 5 times slower at world generation than TMCWv5, which is in turn up to 3 times faster (in biomes with giant trees, 1.5-2x otherwise) than TMCWv4 due to major optimizations, like a 3-4x faster lighting engine, largely due to reducing the number of method calls and get/sets by directly accessing chunk data and efficient use of caching and minimizing object allocation).
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?
After some trial and error I was able to successfully edit the cave generator class for 1.13 to produce what appears to be the same general cave generation as 1.6.4 (it is hard to confirm for certain due to changes in the layout of caves and a lack of map viewers but I certainly found what look like "1.6.4" type cave systems):
These changes were much more involved than before, where I only had to edit a couple numbers; I had to modify the bytecode in a method to override a chance parameter with my own value (I had class verify errors, which appear to be due to the method not being the exact same size as the original, so I added in nop bytecodes to make it the same size. The bytecode itself was derived by compiling a simple class file with the desired code and looking at the bytecode; this is pretty much the most complicated bytecode editing that I've done so far. I also tried the same thing with mineshafts but JBE kept corrupting it (it appears to be for Java 5 and earlier based on warnings to this effect in its console window; mineshafts use more complicated code in its "canSpawn" method and even older versions, compiled with Java 6, cause JBE to error on anything but the simplest methods):
Also, while I was not able to (for now) change mineshafts they are effectively more common than earlier versions unless you travel far from spawn due to a removal of a reduction in their frequency closer to the origin (prior to 1.13 there was code that made mineshafts less common within 80 chunks of the origin along either axis, down to none at chunk 0,0 but I have not seen any evidence of this in the code for 1.13; it now only compares a random double to a value; and I saw quite a few mineshafts close to spawn; for comparison, in 1.6.4 they are less common within 32 chunks of the origin than the 1.7+ base chance).
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?
Hi there! I'm sorry if this has been answered but im having a rly hard time getting these to work for 1.7.10.... trying to install old caves and more ravines and all that, but when I add them to the .jar nothing seems to happen. Would someone be willing to walk me through the process, and where exactly the jar im looking for is etc? Is it the original jar or the forge jar? thanks ahead of time!!
You have to install them in the jar for the version that you are modding, so it would be the Forge jar if you are using Forge, and otherwise you have to make a new version by copying and renaming the 1.7.10 folder inside of .minecraft\versions\ (much as Forge itself has its own folder).
Here is a reply in another thread where I describe the installation process in more detail, and in particular, what you have to edit inside the json so the launcher does not redownload a clean jar:
https://www.minecraftforum.net/forums/support/java-edition-support/2929664-installing-older-mods-with-without-forge?comment=2
In addition to that, you have to add "-Dfml.ignorePatchDiscrepancies=true -Dfml.ignoreInvalidMinecraftCertificates=true" (without quotes) to the JVM arguments so that Forge ignores the modified jar.
Also, you can verify if "old caves" is working by creating a world with the seed "-123775873255737467" and teleporting to -220, 14, 490, which should be in a cave that looks like this, with a very large lava-filled cave past the opening (IIRC the mineshaft is not present; I added a mineshaft mod later on which makes them as common as in 1.6.4):
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?
Thank you so much for replying so thoroughly!!! That answers all my questions thank you so much!!!!!
Hey there, I'm considering using your double ravines mod on 1.7.10 and was wondering if it will take significantly more memory during the worldgen process? I'm running 1.7.10 KCauldron with several mods so RAM is especially tight.
The only impact it would have is slightly increased world generation time but that probably wouldn't be noticeable (a fraction of a second for new world creation), memory usage is identical to vanilla as I only changed a single value.
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?
Quick question, as I am returning to modpacking.
Can the Light version of World Underground work with forge version 1558 or maybe 1400-something?
I remember forge version 1387 was the required version for your mod, but the Streams mod won't work with that..
Thanks
There is no required Forge version; it isn't even a Forge mod (the correct name is also "TheMasterCaver's World" or "TMCW", not "World") and should continue working as long as Forge doesn't add any of its own changes to any of the classes I modified (I did patch one class using Forge documentation, which adds a metadata parameter to the constructor for WorldGenMinable so it can use ores with metadata (presumably, as I did not see the actual code, just the constructor; it was reported to work without any issues), but I kind of doubt that they would make any new changes for such an old version, and this class is optional anyway as it just adjusts ore generation for the changes in caves and if you use other mods that add/change ores you'd want to use them instead; the main difference is that cave lava level is at y=4 instead of y=11 so if unadjusted ores like diamond will be more common. Note that I'm referring to the TMCWv4 version, which is equivalent to the "light" version of the original mod and does not have any other version).
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?
Sorry about the name. TMCW i'll call it
I am quite suprised it was so easy to install. I could have sworn it was way more tricky last time..
I just added the .zip to Minecraft.jar via "Add to Minecraft.jar" button in MultiMC, and put in the JVM arguments. Easy!
Anything special to be aware of when using on server?
Overjay's here. Writing from this weird account, that appeared from nowhere when I logged at work.
Just wanted to ask about TMCWv4_Underground - did you make any updates for it? I know there are no bugs, but maybe there are some new features?
Also I am curious about the cave generator you modify - does it work in all dimensions? Or do you change only Overworld's cave generator? The reason I am asking this is that I also run DeeperCaves mod, which adds dimensions that you mine into, beneath level 0. And I am curious if TMCW will be applied to cave generation in modded dimensions (generally)?
Thanks in advance!
I've been working on a new update for TMCW which includes additional cave and ravine variations, though much of it has focused on other things like enhancing underground biomes and adding more underground decorations (here is a full changelog) with relatively little change to the overall generation of caves, and adding any of this would be highly impractical given that not only would I need to change core worldgen classes and add new blocks and items, making Forge compatibility impossible, I'd also have to completely rewrite them since I'm basically working with my own game engine at this point with large parts of vanilla code rewritten, including the entire world generator (the actual cave generator is still relatively easy to separate with the main changes being changing the data type of the chunk data array; IIRC, the vanilla generator does not support metadata and I had to add in a special case for red sand, which is normally converted to sandstone if left floating, so I specifically check for a mesa biome which has caused some odd block replacements in modded biomes).
As far as other dimensions go, they will work as long as they use the Overworld cave generator; vanilla uses a separate cave generator for the Nether which differs in that caves are more scattered and evenly distributed across the full height range instead of being more common deeper down (in any case they do not generate caves starting higher than y=126, very rarely extending above), but custom dimensions may use either, or their own generator (it should be easy to determine which one is being used, the "CaverFinder" utility can be used to locate non-vanilla caves; at least in vanilla all dimensions use the same seed). I know that DeeperCaves uses its own generators, at least for some dimensions (e.g. this screenshot of the "drop" level is clearly modded).
One potential issue is that I disabled the vanilla ravine generator as my generator generates both caves and ravines at the same time due to how they interact with one another, so any dimension that uses it won't have ravines unless they also use the Overworld cave generator (you could omit "aqs.class" but then the Overworld would have twice as many ravines, though that can be useful if you really want more (post #260 shows what this would be like); if there is a mod that can selectively enable/disable features (like 1.8's Customized) for specific dimensions this could be used as a workaround).
Also, there is a bug with TMCWv4, including both the original mod and this one, with Eyes of Ender finding strongholds more than 46340 chunks away from the origin, although I don't consider it to be a major bug and haven't backported the fix since few players will likely search for a stronghold, much less travel, that far out (it is due to integer overflow when squaring coordinates to find the distance; 46341^2 = -2147479015, and this value allows them to generate when it is 1600 or higher; the code that actually determines if they can generate is not affected as this is only calculated within +/- 40 chunks of the origin).
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?
>Full changelog
I am impressed you do all this as a base edit. I looked into Java Bytecode Editor, and it looked more complicated than Java itself, which I recently started to learn.
>integer overflow
Ha, there's where they should've used "long" type. I know stuff now, haha!
>"drop" level is clearly modded
Yeah, it looks epic actually. 250 block high and 10-20 block wide ravines. But other than that the mod isn't polished, from what I felt. Which is no surprise, since creator rarely shows up around here. But there is an open GitHub for that mod, and I am seriously tempted to make my version of the mod because there is sooo much to do there! Like I could try integrating other cave feature mod into this, Shrooms! from 1.6.4, which wasn't properly ported into 1.7.10
I am also having ridiculous mineshaft spawning in DeeperCaves. Like 1500 blocks deep, in nether-like generation dimension, mineshaft structure spawn in thin air. Which shouldn't be around, according to the lore. I think this might happen due to RTG mineshaft generation since it appears to control mineshaft gen in my worlds. But I suspect poorly written dimension code in Deeper caves even stronger since I haven't seen any mineshafts in the nether.
I actually only use JBE to make the simple edits needed to change cave generation to that in 1.6.4, which involves changing only a couple hardcoded values, and otherwise I have hardly any experience with working with bytecode (I just find the class by using Java Decompiler, then I search for particular strings, then in JBE I look for the right sequence of instructions; there are three consecutive calls Random.nextInt where the "size" of a cave system is determined (line 213, with the "chance" being on line 214; the values of 15 and 7 are 40 and 15 in 1.6.4) and this is not obfuscated so it is pretty easy to spot in the bytecode).
Everything else, including TMCW, is ordinary Java code with MCP used as a development environment (it decompiles and deobfuscates the entire game so you have access to everything; most of my code is in my own classes with the appropriate vanilla base classes modified to call them; e.g. WorldProvider sets up the chunk generator (changed from ChunkProviderGenerate to ChunkProviderTMCW) which in turn calls most other worldgen classes (the vanilla cave generator is MapGenCaves and MapGenRavine; I replaced both with MapGenCavesRavines, which also merges code in a base class, MapGenBase).
For example, here is my "MapGenStronghold" class (from the latest version) which is basically copied from vanilla's with changes to "canSpawnStructureAtCoords" and "getNearestInstance" (the latter method is the one where the overflow occurred; I fixed it by not doing the calculation unless it was within 256 chunks of 0,0 or the result was less than 65536, which is well outside of a 128 + 40 (168) chunk radius). The 1.7.10 version uses all original MCP named classes while I renamed many of the classes in TMCW but they are functionally the same (calling a new class requires editing or replacing the class(es) that call it, which in this case would require editing the "main" class used for generating chunks in the Overworld). For the 1.7.10 version I also had to duplicate some code between the cave/mineshaft/stronghold classes as in TMCW I pass in references to the generators into the constructors so their spawning methods can be called; e.g. caves and mineshafts check for strongholds nearby and mineshafts also check for caves nearby.
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?