[Freeciv-Dev] Re: (PR#8624) New clima function to best handle terrain place, used to place poles.

["Marcelo Burda" <mburda@xxxxxxxxx>]

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

Le jeu 06/05/2004 à 19:28, Jason Short a écrit :
> <URL: http://rt.freeciv.org/Ticket/Display.html?id=8624 >
> 
> > [mburda - Fri Apr 30 10:11:06 2004]:
> 
> > This is a full tuning patch for pole based in a new function map_clima
> > this function return a number form 0 (coolest) to 100. alowing to select
> > terrains types from clima.
> > I use it to fix the poles placing problems. now poles are good placed in
> > all 4 topologies (in torus this is more nice if x-y ratio is 1-1 or (2-1
> > iso) but this is a problem of the choice of sizes.
> 
> The concept is good.  But again we're going to need some tuning.
> 
> We can't go adding "natural" conversions all over the place.  We need
> some new macros in map.h: map_to_ntl_pos, ntl_to_map_pos, ntl_width,
> ntl_height.  Perhaps a do_in_ntl_pos() macro.  (In principle these can
> be used for the overview changes as well, but it's hard to see how.) 
> These should probably be added to map.h in a separate patch.
i'll see it
> 
> near_singularity() shouldn't use the hard-coded city iteration.  Use
> is_valid_city_coords, or a city iterator, or just use circle_iterate.  
singularity no need to be exact a city iterators.
I am choice one of more basic and simplest iterators there. this is one
of fondamentals iterators to be adapted to topologies.(this is the right
choice) spetialy i can't use circle_iterate  this call
map_distance_vector or any other operator where future is (?).
Near_singularity() is moderate time  inefficient but this never need to
be change in future (expet if we like chage it) this function is only
called for map generator, were time is not the first point.

> 
> In fact clean_singularities isn't good since it's very inefficient.  But
> I guess doing it differently means topology code.
i can add a IS_BORDER_MAP to make it best
> 
> Also clean_singularities must not hard-coded arctic, and shouldn't
> hard-code ocean.  I guess we can use a new terrain flag here (given to
> arctic and ocean).  Consider when we have multiple types of ocean: only
> deep ocean should be found near the singularities.
> 
this is part of a mapgenerator code, then i need to handle there reals
tiles. when map generator handle deeps ocean all generators will be
modified and clean_singularities too! but first i need the new tiles!!

> I don't like how assign_poles_numbers() hard-codes knowledge of the
> climate areas.
mmm...assign_poles_numbers need knowledge of where are the poles!. this
is a part of clima handling system. if you no like assign_poles_numbers
we need to make a separate map_clima_poles_list to be called only by
assign_poles_numbers!. 
i ll THINK about it. 


> 
> Also I suspect the separatepoles option is broken (in the current code
> and in your patch).  IMO this option should just be removed.  A new
> option should be added in its place: a boolean controlling whether the
> map has climate differences at all (and hence, whether it has poles). 
> If this value is FALSE, map_clima should always return a temperate (or
> pseudo-random) value.
this option are not realy interesting for me this need to be removed ,
but makepasable stil working in classic topo. in uranus and torus this
never work. for flat i broken it but the flat maps as only one pole now
and all 3 others sides are sea! 

i no like a all-temperate option, but it can be implements.
> 
> There may be more problems but that's all I see right now.
> 
> jason
-- 
 . /  .     '    ,    .      (*)   '        `     '      `    .    
  |    ,  |   `     ,     .      ,   '  Marcelo Julián Burda      .
 /  '     \     `     \@_     '      .        '      `        '    
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~