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

[Gregory Berkolaiko <Gregory.Berkolaiko@xxxxxxxxxxxx>]

On Wed, 10 Apr 2002, Raimar Falke wrote:

> On Tue, Apr 09, 2002 at 08:55:30PM +0100, Gregory Berkolaiko wrote:
> > 
> > /******************** HRM The Cost Map ******************/
> 
> HRM stands for?

his (her) royal majesty

> > /* Generic move cost function 
> >  * Can pass some more info using void * 
> >  * (it will probably need pplayer, moverate, what else?)
> 
> >  * Will probably return pointer to the static internal 
> >  * struct movecost */
> 
> Are the locations adjacent?
> 
> > typedef struct movecost * (COSTFN)(struct location *from,
> >                                    struct location *to, 
> >                                    void *);

good question...  most of the time they should be
could pass "dir" as well

> In summary you put the current gotohand.[ch] in an interface.

sure.  we can't do away with gotohand.[ch]

> 
> Things that I dislike:
>  - the maptype. This is IMHO an error in the current goto(hand).[ch]
>  files.

the maptype is the indicator which one of the internal (built-in) cost 
functions should be used.

>  - you expose too many details. Remove all the stuff which is 
> implemention specific.

of course most of the stuff will be hidden

>  - you missed the ability to calculate the turns to reach a
>  target. This is required for my further agents and has to be
>  included.

Yes.  This is of course 
(cm_get_cost(map, x, y) - cm_get_cost(map, x0, y0)) / move_rate

Here I am assuming that if the unit has 4/6 initial move points, we record 
the missing 2 as the cost to get to the origin.

>  - serveral smaller problems: char for example can only hold the
>  bitmask up to 8 directions, no enum goto_move_restriction, ...

Are we planning to go 3D?  If you are having in mind the general-topology, 
we can change char to int, no problem.

goto_move_restrictions are hardly ever used and should be implemented as 
custom move_cost_function I think.

G.