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

[Raimar Falke <rf13@xxxxxxxxxxxxxxxxx>]

On Sat, Sep 14, 2002 at 08:32:27PM +0100, Gregory Berkolaiko wrote:
> On Sat, 14 Sep 2002, Raimar Falke wrote:
> 
> > On Sat, Sep 14, 2002 at 07:17:48PM +0100, Gregory Berkolaiko wrote:
> > > 
> > > True true.  Your naming confused the hell out of me: 
> > > plain_get_next_position is the function behind pf_next and not behind 
> > > pf_get_next_position as a sane person would expect :)
> > 
> > There is no pf_get_next_position (except in an old comment). There is
> > a pf_next_get_position. It is quite simple:
> >   - there is pf_get_path
> >   - and there is pf_next and the query functions pf_next_*
> > 
> > And the implementation has:
> >  - plain_get_path (called by pf_get_path and pf_next_get_path) and
> >  - plain_get_next_position (called by pf_next)
> 
> So there is
>       pf_next_get_position    
> and
>       plain_get_next_position 
> but they are complitely unrelated.
> 
> I call this confusing.
> 
> > > > > 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.
> > > 
> > > How did it compile with this?
> > 
> > A constant 0 is supplied.
> 
> Why not 42? :)
> 
> Anyway, my code is roughly ready.  It's still wet behind the ears but 
> unless it's picked, there is no need to wash it.  Among other things, it 
> _doesn't_ support is_position_dangerous yet.

> What sort of test shall we run?  How about finding and printing paths to
> Michoacan for all units repeated N times in the attached savegame (login
> aas02101)?

See the new common/test_path_finding

> The path_finding[ch] attached.  Don't fry me please.  If you see
> something that your code does and my doesn't (probably lots of
> things) please tell me.

I have changed some code to make it compile at all and to get it
compiling with my path_finding.h file. The splitup of
path_finding_common.h is only temporary. The weird get_ECOT in
common/test_path_finding is so that this case "If two paths have equal
COP the behavior is undefined." doesn't matter.

Per: this is a good example why I use terms like BMC, EC or
COP. Gregory has:

  u_char cost;                    /* total cost up to now */

Now tell me what kind of cost this is. The comment also doesn't help
here.

BTW: EC can easily get larger than u_char.

Gregory: it would be nice if you audit my changes and than work on the
differences like this one:

  2: both returned one
  2: PF: path (at 0xbfffdad0) is valid
  2: PF:  consists of 2 positions:
  2: PF:    0/   2: (20,36) t/m= 0/ 3 dir=NW/ 3 BMC= 0 EC=0 COP=0
  2: PF:    1/   2: (19,35) t/m=-1/-1 dir=--/-1 BMC= 3 EC=351900 COP=351903
  2: PF: path (at 0xbfffbe80) is valid
  2: PF:  consists of 2 positions:
  2: PF:    0/   2: (20,36) t/m=-1/-1 dir=NW/ 0 BMC= 0 EC=0 COP=0
  2: PF:    1/   2: (19,35) t/m=-1/-1 dir=--/ 0 BMC=255 EC=0 COP=0
  2: both returned (19,35)

Ok till here. Well the extra info of the GB path look weird but this
is only a minor problem.

  2: both returned one

  2: pf_get_current_path: wrong directions recorded!

Bad.

  2: PF: path (at 0xbfffdad0) is valid
  2: PF:  consists of 2 positions:
  2: PF:    0/   2: (20,36) t/m= 0/ 3 dir=N / 3 BMC= 0 EC=0 COP=0
  2: PF:    1/   2: (20,35) t/m=-1/-1 dir=--/-1 BMC= 3 EC=352000 COP=352003

  2: PF: path (at 0xbfffbe80) is invalid

Bad.

  2: problem (20,35) vs (21,37)

Bad.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "SIGDANGER - The System is likely to crash soon"

path_x.diff.gz
Description: application/gunzip