[Freeciv-Dev] (PR#9406) client-side goto takes too-long route

["Jason Short" <jdorje@xxxxxxxxxxxxxxxxxxxxx>]

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

The first two images here are examples of the same problem.  As
explained before, because the goto route considers the worst time only,
the two paths have identical times.  But of course on is constant-time,
while one has a chance (2/3 or 1/3 chance) of being better.

We can fix these particular scenarios by using the best time instead of
the worst time.  This is a matter of changing a single line (patch
attached).  However this may give other problems, because now we have
the opposite situation: if two patch have the same best time, but one
has a chance of being worse, they will be considered equal.  I think
this other situation is rarer.

Both situations are dangerous when "dangerous" terrain is involved I
think.  Using TM_WORST_TIME means you may end up going faster than you
expect and move onto a dangerous tile.  Using TM_BEST_TIME means you may
go slower than expected and not be able to make it off of a dangerous tile.

-jason

Index: client/goto.c
===================================================================
RCS file: /home/freeciv/CVS/freeciv/client/goto.c,v
retrieving revision 1.74.2.4
diff -u -r1.74.2.4 goto.c
--- client/goto.c       10 Nov 2004 02:10:23 -0000      1.74.2.4
+++ client/goto.c       7 Dec 2004 22:51:04 -0000
@@ -675,8 +675,11 @@
   }
 
   /* Note that in connect mode the "time" does not correspond to any actual
-   * move rate. */
-  parameter->turn_mode = TM_WORST_TIME;
+   * move rate.
+   *
+   * FIXME: for units traveling across dangerous terrains with partial MP
+   * (which is very rare) using TM_BEST_TIME could cause them to die. */
+  parameter->turn_mode = TM_BEST_TIME;
   parameter->start_tile = punit->tile;
 
   /* Omniscience is always FALSE in the client */