[Freeciv-Dev] Re: (PR#2749) place_land_type in mapgen

["rwetmore@xxxxxxxxxxxx via RT" <rt@xxxxxxxxxxxxxx>]

At 06:08 AM 03/01/14 -0800, kayeats@xxxxxxxxxxxxxxxxxxxxxxxxx via RT wrote:

>Let me clarify:  once multiple iterations are cleaned up so that the
>forest code need not lean on jungles, (ie so that it is generalizable), do
>you feel that there would be sufficient local control? 

I don't understand exactly how this works yet, but if it does allow one
to define independent global and local probabilities, that is the dual
control mechanism I was looking for. 

Maybe you could explain how it would do this to help out.

>do you think that
>this is a less elegant solution than a two layer approach?  

Two layer is nested, multiple iterations is serialized, right? Seems
about the same, with the caveat that there may be some key ordering
or operation dependencies in a depth vs breadth first pattern.

>have I
>correctly teased out that these are your primary concerns?

Yes, I have been teased :-).

>> There is probably a lot of flexibility in choosing the distribution.
>> the trick is in how the distribution gets randomly selected, and this
>> means that you need multiple criteria and not just a linear magnitude.
>> The criteria might need to change as you proceed with the selection
>> which is easiest if you have two (or more) disjoint techniques, i.e.
>> one for each type of effect.
>
>So there are two issues here, "is a linear combination of component
>functions sufficient?",

Might be. It might depend on whether they were kept separate, so the
threshold for a successful choice was an "any of" the components, as 
opposed to a sum of thresholds being a single choice. The latter is 
one way of introducing interdependency effects, but might result in 
a single effect dominating. The former might allow one to drop a 
particular component or drop all but one under certain conditions,
as in a subsequent iteration.

> and "if we make multiple iterations do we need to
>be able to change the distribution function?". 

This would be the case where next_to(ttype) enhanced the probability
for a local effect. But this sort of assumes you have made a selection
in order to trigger the next_to() boost. In the nested algortihm this
is no problem, as you can keep iterating next_to() until some terminal
condition kicks one back out to the global case. I don't understand how
this might work in a multiple serialized distribution case.

>> I'd like to see it capable of reproducing a range of behaviour that
>> includes CVS, rather than falling short. Absolutely so if it replaces
>> rather than provides an option to CVS, and the option extensions are
>> going to be very limited until the standalone framework allows one to
>> break out of the single server/mapgen.c paradigm.
>
>It may not do everything that you dream of, but I don't see what it
>doesn't do that the cvs code does now.  I deliberately tried to replicate
>the cvs results while providing more freedom to manipulate things.

Maybe it does match CVS. But I don't see that yet, so I'm still a skeptic.

Matching CVS is the threshold, not everything anyone might dream up just
to make sure one focusses on the right criteria :-). And only if it is
going to replace the current CVS algorithm is it critical. I'm game for
options, especially if they are not dead-end, but have some extensibility
possibilities. And I agree in this case to get the first part done, then
extend.

Cheers,
RossW
=====