[WIP] Undergrowth [GitHub]

[Evergreen]

Added the stalactites pebbles and stuff to my fork on github.

[Neuromancer]

Added fork with bushes mod to undergrowth repository on github. Also asked for a pull request for Mossmanikin to pull my changes into the main repository. It said there were no conflicts.

I think that's what we need to do for MM to incorporate our requests into his main undergrowth repository, create pull requests. Do you guys agree? I'm not sure MM needs to create his own branches or forks, but that when we create pull requests he needs to pull them into the main repository. I think he also needs to merge his forestsoils branch into the main repository and that will also get the modpack.txt into the root undergrowth folder.

Thinking about this, I remembered the basic rule of source control, you should only branch if absolutely necessary. I'm thinking MM branched by mistake, and should have just put forestsoils int the main undergrowth repository. The reason you might want to branch is if you have a main production version that you don't want to break, and you branch to create a dev version where you are making changes that will break stuff. Then when you are done with development, you can merge that branch back into the main trunk. I'm not even sure it was best for EG and myself to create forks. It might have been better if we could just contribute directly to the main repository, although this does give MM control to prevent us from making changes he doesn't want into the modpack which is fine.

But that control makes extra work for all of us, because now we have to create pull requests and wait for MM's approval for everything (and he has to do the approvals). That can mean instead of EG or me quickly syncing a bug fix, things can get out of sync before MM approves them, and merging our changes could get more difficult. I think adding us as contributors will just be easier and faster for everyone. If we check in something we shouldn't, MM can always rollback our changes.

If you agree to add us as contributors, just go to the main repository on the github website, click on settings and collaborators and add Neuromancer56 and 4Evergreen4 as friends.

[Mossmanikin]

Added fork with bushes mod to undergrowth repository on github. Also asked for a pull request for Mossmanikin to pull my changes into the main repository. It said there were no conflicts.

I think that's what we need to do for MM to incorporate our requests into his main undergrowth repository, create pull requests. Do you guys agree? I'm not sure MM needs to create his own branches or forks, but that when we create pull requests he needs to pull them into the main repository. I think he also needs to merge his forestsoils branch into the main repository and that will also get the modpack.txt into the root undergrowth folder.

Thinking about this, I remembered the basic rule of source control, you should only branch if absolutely necessary. I'm thinking MM branched by mistake, and should have just put forestsoils int the main undergrowth repository. The reason you might want to branch is if you have a main production version that you don't want to break, and you branch to create a dev version where you are making changes that will break stuff. Then when you are done with development, you can merge that branch back into the main trunk. I'm not even sure it was best for EG and myself to create forks. It might have been better if we could just contribute directly to the main repository, although this does give MM control to prevent us from making changes he doesn't want into the modpack which is fine.

But that control makes extra work for all of us, because now we have to create pull requests and wait for MM's approval for everything (and he has to do the approvals). That can mean instead of EG or me quickly syncing a bug fix, things can get out of sync before MM approves them, and merging our changes could get more difficult. I think adding us as contributors will just be easier and faster for everyone. If we check in something we shouldn't, MM can always rollback our changes.

If you agree to add us as contributors, just go to the main repository on the github website, click on settings and collaborators and add Neuromancer56 and 4Evergreen4 as friends.

Yeah, you're right: accidently created a branch instead of fork.

I don't need to have control over the project. I just happen to be the guy who created the topic and an empty repository. ;)

Added both of you as collaborators.

I'd say if we create something new we just add it, if we make changes to someone else's code/textures we fork.

[Evergreen]

Added fork with bushes mod to undergrowth repository on github. Also asked for a pull request for Mossmanikin to pull my changes into the main repository. It said there were no conflicts.

I think that's what we need to do for MM to incorporate our requests into his main undergrowth repository, create pull requests. Do you guys agree? I'm not sure MM needs to create his own branches or forks, but that when we create pull requests he needs to pull them into the main repository. I think he also needs to merge his forestsoils branch into the main repository and that will also get the modpack.txt into the root undergrowth folder.

Thinking about this, I remembered the basic rule of source control, you should only branch if absolutely necessary. I'm thinking MM branched by mistake, and should have just put forestsoils int the main undergrowth repository. The reason you might want to branch is if you have a main production version that you don't want to break, and you branch to create a dev version where you are making changes that will break stuff. Then when you are done with development, you can merge that branch back into the main trunk. I'm not even sure it was best for EG and myself to create forks. It might have been better if we could just contribute directly to the main repository, although this does give MM control to prevent us from making changes he doesn't want into the modpack which is fine.

But that control makes extra work for all of us, because now we have to create pull requests and wait for MM's approval for everything (and he has to do the approvals). That can mean instead of EG or me quickly syncing a bug fix, things can get out of sync before MM approves them, and merging our changes could get more difficult. I think adding us as contributors will just be easier and faster for everyone. If we check in something we shouldn't, MM can always rollback our changes.

If you agree to add us as contributors, just go to the main repository on the github website, click on settings and collaborators and add Neuromancer56 and 4Evergreen4 as friends.

Yeah, you're right: accidently created a branch instead of fork.

I don't need to have control over the project. I just happen to be the guy who created the topic and an empty repository. ;)

Added both of you as collaborators.

I'd say if we create something new we just add it, if we make changes to someone else's code/textures we fork.

I think that would be a good idea. I'll go ahead and delete my fork and work from the repository on your account.

[Mossmanikin]

I think that would be a good idea. I'll go ahead and delete my fork and work from the repository on your account.

I took the freedom to merge all forks and branches

[Evergreen]

I think that would be a good idea. I'll go ahead and delete my fork and work from the repository on your account.

I took the freedom to merge all forks and branches

Would you be okay if I went ahead and changed the name of license.txt to "LICENSE.txt" and changed the license to CC-BY 3.0? If so, what should I put about it in LICENSE.txt?

[Mossmanikin]

Would you be okay if I went ahead and changed the name of license.txt to "LICENSE.txt" and changed the license to CC-BY 3.0?

Sure.

If so, what should I put about it in LICENSE.txt?

Something like "everything CC-BY 3.0" and the links to human readable and full license, maybe...

EDIT: the "maybe" is because I'm no expert on licenses.

[VanessaE]

It's usually recommended that you include a full copy of the "legal code". For CC-By-SA 3.0, it's here: http://creativecommons.org/licenses/by-sa/3.0/us/legalcode

Just copy&paste that into your LICENSE.txt and put something at the top declaring that the whole thing, code and textures, is under that license.

[jojoa1997]

Hasn't this been enough posts to put a download up

[Chinchow]

Maybe they want the mod to be quality when they release it and not half done

[jojoa1997]

Seems more like license discussion since when I started following

[Evergreen]

Seems more like license discussion since when I started following

The license has already been made.

[Mossmanikin]

Hasn't this been enough posts to put a download up

If you wanna do some alpha testing: look for the github link ;)

Maybe they want the mod to be quality when they release it and not half done

Exaxtly! :)

It's usually recommended that you include a full copy of the "legal code". For CC-By-SA 3.0, it's here: http://creativecommons.org/licenses/by-sa/3.0/us/legalcode

Just copy&paste that into your LICENSE.txt and put something at the top declaring that the whole thing, code and textures, is under that license.

Thanks, guess we'll do that. :)

[Neuromancer]

This modpack already rocks! I just tested it out and was impressed. I improved the variety of the bushes a little and tried to sync my commit, but my firewall/anti virus went crazy (it hates github). So I disabled it, but it still will not let me sync anything to this project. I did commit it to my own version of the bushes mod here and that worked.

https://github.com/Neuromancer56/bushes

[Mossmanikin]

it still will not let me sync anything to this project

Very strange. Maybe it's because you use the name Neuromancer1 as well as Neuromancer56?
Added both names to the list of collaborators, hope it works now.

In case it doesn't work I'll gladly add the changes for you.

[Neuromancer]

it still will not let me sync anything to this project

Very strange. Maybe it's because you use the name Neuromancer1 as well as Neuromancer56?
Added both names to the list of collaborators, hope it works now.

In case it doesn't work I'll gladly add the changes for you.

That is strange. I thought maybe I would need to use the command line. So I went to the command line and entered the command "git push" logged in as Neuromancer56. And the push to your repository worked this time, but it pushed as Neuromancer1. Funny thing, I had forgotten I even had a Neuromancer1 account. I have been using Neuromancer56 for everything for ages. So I'm not sure why it thinks it should be using that account when I'm logged in as Neuromancer56. You might as well leave both accounts as contributors since I'm not sure when it will use either account.

Some random thoughts:
I love the look of the forest soils, but I'm confused as to why you put it near rocks/pebbles instead of just under trees. It's not a bad thing, I kind of like encountering bare earth in random places. Also it looks like there may be a lot of trees where there is no forest soil. Which is ok, because single trees will not always have forest soil, but dense forests should have a lot of forest soil.

Why do we call them pebbles when pebbles are supposed to be the size of a pea? These things look like large rocks to me. I have to admit, I was skeptical about rocks at first, because they were complex node boxes and I thought they would hurt performance, but I love it when I run into them in the game. I get excited for some reason, they just look so cool and like they belong in the Minetest world.

[VanessaE]

I took a brief look at the code for the forest soils - the reason plants_lib seems to be too slow is things like this:

https://github.com/Mossmanikin/undergrowth/blob/master/forestsoils/generating.lua#L58

Note here how you set max_count to 6400, but then rarity to 1 and practically no biome controls at all. So basically you're telling plants_lib to execute your dry-leaves-placement function for every single surface node in the chunk, which is probably not what you wanted. :-)

What you need to do, aside from controlling for temperature, humidity, and other biome factors, is control for nearness to trees, using the near-nodes parameters:

near_nodes = {table}, -- what nodes must be in the general vicinity of the object being spawned.
near_nodes_size = num, -- how wide of a search area to look for the nodes in that list.
near_nodes_vertical = num, -- How high/low of an area to search from the target node.
near_nodes_count = num, -- at least this many of those nodes must be in the area.

Use that to check for the presence of tree trunks. You'll probably want near_nodes_size of about 4 or 5, a vertical of 1, and a count of 1. This will reduce it to a few hundred calls per chunk instead of several thousand.

Further, if you were to instead trigger on tree trunks instead of the ground, and set your near node to dirt with grass (with a _size of 1 and a vertical of 1), and then make your code handle the entire zone around the tree, you can execute your code exactly once per tree instead of once per surrounding node.

It's been a while since I've had to read my own API and code ;-) so I'm not 100% sure if this will work, but try it anyway. Do check the API thoroughly - there are a lot of features in there that will, when used properly, help trim down how many nodes (or function calls) have to be processed.

[Neuromancer]

@MM: I'd like to see more forest soils, especially under trees. Is it possible to do that using Vannessa's suggestions for faster generation?

[Mossmanikin]

I'm confused as to why you put it near rocks/pebbles instead of just under trees.

Actually I wanted it to generate below bushes, didn't work, so I tested how it would look below rocks. Doesn't make a lot of sense, but it adds some depth and variation.

single trees will not always have forest soil, but dense forests should have a lot of forest soil

Tried to define a dense forest by checking for tree nodes (4) within a radius (used to be 3, now 4). Looks good in a jungle, not really with normal trees.
Trees which use plants_lib are ignored (tiny trees, your bushes...).
Far too often forest soil becomes grass again while a block is generated (don't ask me why).

I took a brief look at the code for the forest soils - the reason plants_lib seems to be too slow is things like this:

https://github.com/Mossmanikin/undergrowth/blob/master/forestsoils/generating.lua#L58

Note here how you set max_count to 6400, but then rarity to 1 and practically no biome controls at all. So basically you're telling plants_lib to execute your dry-leaves-placement function for every single surface node in the chunk, which is probably not what you wanted. :-)

What you need to do, aside from controlling for temperature, humidity, and other biome factors, is control for nearness to trees, using the near-nodes parameters:

near_nodes = {table}, -- what nodes must be in the general vicinity of the object being spawned.
near_nodes_size = num, -- how wide of a search area to look for the nodes in that list.
near_nodes_vertical = num, -- How high/low of an area to search from the target node.
near_nodes_count = num, -- at least this many of those nodes must be in the area.

Use that to check for the presence of tree trunks. You'll probably want near_nodes_size of about 4 or 5, a vertical of 1, and a count of 1. This will reduce it to a few hundred calls per chunk instead of several thousand.

Further, if you were to instead trigger on tree trunks instead of the ground, and set your near node to dirt with grass (with a _size of 1 and a vertical of 1), and then make your code handle the entire zone around the tree, you can execute your code exactly once per tree instead of once per surrounding node.

It's been a while since I've had to read my own API and code ;-) so I'm not 100% sure if this will work, but try it anyway. Do check the API thoroughly - there are a lot of features in there that will, when used properly, help trim down how many nodes (or function calls) have to be processed.

Thanks for looking at the code and giving tips. :)
Yeah I'm working with extremes there... I'm still struggling with the settings to guarantee smooth transition.

@MM: I'd like to see more forest soils, especially under trees. Is it possible to do that using Vannessa's suggestions for faster generation?

Didn't have a lot of time the last couple of days. I'm not very satisfied with how it works atm. Guess I'll make a backup and try a different way, using Vanessa's suggestions.

[Evergreen]

I'm confused as to why you put it near rocks/pebbles instead of just under trees.

Actually I wanted it to generate below bushes, didn't work, so I tested how it would look below rocks. Doesn't make a lot of sense, but it adds some depth and variation.

single trees will not always have forest soil, but dense forests should have a lot of forest soil

Tried to define a dense forest by checking for tree nodes (4) within a radius (used to be 3, now 4). Looks good in a jungle, not really with normal trees.
Trees which use plants_lib are ignored (tiny trees, your bushes...).
Far too often forest soil becomes grass again while a block is generated (don't ask me why).

I took a brief look at the code for the forest soils - the reason plants_lib seems to be too slow is things like this:

https://github.com/Mossmanikin/undergrowth/blob/master/forestsoils/generating.lua#L58

Note here how you set max_count to 6400, but then rarity to 1 and practically no biome controls at all. So basically you're telling plants_lib to execute your dry-leaves-placement function for every single surface node in the chunk, which is probably not what you wanted. :-)

What you need to do, aside from controlling for temperature, humidity, and other biome factors, is control for nearness to trees, using the near-nodes parameters:

near_nodes = {table}, -- what nodes must be in the general vicinity of the object being spawned.
near_nodes_size = num, -- how wide of a search area to look for the nodes in that list.
near_nodes_vertical = num, -- How high/low of an area to search from the target node.
near_nodes_count = num, -- at least this many of those nodes must be in the area.

Use that to check for the presence of tree trunks. You'll probably want near_nodes_size of about 4 or 5, a vertical of 1, and a count of 1. This will reduce it to a few hundred calls per chunk instead of several thousand.

Further, if you were to instead trigger on tree trunks instead of the ground, and set your near node to dirt with grass (with a _size of 1 and a vertical of 1), and then make your code handle the entire zone around the tree, you can execute your code exactly once per tree instead of once per surrounding node.

It's been a while since I've had to read my own API and code ;-) so I'm not 100% sure if this will work, but try it anyway. Do check the API thoroughly - there are a lot of features in there that will, when used properly, help trim down how many nodes (or function calls) have to be processed.

Thanks for looking at the code and giving tips. :)
Yeah I'm working with extremes there... I'm still struggling with the settings to guarantee smooth transition.

@MM: I'd like to see more forest soils, especially under trees. Is it possible to do that using Vannessa's suggestions for faster generation?

Didn't have a lot of time the last couple of days. I'm not very satisfied with how it works atm. Guess I'll make a backup and try a different way, using Vanessa's suggestions.

Another idea I had was a transition between grass and desert sand. I was going to do it, but I was waiting until you optimized your code.

[Mossmanikin]

Another idea I had was a transition between grass and desert sand. I was going to do it, but I was waiting until you optimized your code.

Sounds like a good idea.
Changed a lot of the code, the result looks better, not sure if it's still too slow.

[Neuromancer]

Another idea I had was a transition between grass and desert sand. I was going to do it, but I was waiting until you optimized your code.

Sounds like a good idea.
Changed a lot of the code, the result looks better, not sure if it's still too slow.

You're killing me! I installed the latest version of this mod in the Immersive Fun game. I was stunned by the beauty of it. You could really feel the impact that the trees have on the land, throwing leaves everywhere, choking out the grass, fallen logs. Simply amazing. But then there were real bad performance issues. Even on my best machine falling down to 1 fps and not being able to move. I had to look at the ground to get my fps over 1 so I could start moving again. It's like you have achieved perfection, but I'm not sure what to remove from the game to improve the FPS. I can't get rid of any of it. I love it all. And yet I can't play the game like this. :(

[Mossmanikin]

You're killing me! I installed the latest version of this mod in the Immersive Fun game. I was stunned by the beauty of it. You could really feel the impact that the trees have on the land, throwing leaves everywhere, choking out the grass, fallen logs. Simply amazing. But then there were real bad performance issues. Even on my best machine falling down to 1 fps and not being able to move. I had to look at the ground to get my fps over 1 so I could start moving again. It's like you have achieved perfection, but I'm not sure what to remove from the game to improve the FPS. I can't get rid of any of it. I love it all. And yet I can't play the game like this. :(

Please don't die! :D

Glad you like the look, I'm quite satisfied with it too.
Guess I'll have to check the code (of ferns and dryplants too) if there's something unnecessary.

In the meantime you could already make some changes in SeTTiNGS.txt in ferns mod folder:

Your phone or window isn't wide enough to display the code box. If it's a phone, try rotating it to landscape mode.

Code: Select all

Ferns_near_Ores = true --> false
Ferns_in_Groups = false --> true

Horsetails_Spawning = true --> false -- (doesn't change ongen)


and if you like to experiment in settings.txt in dryplants mod folder:

Your phone or window isn't wide enough to display the code box. If it's a phone, try rotating it to landscape mode.

Code: Select all

*_PER_MAPBLOCK = higher_value --> lower_value
*_RARITY = higher_value --> lower_value


[Neuromancer]

All of these fallen logs make me think of mosses, mushrooms and the fungus that would consume them. It would be fun to have a mushroom mod with some poisonous and some healthy to eat. I'm looking at this Mod
https://forum.minetest.net/viewtopic.php?id=2619 But I don't think it fits what I'm looking for.

[VanessaE]

I just cloned and tried out the latest code and this is looking really REALLY nice. No performance issues whatsoever for me.

I notice you support moretrees (at least for tree stumps and fallen logs), wonderful!

A suggestion: moretrees spawns special fast-growing saplings at mapgen time by default, all of which have names of the form, moretrees:xxxxx_sapling_ongen. You should match on those also, to get the under-the-tree leaves/grass mixtures that show up elsewhere.

[Mossmanikin]

All of these fallen logs make me think of mosses, mushrooms and the fungus that would consume them. It would be fun to have a mushroom mod with some poisonous and some healthy to eat. I'm looking at this Mod
https://forum.minetest.net/viewtopic.php?id=2619 But I don't think it fits what I'm looking for.

Yesterday, while remembering one of your earlier posts and looking at some pictures of forests, I thought mosses would be really nice to have.
Mushrooms would also be cool, yes.
Will take a closer look at mods with mushrooms and mosses the following days to see if a new mod is needed or if support for (an)other mod(s) makes more sense.
Bas080's plants mod has some beautiful textures, unfortunately it's a bit slow on my machine.

I just cloned and tried out the latest code and this is looking really REALLY nice. No performance issues whatsoever for me.

I notice you support moretrees (at least for tree stumps and fallen logs), wonderful!

A suggestion: moretrees spawns special fast-growing saplings at mapgen time by default, all of which have names of the form, moretrees:xxxxx_sapling_ongen. You should match on those also, to get the under-the-tree leaves/grass mixtures that show up elsewhere.

Thanks for your feedback. :)
I'm glad you like it and that it works for you.

Very good idea to trigger on those saplings. Will do that.

[Neuromancer]

As much as I try to avoid nodeboxes, I'm starting to come around to the idea that that it might be a good idea to use them for the branches of the bushes, and for putting sticks on the ground. When you go into a woods, sure there are a few fallen logs laying around, but there are fallen branches and sticks everywhere laying on the ground. Most of the sticks are just straight simple sticks. If we wrapped them with all the moretrees textures they would look really nice.

[Neuromancer]

The following thoughts ran occured to me
We could take your tiny tree trunks from the fern mod and wrapped them in all the moretrees textures to come up with a variety of sapling trunks.
Then we could orient them in the corner of the nodebox, instead of the center. That way if you rotate/orient it horizontal it will lay on the ground like a fallen sapling trunk or a fallen tree branch. Also by having the trunk in the corner, we could create branch node boxes that could branch out in any of 4 directions. These branches could be wrapped by all the moretrees textures as well, and could also serve as branches for bushes or fallen branches if oriented horizontally. Then just re-use all of the leaf styles from more trees.

That would give us a a rich and varied sapling, bush, and fallen branch mod.

[Mossmanikin]

@Neuromancer:

Some great ideas. I'm experimenting with small twigs atm.

[Evergreen]

Idea: Once I finish the cavestuff, I'll start working on "beach". ;)