[freeciv-ai] Re: Time to enemy city/unit

[Gregory Berkolaiko <Gregory.Berkolaiko@xxxxxxxxxxxx>]

Quoting "Per I. Mathisen" <per@xxxxxxxxxxx>:

> On Wed, 25 Dec 2002, Gregory Berkolaiko wrote:
> > This is the first step in my quest for unification of the above three
> > functions.
> 
> Into one function? Can you explain a little what this monster function
> would look like? I'm especially concerned with the number of variables
> passes to it...

Ugh, I guess I should say "standartisation" rather  than  "unification". 
Although ultimately I think process_attacker_want could be absorbed into
kill_something_with, since kill_something_with doesn't actually do anything of
any consequence.

> > Will be committed quite soon unless there are objections.
> 
> The patch looks very good overall. Now prospective developers won't be
> frightened with bedtime stories about the dreaded fstk anymore.
> 
> A few nitpicks, though:
> 
> +  if ( !(orig_move_type == SEA_MOVING || orig_move_type == LAND_MOVING) )
> {
>        ^                                                                ^
> I'd prefer no spaces there. Also != SEA_MOVING && != LAND_MOVING is
> better.

Ok.

> +    freelog(LOG_ERROR, "Attempting to deal with non-trivial move_type"
> +            "in process_attacker_want");
> +    return;
> 
> Add an assert, too, please.

Well, it's not a terrible error.  Ideally it would abort if DEBUG is defined and
carry on as normal if it is a released version.

Assert almost does it, but it requires NDEBUG to be defined to be switched off
and you say released versions are not compiled with NDEBUG.

> +/***************************************************************************
> + * A rough estimate of time (measured in turns) to get to the enemy city,
> + * taking into account ferry transfer.
> + * If boat == NULL, we will build a boat of type boattype right here, so
> + * we wouldn't have to walk to it.
> + *
> + * Requires ready warmap(s).  Assumes punit is ground or sailing.
> +
> ***************************************************************************/
> 
> I prefer not having those '*' in front of the function headers comment,
> and IIRC this is how most of the rest of the functions headers are as
> well.

I like to include those because it means emacs tab formatting works on the
comment, but if you insist... :)

G.