Wheeled by Wagn v. 1.14.4

Breaking out of the scheduled scripting 'prison'







Update; revised info and implementation available @ Wave.


As of ArmA 2, the scripting engine can schedule running scripts, causing them to run at a dynamic interval, sometimes even with delays up to multiple seconds.

This counts for all spawned/execVM'ed  script instances, as well as FSM states, unless a loading screen is displayed.


This is great for FPS, as it means no matter how crazy, and how many scripts you're running, it shouldn't affect FPS.

However, this is a real pain in the b, for any time sensitive (realtime / interactive speeds) system.

Good examples of these are: G-Force (Blackout) Effects, Parachute steering and Missile Guidance.


Additionally, the user is mostly unaware of unoptimized / problematic scripts (no notice in FPS), apart from reduced feature performance/responsiveness.

And no matter how much you optimize your own code, there's still problematic BIS modules, other addons, missions, bugs, and what not, that will throw off your systems regardless how well you optimized it.


Since a longer time we have been using loading screens for improving initialization speed and exploiting FSM conditions to run code synchronous, finishing the code before continueing the frame.


As of yesterday we've been prototyping a similair system that is intended for (longer running) loops, and the past hours we've implemented it for various of our systems, with extremely good results :)



It is important to note that running code synchronously with this method, requires extra care and consideration for performance, and what it is applied for.

A good rule of thumb seems to be to implement it for interactive (time sensitive) systems, that involve the player.


Other than that, suspending (sleep/waitUntil) is of course not allowed in this context (though handled differently, like you handle it in FSMs), while loops inside the code are limited to 10.000 iterations.

The behaviour is comparable to that of eventhandlers, triggers/editor init/condition fields etc.



Availability and Plans

The improvements will be available at next update. (There's a prototype of the FSM available already in CBA update of past Friday, however this has already been improved)


The discussion is available at: Google Wave | Public embed service

The prototype and code is available at: Google wavePublic embed service

More about Wave @ Dev-Heaven


We're also still improving and exploring more options, like alternatively using triggers, of which the conditions are ran twice per game-time-second.






_fsmHandle = [[parameters], {exit condition}, {code to run}, {optional, init code}, {optional, exit code}, [optional, private params that you want available through all code blocks], {optional, run condition}] execFSM CBA_common_delayLess_loop;

Where the fsm calls the code given as parameters, at the specified locations: Exit condition, Code to run, start, end, etc.

While [parameters] are read into a _params variable, accessible throughout all the code blocks.


A loop that exits when the player isn't alive anymore. It logs "Init" at launch and it iterates at minimum every 0.5 ingame-time-seconds and logs "Iteration".

_fsmHandle = [[], {!alive player}, {diag_log "Iteration"; _next = time + 0.5}, {diag_log "Init"; _next = time + 0.5}, {diag_log "Exit"}, ["_next"], {time > _next}] execFSM CBA_common_delayLess_loop;