Designing MP missions for good frame rate - share your tips?

[fargo007]

Just starting a discussion around managing the architecture, construction and design of large missions with frame rate being a consideration. I fly VR, and the stutters ruins the experience for me so I'm hyper sensitive to this.

 

I know enough to know I don't know everything, so let's share approaches.

 

Some very basic tenets I follow:

 

1 - Minimize moving units. The amount of moving stuff at any one time.

 

2 - Never use a unit where a static will do. If it's not expected to move or shoot, it's a static.

 

3 - Object count - There's a threshold where this starts to really degrade. Usually seen with lots of infantry. This is still a black hole to me in some ways, but I know it's there.

 

4 - Designing large missions with a framework that has only the objects of current interest live. Examples include using MOOSE :InitLimit() / SpawnScheduled() and also using a function based approach tied to radio menu items to launch entire missions, or segments of one.

 

5 - Stopping big ground formations & convoys at waypoints (hold) when nobody is close enough to even see them moving. Stop condition is a flag that is on when any client is in the area.

 

 

Interested to hear everyone else's tricks. Cheers! Here's to a smooth, high FPS flying experience.

 

Thanks guys!

[Paganus]

You nailed it pretty well with your post.

 

1. Pathfinding matters. Keep routes as simple as possible, through the least obstructed areas. This helps to keep ground units from getting stuck as well.

 

4. I've also used "switches" on the map. A car near a trigger in some corner of the map, I can just command to move (Combined Arms). For times you don't want to put it in the F10 menu.

 

5. Turn the AI of units on/off as needed.

[Emmy]

I like the OP’s #5. Hadn’t ever considered parking a convoy unless / until somebody is in the neighborhood.

 

Just out of curiosity, how big a zone do you use to kickstart them?

[Webber]

a- Disable AI traffic

 

b- Put AI plane in Deactivate( the 3d model is visible but the unit is stand by)

 

c- Use Static Weather

 

d - Ground Units not near airbases

 

e - Do not use Vee formation in groups who walking inside the forest

 

f- Scripts: do no use many schedulers

 

 

Inviato dal mio iPhone utilizzando Tapatalk

[shagrat]

Limit spawns of "new" units, as in keep the unit types to a reasonable limit. Then make sure one of each type is visible (spawned) at mission start, to prevent loading models later in the mission.

Some unit models are extreme reasource hogs, when you add a new unit type and have issues may switch to something different... ED is constantly optimizing the models one by one, but I remember a certain SAM (SA-6?) hit performance pretty hard. Same for typical AI planes from playable modules. Consider F/A-18A, F-16C bl.52 or simplified F/A-18C statics/AI instead of full million-polygons hi-end...

[Glide]

Watch out for units trying to pass each other on the roads, especially with large groups and tight spaces. I've seen units try to climb mountains to get around a slow moving tank.

[fargo007]

I like the OP’s #5. Hadn’t ever considered parking a convoy unless / until somebody is in the neighborhood.

 

Just out of curiosity, how big a zone do you use to kickstart them?

 

We're a helicopter squadron, so I use a "Hugh Jass" zone that's the entire size of the combat area. Let's say 10-20K from the furthest point out that an enemy could be.

[fargo007]

You nailed it pretty well with your post.

 

1. Pathfinding matters. Keep routes as simple as possible, through the least obstructed areas. This helps to keep ground units from getting stuck as well.

 

4. I've also used "switches" on the map. A car near a trigger in some corner of the map, I can just command to move (Combined Arms). For times you don't want to put it in the F10 menu.

 

5. Turn the AI of units on/off as needed.

 

That's a damn great idea man. Thank you.

[Statua]

1) Do not allow artillery or bombers to create a large mess of bomb craters. These are highly unoptimized overlays that exponentially eat away the framerate as they multiply.

 

2) Be stingy with the deck crew models. They seem to impact framerate quite a lot.

 

3) Only use small details like traffic cones, signs, ammo boxes, etc in locations where the player will be stationary or not moving around much. Examples include the parking spot. Rearming area, or near any helipad.

 

4) Use low quality airplane models for background parked aircraft. (such as the f-18 and f-16 low quality models)

 

5) If you are using rain, be extremely vigilant with everything else. The particles in DCS are also very framerate heavy and rain has no shortage of that.

 

6) Consider splitting groups of 12 or more aircraft to two or three different starting positions to minimize "base lag".

[Gizmokev]

1) Do not allow artillery or bombers to create a large mess of bomb craters. These are highly unoptimized overlays that exponentially eat away the framerate as they multiply.

 

I simulated the mortar or artillery coming using explosion zones to negate this in my last mission.....based on your exact words of wisdom Statua or was it Fargo......I cant remember now.....but it was sound advise.

 

Simulate ground fire by making infantry units small (2 or 3) and make them immortal to keep the fire fight going for as long as you need it too.

[Glide]

Size matters. Increasing the number of active units will eventually reach a stutter point. Keep the armies as small as the scenario can allow.

[fargo007]

Size matters. Increasing the number of active units will eventually reach a stutter point. Keep the armies as small as the scenario can allow.

 

Avoiding the obvious joke I could make here.

 

The number of objects is the single biggest contributor to degrading the frame rate that I've been able to find.

[Glide]

Apologies for the locker room humor. :) Agreed. If a unit is on the map for "ambiance" it is wasting resources. i.e. if it's not shooting at you it should be static.

[fargo007]

I rather appreciated the locker room humor! ;-)

[Thor_H]

If you browse or "spy" on a few MP servers you will notice that the more scripts and ai units they have the "rougher" it runs. Even with 32gb of ram i still get water for a "few" seconds when loading into some of those very heavy on ai and scripts missions. And it seems more taxing on CPU than GPU so if you got a CPU that produces good amount of heat(like I7-I9)get ready to order some ear protection not to get your ears hurt from the fan noise and you certainly will not need a seperate heater in your game room even in winter.

[Andrew u.k.]

When unit is less than>spawn new unit.

 

I use in huey missions, 10 infantry can continually march down an lz keeping gunships busy. Or simulate a relentless attacking force. Change the percentage to simulate ebbs and flows.

 

No path finding needed.

 

Sent from my SM-N960F using Tapatalk

[Pikey]

If you browse or "spy" on a few MP servers you will notice that the more scripts and ai units they have the "rougher" it runs. Even with 32gb of ram i still get water for a "few" seconds when loading into some of those very heavy on ai and scripts missions. And it seems more taxing on CPU than GPU so if you got a CPU that produces good amount of heat(like I7-I9)get ready to order some ear protection not to get your ears hurt from the fan noise and you certainly will not need a seperate heater in your game room even in winter.

 

 

Entirely incorrect. Firstly Scripts only run on the server. Secondly they cost milliseconds in time to execute, tenths for large frameworks like MOOSE, which only ever run when no one is on the server.

 

What you see is large unit counts, perhaps units spawning into the game (again a DCS thing, not the script execution) or a lagging, large, server. That's it. There's a couple of ways to demonstrate this, I did analysis on it. One of them is measuring the code to spawn a unit and the time the unit appears in game. The code (one line) runs in one or two milliseconds. The game takes tenths of a second though, to register the group appearing. This is also a big issue for script timing but that is irrelevant. Hence the code execution from Lua is almost nothing, but the actual C running DCS is taking a lot longer, presumably its validating the unit, the floor its going into, adding to databases, updating all the clients in game... I dunno, whatever it does that takes so long, but toi be clear thats DCS being slow, the script ran faster than is meaningfully detectable.

 

FWIW I dont have anything additional to add to the OP except to go into detail on unit count.

It's not just numbers. It's type and their combat. Especially planes, especially planes executing combat AI tasks. 30 planes in combat begins to see quite a bit of degradation and CPU use. YMMV. Recently the game engine has been much improved since March.

[Thor_H]

Entirely incorrect. Firstly Scripts only run on the server. Secondly they cost milliseconds in time to execute, tenths for large frameworks like MOOSE, which only ever run when no one is on the server.

 

What you see is large unit counts, perhaps units spawning into the game (again a DCS thing, not the script execution) or a lagging, large, server. That's it. There's a couple of ways to demonstrate this, I did analysis on it. One of them is measuring the code to spawn a unit and the time the unit appears in game. The code (one line) runs in one or two milliseconds. The game takes tenths of a second though, to register the group appearing. This is also a big issue for script timing but that is irrelevant. Hence the code execution from Lua is almost nothing, but the actual C running DCS is taking a lot longer, presumably its validating the unit, the floor its going into, adding to databases, updating all the clients in game... I dunno, whatever it does that takes so long, but toi be clear thats DCS being slow, the script ran faster than is meaningfully detectable.

 

FWIW I dont have anything additional to add to the OP except to go into detail on unit count.

It's not just numbers. It's type and their combat. Especially planes, especially planes executing combat AI tasks. 30 planes in combat begins to see quite a bit of degradation and CPU use. YMMV. Recently the game engine has been much improved since March.

 

 

I did not mean to make it sound as if i was blaming the scripts themselves but rather the ai units that many scripts generate, many servers have lots and lots(hundreds)of ai units wich is controlled by scripts that are constantly "alive" in the game world and it is those ai units that in my humble opinion puts a strain on the clients pc.

[fargo007]

Thank you for the great input and ongoing discussions gents.

 

What's the impact of a large number of SAM systems & units? Any certain type more "lightweight" or "heavy" than others?