URL:
<http://gna.org/bugs/?15722>
Summary: Client-side goto turn estimation inaccurate with
waypoints
Project: Freeciv
Submitted by: jtn
Submitted on: Sunday 03/28/10 at 02:51
Category: client
Severity: 3 - Normal
Priority: 5 - Normal
Status: Ready For Test
Assigned to: jtn
Originator Email:
Open/Closed: Open
Release:
Discussion Lock: Any
Operating System: None
Planned Release:
_______________________________________________________
Details:
The client-side goto code shows a couple of issues with turn estimation when
setting waypoints:
* Long-standing (since 2.1 at least): when connecting (e.g., with road), I've
noticed that if I set waypoints along the route it would take anyway, the
number of turns displayed is different.
* Recent (regression on S2_2 since 2.2.0, also on S2_1, haven't traced its
arrival): ordinary [G]oto now adds a spurious turn every time you set a
waypoint if you're travelling along a railroad.
I've been noodling with this today and found a couple of contributory
causes:
* Silly mistake: connect was adding the connect_initial cost for every part
(waypoint) when it should only add it for the first.
* More seriously, the parts in the goto code deal in number of turns, which
means that fractional movement points cannot be carried from one part to the
next (as they are in the path-finding code), so adding waypoints introduced
rounding errors.
(These explain the connect error at least. I never tracked down where the
recent goto error was coming from, precisely.)
The attached patch:
* Changes the goto code's length calculations to be in terms of movement
points (scaled by SINGLE_MOVE) rather than turns, allowing fractional MP to
be carried between parts; the whole route is then converted into turns for
display.
* Also works scaled by ACTIVITY_FACTOR; this should give correct results for
units with fractional get_activity_rate() (possible with veteran settlers,
although I've not tested this).
I think this mostly affects just the reported turns and not the computed
route (except in the fractional get_activity_rate() case).
I've tested it with a variety of cases (engineers connecting, soldiers
moving, and planes moving) and I think I've solved the problems I noted above
and haven't obviously broken anything. However, the code could stand further
review and test. (Testing with S2_1 limited due to bug #15721.)
(I think this could equally be done by changing the path-finding code so that
it doesn't discount the initial movement points, and possibly takes an
optional initial cost as input so it can accumulate cost; this would simplify
the goto code since the PF code is already doing a lot of the same work.
However, that's a rather more invasive change and I haven't checked what
knock-on effects it might have.)
_______________________________________________________
File Attachments:
-------------------------------------------------------
Date: Sunday 03/28/10 at 02:51 Name: S2_1-waypoint-accuracy.diff Size: 6kB
By: jtn
S2_1/S2_2/trunk r17172: rework turn calculation in client-side goto
<http://gna.org/bugs/download.php?file_id=8700>
-------------------------------------------------------
Date: Sunday 03/28/10 at 02:51 Name: S2_2-waypoint-accuracy.diff Size: 6kB
By: jtn
S2_1/S2_2/trunk r17172: rework turn calculation in client-side goto
<http://gna.org/bugs/download.php?file_id=8701>
-------------------------------------------------------
Date: Sunday 03/28/10 at 02:51 Name: trunk-waypoint-accuracy.diff Size: 6kB
By: jtn
S2_1/S2_2/trunk r17172: rework turn calculation in client-side goto
<http://gna.org/bugs/download.php?file_id=8702>
_______________________________________________________
Reply to this item at:
<http://gna.org/bugs/?15722>
_______________________________________________
Message sent via/by Gna!
http://gna.org/
_______________________________________________
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
