Complete.Org: Mailing Lists: Archives: freeciv-dev: February 2003:
[Freeciv-Dev] Re: (PR#2370) Path finding

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

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Raimar Falke <rf13@xxxxxxxxxxxxxxxxx>
Cc: "Per I. Mathisen" <per@xxxxxxxxxxx>, <freeciv-dev@xxxxxxxxxxx>
Subject: [Freeciv-Dev] Re: (PR#2370) Path finding
From: Gregory Berkolaiko <Gregory.Berkolaiko@xxxxxxxxxxxx>
Date: Wed, 19 Feb 2003 19:02:12 +0000 (GMT)

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.

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

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

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


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