Unresponsive ACU late game
-
This usually occurs on 40x40 or larger maps. The solution is to play 20x20 or smaller maps
-
This was on a 20x20 map called Direct Fire, I was in the game too.
-
@jip said in Unresponsive ACU late game:
This usually occurs on 40x40 or larger maps. The solution is to play 20x20 or smaller maps
I've never experienced this on the few 40x40 maps that I've played. It usually happens to me on 20x20 maps, specifically setons. It's also occurred on 10x10 maps too.
So small maps are not the solution.
-
The only real solution if you encounter this bug is to limit the unit cap: when there are too many units on the map, most units will become unresponsive (I seem to remember that air units remain somewhat responsive though).
Just to clarify, this is a base supcom bug, not something introduced by FAF (I'm actually half sure this issue was mitigated by patches).
Alternative solution: keep the pressure on, so not as many units remain alive
-
I don't this this game had particularly large unit counts honestly, nothing more than the average setons or gap game. Does this usually affect only one player? I had no issues moving my units and ACU while Cortana was complaining about not being able to move his.
-
Map size has little to do with it - the real issue draws in two aspects - unit count (which is directly responsible for the SIM slowing down) and traffic issues (unit collisions).
While a smaller map does reduce the memory requirement a bit, it has no impact beyond that. Unit count (and the complexity of those units) has long been recognized as the largest influence on performance, and memory consumption - and this 'unresponsiveness' that you're seeing is related to that.
It can impact players at different times, as it's really a measure of CPU 'saturation' - and if the problem is severe enough, it can impact multiplayer games for all players.
Unit collisions play a very big role in this - so anytime you have a situation with a large number of those (like clumps of engineers all crowding around a factory), or traffic jams caused by really tight and complex terrain, you're going to see a very big upswing in CPU activity - which manifests as 'unresponsiveness'.
-
@sprouto said in Unresponsive ACU late game:
Map size has little to do with it - the real issue draws in two aspects - unit count (which is directly responsible for the SIM slowing down) and traffic issues (unit collisions).
While a smaller map does reduce the memory requirement a bit, it has no impact beyond that. Unit count (and the complexity of those units) has long been recognized as the largest influence on performance, and memory consumption - and this 'unresponsiveness' that you're seeing is related to that.
It can impact players at different times, as it's really a measure of CPU 'saturation' - and if the problem is severe enough, it can impact multiplayer games for all players.
Unit collisions play a very big role in this - so anytime you have a situation with a large number of those (like clumps of engineers all crowding around a factory), or traffic jams caused by really tight and complex terrain, you're going to see a very big upswing in CPU activity - which manifests as 'unresponsiveness'.
Yes.
I've had my ACU not respond to a move command for up to 10 minutes once.
It's pretty bad and very frustrating.
-
If it's pathfinding that's the issue, would selecting everything and clicking stop help?
-
If it's your own units - yes - but it may be due to the AI, or other players. The game itself uses a queue to process orders - and that queue is processed at a finite rate. When hundreds of units are colliding - they're creating new orders to 'unbump' themselves - and your single order just gets swamped - and delayed.
-
Why would it only affect one player though?
-
@redx It's a measure of CPU saturation - and it starts with an individual's CPU - so while initially the problem is local to one user, it will eventually and usually quickly, result in apparent lag across the entire multiplayer session, as the others will end up waiting on the slow machine to catch up.