Bug #22556

All objects require persistant network updates regardless of action

Added by jaynus almost 6 years ago. Updated almost 5 years ago.

Status:Closed Start date:07/20/2011
Priority:High Due date:
Assignee:- % Done:


Target version:1.62.95248
Affected ArmA II version:Please select... First affected build:
Reproduced by another DH user:No First affected ArmA II version:
I am using some Mods:No Single / Multi Player?:
I am using: BIForumURL:
Reproducible for you:No NGUrl:
Related to content of DLC: WIKIurl:


A server in MP will always send network updates for AI and objects regardless of changes or actions to these objects. This is best exhibited with AI, as is shown in the test mission below. enableSimulation false; halts all network traffic on these objects, and is a suitable workaround for this for caching measures with AI. However, I think it can still be considered an issue that the server will update objects on a massive scale over the network regardless of their state changes. It almost seems that the server is sending "Object state didnt change" messages to the clients.

Test mission attached.
1. Start the test mission on a dedicated server
2. Proceed to enable and disable the AI via the action menu

You will see the network traffic become excessive for the AI units, regardless of their movement or actions, as long as enableSimulation is true. The server will always send persistent updates for these AI regardless of activity.

Expected Results:
The server should only send network updates on objects which have actively changed.

testAI.utes.zip (13.3 kB) jaynus, 07/20/2011 19:49

Related issues

related to ARMA2 Community Issue Tracker - Bug #20426: AI FSM performance and FSM defaulting/nesting Feedback 06/15/2011


Updated by zGuba almost 6 years ago

  • Description updated (diff)
  • Due date set to 10/20/2011
  • Category set to Multiplayer
  • Status changed from New to Assigned

Updated by dslyecxi almost 6 years ago

  • Description updated (diff)

Do you believe this is the sort of issue that would cause larger counts of static objects to result in greater performance issues for the server?

Updated by jaynus almost 6 years ago

That is exactly the case, Dslyecxi; large amounts of static objects will essentially kill the server.

The problem is semi-fixed by enableSimulation false on all placed objects. However, you still get an initial JIP/mission start desync which risks taking down the server prior to the simulation being disabled.

Updated by Dwarden almost 6 years ago

  • Assignee set to Dwarden
  • Priority changed from Normal to High
  • Target version set to NextGen

Updated by Spyder001 over 5 years ago

My first attempt to fix this is below:


This opened way too many threads when tested with the town generation module for example. So I went with a less effective but much more simple solution. As objects are damaged this will help less. Make sure that this is executed on the server only. It would be possible to run this script every x minutes on the server however to ensure there is no lost performance.


Updated by Spyder001 over 5 years ago

Edit: Script runs every 120 seconds

Be advised, it is possible that if there are a lot of objects (as enableSimulation is global) that this script may cause desync every time this runs (when there is a large server load). A simple solution is it distribute enableSimulation for each object. Because each object uses spawn, you have to be creative.

sleep (random ((count playableUnits) / 2));

For a 60 player server, everything will be completed in 30 seconds. However it will have been distributed throughout that period. I'm going to just assume that this will happen and add it to the script.


Updated by wolffy.au over 5 years ago


_null = [] execVM "SPY\SPY_objectNetUpdate.sqf";

if(!isServer) exitWith{};

[] spawn {
        while {true} do {
        private ["_i","_t"];
        _i = 0;
        _t = time + 60;
                        if (simulationEnabled _x) then {
                                _x enableSimulation false;
                _i = _i + 1;

                                if (((typeOf _x) in ["HeliHEmpty"])) exitWith {};

                                _x addEventHandler ["Hit", "(_this select 0) enableSimulation true;"];    

                                // DEBUG
                                //player sideChat format ["OBJ: %1", _object];

            if(time > _t) exitWith {};

                } forEach (((allMissionObjects "Static") + (allMissionObjects "Thing")) - (allMissionObjects "ThingEffect"));

        if(_i > 0) then {diag_log format["MSO-%1 Spyder Object Network Update - %2 objects disabled", time, _i];};
        sleep 120;

Here's my MSO version. Still to see what effect it has, but its saying its disabling 217+ objects on start-up.

Updated by Spyder001 over 5 years ago


_null = [] execVM "SPY\SPY_objectNetUpdate.sqf";

private ["_includes", "_excludes"];

if(!isServer) exitWith {};

waitUntil {time > 1};

while {true} do {

    _includes = ((allMissionObjects "Static") + (allMissionObjects "Thing"));
    _excludes = ((allMissionObjects "ThingEffect") + (allMissionObjects "ReammoBox2") + (allMissionObjects "HeliH"));


        if ((isNil {_x getVariable "SPY_oNetU_running"})) then {

            [_x] spawn {

                private ["_object", "_damage"];

                sleep (random ((count playableUnits) / 3));

                _object = (_this select 0);

                _object enableSimulation false;

                _object setVariable ["SPY_oNetU_running", 1, false];

                // DEBUG
                // player sideChat format ["OBJ: %1", _object];

                while {true} do {

                    _damage = (damage _object);

                    waitUntil {sleep 0.5; (_damage < (damage _object))};

                    _object enableSimulation true;

                    // DEBUG
                    // player sideChat "SIMULATION ENABLED";

                    sleep 5;

                    _object enableSimulation false;

                    // DEBUG
                    // player sideChat "SIMULATION DISABLED";

                    if (((damage _object) >= 1)) exitWith {};




    } forEach (_includes - _excludes);

    // DEBUG
    diag_log format ["(SPY oNetU - %1): %2 / %3 Objects Disabled", time, _disabled, (count (_includes - _excludes))];

    sleep 30;


Replaced the hit eh with a waitUntil. Mahuja reported to me that I would be better off without the sleep 0.5 in my waitUntil but I want to just do a quick test to make sure.

Updated by jaynus over 5 years ago

Can I assume fixes for this is associated with the below beta notes? They seem relevant, but I just want to confirm; especially since they could just be side-effects of the interpolation changes, although they are associated with this ticket indirectly.

[84374] Optimized: MP: Reduced bandwidth used by standing AI soldiers.
[84271] Fixed: MP: Reduced bandwith usage in missions with many soldiers.

Updated by HomerJohnston over 5 years ago

Just thought I'd add that using "this enableSimulation false" on static objects has no effect whatsoever on server load, bandwidth or FPS. Tested with one client on a dedicated server and 12,000 static objects, game version 1.59 non-beta.

Tested simply by watching #monitor 10 and comparing the numbers, which were essentially the same (average of 15-25 FPS, initial burst of 900Kbps settling down to around 50Kbps)

Updated by bebul almost 5 years ago

Is this still the problem? If so, can anybody prepare some simple repro mission with few objects (the repro mission in this ticket is populated very much)? Is the problem with static objects mostly or with any objects?

Updated by Nou almost 5 years ago

I don't think this is an issue anymore. I had a bunch of local AI on a dedicated server with just myself connected and the outbound bandwidth was 0-5kbps. Not sure about static objects created in game via createVehicle though...

Updated by Fireball almost 5 years ago

  • Due date deleted (10/20/2011)
  • Status changed from Assigned to Resolved
  • Assignee deleted (Dwarden)
  • Target version changed from NextGen to 1.61 BETA

Thus marking resolved.

Updated by kju almost 5 years ago

  • Target version changed from 1.61 BETA to 1.62.95248

Updated by kju almost 5 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF