Lou Montana/Sandbox – User

From Bohemia Interactive Community
Jump to navigation Jump to search
m (Add frameworks, table, and mods advice)
m (Minor updates)
Line 58: Line 58:
|
|
* Use [[createAgent|Agents]] whenever possible
* Use [[createAgent|Agents]] whenever possible
* The more units there is, the more network update there will be - hence the impact on both CPU and network.
* If a client has a low-end machine, they shouldn't lead a group of many AIs as these would then be locally computed.
* If a client has a low-end machine, they shouldn't lead a group of many AIs as these would then be locally computed.
* [[Arma 3 Dynamic Simulation]] allows you to freeze AI that are distant from players. Many distance settings should be set according to the mission.
* [[Arma 3 Dynamic Simulation]] allows you to freeze AI that are distant from players. Many distance settings should be set according to the mission.
{{ Important | Most if not all of the mission calculation (objectives, completion distance, etc.) must be done '''server-side'''. Local effects should be calculated '''client-side'''. }}
{{ Important | Most if not all of the mission calculation (objectives, completion distance, etc.) must be done '''server-side'''. Local effects should be calculated '''client-side'''. }}
{{ Informative | If you own more than one average computers, you could consider [[Arma 3 Headless Client|Headless client]] and code accordingly. }}
{{ Informative | If you own more than one average computers, you could consider [[Arma 3 Headless Client|Headless client]] to offload AI from the server. }}
|-
|-
|
|
Line 90: Line 91:
| {{colorball|green}}
| {{colorball|green}}
| {{colorball|green}}
| {{colorball|green}}
| A [[while]]-loop checking without a minimum loop-[[sleep]] time is usually a sign of bad conception.<br>
|
* <code>[[while]] { [[true]] } {{codecomment|// already "bad" if you don't know what you are doing}}</code>
* A [[while]]-loop checking without a minimum loop-[[sleep]] time is usually a sign of bad conception. Does your code execution need to be frame-perfect, or can you afford a delay of one second?<br><code>[[while]] { [[true]] } {{codecomment|// already "bad" if you don't know what you are doing}}<br>[[while]] { [[alive]] [[player]] } {{codecomment|// better}}<br>[[while]] { [[sleep]] 1 ; [[alive]] [[player]] } {{codecomment|// perfect}}</code>
* [[trigger|Triggers]] check their set condition '''every 0.5 second''' (hardcoded value). If a large area is covered or condition code is too complex, this can be an issue. Convert them to scripts then.
* [[trigger|Triggers]] check their set condition '''every 0.5 second''' (hardcoded value). If a large area is covered or condition code is too complex, this can be an issue. Convert them to scripts then.
* creating [[createUnit|units]]/[[createVehicle|vehicles]] globally implies a network synchronisation.
|-
|-
|
|
Line 103: Line 103:
* Use [[publicVariable]] wisely; for specific cases, consider [[publicVariableServer]]&nbsp;/&nbsp;[[publicVariableClient]]
* Use [[publicVariable]] wisely; for specific cases, consider [[publicVariableServer]]&nbsp;/&nbsp;[[publicVariableClient]]
* Creating [[createUnit|units]]/[[createVehicle|vehicles]] globally implies a network synchronisation, keep them to a minimum / at one-point in the mission.
* Creating [[createUnit|units]]/[[createVehicle|vehicles]] globally implies a network synchronisation, keep them to a minimum / at one-point in the mission.
* keep the '''*global''' version of commands ([[hideObject]]/[[hideObjectGlobal]], etc) to a minimum
* keep the command with [[:Category:Commands with global effects|a global effect]] to a minimum: e.g a [[setPos]] will synchronise the unit position to every client, a good practice is to use these commands punctually. If you need a frequent "set position" you may want to look at [[attachTo]] depending on your usage.
* Lower client's [[viewDistance|view distance]] in order to lessen its object position update requests
* Lower client's [[viewDistance|view distance]] in order to lessen its object position update requests
*
|}
|}



Revision as of 13:58, 29 June 2019

Template:SideTOC

Introduction

This article will try to be a general guide about improving your mission's code and its performance.
As usual, moderation is the key so do not expect to have thousands of AI magically running 144 FPS. Everything comes at a cost, the tweaks on this page will simply allow you to calibrate your mission properly.

This page is about Mission Optimisation. For scripting optimisation, see Code Optimisation.


Before anything

Before optimising anything, make sure you do not have any performance issue running the game itself:

  • Open the editor, place a unit in the area you like and test your computer.
    • Arma 3 displays FPS when you go into video options
    • Steam allows you to display FPS in a screen corner, in Settings > In game > FPS Counter
  • Use (unofficial) Performance Guides to get better performances:
  • Usual bottlenecks:
    • Lower your graphical settings (resolution, textures). If you get way better performances, at least your GPU limits you.
    • If the game keeps having low FPS when running @ 1024×768/low textures then your CPU is most likely the issue. Mission scripts may be performance-hogging too.
Please note that viewDistance (among other settings) impacts both GPU and CPU!


Creating your mission


Performance impact table

Topic CPU GPU Net-
work
Solution

AI units quantity

Template:colorball Template:colorball Template:colorball
  • Use Agents whenever possible
  • The more units there is, the more network update there will be - hence the impact on both CPU and network.
  • If a client has a low-end machine, they shouldn't lead a group of many AIs as these would then be locally computed.
  • Arma 3 Dynamic Simulation allows you to freeze AI that are distant from players. Many distance settings should be set according to the mission.
Most if not all of the mission calculation (objectives, completion distance, etc.) must be done server-side. Local effects should be calculated client-side.
If you own more than one average computers, you could consider Headless client to offload AI from the server.

Objects quantity

Template:colorball Template:colorball Template:colorball The less objects, the more FPS you will have.
only the on-screen objects will strongly impact GPU.

High-frequency scripts

Template:colorball Template:colorball Template:colorball
  • A while-loop checking without a minimum loop-sleep time is usually a sign of bad conception. Does your code execution need to be frame-perfect, or can you afford a delay of one second?
    while { true } // already "bad" if you don't know what you are doing
    while { alive player } // better
    while { sleep 1 ; alive player } // perfect
  • Triggers check their set condition every 0.5 second (hardcoded value). If a large area is covered or condition code is too complex, this can be an issue. Convert them to scripts then.

High-frequency network messages

Template:colorball Template:colorball Template:colorball
  • Use publicVariable wisely; for specific cases, consider publicVariableServer / publicVariableClient
  • Creating units/vehicles globally implies a network synchronisation, keep them to a minimum / at one-point in the mission.
  • keep the command with a global effect to a minimum: e.g a setPos will synchronise the unit position to every client, a good practice is to use these commands punctually. If you need a frequent "set position" you may want to look at attachTo depending on your usage.
  • Lower client's view distance in order to lessen its object position update requests
View distance can be separately set for each clients independently from the server's value, through scripting.
This can make or break performance for the client.


What else?

You have applied all these recommendations and yet, your mission still doesn't run well in multiplayer (but does in singleplayer); an answer to that is that you are using mods, of which some are not well optimised, if at all.

If you want to be sure, run the same mission with and without mods. If you have a big difference in performance, look no further.