Complete.Org: Mailing Lists: Archives: freeciv-dev: February 2002:
[Freeciv-Dev] Re: patch: make ai understand peace and alliances 2 (PR#12
Home

[Freeciv-Dev] Re: patch: make ai understand peace and alliances 2 (PR#12

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: <freeciv-dev@xxxxxxxxxxx>
Subject: [Freeciv-Dev] Re: patch: make ai understand peace and alliances 2 (PR#1277)
From: "Per I. Mathisen" <Per.Inge.Mathisen@xxxxxxxxxxx>
Date: Mon, 25 Feb 2002 15:54:00 +0100 (MET)

On Mon, 25 Feb 2002, Petr Baudis wrote:
> I would rather like adding all these to README.AI (possible cleanup of it 
> would
> be nice as well) - having dozen of READMEs related to AI doesn't seem like a
> best idea to me.

Ok.

> Mentioning possibility to change that using the way like in your teams 
> patch..?

I'll add that to the teams patch instead. Foreshadowing patches that
aren't done yet is bad practice, IMHO. You never know when it'll be ready,
let alone when it will be accepted...

> I somewhat can't see the problems with modpacks.. :( Can please anyone
> enlighten me?

I'll take a hypothetical Middle-Earth modpack as example: Sauron and
MrBalrog start out as allies, at war with Elendil and Isildur, who are
allies. You cannot suddenly have Sauron, whom the AI controls, switch
sides to ally with Isildur, because some algorithm tells it this is the
cool thing to do. That is so not acceptable. So the AI must have contrains
on its ability to do active diplomacy, or it must be optional.

This _can_ be solved by teams. If they are on separate teams, the AI can
be forbidden to break an alliance with its team mates, or make peace with
another team. So in effect teams can be used to place constraints on AI's
active diplomacy as required for modpacks. But it is a crude way of doing
it.

> Ok, once more. I find the code w/o space after ',' MUCH harder to read.

I thought I managed to find all those before sending off the patch, but a
whole bunch of new one crept in while I wasn't looking. Sorry.

> B_PORT isn't a requirement, just an advantage of the city. Maybe it would be
> worth mentioning that it saves the results by modifying the goto destination.

Right. I'll fix that comment.

> The patch appears ok to me otherwise.

Thanks for looking at it.

Yours,
Per

"What we anticipate seldom occurs: but what we least expect generally
happens." -- Benjamin Disraeli



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