[Freeciv-Dev] Re: (PR#7282) Patch: connect as orders

["Gregory Berkolaiko" <Gregory.Berkolaiko@xxxxxxxxxxxxx>]

<URL: http://rt.freeciv.org/Ticket/Display.html?id=7282 >

On Sun, 8 Aug 2004, Jason Short wrote:

> <URL: http://rt.freeciv.org/Ticket/Display.html?id=7282 >
>
> So I updated this patch, following Greg's idea that the MC should
> contain either 0 or 1 (actually I made it SINGLE_MOVE) to look for
> either the minimal path or to not care about distance.  Meanwhile the EC
> (actually moveEC) gives the construction time (travel time plus build
> time), which is used as the tiebreaker.
>
> This worked okay but ran into a problem: in goto mode it shows the
> number of turns for the orders path, and with the above algorithm this
> number is entirely inaccurate.  There are three ways I can see around this:

0: in goto.c:update_last_part, line 199
change from
  p->time = pf_last_position(p->path)->turn;
to
  p->time = (hover_state == HOVER_CONNECT
             ? pf_last_position(p->path)->total_EC / SINGLE_MOVE
             : pf_last_position(p->path)->turn);

> 1.  Don't show the number of turns in connect mode.  The problem is the
> user probably wants to know the number of turns!
>
> 2.  Use the original (using only MC) algorithm for connect mode.  This
> is slightly less accurate but will show the approximate number of turns.
>  However when I do this I now get this error:
>
> 0: illegal TM in path-finding with danger
> civclient: shared.c:667: real_die: Assertion `0' failed.
>
> because TM_NONE doesn't seem to work.  This is odd because this isn't a
> danger path (but is it true that all paths are danger paths now?).

Hmmm.  It was you who committed the patch which made all path dangerous,
wasn't it?
And I strongly suggest to set is_pos_dangerous in
fill_client_goto_parameter to NULL whenever HOVER_CONNECT, because
1. Danger code will be highly confused.
2. I only taught non-danger PF to recognize moveEC.

> 3.  Change PF yet again to have a BC (base cost).  The base cost works
> like the extra cost, but its priority is _higher_ than the move cost's,
> not lower.  This will give ideal results but is probably not worth the
> added complexity.

It is better to make a user-defined callback which combines MC and EC into
one "goodness of path" number.

G.