[Freeciv-Dev] Re: (PR#4538) [Bug] is_enemy_unit_tile sometimes doesn't w
[Top] [All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: |
undisclosed-recipients: ; |
Subject: |
[Freeciv-Dev] Re: (PR#4538) [Bug] is_enemy_unit_tile sometimes doesn't work in client. |
From: |
"Gregory Berkolaiko" <Gregory.Berkolaiko@xxxxxxxxxxxx> |
Date: |
Thu, 17 Jul 2003 04:37:52 -0700 |
Reply-to: |
rt@xxxxxxxxxxxxxx |
On Thu, 17 Jul 2003, Jason Short wrote:
>
> [glip - Fri Jul 11 18:11:05 2003]:
>
> > If you call, from the client, is_enemy_unit_tile on a tile containing
> > enemy unit in a city, the functio will return NULL. This so far only
> > causes problems for path finding but will also cause trouble for any
> > future client-side AI.
> >
> > Same problem applies to all is_*_unit_tile functions.
> >
> > Here we have a choice:
> > (1) fix all is_*_unit_tile functions,
> > or
> > (2) fix the functions which use them.
> > To do (1), the signature of the functions must be changed to bool (not
> > that it's ever used as a pointer).
> >
> > And a problem: the information given by a "occupied" flag over city is
> > not
> > complete. Enemy city may contain neutral unit. And for the fogged
> > city,
> > the occupied flag means nothing.
>
> Rather than return a punit, they could return a pplayer. This would
> keep the semantics of the function as far as most users are concerned,
> would continue to work even in the problem case you describe, and would
> allow certain usages (like is_non_allied_unit_tile in unithand.c) to
> continue to work.
>
> On the other hand, if they are called "is_***" they really should have
> boolean return values...
Return value aside, I think the resolution of this "bug" should be a
warning before these functions that one should be careful when using them
in the client.
G.
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Freeciv-Dev] Re: (PR#4538) [Bug] is_enemy_unit_tile sometimes doesn't work in client.,
Gregory Berkolaiko <=
|
|