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

[Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>]

On Mon, Apr 15, 2002 at 05:00:22PM +0100, Gregory Berkolaiko wrote:
> On Sat, 13 Apr 2002, Raimar Falke wrote:
> 
> > On Fri, Apr 12, 2002 at 03:17:08PM +0100, Gregory Berkolaiko wrote:
> > > On Thu, 11 Apr 2002, Raimar Falke wrote:
> > >  struct pf_parameter {
> > > @@ -65,10 +65,11 @@
> > >       * Definition of the state of a virtual unit unit at the start.
> > >       */
> > >      int start_x, start_y;
> > > -    enum unit_move_type move_type;
> > > -    /* only F_IGZOC and F_IGTER are used */
> > > -    enum unit_flag_id flags;
> > > -    int moves_left;
> > 
> > > +  /* Indicates which built-in BMC-function should be used */
> > > +  enum pf_move_mode {
> > > +    LAND_MODE, SEA_MODE, CITY_MODE, IGTER_MODE, CARDINAL_MOVE
> > > +  } move_mode;
> > 
> > I'm against this. Why should we add another enum when the same can be
> > expressed with enum unit_move_type, enum unit_flag_id and enum
> > goto_move_restriction which are used throughout the code?
> 
> To use a clear-cut unified switch inside the built-in costfn instead of 
> if else if else if not.  But it isn't critical.

If a clear-cut unified switch inside the BMC is faster you can
calculate the appropriate enum value in pf_get_map. And make the whole
enum private.

> > Why have you removed the comment? What is the extra int?
> 
> It's identical with the previous one.  What extra int?  Oops.  I see.  My 
> apologies.

As I side note: it may be possible to remove the second extra cost
function altogether since the trieme cast is now handled in another
way. But this can wait.

> > > +/*===================== Hidden structures 
> > > ==============================*/
> > > +/*======================================================================*/
> > > +
> > > +struct pf_position {
> > > +  int x, y;
> > > +  int moves_used[NUM_TURNS];
> > > +  enum direction8 came_from;
> > 
> > > +  enum direction8 went_to;
> > 
> > You can't do this.
> 
> Why not?  But I probably don't need this...

If pf_position is an internal struct it may be part of more than one
path.

> > > +};
> > > +
> > > +/*
> > > + * Anything else goes here?
> > > + */
> > > +struct pf_map {
> > > +  struct pf_position *the_map;
> > > +  struct pf_parameter *parameters;
> > > +  struct pf_queue *queue;
> > > +}
> > > +
> > > +/*
> > > + * Need to agree upon
> > 
> > No. All of this section should get removed.
> 
> Excuse me, this should go somewhere.  It shouldn't go into path_finding.h 
> but probably path_finding.c  So why don't we discuss it now?  Imagine that 
> everything below 
> /*==============================================*/
> is getting to be stowed away in some other file.

It is just not part of the interface. And pf_map will get bigger. You
need for example a way to cache the per tile extra cost, the per tile
zoc value and so on. And if pf_position is public you can't store it
in pf_position.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
  Microsoft does have a year 2000 problem. I'm part of it. I'm running Linux.