waitUntil – Talk

From Bohemia Interactive Community
Revision as of 17:27, 28 April 2023 by Lou Montana (talk | contribs) (Text replacement - "\[ *((ftp|http)s?:\/\/[^ ]+)([^{])=([^}])([^ ]+)" to "[$1$3{{=}}$4$5")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Is it just my imagination or do conditional waits actually check the condition very, very often? Someone might want to check out how often; more complex scripts can really degrade the performance -- Manny 16:34, 14 April 2007 (CEST)

waitUntil works within the confines of the particular hardware running Arma. If you try to exceed the capabilities of your hardware, then you will probably notice some sort of degradation. It can't perform the impossible. UNN 01:26, 17 April 2007 (CEST)

I was trying to use waitUntil in a trigger's OnActivation field but it would give Generic error. I set waitUntil in code but that didn't work either.

dowaitthing = {player sidechat "hi"; waituntil {alive player}; player sidechat "boo"}; And in the trigger I used call dowaitthing. sleep wouldn't work this way either. --Doolittle 18:40, 19 July 2007 (CEST)


If it's from a trigger or init field, you have to call it like this:


dowaitthing =[] Spawn {player sidechat "hi"; waituntil {alive player}; player sidechat "boo"};

Or move the code into a script file and spawn or execVM that file. Same goes for sleep to. UNN 15:09, 20 July 2007 (CEST)


The output of the following code suggests that the code block is run once per frame. In the output I get no frame number is omitted or appears twice. /* for ARMA 2 only, output goes to the RPT file */ diag_log ">>> start"; _h = [] spawn { waitUntil { diag_log diag_frameNo; false } }; sleep 1; terminate _h; diag_log ">>> stop"; --Worldeater 15:32, 18 June 2009 (CEST)


Performance

I have removed Manny's note regarding possible high system strain when using this command, as I wasn't able to verify his fears. I ran over 500 concurrent waitUntils (even without any sleep delays in them), and noticed hardly any performance degradation. --Kronzky 22:10, 29 April 2009 (CEST)