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

[Raimar Falke <rf13@xxxxxxxxxxxxxxxxx>]

On Sat, Sep 14, 2002 at 03:56:16PM +0100, Gregory Berkolaiko wrote:
> 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.

Yes.

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

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

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

What code does the step forward in the 2-line function pf_next_get_position?

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
  Two OS engineers facing a petri net chart:
        "dead lock in four moves!"