Opened 7 years ago

Closed 7 years ago

#1048 closed defect (no change required)

lab stops producing units

Reported by: Bluestone Owned by:
Priority: major Milestone:
Component: BAR Version:
Keywords: Cc:

Description (last modified by Bluestone)

[16:11:11] <[ACE]FabriceFABS> Pb occurs @ 2"38.

Change History (13)

comment:1 by Bluestone, 7 years ago

Description: modified (diff)

comment:2 by Bluestone, 7 years ago

As far as I can see the unit stops in the lab, with no orders -> ideally would test if it was sent CMD.STOP but non trivial to set up a debug environment that allows me to check this.

comment:3 by beherith, 7 years ago

Units randomly getting a stop command before exiting the lab is (in my experience) related to someone giving then an order while they are under construction (e.g. attack), and the target of the order dies, so the unit has no orders to exit lab.

comment:4 by FabriceFABS, 7 years ago

This occurs quite often, I don't know what causes it.

What I can say is that unit seems to stay in the lab and can't move, simply because when you this wedged unit, it still shows the target move -the default one or the one that has been set on the lab-.

comment:5 by FabriceFABS, 7 years ago

I mean when you select this wedged unit.

comment:6 by Bluestone, 7 years ago

When I analysed the replay above, the "stuck" unit was not stuck; it was able to exit the lab as normal when I gave it a move order. The only reason it hadn't left the lab by itself was because it had no orders to do so (presuably its automatic move order was cancelled, or it had been given a replacement order that was completed/discarded - see behes comment above). Unfortunately doing a more detailed check needs some extra effort and I haven't got around to it.

If you have units 'wedged' and unable to move even when given an order, please upload a replay of that (and its probably a separate issue, if so).

Last edited 7 years ago by Bluestone (previous) (diff)

comment:7 by FabriceFABS, 7 years ago

Yes, agreed : I was not accurate enough and I ended up wrong. Unit is NOT stuck or wedged (also sorry for my lack in English, but the translate for stuck/wedget = coincé = same french word) I don't know what's the different use of those words in English.

For whats Behe said, I would react and be sure of what I'm seeing actually : Maybe I don't understand all, but seems that unit still having its move order, but can't exec it... ? When you select this unit, it doesn't move but still shows its target move. LOOK >> Instructions : 1/ See the targets of the amphibious cons 2/ Seems the normal cons wants to climb also... And check it out : When you select the normal cons, it still got in its queue order its move target but do nothings or move a very little.

Another different replay to see, I did action comments in game LOOK >>

comment:8 by Bluestone, 7 years ago

The issue is caused by the automatic waypoint set by the engine ending up on a non-reachable location - which happens frequently on metal heck and seems highly unlikely on most maps.

comment:9 by anonymous, 7 years ago

Same on BlockWars with kBOT lab >>

The kBOT wants to reach a wind unit around the lab. On the replay I tagged it.

comment:10 by FabriceFABS, 7 years ago

Same on MetalHell (not hilly map) => Unit want to go on a nano and by this, stays in the lab.

Doing extra test, not sure if this problem occurs on a certain lab orientation.

comment:11 by Bluestone, 7 years ago

There is no need for further examples.

comment:12 by FabriceFABS, 7 years ago

I stop my investigations now, reported to mantis. Not related on BAR Only, maybe frequent on MetalHeck but also could be reproduced on othermaps. You can close.

comment:13 by Bluestone, 7 years ago

Resolution: no change required
Status: newclosed
Note: See TracTickets for help on using tickets.