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

[Raimar Falke <rf13@xxxxxxxxxxxxxxxxx>]

On Thu, Aug 01, 2002 at 02:43:37PM +0100, Gregory Berkolaiko wrote:
> On Thu, 1 Aug 2002, Raimar Falke wrote:
> 
> > On Thu, Aug 01, 2002 at 12:52:39PM +0100, Gregory Berkolaiko wrote:
> > > On Wed, 31 Jul 2002, Raimar Falke wrote:
> > > 
> > > > 
> > > > Do I get this correct? With get_COP callback we don't have problems
> > > > and without the callback we have problems?
> > > 
> > > No.  With get_COP callback you get the same problems plus other ones too.
> > > 
> > > But you are right, this seems to be the last point of contention.  It 
> > > seems that COP is only needed for is_position_dangerous handling so far 
> > > and I hope to be able to do it differently.
> > 
> > > We should also think however about the possibility of having 
> > > can_transit_tile call-back.
> > 
> > We have the whole time or haven't we. IMHO it is wrong if the
> > can_transit_tile returns true for safe places. If this function should
> > return true for other position for which ones?
> 
> There is nothing wrong about it if it gives right results.  It's only a 
> tool.  Other possible uses: targeting shore, targeting enemy tiles.

So we have:
 if EC == PF_IGNORE_COST:
   don't go onto this tile
 else if non-transition:
   step onto but don't leave the tile
 else:
   step onto and leave the tile

What do think about a get_tile_status callback which returns either
IGNORE, NON_TRANSITION or NO_RESTRICTION. This is IMHO cleaner than
the overloading of EC with PF_IGNORE_COST. It would also solve the COP
problem in the path_finding_macro because we don't have to use the
user supplied EC callback anymore.

        Raimar

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