[Freeciv-Dev] [bug #21938] ORDER_FULL_MP waits if unit's move rate is reduced after orders laid in
Update of bug #21938 (project freeciv): Status: Need Info = In Progress Assigned to:None = pepeto ___ Reply to this item at: http://gna.org/bugs/?21938 ___ Message posté via/par Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #21938] ORDER_FULL_MP waits if unit's move rate is reduced after orders laid in
Follow-up Comment #2, bug #21938 (project freeciv): '' looks the correct thing. I don't think we should cancel path or recalculate path if the move rate was changed. Or at least not at server side (anyway the AI recalculates path every turns). And I think this is a separated issue. Not that computed paths have many other ways to become obsolete (terrain changes, infrastructure built/removed, non-allied unit moves etc.). ___ Reply to this item at: http://gna.org/bugs/?21938 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #21938] ORDER_FULL_MP waits if unit's move rate is reduced after orders laid in
URL:
http://gna.org/bugs/?21938
Summary: ORDER_FULL_MP waits if unit's move rate is reduced
after orders laid in
Project: Freeciv
Submitted by: jtn
Submitted on: Sat 19 Apr 2014 17:32:58 BST
Category: None
Severity: 3 - Normal
Priority: 5 - Normal
Status: Need Info
Assigned to: None
Originator Email:
Open/Closed: Open
Release:
Discussion Lock: Any
Operating System: Any
Planned Release:
___
Details:
While investigating bug #21932 I came across this in server-side
execute_orders():
case ORDER_FULL_MP:
if (punit-moves_left != unit_move_rate(punit)) {
/* If the unit doesn't have full MP then it just waits until the
* next turn. We assume that the next turn it will have full MP
* (there's no check for that). */
punit-done_moving = TRUE;
/* ... */
}
The != condition looks like it's intended for the common case where moves_left
move_rate, but it looks suspicious to me in the case where a unit's
moves_left is _greater_ than its current move_rate (due to the loss this turn
of some Move_Bonus effect from wonder or tech loss). The unit will waste its
current excess of movement points sitting around doing nothing.
On the other hand, surely the client-side pathfinding algorithm wouldn't have
inserted ORDER_FULL_MP in any such case for the current turn, so it seems
harmless. (Indeed, this check should never fail for input from the pathfinding
algorithm, I'd have thought.)
And if a unit's move rate reduces, any pre-calculated orders are potentially
dangerously wrong, for fueled units. So it's not clear to me what would be
better to put here. (Arguably we should try to cancel orders of units whose
move rate reduces.)
Raising the bug to get others' opinion; it might well get closed Wont Fix or
Invalid.
___
Reply to this item at:
http://gna.org/bugs/?21938
___
Message sent via/by Gna!
http://gna.org/
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #21938] ORDER_FULL_MP waits if unit's move rate is reduced after orders laid in
Follow-up Comment #1, bug #21938 (project freeciv): To my mind, changing this to be = rather than != would be a safe and harmless change. Note that pathfinding is going to ignore any potentially available extra moves (as it considers the path for the *unit class*, with some type attributes, but not the path for the unit itself), so the unit will only benefit from unit_move_rate() moves for any calculated paths. For the second issue, units should probably recalculate paths for GoTo and Connect on any turn change and on any change in move rate (one can easily gain a technology mid-turn, which has examples in the default rules both increasing and decreasing move_rate (decrease through wonder obsolescence)). While critical for fueled units who might otherwise be destroyed due to inability to complete given orders, such reconsideration is likely to cause other units to take advantage of changing conditions (settler passing through a city decides to use newly created road, rather than climbing the mountains, etc.). Dunno what the right UI for this is though: the current UI shows the planned path, and folk who really care about details might get annoyed if that wasn't the followed path. My personal preference would be to not cancel orders just because the move rate changed, if the unit can still complete the orders, or otherwise reach the final destination within approximately the same number of turns. When fighting an air-supported war on multiple fronts, I generally assign aircraft to fronts at build-time, expecting them to arrive to battle in perhaps 4-6 turns. If the path is interrupted, I have no context to know where that aircraft wanted to go (and while I'd rather be able to recover the unit than have it destroyed, I don't want to have to remanage *all* my units just because I learned a new tech or finally completed a wonder, or whatever). ___ Reply to this item at: http://gna.org/bugs/?21938 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
