Complete.Org: Mailing Lists: Archives: freeciv-ai: December 2003:
[freeciv-ai] Re: (PR#6935) AI sends transports with settlers off explori

[freeciv-ai] Re: (PR#6935) AI sends transports with settlers off explori

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: per@xxxxxxxxxxx
Subject: [freeciv-ai] Re: (PR#6935) AI sends transports with settlers off exploring
From: "Gregory Berkolaiko" <Gregory.Berkolaiko@xxxxxxxxxxxx>
Date: Wed, 3 Dec 2003 06:52:57 -0800
Reply-to: rt@xxxxxxxxxxx

<URL: >

On Tue, 2 Dec 2003, Per I. Mathisen wrote:

> <URL: >
> On Mon, 24 Nov 2003, Gregory Berkolaiko wrote:
> > > I might add that it already takes care of a very related situation:
> > > Reservations of tiles for city building. I have used this system to keep
> > > track of reservations for the new settlers system successfully, and it was
> > > not very forgiving about lost reservations.
> >
> > There is a crucial difference here. Settler going to build a city has
> > (1) special AIUNIT_BUILD_CITY role and (2) has a spot reserved. There is
> > no (1) without (2) and vice versa (in ideal code).
> >
> > But there is no AIUNIT_GOING_BY_BOAT role.
> But it does have a punit->ai.ferryboat reservation id tag. As long as it
> has this, it should be snatched up before ai_manage_military grabs it, and
> managed by gothere. If it cannot proceed there, then we can clear it.
> We should never give a unit a boat reservation and then ignore the boat
> (or vica versa). AFAIK we only assign a unit to a boat when we really
> need it, and only change this in the next iteration of ai_manage_unit.

I agree with you in principle.  The current system for military units is 
"forget where you were going, each turn do a full search of targets".  
This is wasteful and makes very hard to coordinate things (e.g. ferries).
However, when cleaning ferries I didn't want to redo the whole military 
units sytem as well.

The system "decide where you are going and then continue going there" is 
also not perfect.  Of course, you need to make basic sanity checks to see 
if going there still makes sense (for this you need to remember what did 
you want to do in the first place).  But it also means you ignore new 
opportunities that might arise.

But there are ways to fix it and it is the way forward.  This is how you 
did diplomats and settlers as I understand.

> I don't really understand how it could be otherwise. The entire ferry
> system you (re)wrote, Greg, is based on remembering passenger and ferry
> numbers. Even the 'find new captain' code depends on it, and fails now due
> to the arbitrary clearing of passenger info.

The system is based on remembering the numbers for one turn.  Because 
there is still too much code which will not care for these numbers.

> Just in case this was not clear: The problem is that the ferry _returns
> home with a valid passenger with a valid destination_. This should not be
> possible.
> > So yes, one can do all boat clearings through
> > ai_unit_new_role(punit, AIUNIT_NONE, -1, -1);
> > which needs to be issued in the very beginning of ai_military_findjob.
> This is a regression. This was how it was done back in the old day, when
> the AI was unable to carry out missions over more than a single turn. Is
> this really the way we want to go?

No, but unless you want to rewrite the whole military code _now_, the 
ferries need to be able to cope with inability of some code to carry out 
missions over more than a single turn.

> Maybe it is - so far only diplomats do it otherwise, and hunters to some
> extent do it too (though they are not yet in cvs), and diplomats may still
> have some problems due to it - occasionally getting blocked and becoming
> deadlocked - a very rare occurance but still a problem that would be
> solved if they would fully recalculate state every turn.

I have some ideas on it, we can start a different thread.

Back to stupid ferries: a quick hack is to move clear_ferry to 
ai_manage_military.  I suspect it might create other problems for 
settlers, but not as bad as the one you described.

I am working on a better solution, but I really haven't got much time.  
It might take another 2 months before I am able to make a good fix.


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