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

["kayeats@xxxxxxxxxxxxxxxxxxxxxxxxx via RT" <rt@xxxxxxxxxxxxxx>]

> The proof is always in the cases where it fails rather than succeeds. :-)

Well yes, but you gave some examples of things which you feared would not
exhibit appropriate clumpyness, and I attempted to discuss how in fact
they were suitably distributed.

> But I'll wait for sufficient evidence to accumulate before coming to a
> final conclusion. You should try to provide tools or explanations on
> how to setup different types of global and local distributions. Others
> will want something different that what you have tuned things to, or
> will want to customize some elements. So you do need to provide an
> understanding on how this should work.

I intend to make it so that the function you use is read from the ruleset.
That way all the freedom available will be accessible from outside
mapgen.c.  Would this be sufficient for your needs.  I was hoping the
current patch would get in first because it is big enough as it is, and
conceptually these are two separate changes.

I initially didn't find that the multiple iterations sat well with me, but
I've changed my opinion on that.  I think using multiple iterations is
useful, effective, and gives at as much control of local effects as what
cvs has.  I may well be convinced to do the deserts that way for the
standard ruleset too when I do up the ruleset patch.

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? do you think that
this is a less elegant solution than a two layer approach?  have I
correctly teased out that these are your primary concerns?

I was actually thinking of adding the capacity for generalized multiple
iterations when I did the ruleset patch.  I suppose really that doesn't
make sense, but I have two external reasons for it.  First contrary to
you, Ross, I think that the current behaviour is good enough to cover cvs
and a bit more, and second I'm leaving in a few hours for Baltimore for a
conference and was sort of dreaming that this patch might get in while I
was away.  If it's still open when I get back I'll change my tune.

> 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?", and "if we make multiple iterations do we need to
be able to change the distribution function?".  There is no reason that
using this framework one couldn't get away from linear combinations, I
didn't because it didn't seem necessary and because staying linear makes
it much easier to specify from the ruleset.  There is also no reason that
one couldn't change the distribution function between iterations, again I
didn't because it didn't seem necessary and because I didn't see how to
elegantly specify it from the ruleset.

While either or both of these might well be useful refinements they aren't
problems with the fundamental technique I'm using.

> 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.