Complete.Org: Mailing Lists: Archives: freeciv-dev: May 2003:
[Freeciv-Dev] Re: (PR#4038) Multiple starting points for PF
Home

[Freeciv-Dev] Re: (PR#4038) Multiple starting points for PF

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: undisclosed-recipients:;
Subject: [Freeciv-Dev] Re: (PR#4038) Multiple starting points for PF
From: "Raimar Falke" <rf13@xxxxxxxxxxxxxxxxx>
Date: Sat, 3 May 2003 08:50:23 -0700
Reply-to: rt@xxxxxxxxxxxxxx

On Sat, May 03, 2003 at 06:39:39AM -0700, Gregory Berkolaiko wrote:
> 
> On Tue, 22 Apr 2003, Raimar Falke wrote:
> 
> > On Sun, Apr 20, 2003 at 06:35:43AM -0700, Gregory Berkolaiko wrote:
> > > +/* Adds (possibly another) starting position to the map.  The 
> > > path-finding
> > > + * will try to find a path to each position from its _nearest_ starting 
> > > + * position. */
> > > +void pf_add_start_pos(struct pf_map *map, int x, int y, int cost, int 
> > > extra);
> > 
> > Hmmmm We should either add all starting positions to the parameter
> > struct as an array or remove the starting position from the
> > parameter. The solution of your patch is an special casting which I
> > think is unclean.
> 
> But I want to have a possibility of adding more starting positions while 
> pf-iteration is running.  The idea behind it is this:
> suppose you are on a boat near continent 1 and want to find a way to the 
> city inland.  To do it you first find the way to all the beaches by boat, 
> then put these beaches into a next map as starting positions and then 
> iterate the second map to find the second segment of your path.
> 
> But if you are quite close to your destination already, you don't want to 
> find the paths to _all_ the beaches first.  You want to start the second 
> iteration as soon as possible, so you can break it early!  So the second 
> iteration should already be running while the first is finding paths to 
> beaches further and further away...

Ok but then this should be the only way to add starting
positions. I.e. remove this from the parameter struct.

> Anyway, nonwithstanding this, here is a patch which changes the
> status of a tile from enum to a bit-vector.  It also introduces new
> flag S_START to denote a start position but there is no possibility
> of multiple starts yet.

With an enum you can't come across a NS_WAITING|NS_PROCESSED but you
can now. These states aren't orthogonal so bits are not the right
abstraction. Or not?

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "It is not yet possible to change operating system by writing
  to /proc/sys/kernel/ostype."              sysctl(2) man page




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