#779 closed defect (fixed)
Villagers stuck on construction sites
Reported by: | James Baillie | Owned by: | philip |
---|---|---|---|
Priority: | Should Have | Milestone: | Alpha 5 |
Component: | UI & Simulation | Keywords: | |
Cc: | Patch: |
Description
Essentially, pre-tasked villagers or troops can get trapped on construction sites if they walk onto them between placement and construction starting; they carry on trying to walk across them, and get stuck. The building remains on 0HP, and they remain stationary. Subsequent troops will also get stuck, and for an AI player this can cause economic wreckage.
Change History (16)
comment:1 by , 13 years ago
follow-up: 5 comment:2 by , 13 years ago
There was a similar-sounding problem in the past (particularly in multiplayer games with long turn lengths), but r9035 (before Alpha 4) fixed it so I'm not sure in what situations this would still be an issue.
comment:4 by , 13 years ago
Milestone: | Backlog → Alpha 5 |
---|---|
Priority: | Should Have → Release Blocker |
comment:5 by , 13 years ago
Replying to Philip:
There was a similar-sounding problem in the past (particularly in multiplayer games with long turn lengths), but r9035 (before Alpha 4) fixed it so I'm not sure in what situations this would still be an issue.
I've seen it happen with AIs, I think you need a lot of units trying to build at once and a few in the foundation moving elsewhere. At first I thought perhaps the orders can conflict so they become deadlocked, but I'm not sure if that's possible.
comment:6 by , 13 years ago
Owner: | set to |
---|
comment:7 by , 13 years ago
Milestone: | Alpha 5 → Alpha 6 |
---|
comment:8 by , 13 years ago
follow-up: 10 comment:9 by , 13 years ago
Priority: | Release Blocker → Should Have |
---|
I don't know if this is a complete fix, since I assume AI doesn't put units into non-default formations so maybe it's hitting a different problem (but I can't imagine what). Need to either have some precise steps to reproduce if it's still a problem for AI, or just assume that it's okay.
(Not a release blocker in any case since it's seemingly pretty rare and not terribly harmful, though if it's still a problem it should get fixed.)
comment:10 by , 13 years ago
Replying to Philip:
I don't know if this is a complete fix, since I assume AI doesn't put units into non-default formations so maybe it's hitting a different problem (but I can't imagine what). Need to either have some precise steps to reproduce if it's still a problem for AI, or just assume that it's okay. (Not a release blocker in any case since it's seemingly pretty rare and not terribly harmful, though if it's still a problem it should get fixed.)
I am able to reproduce this bug most of the time.
You just need to place a foundation (e.g Agora, since your patch prevent the bug to happen with farms), with 4+ builders, on top of 5+ units moving individually (i.e. in INDIVIDUAL.WALKING state).
Each builder will ask every moving units to leaveFormation, resulting in 4*5 calls to pushOrderFront(leaveFormation) / finishOrder / "Order.Walk" / moveToPoint / .. per turn. I read that the call to moveTo* functions are quite time consuming, so I think that's the problem.
comment:11 by , 13 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:12 by , 13 years ago
Milestone: | Alpha 6 → Alpha 5 |
---|
comment:13 by , 13 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
Ah, indeed. MoveToPoint
causes the unit to stop while it computes a new path, which is currently delayed by 2 turns. If you have enough builders to trigger LeaveFormation
every single turn (which I think means 4 builders in single-player, if their timings sync up unluckily), the unit will never get a chance to finish pathing and start moving.
I think DiscardOrder
interacts badly with promotional cheering, though. Say orderQueue = [Cheering, Walk]
and the state is INDIVIDUAL.CHEERING
, then someone calls LeaveFoundation()
, which results in orderQueue = [Cheering, LeaveFoundation, Walk]
. The cheering hits its timer, calls FinishOrder
, then orderQueue = [LeaveFoundation, Walk]
and it processes Order.LeaveFoundation
in the state INDIVIDUAL.CHEERING
, which calls DiscardOrder
. Now orderQueue = [Walk]
but it's still INDIVIDUAL.CHEERING
. Eventually the cheering will hit its timer a second time, call FinishOrder
again, and probably lose that Walk
order, and it'll be broken since DiscardOrder
left it in an inconsistent state.
r9527 makes this easier to test - buildings built on top of cheering units do seem to trigger multiple cheerings in practice, so I think a better solution is needed (though I'm not sure exactly what yet).
comment:14 by , 13 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
comment:15 by , 13 years ago
I think this works, though I'm not absolutely sure it's perfect. The idea is to effectively do DiscardOrder
if the LeaveFoundation
order is being processed via PushOrderFront
(since in that case it's safe to carry on with the previously-front order since we're already in the right state for it); but in FinishOrder
(and PushOrder
) it's equivalent to calling FinishOrder
again, so the next order in the queue is processed anew.
Does this ever happen for human players? (my units seem to get cleared off the construction site)