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

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

[Top] [All Lists]

 To: Freeciv AI development Subject: [freeciv-ai] Re: [RFC] Ferry code From: Gregory Berkolaiko Date: Sat, 5 Apr 2003 18:15:24 +0100 (BST)

```On Sat, 5 Apr 2003, Per I. Mathisen wrote:

> On Sat, 5 Apr 2003, Gregory Berkolaiko wrote:
> > > > We make a big map for U to go to all coastal towns T(i)
> > >
> > > What if there are no coastal towns? In this case I suggest we make a
> > > temporary pick up point in the closest ocean adjacent tile to U.
> >
> > The problem with such pick-up points is that they cannot build boat (this
> > is the problem with Raimar's proposal too).
>
> Yes, but in any fully functional ferry system, actually building 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?

> > At this point the search time becomes exponential as we need to construct
> > sub-pf-map for each ferry to estimate time to T(i).
>
> An idle ferry is by definition in a city. Let's cache pf-maps for all
> cities. That will come in handy for a lot of purposes. We're going to do
> the calculations anyway in the danger code, so why not just store them.

We can.

> We need this (look for idle ferries in other cities) to get optimal ferry
> code. Take the situation: We have city A on continent 1 and city B on
> continent 2. A an B are very close. A has a settler that needs a ferry and
> B has an idle ferry.

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.

> 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.

> > Then I don't understand what you mean by AI build lists...
>
> A city build list (like a worklist), so if you are building a temple or
> something critical, we can schedule our ferry as the next production. This
> way we avoid flip-flopping production. But this isn't very important for a
> first implementation of ferries.

To avoid flip-flopping, you need to remember why something is being built.
Like, "we are building caravan in A to aid wonder in B".  Which means that
A has to be able to check if the goal still exists.  We are struggling to
do that even with the units (I mean that they choosetheir target anew
every turn).

G.

```