Complete.Org: Mailing Lists: Archives: freeciv-dev: April 2002:
[Freeciv-Dev] Re: [RFC] Move cost map interface
Home

[Freeciv-Dev] Re: [RFC] Move cost map interface

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: rf13@xxxxxxxxxxxxxxxxxxxxxx
Cc: freeciv development list <freeciv-dev@xxxxxxxxxxx>
Subject: [Freeciv-Dev] Re: [RFC] Move cost map interface
From: Gregory Berkolaiko <Gregory.Berkolaiko@xxxxxxxxxxxx>
Date: Fri, 12 Apr 2002 14:13:02 +0100 (BST)

On Thu, 11 Apr 2002, Raimar Falke wrote:

> On Thu, Apr 11, 2002 at 05:14:23PM +0100, Gregory Berkolaiko wrote:
> > I think there are only 4 issues remaining:
> > 1. Calculating # of turns.
> > 2. Returning path with every new location (aka performance killa)
> > 3. Taking into account possibility of waiting.
> > 4. Special type of map "city map".

> I'm also for (a) with the extention to have a "int turns[3];" in the
> result. Which is calculated is controlled by ORing NTM_s together.

yes (with a correction: turns are computable from total_moves_expended, 
therefore int total_moves_expended[NTM_LAST])

> > And I object vehemently to the attitude "let's ignore performance issues 
> > now and later we'll see".
> 
> We already have the method to calculate the path: pf_get_path_from_map.

I want a non-destructive one too

> 
> Problem: (x,y) does _NOT_ exactly describe a path. Because there is
> "(4,5) with 1 moves left" and (4,5) and waited a turn and now 3 moves
> left". But I agree that from a performance point of view the path is
> unneeded. Solution? Adding an result moves_left to pf_get_next_path
> and also moves_left as a parameter to pf_get_path_from_map?

if you waited a turn it's going to count on your total_moves_expended, 
which is returned together with your next destination (or accessible using 
your next destination)
if you want to be at your final destination with full points, come there 
using the shortest path and wait a turn.  It should be user responsibility 
to ensure that the destination is safe (if it's an attack goto, first find 
a safe place for the seige camp next to the city).

> > 3. The possibility of waiting must be switchable on by a special parameter, 
> > consider_waiting, as it is not necessary in most cases.  we may choose to 
> > provide for an extra callback is_location_safe, to bring down overhead in 
> > the case when consider_waiting is TRUE.
> 
> But this extra parameter consider_waiting is not needed because it is
> the same as "is_location_safe != NULL".

right

> > 4. Special "city map" type is the cheapest way to have a map incorporating 
> > information usable by all types of units.  If we choose to do away with it, 
> > we'd face the necessity of calculating 4 maps per city: for units with 
> > speed 1, 2, 3 and IGTER units.  What happens if someone starts hacking 
> > rulesets is sad to visualize.  I think that "city map" is an acceptable 
> > estimation for AI use.  In really serious cases (in such case the unit 
> > type will be known) AI can make another map for this particular unit.  
> > "Non-exact" is not synonymous with "useless".
> 
> Can you please explain to me the properties of a city_map? What costs
> does it calculate?

average distance to/from the city.  for more concrete numbers have a look 
at the really_generate_warmap (I don't claim I understand every digit 
there).

> > If you send me the latest of your path_finding?.h, I'll have a go at it 
> > tomorrow.
> 
> Attached.

thanks

G.




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