{"name":"Mission Optimisation","title":"Mission Optimisation","type":"topic","url":"https://community.bistudio.com/wiki/Mission_Optimisation","revid":377936,"updated":"2026-01-11T16:56:35Z","aliases":[],"markdown":"> [!NOTE]\n> This page is about Mission Optimisation. For *scripting* optimisation, see Code Optimisation.\n\nThis article will try to be a general guide about improving your **mission's** performance.\nAs usual, moderation is the key; do not expect to find on this page a magical solution that makes it possible to run thousands of AI at 240 FPS.\nEverything comes at a cost, the tweaks here will simply allow you to locate issues and calibrate your mission properly.\n\n### Before Anything\n\nBefore optimising anything, make sure you do not have any performance issue running the game itself:\n\n- Read Arma 3: Performance Optimisation\n- Open the editor, place a unit in the area you like and test your computer.\n  - You can get current FPS in Arma 3 by going into **video options** or using diag_fps\n  - **Steam** allows you to display FPS in a screen corner, in *Settings > In game > FPS Counter*\n- Use (unofficial) Performance Guides to get better performances:\n  - [Arma 3 performance guide](https://steamcommunity.com/sharedfiles/filedetails/?id=1731305438)\n  - [Arma 2 performance guide](https://www.moddb.com/forum/thread/arma-2-ultimate-tweak-thread)\n  - [Armed Assault performance guide](https://forums.bohemia.net/forums/topic/50167-pc-optimization-for-arma/)\n- Play your mission in singleplayer. If your mission runs fine, its network messages might very well be the issue. See Multiplayer Scripting for good practice tips.\n- Usual bottlenecks:\n  - Lower your graphical settings (resolution, textures). If you get way better performances, at least your **GPU** limits you.\n  - 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.\n\n> [!IMPORTANT]\n> Please note that view distance (among other settings) impacts both GPU and CPU!\n\n> [!NOTE]\n> View distance can be separately set for each clients independently from the server's value through scripting.\n> This can make or break performance for the client.\n\n### Mission Creation\n\n- Be sure to create your scripts with the latest available commands and functions.\n  - In Arma 3 use remoteExec / remoteExecCall and **DITCH BIS_fnc_MP FOR GOOD!** See Arma 3: Remote Execution for more information.\n  - In Arma 2 network communication is done using the Arma 2: Multiplayer Framework.\n- Use the available frameworks and functions for each topic, unless you replace them by third-party ones:\n  - Arma 3: Respawn\n  - Arma 3: Revive\n  - Arma 3: Task Framework\n  - Arma 3: Animated Briefing\n  - Arma 3: Animated Opening\n  - Arma 3: Dynamic Groups\n  - Arma 3: Key Frame Animation\n  - and most importantly: Functions\n\n### Performance Impact Table\n\n> [!NOTE]\n> ● means a heavy impact on performance\n> ●\tmeans an average impact\n> ● means little to no performance impact.\n\n| Topic | CPU | GPU | Net-<br>work | Solution |\n|---|---|---|---|---|\n| **AI unit quantity** | ● | ● | ● | - Use Agents whenever possible<br>- The more units there are, the more network updates there will be - hence the impact on both CPU and network.<br>- If a client has a low-end machine, they should not lead a group of many AIs as these would then be locally computed.<br>- Arma 3: Dynamic Simulation allows you to freeze AI that are distant from players. Many distance settings should be set according to the mission.<br>> [!NOTE]<br>> If you own more than one average computer, you could consider Headless client to offload AI from the server. |\n| **Object quantity** | ● | ● | ● | The less objects, the more FPS you will have.<br>- Lower the quantity of objects in the mission, such as:<br>  - AI units, agents<br>  - vehicles, simple objects<br>  - weapon attachments (their proxies are attachedTo)<br>  - headgear, clothing, vests, backpacks<br>  - head-mounted devices (NVGs, etc.)<br>- Lower view distance<br>- Lower terrain details<br>- Lower the Dynamic Simulation threshold<br>- Use Simple Objects<br>- Use **Garbage Collection** in order to automatically delete bodies and wreckages:<br>  - Arma 3's Eden-integrated Garbage Collection<br>  - Arma 2's Garbage Collector<br>  - Take On Helicopters's BIS_fnc_GC<br>> [!NOTE]<br>> Only the *on-screen* objects will strongly impact the GPU. |\n| **General script mistakes** | ● | ● | ● | Having too many scripts running is a cause for severe performance issues and execution delays in singleplayer as well as multiplayer.<br>- You can track the number of running scripts using diag_activeScripts; you can also use:<br>  - diag_activeSQFScripts<br>  - diag_activeSQSScripts<br>  - diag_activeMissionFSMs<br>- A common bad practice is to spawn a function for each units that need it; the good practice would be to have a single script working with an array of units, array that is edited (unit added/removed) whenever needed:<br>  ```sqf<br>  { _x spawn _myCode; } forEach _units;    // bad<br>  _units spawn _myCode;                    // good<br>  ```<br>  You can use diag_activeSQFScripts to ensure you are not clogging your CPU with multiple instances of the same script.<br>- **Not compiling your scripts:** running multiple times the same script with execVM will make the game read the file every single time; This is an issue, especially if you execute it frequently.<br>  ```sqf<br>  while { sleep 5; alive player } do { player execVM \"myScript.sqf\"; };    // bad<br>  private _myScript = compile preprocessFileLineNumbers \"myScript.sqf\";<br>  while { sleep 5; alive player } do { player spawn _myScript; };            // better<br>  while { sleep 5; alive player } do { player spawn TAG_fnc_myScript; };    // perfect! see Functions<br>  ``` |\n| **High-frequency scripts** | ● | ● | ● | Checking a condition too often is usually a source of poor performance. Does your code execution need to be frame-perfect, or can you afford a delay of a few seconds?<br>- A while-loop checking without a minimum loop-sleep time is usually a sign of bad conception.<br>  ```sqf<br>  while { true }                        // bad if you do not know what you are doing<br>  while { alive player }                // better<br>  while { sleep 1 ; alive player }    // perfect<br>  ```<br>- By default, Triggers check their set condition **every 0.5 second**. If a large area is covered or condition code is too complex, this can become an issue; the triggers should then be converted to scripts if possible. Since Arma 3 v2.00 it is possible to change trigger intervals, either via trigger attributes in 3DEN, or via the scripting command setTriggerInterval.<br>- Triggers can be made **Server-Side only** to save clients' resources.<br>> [!IMPORTANT]<br>> All of the mission-related calculation (objectives, completion distance, etc.) must be done **server-side**. Local effects should be calculated **client-side**. |\n| **High-frequency network messages** | ● | ● | ● | - Use publicVariable wisely; for specific cases, consider publicVariableServer / publicVariableClient<br>- Creating units/vehicles globally implies a network synchronisation, keep them to a minimum / at one-point in the mission.<br>- Keep global effect commands to a minimum:<br>  - 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.<br>  - global marker commands always send *all* the marker's information. If you are creating/updating many markers e.g server-side, edit them with local commands, except the last one (that will be global) to send the whole marker's status over the network, once.<br>- Lower client's view distance in order to lessen its object position update requests |\n| **Unscheduled code** | ● | ● | ● | Unscheduled code can have a high impact on the framerate, as such code is not subject to the scheduler's management (as its name suggests) and will run without limitation. Cyclic unscheduled low-performance code can make the game unplayable, up to freezing it.<br>- As only time-critical scripts should run unscheduled, spawn any other code from unscheduled environment once you have the required results:<br>  ```sqf<br>  /* ... */ // unscheduled code<br>  [_var1, _var2] spawn TAG_fnc_MyFunction;<br>  /* ... */ // other unscheduled code<br>  ```<br>> [!NOTE]<br>> See also Scheduler - Where code starts unscheduled. |\n\n### What Else?\n\nIf you have applied all these recommendations and your mission still does not run well in multiplayer (but does in singleplayer),\nit might be caused by **mods** that you are running which could be badly, or not at all, optimised.\n\nIf you want to be sure, run the same mission with and without mods. If you have a big difference in performance, look no further.\n\n### Performance Diagnostic Tools\n\n#### Server Commands\n\n- #monitor 5\n  - Shows performance information of the server. Interval 0 means to stop monitoring.\n- #monitords 5\n  - Shows performance information in the dedicated server console. Interval 0 means to stop monitoring. (since Arma 3 v1.64)\n\n#### Diagnostic Commands\n\n- Diag. commands only available in Diagnostic Branch\n- Diag. command available in all builds\n\n### See Also\n\n- Multiplayer Scripting\n- Code Optimisation\n- Code Best Practices\n- Performance Profiling\n- Dedmen's ArmaScriptProfiler ([forum post](https://forums.bohemia.net/forums/topic/211626-arma-script-profiler/))","sections":[{"heading":null,"level":1,"markdown":"> [!NOTE]\n> This page is about Mission Optimisation. For *scripting* optimisation, see Code Optimisation.\n\nThis article will try to be a general guide about improving your **mission's** performance.\nAs usual, moderation is the key; do not expect to find on this page a magical solution that makes it possible to run thousands of AI at 240 FPS.\nEverything comes at a cost, the tweaks here will simply allow you to locate issues and calibrate your mission properly."},{"heading":"Before Anything","level":3,"markdown":"Before optimising anything, make sure you do not have any performance issue running the game itself:\n\n- Read Arma 3: Performance Optimisation\n- Open the editor, place a unit in the area you like and test your computer.\n  - You can get current FPS in Arma 3 by going into **video options** or using diag_fps\n  - **Steam** allows you to display FPS in a screen corner, in *Settings > In game > FPS Counter*\n- Use (unofficial) Performance Guides to get better performances:\n  - [Arma 3 performance guide](https://steamcommunity.com/sharedfiles/filedetails/?id=1731305438)\n  - [Arma 2 performance guide](https://www.moddb.com/forum/thread/arma-2-ultimate-tweak-thread)\n  - [Armed Assault performance guide](https://forums.bohemia.net/forums/topic/50167-pc-optimization-for-arma/)\n- Play your mission in singleplayer. If your mission runs fine, its network messages might very well be the issue. See Multiplayer Scripting for good practice tips.\n- Usual bottlenecks:\n  - Lower your graphical settings (resolution, textures). If you get way better performances, at least your **GPU** limits you.\n  - 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.\n\n> [!IMPORTANT]\n> Please note that view distance (among other settings) impacts both GPU and CPU!\n\n> [!NOTE]\n> View distance can be separately set for each clients independently from the server's value through scripting.\n> This can make or break performance for the client."},{"heading":"Mission Creation","level":3,"markdown":"- Be sure to create your scripts with the latest available commands and functions.\n  - In Arma 3 use remoteExec / remoteExecCall and **DITCH BIS_fnc_MP FOR GOOD!** See Arma 3: Remote Execution for more information.\n  - In Arma 2 network communication is done using the Arma 2: Multiplayer Framework.\n- Use the available frameworks and functions for each topic, unless you replace them by third-party ones:\n  - Arma 3: Respawn\n  - Arma 3: Revive\n  - Arma 3: Task Framework\n  - Arma 3: Animated Briefing\n  - Arma 3: Animated Opening\n  - Arma 3: Dynamic Groups\n  - Arma 3: Key Frame Animation\n  - and most importantly: Functions"},{"heading":"Performance Impact Table","level":3,"markdown":"> [!NOTE]\n> ● means a heavy impact on performance\n> ●\tmeans an average impact\n> ● means little to no performance impact.\n\n| Topic | CPU | GPU | Net-<br>work | Solution |\n|---|---|---|---|---|\n| **AI unit quantity** | ● | ● | ● | - Use Agents whenever possible<br>- The more units there are, the more network updates there will be - hence the impact on both CPU and network.<br>- If a client has a low-end machine, they should not lead a group of many AIs as these would then be locally computed.<br>- Arma 3: Dynamic Simulation allows you to freeze AI that are distant from players. Many distance settings should be set according to the mission.<br>> [!NOTE]<br>> If you own more than one average computer, you could consider Headless client to offload AI from the server. |\n| **Object quantity** | ● | ● | ● | The less objects, the more FPS you will have.<br>- Lower the quantity of objects in the mission, such as:<br>  - AI units, agents<br>  - vehicles, simple objects<br>  - weapon attachments (their proxies are attachedTo)<br>  - headgear, clothing, vests, backpacks<br>  - head-mounted devices (NVGs, etc.)<br>- Lower view distance<br>- Lower terrain details<br>- Lower the Dynamic Simulation threshold<br>- Use Simple Objects<br>- Use **Garbage Collection** in order to automatically delete bodies and wreckages:<br>  - Arma 3's Eden-integrated Garbage Collection<br>  - Arma 2's Garbage Collector<br>  - Take On Helicopters's BIS_fnc_GC<br>> [!NOTE]<br>> Only the *on-screen* objects will strongly impact the GPU. |\n| **General script mistakes** | ● | ● | ● | Having too many scripts running is a cause for severe performance issues and execution delays in singleplayer as well as multiplayer.<br>- You can track the number of running scripts using diag_activeScripts; you can also use:<br>  - diag_activeSQFScripts<br>  - diag_activeSQSScripts<br>  - diag_activeMissionFSMs<br>- A common bad practice is to spawn a function for each units that need it; the good practice would be to have a single script working with an array of units, array that is edited (unit added/removed) whenever needed:<br>  ```sqf<br>  { _x spawn _myCode; } forEach _units;    // bad<br>  _units spawn _myCode;                    // good<br>  ```<br>  You can use diag_activeSQFScripts to ensure you are not clogging your CPU with multiple instances of the same script.<br>- **Not compiling your scripts:** running multiple times the same script with execVM will make the game read the file every single time; This is an issue, especially if you execute it frequently.<br>  ```sqf<br>  while { sleep 5; alive player } do { player execVM \"myScript.sqf\"; };    // bad<br>  private _myScript = compile preprocessFileLineNumbers \"myScript.sqf\";<br>  while { sleep 5; alive player } do { player spawn _myScript; };            // better<br>  while { sleep 5; alive player } do { player spawn TAG_fnc_myScript; };    // perfect! see Functions<br>  ``` |\n| **High-frequency scripts** | ● | ● | ● | Checking a condition too often is usually a source of poor performance. Does your code execution need to be frame-perfect, or can you afford a delay of a few seconds?<br>- A while-loop checking without a minimum loop-sleep time is usually a sign of bad conception.<br>  ```sqf<br>  while { true }                        // bad if you do not know what you are doing<br>  while { alive player }                // better<br>  while { sleep 1 ; alive player }    // perfect<br>  ```<br>- By default, Triggers check their set condition **every 0.5 second**. If a large area is covered or condition code is too complex, this can become an issue; the triggers should then be converted to scripts if possible. Since Arma 3 v2.00 it is possible to change trigger intervals, either via trigger attributes in 3DEN, or via the scripting command setTriggerInterval.<br>- Triggers can be made **Server-Side only** to save clients' resources.<br>> [!IMPORTANT]<br>> All of the mission-related calculation (objectives, completion distance, etc.) must be done **server-side**. Local effects should be calculated **client-side**. |\n| **High-frequency network messages** | ● | ● | ● | - Use publicVariable wisely; for specific cases, consider publicVariableServer / publicVariableClient<br>- Creating units/vehicles globally implies a network synchronisation, keep them to a minimum / at one-point in the mission.<br>- Keep global effect commands to a minimum:<br>  - 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.<br>  - global marker commands always send *all* the marker's information. If you are creating/updating many markers e.g server-side, edit them with local commands, except the last one (that will be global) to send the whole marker's status over the network, once.<br>- Lower client's view distance in order to lessen its object position update requests |\n| **Unscheduled code** | ● | ● | ● | Unscheduled code can have a high impact on the framerate, as such code is not subject to the scheduler's management (as its name suggests) and will run without limitation. Cyclic unscheduled low-performance code can make the game unplayable, up to freezing it.<br>- As only time-critical scripts should run unscheduled, spawn any other code from unscheduled environment once you have the required results:<br>  ```sqf<br>  /* ... */ // unscheduled code<br>  [_var1, _var2] spawn TAG_fnc_MyFunction;<br>  /* ... */ // other unscheduled code<br>  ```<br>> [!NOTE]<br>> See also Scheduler - Where code starts unscheduled. |"},{"heading":"What Else?","level":3,"markdown":"If you have applied all these recommendations and your mission still does not run well in multiplayer (but does in singleplayer),\nit might be caused by **mods** that you are running which could be badly, or not at all, optimised.\n\nIf you want to be sure, run the same mission with and without mods. If you have a big difference in performance, look no further."},{"heading":"Performance Diagnostic Tools","level":3,"markdown":""},{"heading":"Server Commands","level":4,"markdown":"- #monitor 5\n  - Shows performance information of the server. Interval 0 means to stop monitoring.\n- #monitords 5\n  - Shows performance information in the dedicated server console. Interval 0 means to stop monitoring. (since Arma 3 v1.64)"},{"heading":"Diagnostic Commands","level":4,"markdown":"- Diag. commands only available in Diagnostic Branch\n- Diag. command available in all builds"},{"heading":"See Also","level":3,"markdown":"- Multiplayer Scripting\n- Code Optimisation\n- Code Best Practices\n- Performance Profiling\n- Dedmen's ArmaScriptProfiler ([forum post](https://forums.bohemia.net/forums/topic/211626-arma-script-profiler/))"}],"categories":["Arma Scripting Tutorials"],"groups":["Scripting"]}