[Freeciv-Dev] Re: questions about agents

[Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>]

On Thu, Apr 04, 2002 at 12:05:41AM +0200, Per I. Mathisen wrote:
> On Wed, 3 Apr 2002, Raimar Falke wrote:
> > > > What are the current plans for Settler Management Agent?
> >
> > I will restart working on it if the new release is out.
> 
> Will this include autosettling of cities? Or just a replacement for
> the current autosettlers?

Cities will be included. Building cities has a benefit which is higher
by a factor of 10 than the benefits of "normal" improvements.

> > Long answer: The general idea is to create/copy-modify code which
> > handles the basic tasks (auto*) and also higher tasks in a fashion
> > which is ok for client side operation. This ai-code and the "classic"
> > server code will both be put into the CVS tree. If at some point the
> > "new" ai-code is as good as the "classic" one and the civbot is coded
> > the "classic" one can disabled/removed.
> 
> So you want to have two AIs simultaneously in development without sharing
> any code between them? Well, I can't say that sounds like an ideal
> situation to me.

Let it me say so: the code in ai/ is un-sharable for me. No problem if
the AI people want to reuse some of the agent code.

> > > > And move GOTO to the client (please)?
> >
> > We have three users of goto (server, client and agents). If we can
> > agree upon an interface and an implementation I would really to unify
> > this and create a common/goto.
> 
> Does the client need anything from the server to create a client-side
> goto, really?

No. Nethertheless we have a modified copy of server/gotohand in
client/goto. AFAIK this is mainly because of a different interface to
the map.

> I thought it had all it needed in the map structs it
> receives. Of course, then you can't have that cheesy "hey I can use GOTO
> to see what is land and what isn't even though I haven't explore this part
> of the map yet" effect, but I don't see that as a loss.

Problem is that server side gotos are also executed if the client
disconnects.

> > This isn't the plan. If you want to use agents at the server you have
> > to either use the civbot way or have to look at this for yourself.
> 
> So you are not opposed to, say, moving client/agents to common/agents, so
> that this code can be shared between client and server AIs?
> 
> (Not that I intend to do the work of implementing this for server-side.)

Not the whole agents. An agent per se is useless for the server
because the way it is called and communicates. However it is possible
to move the calculation functions to common/.

> > I see two points where we disagree:
> >  - where should be code be placed client/agents (maybe with common/) vs ai
> 
> ai/ is kind of a bastard directory. The ideal would be common/agents/,
> common/ai/ and server/ai/, but since we have ai/ already, we can just as
> well pretend it is server/ai/ for all intents and purposes.

Full ack.

> >  - whether we use the existing infrastructure in ai/ or not
> 
> I think we all agree that the current infrastructure sucks. But writing
> code useable both by client and server AIs means we give the client AI a
> head start when that time comes, while also improving the existing AI
> today.

The AI people can take a look and see what is useful from
client/agents/cma_core.c

> So perhaps we should start moving utility functions useful for both client
> and server AI into common/ai/ already?

goto is IMHO the first on the list.

> Also we should make some kind of policy on how to write server AI
> code so that it can be useful for client AI - ie don't use this or
> that server-only code/data that isn't available for client... I
> don't have any clue about that.

I don't see a problem here.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "- Amiga Y2K fixes (a bit late, wouldn't you say?)"
    -- Linus Torvalds about linux 2.4.0 at 4 Jan 2001