Opened 5 years ago
Last modified 2 years ago
#5624 new defect
Units can fail to go around large obstacles when short-pathing
Reported by: | elexis | Owned by: | |
---|---|---|---|
Priority: | Should Have | Milestone: | Backlog |
Component: | Core engine | Keywords: | pathfinding |
Cc: | Patch: |
Description
In the replay for r23063 (still works with r23074) uploaded at Phab:F1100948, at minute 34, there were about 50 naked fanatics that failed to find a path to the enemy units and thus lost the battle without delivering damage.
There was a small passage between houses / pyramids that was obstructed by units, and as a result, the attackers seems to have just not computed any valid path, or followed the longpath, aborted due to the shortpathfinder and then gave up.
See the screenshots at Phab:F1100948#36 and F1100948#37.
The bug is easily reproducible by loading the savegame from that minute uploaded at Phab:F1100948#38, changing the perspective to the green player / go2die / naked fantic owner and then ordering the units to attack one of the cavalry units behind the pyramid or move behind the pyramid.
Attachments (6)
Change History (17)
by , 5 years ago
Attachment: | screenshot0876.jpg added |
---|
by , 5 years ago
Attachment: | screenshot0875.jpg added |
---|
by , 5 years ago
Attachment: | screenshot0879.jpg added |
---|
comment:2 by , 5 years ago
See discussion on http://irclogs.wildfiregames.com/2019-10/2019-10-16-QuakeNet-%230ad-dev.log
This is caused by the max-range of the short-range pathfinder not being large enough to go around the houses in all cases
14:06 < wraitii> at least is soudns plausible
The constant SHORT_PATH_MAX_SEARCH_RANGE
was lowered in r22526.
Increasing to 10 doesn't resolve the specific situation in the replay.
We didn't actually check what the states of these units are, it could be that, but it could also be something randomly different or unknown in the unit pathing logic.
One could create a replay with only one move command for one or more of the naked fanatics, load the savegame and that minimal replay from commandline and analyze the unit logic in nonvisual mode (https://pastebin.com/raw/5xzKwLFx)
comment:3 by , 5 years ago
"This is caused by the max-range of the short-range pathfinder not being large enough to go around the houses in all cases" What if the short-range pathfinder increases its max-range if it can't find any path?
comment:4 by , 4 years ago
"This is caused by the max-range of the short-range pathfinder not being large enough to go around the houses in all cases" What if the short-range pathfinder increases its max-range if it can't find any path?
This already happens. With a sufficiently large range, it will start causing noticeable lag. We can increase 10 to something higher.
Based on elexis comments, I will try to recreate the situation and check if increasing the range does fix it.
by , 4 years ago
Attachment: | commands.2.txt added |
---|
Much worse situation. You need a max_range of 50 for this one, and it _will_ lag noticeably. And that's a single unit computing a single short path.
by , 4 years ago
Attachment: | commands.3.txt added |
---|
In this example, the entity #2393 has no path. So it will keep trying up to any arbitrary upper bound of MAW_RANGE, including the whole map, lagging absurdly in the process.
comment:5 by , 4 years ago
See replays above for some example of why we can't really put an arbitrarily high max-range. It will start lagging, possibly so much that the game becomes unplayable.
It would even be fairly easy for an ill-intentioned player to trigger a similar situation to commands.3.txt but with many more units, making the game unplayable and causing the opponent to resign, to avoid losing a game for example.
Further, because of #3700, it might actually make it possible to disconnect any arbitrary player just by having a faster computer.
I reckon 6 was a poor choice of MAX_RANGE, and I'll bump it back up to 14, which should be "good enough" for most cases, including most of the larger buildings.
comment:6 by , 4 years ago
Owner: | set to |
---|---|
Patch: | → Phab:D2754 |
Phab:D2754 reintroduces a longer range. See also #5586.
comment:9 by , 3 years ago
Keywords: | regression removed |
---|---|
Milestone: | Alpha 24 → Alpha 25 |
Owner: | removed |
Patch: | Phab:D2754 |
Priority: | Must Have → Should Have |
Summary: | Units fail to find path between small passage → Units can fail to go around large obstacles when short-pathing |
This has been mitigated for A24, and I don't think we can do better until we remove the short-pathfinder or can use it over much larger ranges.
Lowering priority and pushing to A25.
comment:10 by , 3 years ago
Milestone: | Alpha 25 → Alpha 26 |
---|
comment:11 by , 2 years ago
Milestone: | Alpha 26 → Backlog |
---|
This is caused by the max-range of the short-range pathfinder not being large enough to go around the houses in all cases [EDIT: in this instance, because the outer-most corner of the houses isn't reachable).
The only fix is to increase the max-range of the short-range pathfinder, but that can increase lag in general.
IMO it's a won't-fix - perhaps we. can increase the max short-range pathfinder a bit, but these kind of issues are inherently unfixable without unit pushing and/or a single pathfinding system.
Edit: also this isn't a regression. Well it technically is, because this sort of bug was fixed by the 'don't add domain edges to the short pathfinder' thing, which I reverted in July, but that particular hack had its own set of problems. We can re-revert that, but fundamentally some edge cases will break whatever we try.