Opened 12 years ago
Closed 7 years ago
#1200 closed defect (invalid)
UnitAI/UnitMotion should reduce repathing attempts when units are stopped
Reported by: | Jonathan Waller | Owned by: | |
---|---|---|---|
Priority: | Should Have | Milestone: | |
Component: | UI & Simulation | Keywords: | |
Cc: | jkufner@… | Patch: |
Description
Currently if a unit is following a command and can't reach the destination, it constantly retries which causes the game to slow down due to pathfinding being called so regularly. The attempts should be made less frequent and after a certain point the unit should give up and become idle.
Attachments (2)
Change History (13)
comment:1 by , 11 years ago
Cc: | added |
---|---|
Priority: | Should Have → Must Have |
Type: | enhancement → defect |
comment:2 by , 11 years ago
I also noticed a huge difference between locked and unlocked gate. When gate is locked, AI uses much more CPU than when gate is not locked, but still closed.
comment:3 by , 11 years ago
One of the best ways to encounter this currently is to try garrisoning the Mauryan support elephant in the CC. The ranges are messed up, so it fails, but it tries continuously. I suspect with a large group, it would cause severe lag.
by , 10 years ago
Attachment: | limit_pathing.diff added |
---|
comment:4 by , 10 years ago
I attached a small patch for testing (it's not serialised yet). The patch keeps the time since the creation of the unit, and allows only a certain number of paths over a certain time (set in the consts, here 15 paths over 20 seconds).
It works, in a way that when something is unreachable, after ~30 seconds, the units give up pathing in most cases (depending on how long they can walk before they hit the obstruction again). But I don't think it will help with the lag problem, as it takes 20 seconds for them to figure out they can't move.
As the number of long-range pathing requests per unit is under 1 per second, it's impossible to make this time a lot shorter. As the limit can perfectly be achieved with manual actions.
Another possibility would be to keep the units in formation until the formation actually reached the asked position (and only disband then). This would reduce the number of pathing requests as only the formation would request new paths. But it's not very good for the AI, as the AI doesn't always path using formations, and often gives a command per unit. This also won't work with units that can't use formations.
comment:5 by , 9 years ago
Keywords: | pathfinding added |
---|
comment:6 by , 9 years ago
Milestone: | Backlog → Alpha 19 |
---|
comment:8 by , 9 years ago
Milestone: | Alpha 19 → Backlog |
---|---|
Priority: | Must Have → Should Have |
This ticket is still relevant, to a lesser extend. The repathing attempts are currently reduced a lot thanks to the hierarchical pathfinder checking the accessibility before computing the paths.
However, the unit motion still tries to repath sometimes and there is a bit of optimization/code enhancement work to do.
by , 8 years ago
Attachment: | 1200noscope.patch added |
---|
comment:9 by , 8 years ago
The attached patch should reduce excessive swarming. It's based on selecting the end point according to h2+4g instead of h * (this expression stems from minimum size of obstacles and Archimedic (linear) spirals). *: h = heuristic dist. to goal, g = length of the traversed path
You can test it e.g. in the huge combat demo by sending 200 units on one point (without engaging combat). Without the patch, roughly 80 units will stop and the rest will swarm around. With it, (almost) everyone will stop.
There remains a lot to do however:
- Units will still check for a path every turn, so it doesn't do that much for performance. Units could get "timed out" if they don't move when they aren't on their goal, which would solve this.
- The patch causes some issues with units "being lazy" in some special arrangements. A better "metric" would certainly help here.
- In the above "proof of concept" situation, units will continue to walk in place (!). This is not only very creepy, it's also a bug.
comment:10 by , 8 years ago
Keywords: | rfc patch added |
---|---|
Summary: | UnitAI/UnitMotion should reduce repathing attempts when units are stopped → [PATCH] UnitAI/UnitMotion should reduce repathing attempts when units are stopped |
Don't know if this have been checked or not, in doubt I put it in the RFC queue
comment:11 by , 7 years ago
Keywords: | rfc patch pathfinding removed |
---|---|
Milestone: | Backlog |
Resolution: | → invalid |
Status: | new → closed |
Summary: | [PATCH] UnitAI/UnitMotion should reduce repathing attempts when units are stopped → UnitAI/UnitMotion should reduce repathing attempts when units are stopped |
I believe #4327 would make this mostly irrelevant, as fewer units will be stuck. In general trying less often is a lot of code for little real improvements (we don't have that many stuck units in the new pathfinder and all) so I'm closing this as invalid.
Furthermore, this is a unit motion bug landmine, having tried before.
I observed this behaviour too. When I have city with properly built walls, enemy units cannot walk inside and as amount of units gets higher, game is less and less playable (sometimes less than one FPS). When I open the gate, enemies can walk in and game is smooth again (before everyone dies).
Path finding and re-planning of AI units must be throttled to reasonable limits, preferrably by game itself rather than by AI.
When unreachable target is targeted by AI, it should be globaly blacklisted, until some building is destroyed (does not matter which one nor how). When any building is destroyed, blacklist should be re-evaluated for target reachability (but not too often). This way AI units will not attack unreachable buildings, but they will select walls and other border buildings.
I have version 0.0.14-3 from Debian.