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

[Raimar Falke <rf13@xxxxxxxxxxxxxxxxx>]

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.

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

> > isn't a good one IMHO. My ordered list of goal for development is
> > still: correctness, maintainability, speed. Warmap had great speed but
> > low maintainability. You change this with PF but you can't get both
> > easily. Inlining is a good way to get speed without affecting
> > maintainability.
> 
> 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.

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

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

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

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
 - it will increase run-time because of extra function calls to
 map_get_known by the user functions.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "We just typed make..."
    -- Stephen Lambrigh, Director of Server Product Marketing at Informix,
                         about porting their Database to Linux