What is this extension? It is a very simple .dll that would go to sleep for X milliseconds before returning control to Arma engine, hence the name delay_ms. Because the call to any extension is blocking, the engine has no choice but to wait until extension is finished before proceeding further. It also doesn’t matter if extension is called from scheduled or nonscheduled environment.

I originally made it to test some Arma engine functionality, but feel that it could also be a useful tool in testing server load for example. Arma server is running at max 50 FPS. This means it allows 20 ms of execution time per frame: 1000 ms / 50 FPS = 20 ms. If all scripts in the frame or a single script cannot be completed in 20 ms the frame will be extended until everything is completed. If your script requires 100 ms to complete this will bring FPS rate to 10: 1000 ms /10 FPS = 100 ms. So if you want to make the server run at 1 fps, for example, you need 1 second (1000 ms) delay…not recommended :) .

Of course the calculations are for the ideal circumstances and Arma engine has own processes to fit in the same frame too. In my tests I could use as much as 16 ms (not ideal 20 ms) delay and the server would still run at 50 FPS. 100 ms delay would make server run at 10 FPS however as predicted.  So what can you fit in 20ms? Depending on how good your CPU is, a simple SQF can be completed in as little as 0.002 ms (count []) and as much as 5 ms (allMissionObjects “”).

In nonscheduled environment, the engine will try to fit everything in one frame and this can affect frame rate directly. This is the reason while do loop is limited to 10,000 iterations in nonscheduled environment. You can still bring the engine to its knees even with this limitation, but this is a good measure to prevent complete game lock up. There are of course ways of bypassing this safety measure, but why would you want to do this?

In scheduled environment on the other hand, your scripts are limited to 3 ms run time after which they are resumed on the next frame. I have explained this in detail in Code Performance post. If you have long running script, in scheduled environment it will run even longer but you won’t be able to affect frame rate in the same way you could do it in nonscheduled environment. That is until you use a single command that takes longer than 3 ms. You can now easily do this with delay_ms extension.

I found interesting that if I limit server FPS to 10 in nonscheduled environment, both diag_fps and diag_fpsmin would show 10 FPS. If however I do this in scheduled environment, diag_fps would be 25 while diag_fpsmin would be 10. You can experiment with this yourself. Download delay_ms_v1.0.zip, unzip and drop it in Arma root dir as usual. Make sure you also have VS 2013 C++ redistributable package if required.

Here is how to lower server FPS in nonscheduled environment for a  pre-defined amount of time. Input: [delay (milliseconds), runtime (seconds)]. The example shows copy paste code to lower server FPS to 10 for 1 minute (must be executed on the server of course):

[100, 60] call { onEachFrame format [ 'if (time > %2) exitWith {onEachFrame {}}; "delay_ms" callExtension "%1"', _this select 0, time + (_this select 1) ]; };

To do the same in scheduled environment use the following code:

[100, 60] spawn { _d = str (_this select 0); _t = time + (_this select 1); waitUntil { if (time > _t) exitWith {true}; "delay_ms" callExtension _d; false }; };