[Freeciv-Dev] Re: [Patch] [RFC] Path finding version 14

[Raimar Falke <rf13@xxxxxxxxxxxxxxxxx>]

On Sat, Sep 14, 2002 at 06:11:44PM +0100, Gregory Berkolaiko wrote:
> On Sat, 14 Sep 2002, Raimar Falke wrote:
> 
> > On Sat, Sep 14, 2002 at 03:56:16PM +0100, Gregory Berkolaiko wrote:
> > > On Sat, 14 Sep 2002, Raimar Falke wrote:
> > > 
> > > > > 2. What are ignore_enemy and omniscience and why these options
> > > > > cannot be implemented through the already existing callbacks?
> > > > 
> > > > I added them to be able to compare path finding to the current warmap
> > > > which avoid some checks. And no these flags can't implemented through
> > > > the existing callbacks.
> > > 
> > > Correct me if I'm wrong: 
> > 
> > > omni = TRUE is essentially returning TILE_KNOWN for every tile,
> > > isn't it?
> > 
> > Yes. But faster. And speed was the reason for these two flags.
> > 
> > > And ignore_enemy = FALSE essentially amounts to using ZOC plus TB
> > > extensively.
> > 
> > No. ignore_enemy=TRUE also avoids the test if we can attack.
> 
> By default I don't make these checks but they can be done in the TB 
> function if wanted.

Yes I slowly come also this this conclusion.

> > > > > 3. Usual objections to get_COP.  I think the parameters to this 
> > > > > useless 
> > > > > function should be (int TEC, int cost, void *), where cost is either 
> > > > > BMC 
> > > > > or (turn + 1) * move_rate - moves_left.
> > > > 
> > > > I though about this and the term "(turn + 1) * move_rate - moves_left"
> > > > is bad. If you use EC in some way you have to scale the EC by
> > > > move_rate. You don't want this. You want the term "turn +
> > > 
> > > I don't quite understand what you mean, but following your logic we'd 
> > > need 
> > > BMC/move_rate too.
> > 
> > Yes.
> 
> BMC and (turn + 1) * move_rate - moves_left have the same scale.  For 
> uniformity we should supply them and not some derivatives.

If we have a standard COP formula should use something other. If we
stick with get_COP this doesn't matter.

> > > > > 4. I thought pf_next_get_position should be non-destructive, just 
> > > > > lifting 
> > > > > info.
> > > > 
> > > > I don't understand:
> > > > 
> > > > void pf_next_get_position(pf_map_t pf_map, struct pf_position *pos)
> > > > {
> > > >   assert(pf_map->last_pos_is_valid);
> > > >   memcpy(pos, &pf_map->last_pos, sizeof(*pos));
> > > > }
> > > > 
> > > > It is clear that we have to overwrite the pos from the caller.
> > > 
> > > Sure.  I mean the other parameter: the map.  I thought (and still think)
> > > that pf_next_get_position should simply read off the position, without 
> > > iterating the map one step forward, this is the job for pf_next.  But 
> > > this 
> > > issue is non-critical.
> > 
> > What code does the step forward in the 2-line function pf_next_get_position?
> 
> Obviously I meant pf_next_get_path all the way.  Sorry.  But the comment 
> still applies.

I still don't understand. pf_next_get_path will not do any extra
iteration steps.

> 5.  What is the last argument to enum known_type (*get_known) (int,
> int, struct player *,int) ?

Good question. Should be removed. No idea how it got there.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "I haven't lost my mind - it's backed up on tape somewhere."