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

[Freeciv-Dev] Re: [freeciv-ai] another fix

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: freeciv-dev <freeciv-dev@xxxxxxxxxxx>
Subject: [Freeciv-Dev] Re: [freeciv-ai] another fix
From: Jason Short <jdorje@xxxxxxxxxxxxxxxxxxxxx>
Date: 06 Jan 2003 14:16:08 -0500

On Mon, 2003-01-06 at 06:33, 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
> 
> 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, but the actual attack code has a few additional checks only found
> there, and one of those prevents an attack on an allied city even if there
> are hostile units there. That's nasty.
> 
> A proper fix would mean putting the checks inside
> can_unit_attack_unit_at_tile(). However, this means we'll lose the player
> feedback, a commend telling him/her why the attack failed. It would just
> say "Game: You can't attack there.", whereas now it says "Game:  Can't
> attack %s's unit in the city of %s because you are not at war with %s."
> 
> Nevertheless, the present state of affairs is clearly unacceptable. So I
> will make a patch that moves this extra check into the standard function.
> 
> I am also quite sure that the goto check in the same code is superflous
> for the AI now and can be conditioned for human use only (we now always
> set activity to idle before attacking and moving), and comment left behind
> that it should be removed as soon as client use of server-side goto is
> finally gone.

Either can_atack_unit_at_tile() should return the cause of the failed
attack (preferable IMO) or the AI should use a separate function to
check this information.

In doing it the first way, we could make the return value into an
enumeration of possible status values (one for each outcome) instead of
a boolean.  Or it could just return different integer values.  Either
way the function name will probably become inappropriate.

jason



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