How to prevent stutter/pause/lag for GROUP ACTIVATE/Respawn via script!

[deadlyfishes]

So everyone knows the issue where you try to spawn in an air, ground, ship or static group into your mission and then it's usually followed by a short stutter, pause, or lag spike (for multiplayer).

 

Some of these issues have been mentioned here:

https://forums.eagle.ru/showthread.php?p=3134763

https://forums.eagle.ru/showthread.php?t=66606

https://forums.eagle.ru/showthread.php?t=184509

 

(Sorry of someone already brought this up or is already well-known but I haven't seen to much about anywhere myself and it was pretty big to us when we found out)

 

This happens when you spawn in units OUT OF THIN AIR using GROUP ACTIVATE, mist.respawn or any of the MOOSE commands.

 

I've been fighting with this issue with my Through The Inferno PvE server which can see up to 45 players during peak hours.

 

It only gets worse the more players you have on your server and how big the group your spawning is.

 

Long story short after much testing we've figured out how to solve this issue, and now we're able to spawn multiple groups of units, of any size. (something reasonable, obviously if you spawn 50 ground units at once with radar, you'll run into issues if your machine can't handle it.)

 

The issue is much more apparent on multiplayer servers, but it's still there in single player.

 

So here's how to handle it for each type of unit:

 

Air Vehicles: (STATIC UNITS DON'T WORK AS WELL!)

 

Place one of each type of air unit that you spawn in your mission at an airfield that is not in use.

 

Set their commands to:

Immortal

Invisible

Take off from ramp

Check

UNCONTROLLED

 

(Sometimes it's a good idea to do this for each player slot as well).

 

Ground/Ship/Static:

Set their commands to:

Immortal

Invisible

 

Keep their AI ON. We've tried AI OFF before and it still stutters/pauses when you spawn in ground units.

 

You can put these anywhere and hide them if you'd like.

 

Remember that scripts like CTLD have statics and units, so be sure to put those in there as well.

 

Other ways to help optimize performance with many ground units:

 

Try using a trigger zone for enemy ground units to turn off their AI on or off.

 

CONDITION PART OF COALITION IN ZONE > GROUP AI ON [REDSAM]

CONDITION ALL OF COALITION OUT OF ZONE > GROUP AI OFF [REDSAM]

 

The only issue we've had before is having close to a hundred active ground units on the map, especially many with radars causing noticeable and continuous lag. Nothing we can do about this without some heavy external processing which is quite a doozy to pull off well.

 

Let me know if this isn't working, I'm sure you may have missed something. Feel free to join our server and ask me to show you that we're able to spawn several aircraft groups (about 20) plus several ground unit groups at once without any lag or stutter at all :)

[FlightControl]

Moose SPAWN ensures that it has all units spawned at the start of the mission. Late activated. Then it activates them when the spawn every is called... Without performance impact indeed. Like 600 units with various options like random routes, random zones, random templates, random ....

 

http://flightcontrol-master.github.io/MOOSE/Documentation/Spawn.html#SPAWN

Edited October 3, 2017 by FlightControl

[deadlyfishes]

Moose SPAWN ensures that it has all units spawned at the start of the mission. Late activated. Then it activates them when the spawn every is called... Without performance impact indeed. Like 600 units with various options like random routes, random zones, random templates, random ....

 

http://flightcontrol-master.github.io/MOOSE/Documentation/Spawn.html#SPAWN

 

I remember using MOOSE before and I still had the issue with spawning in units in a MP environment and still had the stutter/pause.

 

Once you've destroyed them or when the unit is done, they become un-cached right?

[FlightControl]

I remember using MOOSE before and I still had the issue with spawning in units in a MP environment and still had the stutter/pause.

 

Once you've destroyed them or when the unit is done, they become un-cached right?

 

It depends how you use SPAWN.

 

When you use the InitLimit() method of SPAWN, all groups are spawned late activated in advance.

When you use InitArray(), it even makes them visible before start...

 

Nice to make large battalions visible in missions.

 

Unfortunately, DCS had a new bug introduced in multi player.

When groups are visible before start, dynamically spawned but late activated and visible, and when clients connect, the group activations on the server are not synced to the clients. The server will have active groups, and the client won't see them... But this only happens when visible before start.

 

Another fix for ED todo. This issue was with dcs before, and it has returned:-(

Edited October 3, 2017 by FlightControl

[Winston 60]

deadlyfishes, I have had good luck with a technique similar to yours while not noticing any sync issues. I just use an equal number of statics of the same types as all late activated units, placed on the map somewhere at start, and the "pause" when air, ground or ship groups activate is gone.

[Kolyma]

So everyone knows the issue where you try to spawn in an air, ground, ship or static group into your mission and then it's usually followed by a short stutter, pause, or lag spike (for multiplayer).

 

...

 

This happens when you spawn in units OUT OF THIN AIR using GROUP ACTIVATE, mist.respawn or any of the MOOSE commands.

 

...

Let me know if this isn't working, I'm sure you may have missed something. Feel free to join our server and ask me to show you that we're able to spawn several aircraft groups (about 20) plus several ground unit groups at once without any lag or stutter at all :)

Hey thanks for this info. Really helped. I was getting lag with any of the scripting engines. Your suggestions made sense and helped with dynamic spawning new units without lag, regardless of late activation of other kinds of breugelcraft.

[deadlyfishes]

Hey thanks for this info. Really helped. I was getting lag with any of the scripting engines. Your suggestions made sense and helped with dynamic spawning new units without lag, regardless of late activation of other kinds of breugelcraft.

 

 

 

 

Kind of an old thread here.

 

 

I notice this REALLY helped 100% on DCS 1.5, but even with this work-around it's somewhat of an issue in 2.5, with a lot of units, heavy volume of players and objects/AI.

 

 

Maybe it helps on a smaller scale, but it's not as effective as it used to be on 1.5.

 

 

Hopefully fixes and better netcode will come with the supposed dedicated app coming Soon™

[Maverick87Shaka]

......

Let me know if this isn't working, I'm sure you may have missed something. Feel free to join our server and ask me to show you that we're able to spawn several aircraft groups (about 20) plus several ground unit groups at once without any lag or stutter at all

 

I'll try for sure this trick! Can I ask you the server hardware specs and bandwith? I would like to compare "performance" and specs to see if it's time to upgrade my server.

 

 

 

 

 

 

 

.........

Hopefully fixes and better netcode will come with the supposed dedicated app coming Soon™

 

We're all dreaming that moment!

Personally I hope this arrives in time for the F-14, I belive will see an increasing multiseat operation also on public server, so we need a better foundations.

[Kolyma]

Kind of an old thread here.

 

 

I notice this REALLY helped 100% on DCS 1.5, but even with this work-around it's somewhat of an issue in 2.5, with a lot of units, heavy volume of players and objects/AI.

 

 

Maybe it helps on a smaller scale, but it's not as effective as it used to be on 1.5.

 

 

Hopefully fixes and better netcode will come with the supposed dedicated app coming Soon™

Yeah, I saw the old thread and bumped it. Nothing else came up with Google search right away and I had decided to finally look into how to mitigate this issue after on-again / off-again attempts at playing around with servers and scripts. The stop-lag when spawning dynamic units was/is a real pain. Depending on where you are in flight it's either a minor distraction or a one, two, three frame slam into the ground kind of problem.

 

Anyway, I converted my main script from delayed-activated only style to uncontrolled ramp-slotted + delayed-activated controllable & client style units and ran the server for a few hours. Seems for those of us on it that the stop-lag was gone.

 

Need to try Winston_60's suggestion of using statics instead of ramp-parked units. Something bad about having airbase slots taken with defunct units just to correct dynamic spawns stop-lag. That would make more sense

[fargo007]

This topic came up again last night for us.

 

I tried it on the latest openbeta, PG map, and it appears to have zero effect. Looks like it's back to not working.

 

ETA - Specifically ground units of all types.

Edited November 6, 2018 by fargo007

[Kolyma]

This topic came up again last night for us.

 

I tried it on the latest openbeta, PG map, and it appears to have zero effect. Looks like it's back to not working.

 

ETA - Specifically ground units of all types.

Interesting. The testing map we're using has air and ground units. Can't replicate the lag with the extras added but as soon as we run the exact same map without the extras, we get stop-lag. Somewhere there has to be someone who's made engineering-level of detailed analysis about why this happens and how to mitigate. I totally understand a contributing factor could be dynamically spawning units that are NOT currently active in the server. This seems to be what's happening. In our test map, we've got several different kinds of AI units that can be spawned from different areas, but not all types are always active due to random'ing. Seems the stop-lag happens when an AI AC is spawned of a type that is not currently operating in the map. Think it also does it for client slots. Most of my observations so far have been about AC although we've made the same changes for the dynamic ground units.

[fargo007]

Pretty similar here. I'm using MOOSE with :InitLimit() and I'm getting a visible hourglass on every spawn. I'm also spawning in random zones like you are, via :InitRandomizeZones().

 

I have an entire farm of enemy "spawnstub" vehicles on the edge of the map set immortal/invisible, so the same unit at least is active.

 

I am willing to help test against this. I will say this appears to be MUCH less of an issue on caucasus. I'm not sure how to explain why.

[Kolyma]

I have an entire farm of enemy "spawnstub" vehicles on the edge of the map set immortal/invisible, so the same unit at least is active.

What does immortal/invisible actually do? Because I have those setcommand entries on my units but I can still F2 around to them and it appears possible to destroy them. I must have something silly simple not enabled.

[fargo007]

Notionally it keeps them from being detected and destroyed by a rogue AI moving past them for some reason.

 

I've also been able to prove that the AI vehicle spawn hourglass does NOT appear in Caucasus. There's a blink but that's it.

 

It's something specific to PG.

[Kolyma]

Notionally it keeps them from being detected and destroyed by a rogue AI moving past them for some reason

Is there a way to leave these placeholder aircraft out of the F2 looky-see circle of aircraft?

[ViFF]

The uncontrolled units have different and/or additional 3d objects and don't have pilot in the cockpit. The method I use to avoid the small freezes / lags with dynamicly spawned aircraft is to have the various types of units on remote airfields set to ramp start with 0% fuel.

 

They will have a pilot inside the cockpit. Units with anti collision lights will be on and flashing.

Edited November 9, 2018 by ViFF

[fargo007]

Does anyone have a workaround for this that operates successfully on the PG map in 2.5.3?

 

The behavior is reproducible here, but not in caucasus.

 

The spawning of any ground vehicle generates a client wait state where they are looking at an hourglass, a screen freeze or whatever message their VR headset displays.

 

Everytime it happens, you have (n) pilots chattering that "I have some kind of big lag spike....." and some of them crash through (this time) no fault of their own.

 

Using MOOSE, with :InitLimit(n,n) and :SpawnScheduled(n,n)

 

I experimented with scoping the variables as local or not, and when the SPAWN: declaration is made local, there's no spawn at all, and it outputs a message that it's scheduling the spawn of an obsolete group.

 

I also have a copy of every enemy ground unit in the mission alive on the map elsewhere.

 

Would really like to resolve this any which way, but if someone else can still reproduce after a bit of hacking at it, I think it's time for a bug report.

 

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

 

ETA - I was able to dramatically minimize this by making the SPAWN: declaration local and by making the :SpawnScheduled(n,n) call non-local.

 

I'm not sure why this worked, but it definitely did.

 

Does not spawn:

local apc = SPAWN:New( "apc")
:InitRandomizeZones(SamZones)
:InitRandomizeRoute(1,5,3000)
:InitLimit( 4, 360 )
:SpawnScheduled(2,1)

 

 

 

 

Spawns with unacceptable (enough to crash your plane) lag:

 

apc = SPAWN:New( "apc")
:InitRandomizeZones(SamZones)
:InitRandomizeRoute(1,5,3000)
:InitLimit( 4, 360 )
:SpawnScheduled(2,1)

 

 

Spawns with almost imperceptible lag most of the time:

 

local apc = SPAWN:New( "apc")
:InitRandomizeZones(SamZones)
:InitRandomizeRoute(1,5,3000)
:InitLimit( 4, 360 )

apc1 = apc:SpawnScheduled(2,1)

Edited December 4, 2018 by fargo007
Workaround discovered