Complete.Org: Mailing Lists: Archives: freeciv-ai: December 2002:
[freeciv-ai] (PR#2633) ai_military_attack() bug#1
Home

[freeciv-ai] (PR#2633) ai_military_attack() bug#1

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: per@xxxxxxxxxxx
Cc: freeciv-ai@xxxxxxxxxxx
Subject: [freeciv-ai] (PR#2633) ai_military_attack() bug#1
From: "Gregory Berkolaiko via RT" <rt@xxxxxxxxxxxxxx>
Date: Tue, 24 Dec 2002 10:34:40 -0800
Reply-to: rt@xxxxxxxxxxxxxx

On Mon, 23 Dec 2002, Per I. Mathisen via RT wrote:

> @@ -1980,7 +2012,7 @@
>        repeat++;
>        if (!is_tiles_adjacent(punit->x, punit->y, dest_x, dest_y)
>            || !can_unit_attack_tile(punit, dest_x, dest_y)
> -          || could_unit_move_to_tile(punit, dest_x, dest_y) == 0) {
> +          || !could_unit_move_to_tile(punit, dest_x, dest_y) == 0) {
>          /* Can't attack or move usually means we are adjacent but
>           * on a ferry. This fixes the problem (usually). */
>          int i = ai_military_gothere(pplayer, punit, dest_x, dest_y);
> 
> We should only use ai_military_gothere() if we can't single-step into the
> tile. The comment is correct (but maybe a little misleading - the biggest
> reason to use gothere is when you are _not_ adjacent), while the code is
> wrong.

The condition was fine!  It was
        could_unit_move_to_tile(punit, dest_x, dest_y) == 0
which reads "could NOT move to tile".

(Or maybe it could not move because there is enemy there?).

Anyway, I committed it but then reverted it.  This piece of code is very 
confusing, so you really need to explain to me what is happening and what 
should be happening.

G.





[Prev in Thread] Current Thread [Next in Thread]
  • [freeciv-ai] (PR#2633) ai_military_attack() bug#1, Gregory Berkolaiko via RT <=