Complete.Org: Mailing Lists: Archives: freeciv-ai: September 2002:
[freeciv-ai] Re: [Freeciv-Dev] Re: [Patch] [RFC] Path finding version 14

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

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.

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.

>       Raimar


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