MP! Game freezes when group of unit is activated

[Xjikz]

Hi everyone,

 

I meet a problem with the multiplayer missions, each time a group of units is activated by a trigger, then all the human clients of the game have a freeze for about 2 or 3 seconds, this is very frustrating as it kills the gameplay and I have to limit the quantity of units to activate in the ME.

 

I didn't find any topic regarding this problem so I wonder if this is due to something wrong on the server hosting the game, or a "bug" that everybody already know ?

 

Thanks in advance,

cheers !

[Grimes]

This freeze has been around for a very long time now. The best way around it is to limit the number of units activated at a single moment. So if you have several groups each with 10 units or so you can use triggers to activate them a few seconds apart.

[Xjikz]

Ok thanks Grimes, unfortunately I don't use delays in my missions, but conditions based on events.

Hope this "freeze" will be fixed in a future patch....

 

Have a nice day !

[Grimes]

What I mean is you could use triggers to delay them. So on an action if you want to spawn 3 groups but not have them all spawn at once simply have the trigger code look something like this...

 

On Flag 1 > Set Flag 2 and Activate SubGroup 1

Time since Flag 2 is 5 seconds > Set Flag 3 and Activate SubGroup 2

Time Since Flag 3 is 5 seconds > Set Flag 4 and Activate SubGroup 3

...

and so on

 

Over a period of 15 seconds several smaller groups will spawn in. It might minimize the pause.

[EtherealN]

As a further note, this isn't actually the simplest thing to fix. Basically, freezes like this are usually caused by one of two things:

 

1) Sound system problems. New sounds get loaded and sound card throws a hissy. Fixable through sound card settings/drivers.

2) HDD access latency. New units that are spawning require new source files to be loaded (models, textures, possibly sounds etc) into RAM. Theoretical fix is to pre-load all resources into the process at mission start.

 

However, in this case we would have a problem: for one thing, we'd need some pretty complex memory management stuff in order to not completely lock out everyone with less than optimal RAM amounts. Second issue is that we're running into a wall at 2GB for a 32-bit process. Ways around that (large_adress_aware) but there are drawbacks. So until we have a 64-bit executable we'll be running into the 32-bit 2GB wall even on a 64-bit system with 12GB RAM. And it gets worse: graphics card vRAM is also in on that calculation, so a 1GB graphics card that you load full of textures can cause you issues in other parts (sound f.ex), while a 512MB card (like mine) might not have enough at all times to do a proper preload of everything it might need.

 

So based on the above, I myself believe the general solution to be named "64-bit". We have the hardware and the OS to solve the problem, but it requires doing a bit of rewriting (and establishing a duplicate test tree unless the decision is made to simply drop 32-bit entirely, which might cause an upset for a lot of people who aren't running 64-bit OSes yet).

 

As far as I know, there is a prototype 64-bit build in the works, but I am unsure about when and how and for which product that can get deployed.

[c0ff]

Sound system problems. New sounds get loaded and sound card throws a hissy. Fixable through sound card settings/drivers.

 

The sound engine uses time-critical (highest available priority for a user application) thread for rendering, loads sounds in a separate background thread and there's no locking used. So, if you hear a sound glitch it means that OS did not run rendering thread in time - possibly used the CPU for something else, that it considers more critical. There's nothing I can fix.

The only solution for glitch-free audio is to have enough spare resources (just in case). Given multiple cores we have today, I suppose the main bottleneck is HDDs. We should rethink our graphic resources loading (make it a true background task).

[Grimes]

2) HDD access latency. New units that are spawning require new source files to be loaded (models, textures, possibly sounds etc) into RAM. Theoretical fix is to pre-load all resources into the process at mission start.

 

So in that logic if you place a single T-72 tank and then spawn a convoy of 30 T-72 later on in the mission there should be reduced stuttering?

 

I wonder how big of an impact "visible before start" would have on spawned units..

[Xjikz]

ok.....

Edited May 27, 2010 by Xjikz