[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 08:32:27PM +0100, Gregory Berkolaiko wrote:
> > 
> > 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.

   *    cost = BMC          (TM_NONE)
   *    cost = (turn + 1) * move_rate - moves_left (other cases).

I admit that the comments are a bit misplaced.

> BTW: EC can easily get larger than u_char.

Yes.  It's a rudiment.

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

It was introduced by you:
#if 1
        int cost_of_path=0;
#else
        int cost_of_path 
          = (the_map->params->get_COP 
             ? (*(the_map->params->get_COP))(cost, extra, 
                                             the_map->params->get_COP_data)
             : PF_COST_FACTOR * cost + extra );
        node_xy1->extra_cost = extra;
        node_xy1->cost = cost;
        node_xy1->dir_to_here = dir;
#endif

Sorry, but you cannot cut the code like this and then expect it to work.

>   2: both returned one
> 
>   2: pf_get_current_path: wrong directions recorded!
> 
> Bad.

See above.

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

Ditto.

>   2: problem (20,35) vs (21,37)
> 
> Bad.

That could in principle be my fault: the ECOT you specified wasn't 
supported by my code.

I will now diff your changes from my code and see if you left other mines 
in it ;)  Then fix the ECOT issue.

BTW, the code didn't compile straight away, there were some pf_ leftovers 
in civclient.c

G.