Complete.Org: Mailing Lists: Archives: freeciv-ai: April 2003:
[freeciv-ai] Re: [RFC] Ferry code
Home

[freeciv-ai] Re: [RFC] Ferry code

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Freeciv AI development <freeciv-ai@xxxxxxxxxxx>
Subject: [freeciv-ai] Re: [RFC] Ferry code
From: "Per I. Mathisen" <per@xxxxxxxxxxx>
Date: Sat, 5 Apr 2003 17:28:18 +0000 (GMT)

On Sat, 5 Apr 2003, Gregory Berkolaiko wrote:
> > Yes, but in any fully functional ferry system, actuallybuilding another
> > boat should be a fall-back. The primary goal is to find a ferry somewhere
> > and send it there.
>
> If building a ferry is only a fall-back, how will they ever get built?

Uh, we fall back to building a ferry when there isn't any to be found?

> In my proposal, when settler decides he will go through B, he will inform
> B and B will find and book the ferry. Note that actual ferry-searching
> happens only after the unit has decided on the port of embarkation.

That isn't very optimal. I'm not always for optimal solutions, but in this
case, I think we can get optimal results without big sacrifices, so let's
do it. Or at least try it :-)

> > The new settlers code requires ferrying to replace the existing code. I
> > have the old and new code working alongside each other (using
> > 'experimental'), so I could always put it in as a testbed for ferrying if
> > the other maintainers don't object to that. If that is an acceptable way
> > of proceeding, I'll fix up that code and post it for review.
>
> Sounds like a good plan.

Ok, I'll try to get around to it.

> To avoid flip-flopping, you need to remember why something is being built.

We can create a virtual unit that we stuff with the roles, gotos etc that
the real unit should have, then we can test this virtual unit each turn
whether its assignments are good. But this is for later.

  - Per



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