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