Complete.Org: Mailing Lists: Archives: freeciv-dev: July 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: Gregory Berkolaiko <Gregory.Berkolaiko@xxxxxxxxxxxx>
Cc: Freeciv Development List <freeciv-dev@xxxxxxxxxxx>
Subject: [Freeciv-Dev] Re: [RFC] Path finding implementation.
From: Raimar Falke <rf13@xxxxxxxxxxxxxxxxx>
Date: Tue, 30 Jul 2002 18:51:16 +0200

On Tue, Jul 30, 2002 at 05:30:16PM +0100, Gregory Berkolaiko wrote:
> On Tue, 30 Jul 2002, Raimar Falke wrote:
> 
> > On Tue, Jul 30, 2002 at 01:06:34PM +0100, Gregory Berkolaiko wrote:
> > > On Mon, 29 Jul 2002, Raimar Falke wrote:
> > > 
> > > > > so the name is not good, EC can be bigger than
> > > > > PF_MAX_EXTRA_COST, but it will effectively mean that we'd prefer a 
> > > > > longer
> > > > > but safer route.  Although I am not a big fan of this practice, I
> > > > > regocnize it might be useful.
> > > > > 
> > > > > But the EC supplied to safe-path routine should not exceed 
> > > > > PF_MAX_EXTRA_COST
> > > > 
> > > > I don't see how this will solve the problem above.
> > > 
> > > What is the problem above, maybe we are talking about different problems?
> > > Is it "to ensure that the frontier tiles will be dequeued basing on the 
> > > time that it takes to reach them, i.e. a tile that is (k+1)turns away 
> > > will 
> > > never be considered before a tile k turns away" ?
> > 
> > Yes this is the problem. Ok I try it another time: we have a position
> > and want all (micro) paths from this position which end in a safe
> > position in this turn. If they can go over safe tiles or not isn't the
> > problem here. We need the user-supplied ECOT because the path choosen
> > needs it. However this user-supplied ECOT can return such big ECOT
> > that a tile at (k+1)-turn is returned before a k-turn tile is
> > returned. It doesn't depend how you choose the ECOT and the COP
> > function. It was a design goal that you can compensate big ECOT with a
> > turn and vice versa.
> 
> Don't you think that asking a user to supply ECOT not exceeding 
> PF_BMC_FACTOR when also supplying is_position_dangerous call-back is 
> quite reasonable?

I think it is a restriction which can be removed quite easy. The
callback are a few lines and the code which calls the callback is also
only a few lines. This is nothing compared to the
is_position_dangerous support.

> Not incorrect but suboptimal.  Never mind for now.  I was just confused by 
> the the two calls to expand from macro_get_next_position

Feel free to optimize it.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "Are you saying that you actually used the Classpath Java AWT classes in 
  addition to the GTK peers and got them to display something?
  Wow.  That's way better than I did and I wrote the code!"
    -- Aaron M. Renn in the classpath mailing list


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