Complete.Org: Mailing Lists: Archives: freeciv-dev: February 2003:
[Freeciv-Dev] Re: (PR#2957) is ocean as a function with oceanness read f
Home

[Freeciv-Dev] Re: (PR#2957) is ocean as a function with oceanness read f

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: kayeats@xxxxxxxxxxxx
Subject: [Freeciv-Dev] Re: (PR#2957) is ocean as a function with oceanness read from ruleset
From: "kayeats@xxxxxxxxxxxxxxxxxxxxxxxxx via RT" <rt@xxxxxxxxxxxxxx>
Date: Mon, 10 Feb 2003 05:44:19 -0800
Reply-to: rt.freeciv.org@xxxxxxxxxxxxxx

> >     make_<terrain>: two possible solutions to this.
> >             1) if something similar to my mapgen patches #2749 +- 1
> > gets in (incidentally Ross Wetmore had a good suggestion on how to fix his
> > largest concern with that patch which I intend to code up soon...) then
> > a half dozen or so parameters are sufficient to determine the placement of
> > a given terrain, along with a river flag and a polar flag to make the
> > polar strips.  I was working on a prototype of this but it isn't ready
> > yet.
>
> I think it would be nice if I could set a height range for a terrain
> type. This would allow for example to create a terrain type "highland
> lake" (think Titicaca) which would have different properties than a
> normal "lake" terrain type.

This is exactly the sort of thing which would be possible under the
framework I'm thinking of (PR #2749 is a terrain placing algorithm which
places all the terrain types (except river) by calling one procedure with
a parameter "placement function".  The placement function is a combination
of simpler functions like height, distance from poles, a random factor,
etc.  With the promised modification that Ross suggested you would also
have proper recursive clumping as a potential base function.)

> > The 6 terrain placing parameters could be combined together into a
> > string or list which would get parsed up.
>
> You mean "mountains", ..., "deserts"? Why?

Not exactly, the terrain placing parameters would be values for the
different component placing functions, so:
height_fn = 50
proximity_fn = 20
...

I haven't thought exactly about how best to combine them together in one
string or list, h50p20... would always be possible but there is probably a
better solution.

> I'm pleased that you have a plan. I think that it is worthwhile to
> remove the hardcoded restrictions. However I don't agree with your
> proposed change in light of the plan outlined above. There should be
> for example a flag infrastructure as in the other types (unit,
> government). It would also be nice if you post a list of the flag that
> you think are needed.

That's reasonable.

It looks like we're looking at:

river, ocean, and polar flags, along with perhaps a "base good terrain"
flag (and at worst a few more).  Its concievable that it would be
worthwile for some of these (river esp, possibly also ocean) not to be
flags at all but variables which can take more than two values (eg for
river placing as mentioned in the previous email), but they could start
out as flags and get pulled out as variables if the need arised.

global warming and nuclear winter variables which take a terrain type as a
value.

terrain placing parameters.  About 6 given a framework something like my
mapgen patch.  Other mapgen solutions would require something different.






[Prev in Thread] Current Thread [Next in Thread]