![[ie]](/mwf/flags/ie.png "Ireland")
I added the Place() function in the plants library. Parameters are simple: int amount, proplist rectangle (Zapper committed Rectangle() yesterday or so).These two are the standard parameters (for now, see below). The whole function is basicall a wrapper for PlaceVegetation but certain plant may overload it to do custom stuff. Also more parameters may be added by plants.
Just call on any definition you want to place.
Tree_Coniferous->Place(10); (standard rectangle is the whole landscape).In addition, I made a little helper function PlaceForest (in System.ocg/Creation.c). Parameters are:
array plants, int x, int y, int widthplants is an array with plants that occur in the forest. The first value is the main plant of the forest, the others will spawn randomly within (it's not guaranteed that everything is in there though) in little groups. Start and ends of the forest will consist of smaller plants, the rest is fully grown.
x is the starting point of the forest, width the width, y is the lowest point from which to start to look for the surface.
I added PlaceForest() in Goldmine so you can have a look at it. At a matter of fact, I forgot a soil check. Will do that tomorrow ;)
Maybe a note to anyone who feels responsible for fire (Zapper?): One flint is enough to burn down the whole forest. Maybe incineration is a bit too strong?
The other reason why I opened the topic is to ask some further questions about what is wanted:
->Place() only places fully grown plants. Adding a growth parameter to it is easy, just passing that to PlaceVegetation. Wanted yes or no? Will increase the number of standard parameters for Place() (bear in mind that if you want to access some custom parameters of plants, you will always have to fill in the standard params first. Keeping these as few as possible spares some work and traps).
I had the idea of artificially confining plants to certain areas of the maps. That would be a
bool keep_area parameter for Place(), making certain that the plants and their offspring will not exceed the given rectangle. Wanted yes or no? Again adding a standard parameter. Eleutherotes noted that it's also possible to contain plants somewhere by adding "natural" borders like non soil material. Although one have to make certain that these borders are big enough so the travel distance of the offspring will not cover it.And the last thing, what about foreground trees? I always liked the mod in CR. It's an tremendously easy way of spicing things up and give one the feeling that these trees are "all around you". The downsides are of course things like covered object and so on. But hey, don't let your stuff lie around in a forest!
![[de]](/mwf/flags/de.png "Germany")
>Adding a growth parameter to it is easy, just passing that to PlaceVegetation
>That would be a bool keep_area parameter for Place()
Both sound like a good idea.
What about adding a parameter "extra_options" as the third standard parameter which is a proplist?
MyTree->Place(10, Rectangle(x, y, w, h), {growth = 50, keep_area = true}) would be the way to call it then.
The advantage of that is that it scales - you can add new standard parameters without having to change any plants that have custom parameters. Just because you can add it all to the proplist.
>And the last thing, what about foreground trees?
Mh, what about doing that only for initially placed trees? That would keep the feeling of "oh, there is a thick forest" but without having trees spawn (later) in front of your stuff. extra_options.allow_foreground? ;)
>Maybe incineration is a bit too strong?
Mh. Currently several small fires are a lot stronger than one single, big fire. I did it that way to preserve the strength of fire bombs (etc) but to prevent dying from one, random burning object (like in CR).
Ideas on that? It could be worth a try that every time object A incinerates object B, A loses fire strength itself. That could lead to a fire going through the whole forest but still dying after some time. Whether that is wanted is another question.
Another point:
Would it make sense to have Place() as a global function with some standard behavior? (as opposed or in addition to being in Library_Plant)
That function could behave differently with different objects.
Gold->Place(4), etc
Wrapping everything up in a proplist sound weird. But maybe it's the solution.> but without having trees spawn (later) in front of your stuff.
Yeah, that's a good idea.
> extra_options.allow_foreground? ;)
I'd rather keep that to the plant itself. I suppose it's only nice for trees and for the berrybushes or so.
> Would it make sense to have Place() as a global function with some standard behavior?
What would that standard behaviour be?
CreateObject(def, Random(LandscapeWidth()), Random(LandscapeHeight()), NO_OWNER);?I'd rather make the inearth algorithm of the engine available through script and then make a InEarth library which is to be included in Gold.
>I'd rather keep that to the plant itself.
Sometimes you may need to turn this off. Hiding behind trees may not be wanted in melees.
>I'd rather make the inearth algorithm of the engine available through script and then make a InEarth library which is to be included in Gold.
But having a global Place function that probably even uses the Placement property of the objects may be more useful. How would you place buildings per script without such a function?
> Sometimes you may need to turn this off. Hiding behind trees may not be wanted in melees.
Then you'll have to see to turn it off. It's not impossible. It's better to have a solution that is wanted by most of the use cases than overburden everything with super flexible controls that in the end just annoy everyone.
> How would you place buildings per script without such a function?
What do you mean? Placing buildings worked very good so far in Clonk. And buildings don't have any placement property.
>I'd rather keep that to the plant itself. I suppose it's only nice for trees and for the berrybushes or so.
Sounds good - if you really need to disable it for a certain scenario, you can still do that manually (@Eleutherotes)
>What would that standard behaviour be?
Trying to use the placement attribute f.e.
In earth objects: random point in earth; other items: surface or even in chests if found
That would of course only be a best-effort try. But it might help in some cases - depending on how smart Place() is.
But I am also not sure whether that makes enough sense to be worth the effort.
>Wrapping everything up in a proplist sound weird. But maybe it's the solution.
Proplists are the future!111
We could have a wrapper for that if it feels too weird in practice ;)
Changes:Default Place() has now one more parameter:
Place(int amount, proplist rectangle, proplist settings)settings default is:
{ growth = 100000, keep_area = false }Both params act as described in the start post.
->Place() now returns an array of the created plants which makes it easier for custom Place() calls in single plant definition to manipulate the plants (see Tree_Coniferous for an example).
I added a foreground paramater to the Place() function of Tree_Coniferous. If true, it makes roughly every 3rd foreground.
Just curious: What's the reason for having some parameters as regular parameters, and putting some other arbitrary parameters into a proplist? I don't know any other function that use this kind of concept.
As stated in the first post:> Adding a growth parameter to it is easy, just passing that to PlaceVegetation. Wanted yes or no? Will increase the number of standard parameters for Place() (bear in mind that if you want to access some custom parameters of plants, you will always have to fill in the standard params first. Keeping these as few as possible spares some work and traps).
The reason is that every plant may introduce custom parameters (like Tree_Coniferous now has) but the first ones always stay the same.
If we later discover that we want more global parameters, we cannot add them because that would break compatibility.
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill
