Complete.Org: Mailing Lists: Archives: freeciv-dev: January 2003:
[Freeciv-Dev] Re: (PR#2749) place_land_type in mapgen
Home

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

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: kayeats@xxxxxxxxxxxx
Subject: [Freeciv-Dev] Re: (PR#2749) place_land_type in mapgen
From: "Gregory Berkolaiko via RT" <rt@xxxxxxxxxxxxxx>
Date: Tue, 7 Jan 2003 11:12:59 -0800
Reply-to: rt@xxxxxxxxxxxxxx

On Tue, 7 Jan 2003, kayeats@xxxxxxxxxxxxxxxxxxxxxxxxx via RT wrote:

> > 1. Why you don't like calloc?
> 
> Well the truth is I've just been copying what was done elsewhere in mapgen
> when I needed to allocate memory.  Calloc seems much nicer now that I look
> into it.

It is.  And it clears the memory for you, so you don't have to do it 
manually (which you still do in your patch)!

> > 2. You should check in place_land_type (which is really place_ter_type) if
> > the function returns value within the bounds.  "We require" put in the
> > comment doesn't always help.
> 
> Would I be correct that at run-time the name of the function that
> place_land_type was called with is not availiable (because at the linking
> stage it was replaced with an explicit pointer) and hence that there is no
> easy way to return in my error message what the function was?

I suspect there are tricks to get the name, but I think the message you 
print is enough.  The primary function of the checks is to avoid overflow, 
at any rate.  BTW, you probably should cache the return value of the 
function in a local variable.  Compiler would probably do it for you, but 
still...

> > 3. Placing mountains and hills depending not only on height but on
> > gradient too is a very noble aim, but maybe a bit excessive at this time
> > (this is directed to Ross too, who I believe started it in his cleanups).
> > I seem to recollect how someone was arguing against artillery bombarding
> > ships: "the scale is wrong".  I feel similar arguments are applicable
> > here.  Even if they aren't, we can still use the height as the first
> > approximation of whether it's a hill or plains.
> 
> I think that using gradient simply looks nicer.  Instead of always getting
> big piles of mountains in the middle of the continent (which in reality
> occurs only when two land plates meet (eg India and Asia)) you sometimes
> get that and sometimes get coastal mountain ranges.  Try a really big map
> and I think you'll see that just using height looks rather funny.  Maybe
> this is really a problem with the heightmap generation, I don't know.
> I've left it for the time being; its just a case of changing "parameter"
> in the function in question, which I'll do if you're really convinced just
> using height is best.

It's the simplest, but if it really looks better...

> > 5. Recursive placing of deserts was removed.  But you can do it even in
> > you framework (and then do forests similarly).
> 
> Deserts I placed based on closeness to tropics with a bit of flatness
> added in to make them blob shaped.  Forests however occur at almost all
> altitudes, at all slopes, and at almost all latitudes.  Could you suggest
> what function I could use?  (jungles could be closeness to equator with
> some flatness to make them blob shaped, but I hesitate to separate out
> jungles when I can't improve forests)

I was just thinking of increasing the probability of desert/jungle/forest 
at (x,y) if there is a forest around and then generating it in three or so 
calls to the same function, so it would imitate the 3 levels of 
recursion...

> > 7. How is it more convenient?  In any case, I feel we should have a
> > function is_been_placed(x, y) rather then explicit check for the GRASS or
> > PLAIN.
> 
> Would you hide a check for GRASS or PLAINS inside this function or do you
> have in mind a more complicated way of keeping track?  I went for the
> former option in the attached version of the patch.

Yes, that's what I had in mind.  So why PLAINS were more convenient for 
you?

G.




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