Complete.Org: Mailing Lists: Archives: freeciv-dev: September 2002:
[Freeciv-Dev] Re: [Patch] [RFC] Path finding version 14
Home

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

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Gregory Berkolaiko <Gregory.Berkolaiko@xxxxxxxxxxxx>
Cc: freeciv development list <freeciv-dev@xxxxxxxxxxx>
Subject: [Freeciv-Dev] Re: [Patch] [RFC] Path finding version 14
From: Raimar Falke <rf13@xxxxxxxxxxxxxxxxx>
Date: Mon, 16 Sep 2002 11:03:50 +0200

On Sun, Sep 15, 2002 at 04:48:19PM +0100, Gregory Berkolaiko wrote:
> 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.

Sorry I just want it to compile and your get_COP call was different
than my get_COP.

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

Who compiles clients? ;)

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "Your mail could not be delivered to the following Address:
  VTCMC.VTLPR@xxxxxxxxxxxxx        ** Unassigned error message **"


[Prev in Thread] Current Thread [Next in Thread]