Jump to navigation Jump to search
- Suspend execution for given time in seconds. The sleep precision is given by a framerate, the delay given is the minimal delay expected. Must be called inside of a context which is interruptible, i.e. a script executed by execVM or spawn.
- this command only guarantees that the code will be suspended "at least" the given amount of time, however it often is more and on occasion is a lot more if script scheduler is particular busy
- this command will suspend the script indefinitely if game simulation is paused in SP. To avoid this, use uiSleep.
- Posted on December 20, 2006 - 19:53
- Sleep suspends both SQF functions and SQF scripts. In functions, the calling script is still in suspension due to waiting for a return from the call command. The game engine will continue, however. See Function for more detail.
- Posted on February 12, 2007 - 20:16
- Sleep durations between .0005 and .02 will cause the same delay (roughly .02 seconds).
Delays of .0005 and less have no effect (ie, the sleep call will return immediately).
- The comment above is a little misleading. The game engine appears to work by processing frames and then checking to see whether scripts are available to execute. Sleep causes the script/function to be suspended until at least the specified time has elapsed. To wait for the next frame, or give other scripts a chance to run, use Sleep 0.001.
- Posted on July 16, 2007 - 00:13
- For scripts called by the Init Event Handler the first sleep command will suspend the script at the briefing screen at the start of a mission. The script will continue after the briefing screen, when actually "in game".
- Posted on July 12, 2014 - 13:41 (UTC)
- Sleep will treat negative values as if they were 0. (Tested in Arma 3 v1.22)
- Posted on October 18, 2014 - 21:24 (UTC)
- For server scripts, if you are creating "while true" timers, it is best to use uiSleep instead, as the sleep from that command is not slowed down by simulation / server lag, so the timers will execute at intervals that are much closer to real time, even under heavy lag.