Complete.Org: Mailing Lists: Archives: freeciv-dev: January 2003:
[Freeciv-Dev] Multiple alliances was: Re: another fix
Home

[Freeciv-Dev] Multiple alliances was: Re: another fix

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Multiple alliances was: Re: another fix
From: Christian Knoke <chrisk@xxxxxxxx>
Date: Mon, 6 Jan 2003 13:02:34 +0100

On Mon, Jan 06, 2003 at 11:33:23AM +0000, Per I. Mathisen wrote:
> On Sun, 5 Jan 2003, Thomas Strub wrote:
> > I applied that and the problem with the rampage isn't solved 100%
> >
> > Attached is a savegame, start it, wait 4 rounds
> 
> Right. There are more bugs. This one took more than a few hours to track
> down.
> 
> It is rather subtle, as it involves three players in very specific
> diplomatic states with each other.
> 
> A is at war with C and allied to B
> B is allied to A and C
> C is at war with A and allied with B

You mean: allied(A,B) && allied(B,C) && at_war(A,C)

Just a thought: 

Given allied(A,B) && at_war(A,C). Why is whatever(B,C)-->allied(B,C)
possible at all?

> C attacks a tile that houses a city belonging to B and a unit belonging to
> A. According to can_unit_attack_unit_at_tile(), an attack on this tile is
> fine, 

This is strange. Why not require !at_war(A,C) before allied(B,C)?
If C declares war to A after this, do allied(B,C)-->peace(B,C).
If A declares war to C after this, do allied(A,B)-->peace(A,B).

So we can avoid having ally and enemy on the same tile.

General rule: declare_war(A-->B) implies cancel_alliance(A,i) for all
i with (allied(B,i) && allied(A,i)).

I think this is also more realistic.

Christian

-- 
Christian Knoke     * * *      http://www.enter.de/~c.knoke/
* * * * * * * * *  Ceterum censeo Microsoft esse dividendum.


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