Complete.Org: Mailing Lists: Archives: freeciv-dev: May 2004:
[Freeciv-Dev] Re: (PR#8624) New clima function to best handle terrain pl
Home

[Freeciv-Dev] Re: (PR#8624) New clima function to best handle terrain pl

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: undisclosed-recipients: ;
Subject: [Freeciv-Dev] Re: (PR#8624) New clima function to best handle terrain place, used to place poles.
From: "Marcelo Burda" <mburda@xxxxxxxxx>
Date: Sun, 23 May 2004 00:36:33 -0700
Reply-to: rt@xxxxxxxxxxx

<URL: http://rt.freeciv.org/Ticket/Display.html?id=8624 >

Le dim 23/05/2004 à 01:20, Jason Short a écrit :
> <URL: http://rt.freeciv.org/Ticket/Display.html?id=8624 >
> 
> 1.  There's no need for is_singular_map_pos to be inline.  Just make it 
> a regular function in map.c.  (Did I say differently before?  I hope not...)
you never say a this but you are right.
> 
> 2.  Clima isn't an english word.  I guess it's French or Flemish?  What 
> can we call this function in english?  Or maybe we can invent a new term 
> (at least that way it's unique), but in that case we have to make sure 
> it's well defined.
french-spanish clima is translated to climates/climes, you think
temperature is best?
> 
> 3.  This code:
> 
> +    x_2 = NATURAL_WIDTH / 2 - 1 + NATURAL_WIDTH % 2;
> 
> isn't it the same as (NATURAL_WIDTH - 1) / 2? 
Yes
>  Also x_2 is not a good 
> name.  And, don't you want x_2 = (NATURAL_WIDTH + 1) / 2 so that when 
> you divide by x_2 later you never get a value over 1?
 never.
> 
> 4.  Be careful with your use of float values.  For instance in this code:
> 
> +  if (x + y > 1) {
> 
> I think it's better to have (x + y > 1.0) to make sure (and clear to the 
> reader) that everything is treated as a float.
> 
ok
> 5.
> 
> +  return 150 * (x * x * y + x * y * y) - 50 * (x * x * x + y * y * y) +
> +      150 * (x * x + y * y);
> 
> This needs some explanation.  Does this come from the Pierce projection?
> 
This is symplt a mathematical equation to make poles as 2 separate
cercles and equator whit a shape of squere, this whit a area
proportionality.
i am create it to be exatly i want.
> 6.  rand_clima_map_pos should use rand_map_pos_filtered.
> 
i ll see
> 7.  In near_singulararity, where does the value 2 come from?  Should 
> this be MAP_CITY_RADIUS?
> 
yes
> 8.  In this code:
> 
> -    if (has_poles && nat_y > map.ysize * 42 / 100
> -       && nat_y < map.ysize * 58 / 100 && myrand(100) > 50) {
> +    if (T > 42         && T <  58  && myrand(100) > 50) {
> 
> I think it is wrong.  T == 100 at the equator, right?  So the check you 
> want is T > 84.  I think there's a similar error in the creation of forests.
Oops, yes, i was no so happy of forest and i no understan why? :-) now
yes
> 
> 9.  In this code:
> 
> -    if (adjacent_river_tiles4(x, y) != 0||
> -       adjacent_ocean_tiles4(x, y) != 0) {
> +    if (adjacent_river_tiles4(x, y) != 0 ||
> +       adjacent_ocean_tiles4(x, y) != 0 ||
> +        (map_get_terrain(x, y) == T_ARCTIC
> +         && map_clima(x, y) < 8)) { /*rivers end at poles */
> 
> why?  And can you avoid the reference to T_ARCTIC here?
simply there is not posible to make big rivers on poles, i can define a
class of tiles ice and chek for it to make rivers end at poles, ice is
water.
if i avoid this very long rivers are create on circle poles, and the
number of rivers on land is reduced, very bad!
> 
> 10.  assign_poles_numbers is really not good!  It's not clear at all 
> that this doesn't enter an infinite loop.
yes it is clear, you never get a infinite loop! ;-)
but now a can delete it, we no more reserve numer 1 and 2 to poles
> 
> 11.  I'm not sure that separatepoles is handled rigorously.  If you have 
> a sufficiently small map I suspect there is some chance that the 
> separation will not be sufficient.  But maybe this is acceptable or 
> unavoidable.
> 
i think it is acceptables now,  if poles touch a continent this is no
more a problem to locate start places.
gene 5 make it good gene 1 some times make it a litle bad i need to tune
it a litle more. for gene 2-4 this are all the time make as separate
island.
i am tested it for map of size 1 whit not big problem. (using Size and
Ratio patch)
> 12.  For flat-earth maps I don't think it's good to assume poles on just 
> one end.  IMO it would be better to just assume there are no climate 
> differences in the map.  Perhaps this is a question for the design board.
> 
A use the has_pole option as a !all-temperate map option, if you like it
we can add a server option.
A one-poles and !separatepoles flat map make nice maps, as a europa, or
asia map. but 2 poles are very bad! 2 poles and no wraps is very ugly
concept.
A one-pole and separatepoles is a less interestig gameplay.
> 13.  The poles are very large.  Particularly in the standard case it's 
> just wasteful to put lots of arctic tiles up there.  I'm really not sure 
> what to do about this.
mmmm poles are 20%, we can reduce it to 10%(or less) if separate poles
option is actived for clasical topologies, the poles are less
interesting in clasical topos spetialy when separated.
for circle poles i think we can make somethig interesting, spetial
wonders as "Scott voayage" to reduce lost danger, create spetialist
civilizations than can expand on these climes. probably we can whait a
litle befor reduce poles less than a 20% exept for the separatepoles
classic topos
> Finally, make sure you test it out with all generators.
> 
> There may be more but I think this is okay for now :-).  Your design is 
> good but there's still a lot of work to be done.  But this is really 
> true of any code that tries to change mapgen.  The current mapgen code 
> is so non-extensible it's hard to add anything to it without rewriting a 
> lot of it.
yes :-S
> 
> jason
> 
thx for your coments





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