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

["Raimar Falke via RT" <rt@xxxxxxxxxxxxxx>]

On Sun, Feb 09, 2003 at 04:40:11PM -0800, kayeats@xxxxxxxxxxxxxxxxxxxxxxxxx via 
RT wrote:
> 
> Here is my vision of things which I think answers both your concerns.
> 

> In the foreseeable (though not immediate) future it should be
> possible that there be no references to T_<terraintype>. 

I agree. This is also a requirement for all future work.

> It will necessitate new ruleset flags

Maybe even also some non-boolean values.

> , but the result would be a lot less hard-coded stuff so much more
> exotic modpacks could be easily made.  Also there are interesting
> steps along the way (like ocean shelf done properly).  If terrains
> are going to be in the ruleset it makes sense to me that they be as
> fully in the ruleset as possible -- at least as a long-ish term
> goal.

> Take a look at the code; terrain types are only specifically referenced in
> a manageable number of places:
> 
> <DETAILS: skip to END to get back to general discussion>
> 
> client/tilespec.c: used for various display reasons, I don't know this
> code at all, so this is the one case I can't vouch for being able to do
> away with.
> 
> common/map.c:
>       terrain_is_clean, and is_starter_close: need to know the good base
> terrain types (grass and plains), this can either be calculated somewhere
> based on f/p/t of each type or could be a flag.  Also need to know about
> rivers (one flag).
>       is_good_tile, something comparable should be calculable from the
> f/p/t of each type; it's only used to place starting positions.
>       is_water_adjacent_to_tile, river and ocean flag needed
> That's all for map: between 2 and 3 ruleset flags needed (including ocean)
> 
> common/terrain.h
>       T_'s are defined here

> server/mapgen.c
>       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.

>               2) ultimately a mapgen which calls external stuff would
> certainly solve the problem, no extra parameters needed since external
> programs special to particular modified rulesets could be used.
> 
>       river code: again two solutions, or some combination of the two
>               1) make rivers from the height_map, no flags needed
>               2) use the new river flag to determine the affinity of a
> terrain for rivers rather than as a boolean
> 
>       make_passable: This needs to know something about how to treat the
> different types of ocean.  A non-boolean ocean flag should do the trick,
> or it might be deduceable from the placing functions of each ocean type, at
> worst an extra "default ocean" flag could do the trick.

>       make_fair: needs to know a suitable non-base (not grass/plains)
> terrain type to break up clumps of the base with.  Either calculable
> from the f/p/t or at absolute worst another flag.  Really I don't see why
> we couldn't do away with this function all together.

I agree that a solution based on the f/p/t and move cost would be
better.

>       make_huts: has a check for T_ARCTIC.  I'm not sure why that's
> worthwhile but a polar flag should be good enough.
>       gens 2-4 terrain placing: the placing function info used in the
> make_<terrain> should be sufficient here also.
> 
> so we're up to a total of between 9 and 12 flags.  That's starting to get
> a bit big.  

> The 6 terrain placing parameters could be combined together into a
> string or list which would get parsed up.

You mean "mountains", ..., "deserts"? Why?

> server/maphand.c
>       is_terrain_ecologically_wet: river and ocean flags would suffice
>       global_warming and nuclear_winter: probably another ruleset
> parameter each, though possibly deducible from what the terrains can be
> transformed into along with f/p/t to make sure the players lose.  A proper
> climate model would of course also do the trick but I don't expect that
> anytime soon.
> 
> so we're up to something like 11 flags (best case 9 worst 14), or with the
> terrain placing stuck together as one more complicated variable: 6.
> 
> server/sanitycheck.c one reference to T_ARCTIC which should be T_FIRST
> 
> server/settlers.c on a philosophical level the settlers should be able to
> behave correctly just from info about terrain types.  This is probably a
> longer term goal, though I don't know this code either so I can't really
> say.
> 
> The sdl gui also uses the terrain types lightly, but the others do not so
> it can't be unavoidable.
> 
> <END of DETAILS>
> 

> So this is what I see as possible and worthwhile.  Doing it all at
> once would be unreasonable.  However it seems to me it can be done
> piecemeal.  This patch is one part which as well as being part of
> the large goal is also a step towards the possible subgoal of ocean
> shelf.  6 or 11 new flags is a fairly large number, but not
> unmanageably so.  Whether all this would be worthwhile is of course
> not my decision to make.

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.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "Programming today is a race between software engineers striving to
  build bigger and better idiot-proof programs, and the Universe trying
  to produce bigger and better idiots. So far, the Universe is winning."
    -- Rich Cook