Complete.Org: Mailing Lists: Archives: freeciv-dev: January 2003:
[Freeciv-Dev] Re: (PR#2290) [rff] onsetwar
Home

[Freeciv-Dev] Re: (PR#2290) [rff] onsetwar

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: ue80@xxxxxxxxxxxxxxxxxxx
Cc: freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: (PR#2290) [rff] onsetwar
From: "Per I. Mathisen via RT" <rt@xxxxxxxxxxxxxx>
Date: Mon, 27 Jan 2003 14:58:09 -0800
Reply-to: rt@xxxxxxxxxxxxxx

I've done some more reading on this patch, and noticed more
problems:
 - The checks for whether a diplomat can perform an action must also be
put in common/unit.c's is_diplomat_action_available()
 - The checks for whether a unit can attack another unit must also be put
in server/unittools.c's can_unit_attack_unit_at_tile().
 - It conflicts year2turn patch, and we need to consider whether onsetwar
should be given as turns instead of years.
 - I don't like the change to pplayers_at_war() since it reports a wrong
result: The diplomatic state _is_ war, but it says it isn't. This is bad.
 - It conflicts with AI diplomacy patch in giving this new behaviour to
pplayers_at_war(). The former patch expects this function to behave in the
old way big time.
 - The AI has no idea about onsetwar without this hack.

The solution to the pplayers_at_war() problem would be to prevent a player
from getting to the DS_WAR state in the first place, and make AIs go to
DS_NEUTRAL until onsetwar. However, then a way to set them to DS_WAR again
when onsetwar elapses is needed.

In some ways doing onsetwar after the AI diplomacy patch would be simpler,
since it would give the framework to handle such an option correctly,
since the AI knows about diplomatic states and how to change them. But
that patch may take some time to finalize.

Another solution is to let the AI skip onsetwar and attack freely anyway,
but I suppose that would defeat part of the reason for the patch in the
first place.

  - Per




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