Opened 4 years ago

Last modified 2 years ago

#5771 new defect

Orders are rejected in incorrect way [UnitAI]

Reported by: Silier Owned by:
Priority: Must Have Milestone: Backlog
Component: Simulation Keywords:
Cc: Patch: Phab:D3283

Description

All orders except few, which are ignored entirely, are rejected by calling FinishOrder. They are supposed to return {"discardOrder": true}

This is problematic, because it makes entity to leave current state and enter idle for no reason.
Effect can be seen in idle -> refused attack -> idle. In ideal world it would never leave idle state when order is refused.

Even function PushOrder is calling FinishOrder when only one order is in queue and that one was rejected. It should just remove that order from queue as done correctly in PushOrderFront.

Change History (10)

comment:1 by Silier, 4 years ago

Milestone: Alpha 24Backlog

probably will not happen in a24

comment:2 by Silier, 3 years ago

Milestone: BacklogWork In Progress
Owner: set to Freagarach
Patch: Phab:D3283

comment:3 by Freagarach, 3 years ago

Resolution: fixed
Status: newclosed

In 24956:

Properly discard orders.

Instead of manually calling FinishOrder(). Also, { "discardOrder": true } is changed to a const false.

Differential revision: D3283
Fixes: #5771
Comments by: @Angen, @Stan, @wraitii

comment:4 by Freagarach, 3 years ago

Milestone: Work In ProgressAlpha 25

comment:5 by wraitii, 3 years ago

Resolution: fixed
Status: closedreopened

comment:6 by wraitii, 3 years ago

In 24978:

Partial revert of rP24956 / REJECT_ORDER with FinishOrder()

Fixes rP24956, by partially reverting it.

If the new order is rejected, PushOrder() will call FinishOrder. If there are no more orders on the queue, this calls SetNextState("idle"), with the intention os switching the unit to IDLE. However, this only works from within an FSM call, and thus does nothing if a new command gets rejected.

The problem is that this.order/this.orderQueue is already replaced by the point the order is rejected when called via ReplaceOrder. Ideally, this would not happen (but doing so isn't trivial).

The current code avoids having 2 different ways to reject an order, thus isn't a complete revert of rP24956. It triggers an IDLE re-entry that wasn't there before if the unit is IDLE when it receives the rejected order, which at the moment basically never happens.

Refs #5771 (reopened)

Reported by: gameboy

Comments by: Freagarach, Angen

Differential Revision: https://code.wildfiregames.com/D3618

comment:7 by Freagarach, 3 years ago

Owner: Freagarach removed
Status: reopenednew

I abandoned the effort. Though I think this is still needed.

comment:8 by gameboy, 3 years ago

@wraitii Please help us !

comment:9 by wraitii, 3 years ago

Milestone: Alpha 25Alpha 26

comment:10 by Silier, 2 years ago

Milestone: Alpha 26Backlog
Note: See TracTickets for help on using tickets.