[Freeciv-Dev] Re: (PR#2370) Path finding

[Raimar Falke <rf13@xxxxxxxxxxxxxxxxx>]

On Wed, Feb 19, 2003 at 08:20:11PM +0000, Gregory Berkolaiko wrote:
> On Wed, 19 Feb 2003, Raimar Falke wrote:
> 
> > On Wed, Feb 19, 2003 at 07:02:12PM +0000, Gregory Berkolaiko wrote:
> > > On Wed, 19 Feb 2003, Raimar Falke wrote:
> > > 
> > > > On Wed, Feb 19, 2003 at 09:28:49AM +0000, Gregory Berkolaiko wrote:
> > > > 
> > > > > Attached is my attempt to minimize the interface.  Not hugely
> > > > > successful.  If you can see what else can we ditch, please point it
> > > > > out to me.  I think we can get rid of get_TB, since get_cost
> > > > > callback can absorb it easily.  It wouldn't be possible to cache TB
> > > > > but is caching really helping the speed?
> > > > 
> > > > It is get_BMC and not get_cost.
> > > 
> > > I never liked BMC or for that matter any of the abbreviations.  They are 
> > > not user-friendly and so reduce maintainability.
> > 
> > "cost" is just too general.
> 
> move_cost ?

Same. You can use any name you like in the implementation but the
interface should stay clean.

> better than BMC...

> > > > We _could_ merge get_BMC, get_ECOT and get_TB into one function (which
> > > > would be similar to get_COP) but I don't see the reason for it. Speed
> > > 
> > > merging extra_cost and cost is not good because then you cannot lift the 
> > > number of steps.
> > 
> > I don't understand. "number of steps"?
> 
> Ooops, sorry.  Number of turns to dest.  Extra cost will get in the way if 
> the callback returns just COS (cost of the step).

Yes you are right we would need to return two values ECOT and
BMC_merged_with_TB.

> > > > > Anyway, I hope you find new interface ok.
> > > > 
> > > > We can remove 
> > > > +  struct player *owner;
> > > > +
> > > > +  bool zoc_used;
> > > > +  bool omniscience;
> > > > 
> > > > and also the tile-known management.
> > > 
> > > While it is nice to see you trying to get rid of some cruft, I don't 
> > > think 
> > > we should sacrifice the essential bits.  Tile-known management is quite 
> > > important, otherwise client-side is in difficulty and also we are forever 
> > > bound to know-all AI.
> > 
> > I don't see the link. Lets see where known is used:
> > 
> > +  if (node1->node_known_type == TILE_UNKNOWN) {
> > +    return MOVE_COST_UNKNOWN;
> > +  }
> > 
> > get be done in get_BMC.
> 
> get = can?

Yes.

> > +    node->behavior =
> > +        params->get_TB(x, y, node->node_known_type, params->get_TB_data);
> > 
> > +    node->extra_tile =
> > +        params->get_ECOT(x, y, node->node_known_type,
> > +                         params->get_ECOT_data);
> > 
> > Both can be done in the callbacks.
> 
> You mean both requests for the known type?  I agree.

The known parameter is removed from the signatures and the called
functions query the known state by itself if required.

> > > Owner is needed to be passed to get_known function. Treating ZoC is
> > > the same.  All of it could be fused into get_cost callbacks though.
> > > Should we do that?
> > 
> > ZoC should be done in get_TB. I'm against merging them because the
> > callback function will get big and complicated. At least I think so.
> 
> ZoC cannot be done in get_TB, because move_ZoC_allowed is a two-tile 
> function and TB is one-tile function

Correct. Than we could add ZoC handling to get_BMC.

> > About the known-management: if we remove it from the core code:
> >  - it will reduce the number of parameters
> >  - it will reduce the size of the cell/node
> 
> true.  Less memory -- faster.
> 
> >  - it will increase run-time because of extra function calls to
> >  map_get_known by the user functions.

> mind you, caching can still be done through void *data parameter.
> We can pass pointer to caching map.

Can you explain more?

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "Transported to a surreal landscape, a young girl kills the first woman
  she meets and then teams up with three complete strangers to kill again."
    -- TV listing for the Wizard of Oz in the Marin Independent Journal