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: "Ross W. Wetmore" <rwetmore@xxxxxxxxxxxx>
Cc: freeciv development list <freeciv-dev@xxxxxxxxxxx>, freeciv-ai@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: [Patch] [RFC] Path finding version 14
From: Raimar Falke <rf13@xxxxxxxxxxxxxxxxx>
Date: Fri, 13 Sep 2002 15:55:08 +0200

On Fri, Sep 13, 2002 at 09:49:42AM -0400, Ross W. Wetmore wrote:
> At 08:06 PM 02/09/12 +0200, Raimar Falke wrote:
> >On Thu, Aug 15, 2002 at 09:59:18AM +0200, Raimar Falke wrote:
> >> 
> >> Changes to the interface
> >>  - remove PF_IGNORE_COST
> >>  - add enum tile_behavior
> >>  - add get_TB
> >>  - add ignore_enemy and omniscience flags
> >> 
> >> The first three should be obvious. I will explain the last one latter.
> >> 
> >> Changes to the implementation:
> >>  - add bucket list heap (activate with USE_HEAP2)
> >>  - add some inlining (activate with USE_INLINE) This is a moderate
> >>  inline which brings the path finding in the same area as
> >>  really_generate_warmap. The 8 small helper function are all moved
> >>  into plain_get_next_position and so plain_get_next_position and
> >>  really_generate_warmap are now the big functions.
> >>  - support for the get_TB, ignore_enemy and omniscience
> >>  - added a missing heap_destroy call
> >
> >And a new version. Changes:
> > - remove the testing path finding user from gotohand.c
> > - add some documentation and license headers
> >
> >There were no comments on the last version. So I would think that this
> >version can be applied next week if there are no comments/objections.
> 
> The initial comments have not been addressed and still apply.

> This interface is both overly restrictive and heavy weight in what it does
> and insufficiently flexible to accommodate any reasonable extensions. It
> does not clearly separate the core iteration algorithms from the user
> modifiable condition set and allow arbitrary user conditions to be
> implemented on an as needed basis. It is clearly a wrong approach to the
> general problem.

What flexibility is required? What do you think about the current
warmap-interface? If it has defects what would you change? Should any
new interface support special cases like triremes?

> But if you wish to use this in your agent code there are no objections.

> Hopefully it will never be used in the core AI routines where speed and
> flexibility are stronger requirements.

Per thinks about using the path finding for the server AI.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "Just because you put a flag on the moon doesn't make it yours, it just
  puts a hole in the moon."


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