Complete.Org: Mailing Lists: Archives: freeciv-ai: November 2002:
[freeciv-ai] Re: patch/rfc: goto and move/attack test wrapping
Home

[freeciv-ai] Re: patch/rfc: goto and move/attack test wrapping

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: "Per I. Mathisen" <per@xxxxxxxxxxx>
Cc: freeciv-ai@xxxxxxxxxxx
Subject: [freeciv-ai] Re: patch/rfc: goto and move/attack test wrapping
From: Gregory Berkolaiko <Gregory.Berkolaiko@xxxxxxxxxxxx>
Date: Wed, 27 Nov 2002 16:30:49 +0000 (GMT)

On Mon, 18 Nov 2002, Per I. Mathisen wrote:

> Taken from massive ai. Unless I get disagreeing comments, I will commit
> these wrappers and the associated changes in the rest of the code.
> 
> This is an important API decision so please consider it carefully.
> 
> gothere is used for goto over several turns and goto with ferries, and is
> the one which should eventually be expanded into a replacement for
> military and settler gothere with associated ferrying capability. Before
> calling it, always set goto destination explicitly.
> 
> goto is for one-turn gotos, for example run off and attack a target of
> opportunity. It will _retain_ existing goto destination and role, ie it is
> non-destructive for existing missions.

And some general comments:  

There should be clean separation of data structures as well.  For example
AIUNIT_ should describe what unit is doing strategically and ACTIVITY_ is
what it is doing tactically.  I think it is the current situation anyway,
with few exceptions.  Then, for example, ACTIVITY_PATROL and
ACTIVITY_EXPLORE fall into AIUNIT_ category. ACTIVITY_GOTO is probably
okay for an activity.

Same should be done for goto destination data.  There should be a struct 
with ACTIVITY_GOTO destination (local target) and also global destination 
for the AIUNIT-type tasks.

Then the necessity of goto-wrapper will disappear and Ross' complaints 
will be answered.

G.



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