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

[Gregory Berkolaiko <Gregory.Berkolaiko@xxxxxxxxxxxx>]

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?

> > 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)

> > > > Some goto-related code uses a rather esoteric function goto_zoc_ok...
> > > > 
> > > > There is no need to have an end-user-specified function, but maybe some
> > > > service code could specify it.  It really depends if we want to convert
> > > > find_the_shortest_path to use PF module.  That'd be a messy job though.
> > > 
> > > You will see that the zoc function can be splitted and cached
> > > nicely. So the zoc function is rather ditributed in the code (at least
> > > in my code).
> > 
> > Please share your code with us ;)
> 
> It isn't debugged, it isn't commented, it isn't finished. So you have
> been warned.

ok, I'll be careful

G.