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

[Gregory Berkolaiko <Gregory.Berkolaiko@xxxxxxxxxxxx>]

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

> > I am not sure what you cal "correctness".  If it's about following some 
> > sort of programming dogmas, then it should get stuffed.  If it's about 
> > treating zoc and known and all such things correctly, then the present 
> > interface allows user to request as correct a map as they wish.
> 
> Similar to the latter: it should not happen for example that the a
> position is returned which has a lower COP than a previously return
> position. It should not happen that total_BMC is calculated wrong and
> so on.

Okay.  That is certainly the main priority.

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

okay.

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

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

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

G.