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

[Raimar Falke <rf13@xxxxxxxxxxxxxxxxx>]

On Thu, Jun 06, 2002 at 12:52:48PM +0100, Gregory Berkolaiko wrote:
> On Wed, 5 Jun 2002, Raimar Falke wrote:
> 
> > On Wed, Jun 05, 2002 at 06:36:01PM +0100, Gregory Berkolaiko wrote:
> > > On Wed, 5 Jun 2002, Raimar Falke wrote:
> > > 
> > > Why so categorically, "should use"?  Why not pass all the parameters as 
> > > the arguments?  Where is the advantage in having a spoof data structure 
> > > which is never used?
> > > 
> > > You are probably right, but please give reasons.
> > 
> > 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 ...

Please we had this discussion in the past.

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

> > > > > ZOC, yes, I forgot about it.  It can be done via (maybe even 
> > > > > user-supplied) function is_enemy_zoc(int x, int y, struct player).
> > > > 
> > > > I though we have agreed that user supplied zoc checking is useless?!
> > > 
> > > Let me think again (I actually don't remember ever thinking about it, I 
> > > think it was you arguing with yourself and then reaching an agreement 
> > > with 
> > > yourself.  I was too afraid to interfere ;)...
> > 
> > ;)
> > 
> > You didn't object so I took this as an agreement ;)
> > 
> > > 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.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "This is Linux Country. On a quiet night, you can hear Windows reboot."

diff
Description: Text document

path_finding.h
Description: Text document

path_finding.c
Description: Text document