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

[Gregory Berkolaiko <Gregory.Berkolaiko@xxxxxxxxxxxx>]

On Mon, 6 Jan 2003, 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."

Can we do it like it is done for movement with 
        can_unit_move_to_tile_with_notify ?

Which is essentially what Jason suggests.

> I am also quite sure that the goto check in the same code is superflous

What check?

> 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.

G.