[Freeciv-Dev] Re: [RFC] Path finding implementation.

[Raimar Falke <rf13@xxxxxxxxxxxxxxxxx>]

On Thu, Jun 06, 2002 at 05:53:32PM +0100, Gregory Berkolaiko wrote:
> On Thu, 6 Jun 2002, Raimar Falke wrote:
> 
> > On Thu, Jun 06, 2002 at 12:52:48PM +0100, Gregory Berkolaiko wrote:
> > > On Wed, 5 Jun 2002, Raimar Falke wrote:
> > > 
> > > > 
> > > > The struct is faster because you can reuse the struct and only have to
> > > > change certain fields. Well this isn't such a big argument.
> > > > 
> > > > enum unit_move_result test_unit_move_to_tile(Unit_Type_id type,
> > > >                                              struct player *unit_owner,
> > > >                                              enum unit_activity 
> > > > activity,
> > > >                                              bool connecting, int src_x,
> > > >                                              int src_y, int dest_x,
> > > >                                              int dest_y, bool igzoc);
> > > > 
> > > > has 9 arguments. Version 10's pf_parameter contains 17 fields. Can you
> > > > expect how messy this will be? However we are far from the limits:
> > > 
> > > In my opinion 17 is a bit exaggerated ;)
> > > 
> > > You need: 
> > > * pplayer         (for ZOC and vision-related things)
> > > * x0, y0          (obvious)
> > > * move_rate       (for correct calculation of BMCs)
> > > * initial_moves (for correct calculation of AMCs)
> > > * turn_mode     (   ditto   )
> > > * costfn        (BMC function itself)
> > > * extrafn       (extra cost function itself)
> > > * igzoc         (but maybe we can manage without it)
> > 
> > plus move_rate, plus move_backward, plus get_known, plus ...
> 
> move_rate is in my list, move_backward is not needed since you specify 
> costfn, get_known is fully specified by pplayer.
> 
> > Please we had this discussion in the past.
> 
> We had indeed and you know my opinion: these 4 parameters
>       enum unit_move_type move_type;
>       enum unit_flag_id flags;
>       bool move_backward;
>       enum goto_move_restriction restriction;
> are plain ridiculous, instead you can specify costfn, and these
>       int turn_cost_factor, move_cost_factor
> will either break your code or can be removed altogether.
> 
> Undoubtely, both the user code and the implementation can be squashed into 
> procrustean bed of pf_parameters and family, but is it worth it?

At some point we have to interpret the parameters (move_type, flags,
restriction). We can do this before calling the path_finding by
translating it into the appreciate costfn or in the path finding
code. You have to code it somewhere. I'm for doing it in the path
finding code because:
 - you can just copy the values from punit and the unit type
 - you need the seperate values to test if the move is possible at all
 - the mapping from parameter to costfn is fix (at least IMHO. I have
 asked you for cases where this isn't the case. We took care of the
 city and trireme case in other ways.). So there is no need that each
 user has to do the work each time by itself.

> > > You can comment function prototype as well as a struct, but the struct 
> > > has 
> > > the advantage of having named fields.
> > > 
> > > Also, I wouldn't want anything but the service code use either 
> > > pf_parameter or this rather big function call.  But maybe service code 
> > > can 
> > > be allowed to fill the pf_map struct directly?
> > 
> > Service code?
> 
> Like the function Per wanted for claculating the best place to meet etc.
> Hierarchy:
>   path-finding engine
>            |
>   service code (path finding in special cases)
>            |
>   user code (using the above for AI and agent needs)

I have no problem of having a wrapper function which hiddes a lot of
the parameters and take a punit instead. But the flexibility is needed
at some point. And normally you make the real function the one which
offers the flexibility and then reduce it if you have more info.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
  "With a PC, I always felt limited by the software available.
   On Unix, I am limited by my knowledge."
    -- Peter J. Schoenster <pschon@xxxxxxxxxxxxxxxxx>