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

[Gregory Berkolaiko <Gregory.Berkolaiko@xxxxxxxxxxxx>]

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.

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

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

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

G.