Complete.Org: Mailing Lists: Archives: freeciv-dev: August 2002:
[Freeciv-Dev] Re: [RFC] Path finding implementation.
Home

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

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Raimar Falke <rf13@xxxxxxxxxxxxxxxxx>
Cc: Freeciv Development List <freeciv-dev@xxxxxxxxxxx>
Subject: [Freeciv-Dev] Re: [RFC] Path finding implementation.
From: Gregory Berkolaiko <Gregory.Berkolaiko@xxxxxxxxxxxx>
Date: Thu, 1 Aug 2002 15:05:36 +0100 (BST)

On Thu, 1 Aug 2002, Raimar Falke wrote:

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

I agree that it's cleaner.  Trying to find a beter description than 
non-transitive...  Cul de sac?

G.



[Prev in Thread] Current Thread [Next in Thread]