Are you sure you are putting these files in version 1.2.2 of the jar? I just got to test it here at home and deleted my bin and resources folders in my .minecraft directory, ran Minecraft.exe to let it download 1.2.2, then opened the jar with WinRar and deleted META-INF and dropped in the modified class files. I ran the game and it worked fine. The black screen means there is some serious issue with classes that is causing the game to fail at starting up. Maybe you still have 1.2.1?
Quote from Portalboat »
If I don't delete the meta-inf folder, I get get past the loading screen, but as soon as I try to generate a world, it crashes. Here's the error log:
You have to delete META-INF or you will get that error because there are SHA1 hash codes in there. Any change to the classes will cause the SHA1 values to not match any more and throw that error.
Quote from Lemming »
Awesome mod :smile.gif: I mad a full desert map. Takes survival to a new level..
I have a few question tho--> I set moisture min and max to 0.0 and temperature to 1.0 max and min. Then I set waterless desert to true, and desert dirt true, desert dirt frequency to 2, and final I enable underground lakes.
So i wonder if there will be underground dirt pockets? And what about oceans, are they still around? And what about grass? If I have water close to dirt, will grass grow there in time? If not, what do I have to do to the settings to get a little grass here and there?
Thanks :smile.gif:
Thanks. Credit definitely goes to the others I mentioned in the OP as well :smile.gif:
Underground lakes are processed after water is removed from desert biomes so the waterless desert setting will not affect underground lakes. If the biomes are desert only and waterless deserts is turns on then that means the entire map is a desert biome. This means there is no water at all since oceans are not a separate biome. I am not familiar with the requirements for getting grass to grow, but if it is to simply have light and water (nearby) then, yes, grass should grow on the dirt. If the requirement is that there must be grass for it to spread from (as I imagine is the case), then no, grass will not grow. The only way to solve that is to make a setting that places grass in the desert biome just like the desert dirt setting does.
Quote from smurfsahoy »
Actually, mine now randomly stopped working. I can load an existing world, but upon trying to create a new world in an empty slot, it just hangs forever on the dirt menu screen, and no error report.
You can delete the biomesettings.txt file and let it recreate it to make sure there isn't an odd setting in there. Have you, also, tried different worlds and/or checked to make sure there isn't an erroneous world save in your save folder? I had a problem during testing where I had a crash during a world generation that left a bad world save in my save folder. Every time I tried to use that world slot it would hang. Other than those possibilities I am not sure what it could be :sad.gif:
Quote from molkien »
For the most part everything looks like it is working, but I tried creating an all desert map. Moisture has been set to 0, Temperature has been set to 1, and DesertDirt has been left at false, but I'm still getting some small patches of dirt in the desert. Don't know if adjusting the AverageDepthMax or VolatilityPrimary/Secondary effects that at all though.
Hmm, I've never seen that. I'll investigate.
Quote from Rofang »
Heh, dang, I was hoping it would work. Copied the files into the jar and deleted Meta-inf, but crash on loading a world. I'm running OS X 10.5.8, if it matters (was this compiled for Java 1.5 compatibility?).
Oops, yeah was using my work computer and it was still set to use 1.6 and not 1.5. I recompiled it for you and updated the link in the OP.
I'm getting a black screen on 1.2.2, and I deleted META-INF and then extracted the file.
I was running v6 (before you updated for compatibility with today's update), and I noticed some interesting things. I created a new map using the defaults, and then I simply altered the biomesettings.txt in the World1 folder, and deleted all the chunks (leaving a "level.dat" and "biomesettings.txt" in the World1 folder, and nothing else). I did this a number of times, until I got a world I liked.
First off, as long as the landscape didn't drastically change (ex: of drastic change - all volatility settings of any kind to 1.0. Really interesting, actually! At least 1/2 the map was hitting the height limit, but the land formations were amazing!), all the cave systems (that I explored) were essentially the same, but ore, gravel, grass, and dirt distribution were different. Also, every time I reloaded the world (after changing one of the settings), the biomes would always be completely different. My spawn point is underwater (even though water level is 64! I don't know why this is), and once, I was stuck beneath the ice. I made it out, but only barely (2 hearts left? And I was playing on Peaceful, so health was slowly regenerating...). I looked at my world in a map viewer, and the bottom layer is all bedrock, with out exception. I made sure that option was disabled, and I still get all bedrock. I enabled it, thinking perhaps it was backwards, and it made no difference.
I also set the average depth to 10, and water went all the way to bed rock (lol!), so I then put it at 5 (I think I got "ground" at around 10 with that). I now have it at 2, and "surface water" (water that starts at the surface, and goes all the way down) stops at around 29. After seeing what all the volatility settings at 1.0 did, I switched it to 0.5 for all of them. It's pretty interesting looking, but there's some parts that I can't tell if they're chunk errors, or if the map is actually supposed to look like that.
I love this mod! This is easily my favorite mod for Minecraft! If Minecraft updated, and permanently broke support for this mod, I would probably never update. I *love* all the screwy things I can do with this! I think I'll still play with the settings, but I'm hoping to eventually create a map with water at level, say, 30-40 (going almost all the way to bedrock), and floating islands (not connected to the ground at all) everywhere. Unfortunately, as the game is currently, this would make it so I'd probably never find any diamond, and probably no gold or redstone....
I look forward to when you have the cave generation code figured out. I'll make huge monstrous caverns! I can seriously have as much fun (and likely more) just creating worlds, as I can playing the game now! Thank you so much for this awesome mod! Mouser X over and out.
I played around with a few things last night and managed to get the game to populate the are between 128 and 255 with blocks. Problem was it was extremely bugged out (indivisible blocks that seemed to be stack inside each other). So it is very possible to populate beyond the limit of 128, it's just going to take a lot of work to figure out all the other bugs that is causes.
I also messed around with trying to make reliable floating islands that aren't connected to the ground. No luck on that front yet, but I did manage to create the equivalent to massive cave systems.
Also, the height at which diamond and redstone appear can be easily altered. I may add that in as an option.
I'm going to miss cadde's no dirt/gravel undergound thing. :-(
But this is an A+ mod right here, hot dang!
I can probably implement no dirt/gravel underground. I'll look at adding that for the next update.
Quote from NoiGren »
I wonder if Minecraft will ever support something like this out of the box. If not for the volatile nature of mods I would have some of the features on all the time.
Great work!
I really do wish MC had options like this built in by default (like Civ). Seems to make more sense to let users alter landscapes how they want rather than sticking them with the same, average landscapes all the time. I mean who doesn't like massive landforms, giant gaves, floating islands, etc... :tongue.gif:
Hey Bucyruss.
In your to do list, I see you want to investigate cave mods. What plans do you have for them? And have this investigation started?
I`ve been asking around for a few days about a cave density mod. Just beacause I want less caves in my worlds :smile.gif: Are your plans for the caves anything in this direction, where we can play with the density of caves?
Your doing awesomely :smile.gif: Dont stop..
Hey Bucyruss.
In your to do list, I see you want to investigate cave mods. What plans do you have for them? And have this investigation started?
I`ve been asking around for a few days about a cave density mod. Just beacause I want less caves in my worlds :smile.gif: Are your plans for the caves anything in this direction, where we can play with the density of caves?
Your doing awesomely :smile.gif: Dont stop..
I plan to mess with whatever there is to mess with :tongue.gif: That should include, among other things, cave density and size. Unfortunately, no, I've not really gotten started in on caves. I wish I had more time to dedicate toward this, but such is life.
Have you noticed that spawning a new world with an increased WaterLevel value (say, 90-ish) takes a REALLY long time to generate, and when it does, the file size is pretty large (8MB)? I'm guessing this is just a quirk of how Minecraft generates worlds rather than a mod-specific problem.
I noticed that it would hang at the dirt screen after clicking on an empty world slot if I modified the water level.
Ah, see, that's what I thought at first too, but I noticed if I left it a few minutes, the world would generate. It's just a huge world file. Did you notice this moving the water level down too, or just up?
I don't know if you can really explain this in words I can understand, but just what are the Volatility variables governing? It looks like the correspond to general weirdness, but I can't imagine how one would code for that.
I played around with a few things last night and managed to get the game to populate the are between 128 and 255 with blocks. Problem was it was extremely bugged out (indivisible blocks that seemed to be stack inside each other). So it is very possible to populate beyond the limit of 128, it's just going to take a lot of work to figure out all the other bugs that is causes.
I have a question regarding this. Would it be possible to, instead of adding an additional 128 blocks on top of everything, add 64 blocks below and 64 blocks above? I mean, I guess that would be the same as adding 128 more blocks on top and shifting the water level and such up to 127 instead of 64, but I digress. I would want this more than 64 blocks of cave/underground and 192 blocks of air space because then the caves could get super awesome and the terrain above would also have room to get better.
Encountered an error with setting lower than default values for WaterLevel. It is possible to set a value of 63 or 62 and a new world will generate correctly, but for any value less than 62 the client will begin the world building process but never truly finish. All you will see in the client window screen is the brown dirt background, no text or loading bar will appear to indicate any kind of progress.
A World directory does get generated by this process (but no level.dat file) and if left to run for a minute or more the size of the directory continues to grow as whatever process continues to run. Quickly got to a 25meg+ directory size trying to see if the process would complete before deciding to terminate.
I have tried a number of WaterLevel values between 62 and 1, but not all of them to see if this occurs on every iteration.
I don't know if you can really explain this in words I can understand, but just what are the Volatility variables governing? It looks like the correspond to general weirdness, but I can't imagine how one would code for that.
I don't know this for sure but I can make a few assumptions and guess at it:
Notch has mentioned before that he uses a perlin noise function to do the terrain generation. How this basically works is that you generate several random noise patterns with varying levels of noise like this:
High randomization, low max/min noise level
medium randomization, medium max/min noise level
Low randomization, high max/min noise level
You then combine these noise maps into a single map that creates what looks like a natural landscape.
My guess is that the volitility settings are for the max/min noise level and the allowed difference between local data points.
Added:
- convert surface dirt/grass to sand for desert biomes
- muddy swamps
- muddy swamp size
- convert bedrock to obsidian
- landscape fracturing parameters (additional modification to the terrain algorithm)
- replaced Cadde's alternate ore distribution with an equivalent implementation that allows the use to set the ore deposit parameters
Check the OP for details on these changes/additions.
Hey Bucyruss.
In your to do list, I see you want to investigate cave mods. What plans do you have for them? And have this investigation started?
I`ve been asking around for a few days about a cave density mod. Just beacause I want less caves in my worlds :smile.gif: Are your plans for the caves anything in this direction, where we can play with the density of caves?
Your doing awesomely :smile.gif: Dont stop..
I've found the cave algorithm (I think anyways :tongue.gif:) and pulled it and included it in the latest version of the mod, but not made any changes to it. I'll try looking at it this afternoon/tonight instead of working on trees (yeah I keep putting those off, sorry!)
Quote from Rofang »
Have you noticed that spawning a new world with an increased WaterLevel value (say, 90-ish) takes a REALLY long time to generate, and when it does, the file size is pretty large (8MB)? I'm guessing this is just a quirk of how Minecraft generates worlds rather than a mod-specific problem.
Yeah, it just seems to be an issue of how minecraft handles world generation with increase water levels. It's changing nothing more than an integer value in the algorithm from 64 to whatever is in the settings file. So nothing in the realm of mystical coding going on there.
Quote from dahud »
I don't know if you can really explain this in words I can understand, but just what are the Volatility variables governing? It looks like the correspond to general weirdness, but I can't imagine how one would code for that.
Believe me, I've racked my brain over trying to figure out a good way to actually describe/figure out what those variables do. "Volatility" was the best term I could come up with (also see the same thing with the new "Fracture" settings) for what they did observationally. The algorithm is painful to try and understand in terms of what any one variable does to it. In the parent algorithm for terrain there is no less than 20 (4 hard-coded and the rest variable of different inputs) different variables, 8 two-dimensional arrays, and 5 calls to other functions (each with 10 variable and hard-coded inputs) in a different class. These function calls all call the same function, but in this function is a few more variable and hard-coded values and a function call to another class with 30 to 40 variables.
The "volatility" settings are modifications to a hard-coded value that is applied to near "end state" arrays of values that ultimately determine the terrain. I could have modified a number of different variables in a number of places and got similar results in the end. The new "fracture" settings modify large, hard-coded values that feed into the start of the algorithm and affect the entire behavior of it (as opposed to the "volatility" settings affecting the result of the algorithm).
I really need to sit down and try to dive more deeply into the algorithm to see if I can find more "fine tuned" variables that can be changed to get better controlled results. But dealing with an algorithm like this can get frustrating at times :tongue.gif:
Quote from LINKed_up »
I have a question regarding this. Would it be possible to, instead of adding an additional 128 blocks on top of everything, add 64 blocks below and 64 blocks above? I mean, I guess that would be the same as adding 128 more blocks on top and shifting the water level and such up to 127 instead of 64, but I digress. I would want this more than 64 blocks of cave/underground and 192 blocks of air space because then the caves could get super awesome and the terrain above would also have room to get better.
With how it's written, it would be much easier to just add to the top. Trying to modify the height limit in a way that makes it functionally usable is a mammoth undertaking. Every time I get in the mood to poke at it I end up spending a good bit of time making little to no headway. I can make a change here and a change there and see some minor results, but I usually get overwhelmed by the magnitude and revert my code and move on to something else. I got enough on my plate as it is that I'm really not considering alterations to the height limit a high priority at the moment.
Quote from Alluvian_Est-Endrati »
Encountered an error with setting lower than default values for WaterLevel. It is possible to set a value of 63 or 62 and a new world will generate correctly, but for any value less than 62 the client will begin the world building process but never truly finish. All you will see in the client window screen is the brown dirt background, no text or loading bar will appear to indicate any kind of progress.
A World directory does get generated by this process (but no level.dat file) and if left to run for a minute or more the size of the directory continues to grow as whatever process continues to run. Quickly got to a 25meg+ directory size trying to see if the process would complete before deciding to terminate.
I have tried a number of WaterLevel values between 62 and 1, but not all of them to see if this occurs on every iteration.
I've never noticed a problem and had value between 30ish and 100ish in testing and everything worked fine. There seem to be enough people having issues with water levels that I'll look into it and see if there's anything obvious that may be causing the problem.
Quote from LordNewt »
I don't know this for sure but I can make a few assumptions and guess at it:
Notch has mentioned before that he uses a perlin noise function to do the terrain generation. How this basically works is that you generate several random noise patterns with varying levels of noise like this:
High randomization, low max/min noise level
medium randomization, medium max/min noise level
Low randomization, high max/min noise level
You then combine these noise maps into a single map that creates what looks like a natural landscape.
My guess is that the volitility settings are for the max/min noise level and the allowed difference between local data points.
You'd be correct from what the code looks like. There's a total of five noise maps. Two are used for handling some decision making with some variable values, two hold the values for the landscape itself, and one is used for making a decision between using one or the other or some combination of the two for the two mappings that hold the landscape values. The two that hold values for the landscape have identical inputs so other than randomization in the noise algorithm itself, they are identical. The values in the mappings for the landscape are each divided by 512 and the "volatility" values act as multipliers to the map values before they are divided. Basically it's
For some reason, when i start minecraft my screen just goes black and crashes. This has happened for a lot of mods I've tried.
You are using the desktop version and not the web version right? Also, you are using the latest version of the game; 1.2.2?
Quote from mctucker »
Nice mod! Is there support for Linux?
I would imagine this will work in linux as I wouldn't think that the jar/classes are any different from OS to OS. The steps to edit the jar are just different. I'm sure they are listed on the forum in a number of places.
A primary fracture (horizontal) of 1 ensures you can still build things with relative ease, as does the primary volatility of 0.0. The secondary fracture (vertical) of 50 gives you the floating islands, along with the increase in max height of 0.5. The height increase also ensures that you have a decent head of building space above you when on most large floating land masses. If you want slightly smaller islands, increase the primary fracture a little.
Also of note is that I have several of the settings on that change the appearance as such (like biome trees) as well as Cadde's ore distribution. I'm certain a little tweaking of the ore distribution could even make the islands viable for mining.
BiomeSize:5
MoistureMin:0.0
MoistureMax:0.444
TemperatureMin:0.905
TemperatureMax:1.0
WaterLevel:64
AverageHeightMax:10
AverageDepthMax:30
VolatilityPrimary:0.0
VolatilitySecondary:0.0
VolatilityPrimaryWeight:0.5
VolatilitySecondaryWeight:0.45
BiomeTrees:true
TreeDensityGlobal:0
TreeDensityRainForest:5
TreeDensitySwampland:0
TreeDensitySeasonalForest:2
TreeDensityForest:5
TreeDensitySavanna:-2
TreeDensityShrubland:-1
TreeDensityTaiga:5
TreeDensityDesert:20
TreeDensityPlains:-20
TreeDensityTundra:-20
WaterlessDeserts:true
DesertDirt:true
DesertDirtFrequency:1
FlatBedrock:false
GuaranteedBedrock:true
AlternateOreDistribution:true
UndergroundLakes:true
I played around with a few things last night and managed to get the game to populate the are between 128 and 255 with blocks. Problem was it was extremely bugged out (indivisible blocks that seemed to be stack inside each other). So it is very possible to populate beyond the limit of 128, it's just going to take a lot of work to figure out all the other bugs that is causes.
I also messed around with trying to make reliable floating islands that aren't connected to the ground. No luck on that front yet, but I did manage to create the equivalent to massive cave systems.
Also, the height at which diamond and redstone appear can be easily altered. I may add that in as an option.
I can probably implement no dirt/gravel underground. I'll look at adding that for the next update.
I really do wish MC had options like this built in by default (like Civ). Seems to make more sense to let users alter landscapes how they want rather than sticking them with the same, average landscapes all the time. I mean who doesn't like massive landforms, giant gaves, floating islands, etc... :tongue.gif:
In your to do list, I see you want to investigate cave mods. What plans do you have for them? And have this investigation started?
I`ve been asking around for a few days about a cave density mod. Just beacause I want less caves in my worlds :smile.gif: Are your plans for the caves anything in this direction, where we can play with the density of caves?
Your doing awesomely :smile.gif: Dont stop..
I plan to mess with whatever there is to mess with :tongue.gif: That should include, among other things, cave density and size. Unfortunately, no, I've not really gotten started in on caves. I wish I had more time to dedicate toward this, but such is life.
Ah, see, that's what I thought at first too, but I noticed if I left it a few minutes, the world would generate. It's just a huge world file. Did you notice this moving the water level down too, or just up?
I have a question regarding this. Would it be possible to, instead of adding an additional 128 blocks on top of everything, add 64 blocks below and 64 blocks above? I mean, I guess that would be the same as adding 128 more blocks on top and shifting the water level and such up to 127 instead of 64, but I digress. I would want this more than 64 blocks of cave/underground and 192 blocks of air space because then the caves could get super awesome and the terrain above would also have room to get better.
A World directory does get generated by this process (but no level.dat file) and if left to run for a minute or more the size of the directory continues to grow as whatever process continues to run. Quickly got to a 25meg+ directory size trying to see if the process would complete before deciding to terminate.
I have tried a number of WaterLevel values between 62 and 1, but not all of them to see if this occurs on every iteration.
I don't know this for sure but I can make a few assumptions and guess at it:
Notch has mentioned before that he uses a perlin noise function to do the terrain generation. How this basically works is that you generate several random noise patterns with varying levels of noise like this:
High randomization, low max/min noise level
medium randomization, medium max/min noise level
Low randomization, high max/min noise level
You then combine these noise maps into a single map that creates what looks like a natural landscape.
My guess is that the volitility settings are for the max/min noise level and the allowed difference between local data points.
Added:
- convert surface dirt/grass to sand for desert biomes
- muddy swamps
- muddy swamp size
- convert bedrock to obsidian
- landscape fracturing parameters (additional modification to the terrain algorithm)
- replaced Cadde's alternate ore distribution with an equivalent implementation that allows the use to set the ore deposit parameters
Check the OP for details on these changes/additions.
I've found the cave algorithm (I think anyways :tongue.gif:) and pulled it and included it in the latest version of the mod, but not made any changes to it. I'll try looking at it this afternoon/tonight instead of working on trees (yeah I keep putting those off, sorry!)
Yeah, it just seems to be an issue of how minecraft handles world generation with increase water levels. It's changing nothing more than an integer value in the algorithm from 64 to whatever is in the settings file. So nothing in the realm of mystical coding going on there.
Believe me, I've racked my brain over trying to figure out a good way to actually describe/figure out what those variables do. "Volatility" was the best term I could come up with (also see the same thing with the new "Fracture" settings) for what they did observationally. The algorithm is painful to try and understand in terms of what any one variable does to it. In the parent algorithm for terrain there is no less than 20 (4 hard-coded and the rest variable of different inputs) different variables, 8 two-dimensional arrays, and 5 calls to other functions (each with 10 variable and hard-coded inputs) in a different class. These function calls all call the same function, but in this function is a few more variable and hard-coded values and a function call to another class with 30 to 40 variables.
The "volatility" settings are modifications to a hard-coded value that is applied to near "end state" arrays of values that ultimately determine the terrain. I could have modified a number of different variables in a number of places and got similar results in the end. The new "fracture" settings modify large, hard-coded values that feed into the start of the algorithm and affect the entire behavior of it (as opposed to the "volatility" settings affecting the result of the algorithm).
I really need to sit down and try to dive more deeply into the algorithm to see if I can find more "fine tuned" variables that can be changed to get better controlled results. But dealing with an algorithm like this can get frustrating at times :tongue.gif:
With how it's written, it would be much easier to just add to the top. Trying to modify the height limit in a way that makes it functionally usable is a mammoth undertaking. Every time I get in the mood to poke at it I end up spending a good bit of time making little to no headway. I can make a change here and a change there and see some minor results, but I usually get overwhelmed by the magnitude and revert my code and move on to something else. I got enough on my plate as it is that I'm really not considering alterations to the height limit a high priority at the moment.
I've never noticed a problem and had value between 30ish and 100ish in testing and everything worked fine. There seem to be enough people having issues with water levels that I'll look into it and see if there's anything obvious that may be causing the problem.
You'd be correct from what the code looks like. There's a total of five noise maps. Two are used for handling some decision making with some variable values, two hold the values for the landscape itself, and one is used for making a decision between using one or the other or some combination of the two for the two mappings that hold the landscape values. The two that hold values for the landscape have identical inputs so other than randomization in the noise algorithm itself, they are identical. The values in the mappings for the landscape are each divided by 512 and the "volatility" values act as multipliers to the map values before they are divided. Basically it's
From the OP in the section explaining these settings:
So yes, it's intentional. It lets people implement up to four variations of each ore deposit type if they want to.
You are using the desktop version and not the web version right? Also, you are using the latest version of the game; 1.2.2?
I would imagine this will work in linux as I wouldn't think that the jar/classes are any different from OS to OS. The steps to edit the jar are just different. I'm sure they are listed on the forum in a number of places.
Settings for practical floating islands:
AverageHeightMax:0.5
AverageDepthMax:0.5
LandscapeFracturePrimary:1.0
LandscapeFractureSecondary:50.0
VolatilityPrimary:0.0
VolatilitySecondary:0.75
VolatilityPrimaryWeight:0.5
VolatilitySecondaryWeight:0.45
A primary fracture (horizontal) of 1 ensures you can still build things with relative ease, as does the primary volatility of 0.0. The secondary fracture (vertical) of 50 gives you the floating islands, along with the increase in max height of 0.5. The height increase also ensures that you have a decent head of building space above you when on most large floating land masses. If you want slightly smaller islands, increase the primary fracture a little.
Also of note is that I have several of the settings on that change the appearance as such (like biome trees) as well as Cadde's ore distribution. I'm certain a little tweaking of the ore distribution could even make the islands viable for mining.