bugFreeciv - Bugs: bug #21938, ORDER_FULL_MP waits if unit's move...

 
 
Show feedback again

bug #21938: ORDER_FULL_MP waits if unit's move rate is reduced after orders laid in

Submitted by:  Jacob Nevins <jtn>
Submitted on:  Sat 19 Apr 2014 04:32:58 PM UTC  
 
Category: NoneSeverity: 3 - Normal
Priority: 5 - NormalStatus: In Progress
Assigned to: pepeto <pepeto>Open/Closed: Open
Release: Operating System: Any
Planned Release: 

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Mon 19 May 2014 08:40:26 AM UTC, comment #2:

'<' 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.).

pepeto <pepeto>
Project MemberIn charge of this item.
Sat 19 Apr 2014 04:57:59 PM UTC, comment #1:

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).

Emmet Hikory <persia>
Project Member
Sat 19 Apr 2014 04:32:58 PM UTC, original submission:

While investigating bug #21932 I came across this in server-side execute_orders():

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.

Jacob Nevins <jtn>
Project Administrator

 

(Note: upload size limit is set to 1024 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by pepeto (Posted a comment)
  • -unavailable- added by persia (Posted a comment)
  • -unavailable- added by jtn (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 2 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Tue 02 Sep 2014 02:06:45 PM UTCpepetoAssigned toNone=>pepeto
    Tue 02 Sep 2014 02:06:44 PM UTCpepetoStatusNeed Info=>In Progress
    Show feedback again

    Back to the top


    Powered by Savane 3.1-cleanup