Sedimentology
Project Moved to Minetest
I am ceasing all Bukkit-related development, and instead focusing on a 100% GPL Voxel game called Minetest. I have ported this plugin over to Minetest, and encourage everyone to switch with me.
This project is *not* dead (on the contrary) but there will be no new releases for Bukkit or any minecraft server mod. No permissions to take over or maintain the current project page on dev.bukkit.org are granted.
For more information, Visit the Minetest Mod releases Forum.
Cheers,
s0f4r.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Quick links: <Concepts> <Configuration> <Screenshots> <Bugs>
Sedimentology
a bukkit plugin that simulates erosion and sedimentation
Description
This plugin attempts to create processes that are involved in the transport and deposition of sediments:
- water picking up material
- transportation down slopes
- weather influence
- material falling down cliffs
- material decaying/degrading into smaller grained materials
- creating thicker piles of snow, and thawing snow
The plugin doesn't properly recreate real geologic processes, instead it mimics the bahavior of erosion and deposition by rolling a dice for most of the factors involved, and if the roll was succesful, proceed to the next step.
Material hardness and resistance are taken into account - some materials are easier displaced than others. Some materials degrade easier than others. Some materials (sand) have a different angle of repose.
This plugin isn't meant to enhance game play per se, it will operate slowly over time and vegetation will prevent most of it's effects from taking a toll on the landscape in most cases, so it will take a long time in default settings from actually doing anything noticeable. Because dirt naturally gets a grass cover in Minecraft it will be unlikely that this plugin does significant damage to your world. Of course, planting stuff is still advisable if you want to reduce the effects of the plugin further.
From version 8 on and higher, this plugin will create thicker piles of snow, potentially up to several blocks high. Snow accumulation and melt are based on various factors and will create thick snow covers on mountain tops, and thin covers near snow edges or lower down. Daylight and sunshine cause snow melt, and the plugin can even remove all snow cover entirely over time if the parameters are right.
Do you like a more dynamic world? Please check out my Botany plugin too!
Screenshots
Please have a look at the screenshots page here.
Concepts
Please have a look at the in-depth Concepts of Sedimentology page here for more information on the concepts of this plugin.
Configuration
Please have a look at the Configuration page for console commands and configuration options.
Factions / Towny / WorldGuard
These plugins provide ways to protect blocks from being modified, and Sedimentology can interface with them to see if blocks are part of a Faction claim, Towny town, Residence claim etc. If the protection feature is enabled in the config.yml file, and one or more of these plugins are loaded, then Sedimentology will not modify blocks in any region that these plugins have on file. Snow buildup, however, will still take place everywhere, since it's a reversible process that is not destructive.
The testing that I do for these plugins is limited - please report any issues in the bug tracker on github.
Tested are these versions:
- Factions 1.6.9.5
- Factions 2.3.0 with mcore 7.0.1
- Towny 0.84.0.9
- WorldGuard 5.8
Bugs / Code
The project code is hosted on my github page: https:github.com/sofar/Sedimentology.
Please file all bugs and feature requests here: github.com/sofar/Sedimentology/issues/new
Due to the overwhelming number of requests and issues I'm receiving for this plugin I request that everyone please file all issues on the github issue tracker. You can file support requests, errors or crashes, feature requests and report problems with this plugin.
The main page thread can be used for discussion just as it is being used right now, and I have no problems with people discussion issues there, but please take the courtesy of filing an issue for problems you see so I can properly track all reported problems and do not need to scan through the many pages of comments.
For bugs, tips, donations please feel free to contact me: Auke Kok - [email protected]
@s0f4r
I did a quick test on my computer and it seemed to work great, so I've installed it on the server now and there seems to be no problems so far. How does the new snowblocks config option work by the way?
@DivinityCraft
I just uploaded v9. If you don't want to wait for bukkti staff to sanction it, you can get it from here for testing: https://github.com/sofar/Sedimentology/releases/tag/v9
@s0f4r
That's great news, I'll be happy to test it extensively for you. Build me a jar please, I can't do it myself. My dev friend finished the decay plugin by the way, I can't wait to get Sedimentology too since it can fix up whatever terrain damage and such what left behind after a ruin decays away, thus making the world completely self-cleaning. I'm excited about the new snow mechanics too.
@DivinityCraft
FYI, I've pushed some code that seems to work for 1.7.x and Factions-1.6.9.5, in a way that Factions 2.2.2 also should still be working properly. I'd like you to test it - let me know if you want me to build you a testing jar or if you can do so yourself. The code change is pushed to the git repository already, and seems to work for me with 1.6.9.5.
@DivinityCraft
BTW if it's wasn't clear - yes that's the source code development repository - and I'll gladly accept pull requests and patches - and I'll even post releases if someone figures this out for me. I don't know java that well to see if I can handle multiple conflicting API's at the same time... Patches welcome!
@DivinityCraft
yes - I'm not saying that it will be hard to port Sedimentology to the old factions API, but I'm not feeling like maintaining a separate branch and doing all the merging needed to maintain that branch.
Frankly, I wish that block protection plugins would export some common interface so we didn't have this mess of having to code the same thing multiple times in order to work with Towny, Factions, WorldGuard etc... let alone multiple API versions of each... It is a nightmare.
@s0f4r
I've got a dev making the decay plugin we talked about earlier and it will be for old factions, if you're fine with it I could ask him to do it. I'm myself no programmer, is the source code here? https://github.com/sofar/Sedimentology
@DivinityCraft
Not compatible, at all. Sorry.
The Factions API changed dramatically between 1.6.9.5 and later versions - enough to make it so that you can't have one version of Sedimentology support both 1.6 and current versions. I'm not inclined to maintain branches for this project at this time, so this isn't going to happen unless someone is interested enough to code this up and push a branch.
Is it compatible with Factions 1.6.9.5 (the last version to not need mcore)? If not we would appreciate a lot if support was added for it. Why use an old version of Factions you may ask. It offers vastly superior reliability, ease of use and retains many features that were removed in newer versions like faction chat, and has no dependencies. The new Factions has broken with every major patch, but the 1.6 series keeps working flawlessly so many servers still use it.
@pilvimaa
Not intentionally - this was a bug in earlier releases where chiseled sandstone and smooth sandstone would degrade into gravel, dirt and sand and the data value would not be set to 0, but it was fixed before version 8.
It's still possible that your world had gravel or dirt created by previous versions with the bug, but I haven't seen this happen since.
Also note that sand (id 12) is either normal sand (data 0) or red sand (data 1). You can test this with e.g. worldedit: set 12:1
I noticed that I have sand in my world that has different meta datas. Is this how you keep track of it's wear? It will not stack of course with other sand of different metadata value. I don't know whether or not it will affect crafting. Probably not.
Perhaps you should mention this detail in the documentation (if it's caused by Sedimentology?) as in some situations it might affect possible custom blocks. But it's probably very unlikely that many servers would have blocks like that.
Now that I'm writing about it ... it's actually a pretty sweet idea ... could add some custom random generation of rock with different metadata and adjust it's hardness values ... or something like that, hm.
@DoctorCooper
You were using CB-1.6.4, which is not compatible with Sedimentology 5 and up. Please use Sedimentology-4 instead (this is listed in the release notes!).Seems that Towny broke API between 0.77 and 0.84, I'm attempting to fix this up as we speak, for now, you'll have to use Towny 0.77 or wait until the update comes out that supports the new Towny API.
@s0f4r
I keep getting errors. I'd post it here, but it's a bit too long. I'll send it to you over Skype (DoctorCoops).
@s0f4r
pvilmaa: if you're interested in at least reviewing the code (which, considering your interest, is something I think you should at this point), or even submit patches, please check out the github repo. I often push code as I write, often, and you'll be able to build your test versions of the plugin yourself as well if needed.
@pilvimaa
It's been somewhat bothering me too, which is why I added several restrictions to the code to limit sand and clay generation. Clay now basically only gets generated in oceans below sealevel, and in rivers below sealevel. For sand however, I wrote the rule to be that sand can be created if the dirt block is in a sand biome (e.g. desert or river, beach) or the block is underwater. I may just have to add an elevation check to the underwater part and reduce the chance that we create sand higher up, but below sealevel I don't see a problem with river beds becoming sand per se, that feels natural to me.
Also, underwater dirt is the most volatile block right now, so it's obvious that you will heavily notice it - the combination of chances works out that way.
FYI snow buildup bypasses protection right now. That wasn't intentional, but sure makes for a more consistent landscape ;).
I can see about putting the snow accumulator on a different runnable task, that would allow you to change the rate independently.
Also, I really, really appreciate the feedback you've put into this plugin, it's given me a lot of things to consider and prioritize, fix, and ultimately the plugin is more fun (better) because of it. :). Most, if not all of your feedback is something I want to address in one way or another - and most likely I will in time - for now I just do 1-2 things at a time and run with it to see if there are no side effects or bugs (like that time early on where my plugin would just chomp holes in the ground ;)).
There's one thing that's been bothering me a bit for a while now.
Basically even with extremely slow settings all the river beds will turn - quite fast - into 100% sand. All the dirt will become sand if it has water on it.
Is this really how it should work? It's like .. I have the settings at 1 block per 20 ticks and I pour water somewhere .. and in 24 irl hours it's basically all sand.
And all of the sand will eventually become clay and that is the end of the line? Will the surrounding blocks have effect on the outcome or will it always follow a straight line? I'm thinking about, like, forest streams with rocky/gravel bottoms where the water carries away all the small particles and sand and just leaves the rocks.
EDIT: I re-read the concepts page but dirt's degradation to sand still seems very fast in comparison to everything else I've observed. If the ratio is ok in the code then I should probably just ... turn the settings down even more .. ?
Actually I rather like the hard coded aspect of Sedimentology because you obviously know very well what you are doing and it would be easy to mess up settings for things that are as complex and interdependent as these.
And it's ok if you want to keep the snow accumulation tied to the same tick rate as erosion, I'm sure I can implement my own solution for the snow if it turns up I need more of it in the long run. I can also make my own implementation for killing the plants at snow storm. Should be simple enough, 5 minute thing.
You are doing an awesome job. Thanks!
@pilvimaa
Hi pvilmaa,
The light level has to be 12 or above before a block will melt, so at night time no snow will ever melt.
I can see about adding an elevation factor into snow melt and make the chance to thaw at higher elevations lower exponentially, which should make snow last much longer on high mountains, and is very easy to implement - I already have 2 versions of algorithms in the code like that right now.
Snow blocks will only disappear if they are on the edge of a snow field, which should slow down melting of snow patches and remove the chance that random holes appear in snow fields...
As for plants, I'll need to play around with some ideas to either stack snow on top of plants (which would remove the "holes" in snow) or otherwise destroy them (something I would not prefer right now). I'm not too worried about plants on hillsides and mountains, since ultimately erosion will cause these plants to be squashed by falling blocks - something that the plugin already does. The list of "crushable" blocks is defined in the code as pretty much all natural non-solid plant blocks (e.g. leaves, flowers, saplings, dead bush, etc, but not logs).
I realized early on that there would be some demand for "tweaks" in the plugin. All of these parameters are now pretty much hard coded - which I did because I didn't want people to deploy this relatively new plugin and start tweaking with the parameters. The complex rules that involved in some of the parts also make it prohibitive, or at least really complex, to make it configurable- for instance, how would I handle the config.yml needed to specify that dirt degrades into sand, but not in land biomes, unless it's a rover biome and it's below sealevel?. Even the hardness/resistance table is non-static and there are modifiers for the values.
At this point I prefer to keep most of the parameters hard-coded and determine better what is a good balance for the typical case - your day-night cycle change is something we can probably compensate for by tuning the thawing code better to prefer snow accumulation, which should help make snow fields look better for everyone. Needless to say that I'd prefer more feedback from other people who have deployed the plugin and are testing it....
I've been unable to reproduce the bug so far. And no podzol either as far as I can tell.
I also tried a few things with other plugins to try to achieve the buggy behaviour but nothing turned up. I am at a loss what could be causing this on my production server. I will let you know if I come up with something in the future.
Your snow melting algorithm is a beauty to watch. You have even taken the nights into account.
I would like to suggest that you'd use a different clock for the snow than you use for erosion effects (ie. just for the growing piles of snow/melting).
It's all fine with the default settings but as I've mentioned before I have longer day than usual on my server and slow growth rates so I like to set the erosion to something like 1 block at 20 ticks. But the problem is that this is too slow for the snow since it's all controlled by the same setting.
I would like to gain snow faster than it's generated with these settings (you only get extra layers of snow on a couple of blocks during a snow storm if you set erosion to a really slow setting).
I noticed something when I was testing with very fast erosion rate. When it's not snowing the mountain tops get cleared of all snow. I know this is caused by the extremely fast erosion rate but the thought occurred to me that... is there a need for permafrost at height above Y or slower melting at certain heights?
About plants and flowers: I would very much like to see a function where snow storm kills plants like flowers and grass etc. Now we get areas that are filled with snow so-high except for the blocks that have some kind of plant or grass sitting there taking up the space.
If you have any interest in implementing this then I think it should have:
- You should be able to freely enable/disable plant destruction, of course.
- A freely definable list of technical names for the things that get broken by snow. That way you could use it also with any other plugin that add new plants. Sedimentology would remain neutral as to what the block is. If it's on the list and exists -> it would get destroyed (or replaced?) by snow. If you just remove the block during the normal snow clock cycle it would be fast and easy to implement since the normal snow generation would kick in after the block is made vacant of any plants -> which in turn would activate your extra snow generation/melting algorithm.
- It should have option to enable/disable drops from the broken items, ie. when a flower gets destroyed by snow - should it drop a flower or not.
Can't think of anything else right now. That would probably suffice.
@s0f4r
I will make a clean test server on a local machine and double check but it did take a long time before anything happened. And I have one idea that might affect it that I will try out.
Another thing: I'm not sure if this got fixed with previous version when there was the trouble with block meta data, but I have been seeing podzol lately in places where it shouldn't be. Couple of blocks here and there. They might be remnants of the time before the fix but... I have not noticed them before. I suspect they may have been generated when dirt/grass falls down hill. I will try to reproduce that too when I set up the clean server but if it's not too much trouble could you check you have the above scenario covered with the fix you made earlier?
I will get back to you. There is only one other possibility that could be generating the snow but it's unlikely and I didn't mention it before since it's turned off in it's config. But I suppose it wouldn't be the first time when something disabled at config is still active... let's see how the clean server turns out.