[Freeciv-Dev] Re: (PR#2370) Path finding

[Gregory Berkolaiko <Gregory.Berkolaiko@xxxxxxxxxxxx>]

On Tue, 18 Feb 2003, Raimar Falke wrote:

> On Tue, Feb 18, 2003 at 01:01:12PM +0000, Gregory Berkolaiko wrote:
> > On Tue, 18 Feb 2003, Per I. Mathisen wrote:
> > 
> > > On Tue, 18 Feb 2003, Raimar Falke wrote:
> > > > I really don't want that core PF module get the kitchen sink for all
> > > > possible (ab)uses. I will not allow it to be cluttered like the old
> > > > warmap which mixed the algorithm with the users of this.
> > > 
> > > So you don't want to create code that is adapted to usage?
> > > 
> > > Overlapping into ocean/land is needed for
> > >   - diplomat bribe
> > >   - unloading passengers (to land)
> > >   - boarding ferry (to ocean)
> > >   - artillery (PR#2292)
> > >   - sea units attacking land targets
> > > 
> > > I do not want to kludge all these in the iterator macro just because you
> > > have some silly notion of "purity of code".
> > 
> > This is a non-issue.  I was writing path-finding with these tasks in mind 
> > and tried hard to gear it towards such tasks.  This is why I was clinging 
> > to move-cost call-backs in our long negotiations with Raimar.  It would be 
> > much better to have such call-backs supplied from outside pf-module, but 
> > Raimar was so vehemently opposed to it, that I agreed to restrict them to 
> > pf-module.  But on the condituon/understanding that more call-backs could 
> > be added to serve AIs needs.  If Raimar didn't care to read what I wrote 
> > about these needs, it's not a valid excuse to stop PF from functioning on 
> > full-power now.
> > 
> > You, Per, should have participated in the discussion too, maybe Raimar 
> > would believe you more than me.
> 
> The alternative would be what I suggested in
> 
> http://lists.complete.org/freeciv-ai@xxxxxxxxxxx/2002/09/msg00046.html.gz
> 
> You found it nice:
> 
> http://lists.complete.org/freeciv-ai@xxxxxxxxxxx/2002/09/msg00047.html.gz
> 
> So while this give more flexibility I don't see that this is
> faster. You can't inline these functions.

Just for the reference,
<Raimar wrote>
You get full control over the cost (get_BMC, get_ECOT) and the
termination condition (get_TB). You may want additionally to do the
moves_left and turn calculation by yourself. If the *_data stuff and
the comments are removed:

struct pf_parameter {
  int start_x, start_y;
  void (*update_turn_and_moves_left) (int *, int *, int, int);
  enum tile_behavior (*get_TB) (int, int, void *);
  int (*get_ECOT) (int, int, void *);
  bool(*is_position_dangerous) (int, int, void *);
  int (*get_COP) (int, int, int, int, void *);
};

This is quite minimal. Do you want this?
<end quote>

Yes, I agreed to it and I still do.  You forgot to add get_BMC call-back, 
but otherwise almost everything you need is there.

The hard problem is to decide what info to pass to get_BMC, though.

> This is btw also a flaw in the recent pf*.diff: the use of callbacks
> for the BMC. _IIRC_ you said that this is an error and you want to fix
> it.

I don't think I said it's an error.  Probably I said it could possibly be 
made faster by turning it into a switch and then new callbacks would be 
equivalent of adding a new switch to the statement.  I am not 100% sure it 
would be much faster though, but one can try...

G.