[Freeciv-Dev] Re: questions about agents

[Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>]

On Wed, Apr 03, 2002 at 04:27:22PM -0600, Mike Kaufman wrote:
> > > citizen management, autosettler, autoexplore, etc are more
> > > mundane things that the human client hands off to the ai to do. 
> > 
> > > It's code duplication and bad practice to have two different sets of
> > > code do citizen management.
> > 
> > I agree. But the code in ai/ left me with no other choice. If some
> > poor soul want to adapt the ai to use code of the CMA feel free
> > so. However the resulting extract should be placed in common.
> 
> well, some poor soul really needs to, but the resulting extract should
> absolutely not be in common/, it should be in ai/. common/ is [should be] for
> code that is common to the client and server. the server should have
> nothing at all to do with the core cma functions. It shouldn't even know
> they exist. For now of course, since the ai library is needed by the server
> (by virtue of the server running the ai), it will see it.

The client currently doesn't need libcivai.a. This is good this so. I
don't want to change this. The ai directory is for the server ai
only. So it should really be moved to server/ai/.

> > > Agents should do two things. Get directives from the client to tell the 
> > > ai 
> > > what to do and then request the server to do that thing. Using CMA as an
> > > example, the agent should 1. get the goals from the client gui and ask the
> > > ai function what worker arrangement best satisfies that goal directive. 2.
> > > then send some packets to the server requesting worker rearrangement. All
> > > the actually calculation should accomplished in ai/
> > > 
> > > Actually this might be a good first step toward a more rigorous ai
> > > advisor type setup. The advisor in advdomestic.c presents goals---just 
> > > like
> > > the human client---to the core cma code which returns the best 
> > > arrangement.
> > > The advisor then implements that arrangement in the current server-ai
> > > setup, or will send requests to the server in the future client-ai setup.
> > > 
> > > another example is the autoexplorer. Right now, we hand the unit off to 
> > > the
> > > server which calls ai_manage_explorer. In a perfect world, the server
> > > should not be the one doing this. There should be an agent which manages
> > > all the autoexplorers doing the calls into ai_manage_explorer, and then
> > > send destination or move info to the server through the regular request
> > > packets.
> > 
> > I see two points where we disagree:
> >  - where should be code be placed client/agents (maybe with common/) vs ai
> >  - whether we use the existing infrastructure in ai/ or not
> 
> see above on the first. I'm not sure I see your position. The agents code
> itself should be in client/agents. The code it interacts with should be in
> ai/ on the one hand, and packhand/guis on the other. Why would you have it
> otherwise?

For you the agents are just a glue between the real ai functions and
the GUI?! Right?. For me the agents include the real ai functions.

> as for the second point, I want to do: for the interim add new files in ai/
> that house the cma, sma, etc core functions. agents will use those
> functions right off the bat. The functions should be general enough so that
> ai can eventually use them. When we're ready, we punt the old worker
> management and autosettlers code off the end of a pier (though some of the
> old worker management stuff should be folded into the "city advisor")
> 
> What do you want to do that's different than this?

As I said I don't want the client to use the ai directory. Merging the
two ais wasn't in the plan. Instead of putting them in ai/ and
connecting them I want to put the common part (the core calculation
methods) into common/(ai/).

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "This is Linux Country. On a quiet night, you can hear Windows reboot."