"Script-lag"?

[dmarkwick 261]

I've noticed a phenomena in ArmA2, which I can only describe as a sort of "script lag". It's most noticeable when you do addons that require heavy real-time visual feedback, which for me means effects and particles.

When the game has been running for a little while, or is getting a little complex, scripts seem to be scheduled to run on some sort of queuing basis, eventually descending into a cycle of pauses between executions. As an example, I have an addon that uses lots of small particle emitters in development. For a good while, these emitters act OK, looking pretty much consistent. After a while however, some of them will simply stop, then start, or might emit much more slowly, or some combination.

Another addon I'm developing has an object (invisible ingame but visible for dev purposes) rise up over time, a discrete value each second in fact. When there is "script-lag" going on, this movement is affected, meaning that it doesn't rise at the required rate.

A fired event sometimes happens several seconds after the fired event itself.

In yet another example, I try to synchronise two activities by passing the same lifetime parameter to each script, relying on that value to ensure that two things happen (or rather stop happening) at the same time. Script-lag means that in fact these two actions are wildly out of sync in time. It seems that even using "time" command to ensure something happens at a set time ingame doesn't cure this, as script-lag means that the check might not be done for several seconds, or even longer (sometimes as long as a couple of minutes even.)

Now, I can see how this might be some sort of performance saving measure, but my question is: is it related to the fact that I'm just using scripts? I'm not using any precompile or other fidgey-widgeyness. I note that other addons that you might suppose are susceptible to script-lag are in fact not, for example I have at least two blood addons running, and they seem to act OK. I guess I'm asking for some explanation/example of how to use this feature, where it happens, stuff like that.

[Deadfast 43]

In ARMA 2 scripts can only run for 3ms.

If it takes longer than that the execution is interrupted until the next frame.

[.kju 3245]

Scripts may not take longer than 3ms per frame, if they do, the execution will be halted until the next frame.

This could have quite some impact depending on the time-sensitivity of your scripts.

http://community.bistudio.com/wiki/ArmA:_Editing#Forward_Compatibility

http://dev-heaven.net/boards/37/topics/show/949#message-1082

I think thats what you after.

[dmarkwick 261]

Hmm, thanks for the info & links guys. I'm guessing that 3ms limit is not per script, but for ALL current scripts executing?

It seems, to me, that the overflow scripts are not executed strictly in order, as often the same script (or instance of script) will be delayed for many seconds.

[.kju 3245]

well how about doing some time measuring and logging that to rpt

http://community.bistudio.com/wiki/diag_tickTime

http://community.bistudio.com/wiki/diag_log

[dmarkwick 261]

*Idea*

I wonder if BIS would consider exposing/cfg enabling this 3ms value? For people who'd exchange performance for script fluidity?

[.kju 3245]

Read up why they have implemented it and you will understand why this will never happen.

[dmarkwick 261]

I saw this snippet:

It is under evaluation if and how possibly allow user scripts to change how much time they may take from the CPU in every frame.

which, while I will admit is not inclusive of my own suggestion, does suggest that there's still room for movement on user-timings etc.

I guess what also could be implemented is a more robust queuing system, so that scripts that are delayed get increased priority next frame around. Last night for example I timed 17 seconds from a user action to execution, how many 3ms time limits did that particular example miss? If I estimate a 15 FPS performance at the time, I guess that means it missed at least 255.

[TRexian 0]

Is there some way to log when it happens and to which scripts? That might allow for the author to re-arrange the structure to mitigate the problem.

[.kju 3245]

hey DMarkwick, try this good blog post by i0n0s:

new-to-arma-2-the-3ms-break

[dmarkwick 261]

Thanks for the link :)

I already implement judicious use of the Sleep command, so I think it's just sheer script numbers clogging up. I still think there's a scheduling problem though.

Edited September 22, 2009 by DMarkwick

[charon productions 10]

Yeah i have a hard time with that too.

In a big battle, a simple "10 line camera script" that follows a unit

can lag up to 5 seconds in some cases.

A priority handle would be really helpful for very important time-critical scripts.

At least it`s up to the developer then to decide about FPS issues.

I am also under the impression that this script cueing system has some

bug in it like DMarkwick notioned that unnecessarily clogs up scripts in queues.

[.kju 3245]

Well unless you show your code (in pastebin), no one will be able to tell you.

[dmarkwick 261]

Well unless you show your code (in pastebin), no one will be able to tell you.

Pastebin link.

But there's really nothing to it kju, just a script that runs for 10 minutes and employs a simple distance culling conditional to emit particles or not. The thing is, there can be several hundred of them :D so that's where the script-lag comes into it. I only see the script-lag about 20 minutes into any mission that uses this addon, the effect is that sometimes emitters simply stop, or are intermittent, or are inconsistent, or some combination. If the scheduler was robust, I would expect to see consistent slowdown across all instances of the script, but it appears that I do not.

[.kju 3245]

Thanks. Here with better formatting. :P

http://pastebin.com/f3f4da137

a) Not having private at top could be a problem.

b) Why do you need that many instances? More instances are never a good idea from what I can tell. Just put all positions in an array or shuffle them between two (10s sleep vs every 0.4s check ones).

[dmarkwick 261]

Thanks for the look :)

a. I thought that the Private statement is processed prior to the script in any case? If not, no big deal to move them all.

b. Each instance (which amounts to each emitter) has a unique position, lifetime, direction of emission and two unique colours also, I'd hate to deal with the array that shuffles all that about :)

To clarify, this is part of an addon that works with a tracker dog we're developing. Each unit drops such an emitter at regular distances, with a unique "scent" (colour makeup) and each emitter emitting toward the next emitter for that unit. So that the tracker dog can follow a unique colour trail among other trails and track someone down.

Sample vid:

Example trail emitters first evident at about 2 minutes in.

Edited September 22, 2009 by DMarkwick

[sbsmac 0]

Ok, here's my theory about what is happening....

You have said that you have spawned several hundred instances of the script. These are likely held by the scheduler as a list S0,S1,S2...Sn.

I strongly suspect that after rendering a frame, the scheduler starts executing S0, then S1, S2 etc until it runs out of time (3ms). At that point it returns control to the rendering engine which renders another frame. The scheduler is then re-run and starts executing S0, S1 etc.

The net effect (if I am correct) would be that you would see some instances of the script (Sn where 'n' is a large-ish number) running intermittently or not at all depending upon the CPU load of the scripts ahead of it in the list.

You can test this theory very easily by spawning a few very CPU-intensive scripts and seeing whether they all run (detectable by emitting diag_log strings).

If this is the case, there is no easy workaround except to implement your own 'scheduler' by replacing the spawned instances with an array which you iterate over as kju suggests.

In any case, it would be interesting to know the results of your tests.