New to ArmA 2: The "3ms-break"

BI implemented a new "feature" in ArmA 2. This feature is not noticeable for normal people, but mostly for developer.

So what's about the feature?

Scripts will get paused if it takes to much cpu time. This allows other scripts to run. On the next frame the script will continue.

This allows to use scripts like this:

Code:

...

In Armed Assault this would lock the client. A real nice death lock
In ArmA II, the script will run without locking the client. ArmA II will break the script so that no death lock will appear.
Nevertheless:
This is an endless loop and will take every resource it can. So don't do this and add sleeps.

Why 3 ms?

We don't know which time a script can take, we simply say 3 ms. And it isn't really important how long it can run without a break. This will change from computer to computer and from mission to mission. It is just important to know this.

Ok, good or bad?

You already know this bug. It's a effect by this "feature".
But in general:
It's a good feature for starter since they cannot lock ArmA II. The worse is: They cannot lock ArmA II. So they won't detect such faults. And I know what I'm talking off

Is there any way around it?

Yes, but it won't work in every case. Those break doesn't occur in scripts which doesn't allow suspension. So event handler and trigger are a good place for it. With the downside that we can't use waitUntil and sleep. But this is not that worse. It's more worse that we cannot start this scripts any more, at least not direct like call. We can simulate spawn via a trigger and also can add a return value, but we still need to wait till the trigger fires, at least one frame.
We will have a forced sleep if we want to bypass the 3 ms break, at least if we can't use a event handler.
Or we have scripts which run every x seconds, in this case we can use triggers to fire them on time. We just need one trigger for each script. On activation will set the variable trigger to false and executes the script. On deactivation we set the variable to true again. We just set the timeout time to the required delay.
If we have a script which should get executed every frame, we have a problem since a trigger will get evaluated only every half second.