Download | Support | Changelogs

 

Documentation:

General Information

Introduction | Overview | Features | Goals and Scope | FAQ Installation | Running an ACE Server | Tracking Problems

 

Community Information

About Us (contact) | Compatible Mods | Contribute | Guides | Missions | Servers | Videos

 

Developer Information

API | Classlists | Compatibility | Modification | Resources

 

Ongoing development Wagn_feed_icon-medium-9343

ACE 1.14 RC1 [2012-10-26]

 

Stable Wagn_feed_icon-medium-9343

   ACE 1.13 for OA [2011-12-23]

   ACE 1.3 for A2 [2010-07-05] (Deprecated)

 

Dev blogs Wagn_feed_icon-medium-9343

1 2 next » (38)

1 2 next » (38)

 

Wheeled by Wagn v. 1.10.7

 

Ace_logo_2-small-12945

 

Breaking_out_of_the_scheduled_scripting_prison_+image-large-10990

 

+blog

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 :)

 

Notes

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.

 

 

Usage

 

Breaking_out_of_the_scheduled_scripting_prison_+blog+image-large-11039

_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.

Example

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;