[freeciv-ai] Re: [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 02:51:22PM +0100, Gregory Berkolaiko wrote:
> > On Thu, 12 Sep 2002, Raimar Falke wrote:
> > 
> > Lots of comments now:
> > 
> > 1. In struct pf_position why would you need BMC_of_next_step and COP?
> 
> Both are information without a "hard" value. BMC_of_next_step could
> for example display in the GUI if the user chooses a path. No idea
> about COP.

I'll skip them for now, then.  BTW, user has the get_COP function and all 
info, so he can generate it easily if wanted.

> > 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?  And ignore_enemy = FALSE essentially amounts to 
using ZOC plus TB extensively.

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

> moves_left/move_rate" instead. But this is a float which we don't
> want.
> 
> > 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.

> > 6. Which heap is better performing?
> 
> Try for yourself. See my original posting. The difference is very
> minimal because the heap isn't the bottleneck.

Yes, sorry.

G.