OpenRA
Pathfinding performance issues
Can't really vouch for this one being a new thing, but naval AI units put a skirmish game to a halt with just 5 cruisers trying to target my army on the ground out of their reach. Destroying cruisers one by one increased performance considerably, up to VSync-limited 60fps.
https://youtu.be/C9JkW2IwctA
Here's a replay, though it also has a lot of other unneeded stuff. Noted a perfdrop at around 5min, then it got better around 7:20; cruisers chase is closer to the end of the file. https://www.dropbox.com/s/dh5b2qfgen02ex6/OpenRA-2020-03-01T182317Z.orarep?dl=0
Confirmed this - the issue is MoveWithinRange. It isn't limited to AI nor even cruisers or boats in general, however, though the highest effect to FPS is when a cruiser is used. The easiest way to reproduce is to build a cruiser and force-fire on land that is out of range. Seems to be a regression from release-20200202 which doesn't lag in the same case.
Yes, a bunch of island-strapped AI units also cause the substantial FPS drop.
Yes, a bunch of island-strapped AI units also cause the substantial FPS drop.
I'm nearly certain it's a regression from release-20200202, which isn't too bad because there isn't much to check in order to fix it. Have you tested the same conditions in that version yet, just to confirm that it is a regression?
The worst part of this was probably introduced by a28be21e07641050df2a7039096280e7f39e0561, which makes us we call the expensive MoveAdjacentTo.CalculatePathToTarget method 4 times per unit per tick instead of just once.
The best fix here will be to find a way to call this at most once every few ticks instead.
The check at https://github.com/OpenRA/OpenRA/blob/bleed/OpenRA.Mods.Common/Activities/Move/MoveAdjacentTo.cs#L129 is the ain bottleneck, which isn't affected by the check value. 4a609bbee81f4a82bd85ea8244857f02145649c8 also hurt a lot, but there is no clear simple mitigation we can apply.
We could work around the worst of the regression by passing all the BlockedByActor values through Move.EvalPath and into the getPath so we can loop over them after the expensive domain filtering. This is not elegant, but should work if needed as a last resort.
A smarter solution would be to cache searchCells, which would allow them to be reused across multiple ticks. Some thought will need to go into when to invalidate the cache.
It also seems that AttackFollow.AttackActivity does not cancel itself or rate limit repathing attempts if the target is unreachable.
@pchote Have you considered creating tests for the engine so as to avoid regressions such as these in the future? I know it will be a painful task, but it may be worth the time saved by making them.
Of course, and we already do for many things. But there is a big difference between deciding that something like this issue needs to be tested and designing an implementation that actually works.
Just copy-pasting my report from discord:
@ Bug: Attack move on blocked routes lead to massive lag If you select an army and attack a building on the other side of a destroyed bridge without any alternative route, the game will slow down drastically. The larger the army gets, the more it slows down. It does not happen if you only use the move command. If you cancel the attack-move, the game will be fast again.
Reproduction (1) Select Europe 2 map, select your army and attack a building in France while the bridge in between is destroyed. (2) Select Europe 2 map, build a navy yard between Spain and Morocco. Attack move something on the other side of your ships.
I also tried to check if walls can be a problem, but I did not observe any lags with them.
I checked it out because I observed how a few Europe FFA games got ruined because of that.
I could perhaps assist in implementing flowfields, if you would like.
I could perhaps assist in implementing flowfields, if you would like.
How well does it work in a grid based setup with 8 direction constrain?
That would need to be assessed, but I believe that the constraint does nothing but simplifiy things.
The main strength over Astar is performance from what I've seen, the resulting paths are about the same.
Den tors 15 okt. 2020 21:36teinarss [email protected] skrev:
I could perhaps assist in implementing flowfields, if you would like.
How well does it work in a grid based setup with 8 direction constrain?
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/OpenRA/OpenRA/issues/17753#issuecomment-709546919, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFDEADX2HYM44TUYGQ46T3SK5FKJANCNFSM4K7HTIIQ .
If you select an army and attack a building on the other side of a destroyed bridge without any alternative route, the game will slow down drastically. The larger the army gets, the more it slows down. It does not happen if you only use the move command. If you cancel the attack-move, the game will be fast again.
This sounds to me like attack-move commands circumvent our domain checks. That sounds like something we should fix, no matter how much we improve pathfinding performance itself.
@ Bug: Attack move on blocked routes lead to massive lag
This was fixed in #19591. The technical details being that our domain checks didn't correctly handle bridges being repaired and destroyed previously. With this fix in place trying to move to an island that is inaccessible due to a destroyed bridge, or indeed just to another island separated by water, will now no longer cause lags.
Yes, a bunch of island-strapped AI units also cause the substantial FPS drop.
Similarly AI no longer causes these lags when they attempt to attack things out of reach - but they are still trying to attack things out of reach.
[...] naval AI units put a skirmish game to a halt with just 5 cruisers trying to target my army on the ground out of their reach.
This would be fixed in #20227 - the lands units will no longer be ordered to attack the unreachable naval units.
