time: Difference between revisions

From Bohemia Interactive Community
Jump to navigation Jump to search
mNo edit summary
m (Text replacement - ">Posted on October ([0-9]{2})[ a-zA-Z]*, ([0-9]{4})" to ">Posted on $2-10-$1")
 
(87 intermediate revisions by 11 users not shown)
Line 1: Line 1:
{{Command|= Comments
{{RV|type=command
____________________________________________________________________________________________


| ofp |= Game name
|game1= ofp
|version1= 1.00


|1.00|= Game version
|game2= ofpe
____________________________________________________________________________________________
|version2= 1.00


| Time elapsed since mission started (in seconds). |= Description
|game3= arma1
____________________________________________________________________________________________
|version3= 1.00


| [[Number]] <nowiki>=</nowiki> '''time''' |= Syntax
|game4= arma2
|version4= 1.00


| [[Number]] |= Return value
|game5= arma2oa
____________________________________________________________________________________________
|version5= 1.50


| [[daytime]], [[date]], [[dateToNumber]] |= See also
|game6= tkoh
|version6= 1.00


}}
|game7= arma3
|version7= 0.50


<h3 style="display:none">Notes</h3>
|gr1= Time
<dl class="command_description">
|gr2= Mission Information
<!-- Note Section BEGIN -->


<dd class="notedate">Posted on August 4, 2006 - 12:02</dd>
|descr= Returns time elapsed since mission started (in seconds). The value is different on each client. If you need unified time, use [[serverTime]].
<dt class="note">'''[[User:Hardrock|hardrock]]'''</dt><dd class="note">''Notes from before the conversion:''


Not to be confused with '''_time'''. Within a script, the reserved local variable '''_time''' returns the time elapsed since the script started running. Note that the value of time is not saved when the mission is saved and so will be reset to zero when a mission is restarted from a saved position. The value of _time is saved correctly and will resume from where it was.
|s1= [[time]]
</dd>


<dd class="notedate">Posted on January 5, 2007 - 12:24</dd>
|r1= [[Number]]
<dt class="note">'''[[User:Giova|Giova]]'''</dt><dd class="note">''Notes from before the conversion:''


time works properly in sqf called with execVM command. In an other hand, _time does not works in sqf called with execVM command.(Arma v1.02.5103GER)</dd>
|x1= <sqf>private _future = time + 30;
waitUntil { time >= _future };  // continue after 30 seconds</sqf>


<dd class="notedate">Posted on October 02, 2010 - 12:02</dd>
|x2= Wait until mission fully started:
<dt class="note">'''[[User:TeaCup|teaCup]]'''</dt><dd class="note">
<sqf>waitUntil { time > 0 };</sqf>
On overloaded servers (below ~10 server FPS), time readings are unreliable. Seconds actually take longer. While the clients keep a steady tempo, server time "slides" backward, resulting in considerable offset between client and server time (easily 30 minutes for a 2 hour game). Server and client time are synchronised during JIP, but other than that they run independently.
</dd>


<!-- Note Section END -->
|seealso= [[date]] [[dayTime]] [[serverTime]] [[skipTime]] [[accTime]] [[dateToNumber]] [[timeMultiplier]] [[setTimeMultiplier]] [[missionStart]] [[diag_tickTime]] [[diag_deltaTime]] [[systemTime]] [[systemTimeUTC]] [[BIS_fnc_timeToString]]
</dl>
}}


<h3 style="display:none">Bottom Section</h3>
<dl class="command_description">


<dt><dt>
<dd class="notedate">Posted on 2006-08-04 - 12:02</dd>
<dt class="note">[[User:Hardrock|hardrock]]</dt>
<dd class="note">''Notes from before the conversion:''<br>
Not to be confused with the '''SQS''' variable ''_time''. Within an '''SQS''' script, the reserved local variable ''_time'' returns the time elapsed since the script started running. Note that the value of _time is not saved when the mission is saved and so will be reset to zero when a mission is restarted from a saved position. The value of [[time]] is saved correctly and will resume from where it was.
::''_time'' has only special meaning in SQS scripts, in SQF script it is just another variable. --[[User:Killzone_Kid|Killzone_Kid]]
<dt><dt>
<dd class="notedate">Posted on 2007-01-05 - 12:24</dd>
<dt class="note">[[User:Giova|Giova]]</dt>
<dd class="note">''Notes from before the conversion:''<br>
time works properly in sqf called with execVM command. In an other hand, _time does not works in sqf called with execVM command.(Arma v1.02.5103GER)
<dt><dt>
<dd class="notedate">Posted on 2010-10-02 - 12:02</dd>
<dt class="note">[[User:TeaCup|teaCup]]</dt>
<dd class="note">
On overloaded servers (below ~10 server FPS), time readings are unreliable. Seconds actually take longer. While the clients keep a steady tempo, server time lags behind, resulting in considerable offset between client and server time (easily 30 minutes for a 2 hour game). Client time is synchronised to server time during JIP, but other than that it runs independently.
<dt><dt>
<dd class="notedate">Posted on 30 Oct 2013</dd>
<dt class="note">[[User:Dr_Eyeball|Dr Eyeball]]</dt>
<dd class="note">'''Arma 3 JIP bug:'''<br>
As of Arma 3 v1.02, for JIP clients 'time' value will start off counting from 0, not the real 'time' value. After about 2.5sec (on average), it will then jump to a high value and synchronise with the real 'time' value, which could be 900, for example.


Therefore, do not use 'time' for any start of mission init timeouts; it is unreliable. (It's odd that it doesn't synchronise at the same time as public variables.)
<dt><dt>
<dd class="notedate">Posted on 2016-09-01 - 18:18 (UTC)</dd>
<dt class="note">[[User:Demellion|Demellion]]</dt>
<dd class="note">
'''In MP''': Since per-client time and server time is unconsistant I strongly recommend execution of time-critical tasks from server-side scripts and with [[remoteExec]] or [[remoteExecCall]] ('''Since only A3 1.50''' alternative may be [[publicVariableClient]] with pre-defined handler) as this will eliminate any time calculation lags and make it reliable.
</dd>


[[Category:Scripting Commands|TIME]]
</dl>
[[Category:Scripting Commands OFP 1.96|TIME]]
[[Category:Scripting Commands OFP 1.46|TIME]]
[[Category:Scripting Commands ArmA|TIME]]
[[Category:Command_Group:_Mission_Information|TIME]]
[[Category:Scripting Commands ArmA2|{{uc:{{PAGENAME}}}}]]
[[Category:Scripting Commands VBS2|{{uc:{{PAGENAME}}}}]]

Latest revision as of 00:12, 14 May 2023

Hover & click on the images for description

Description

Description:
Returns time elapsed since mission started (in seconds). The value is different on each client. If you need unified time, use serverTime.
Groups:
TimeMission Information

Syntax

Syntax:
time
Return Value:
Number

Examples

Example 1:
private _future = time + 30; waitUntil { time >= _future }; // continue after 30 seconds
Example 2:
Wait until mission fully started:
waitUntil { time > 0 };

Additional Information

See also:
date dayTime serverTime skipTime accTime dateToNumber timeMultiplier setTimeMultiplier missionStart diag_tickTime diag_deltaTime systemTime systemTimeUTC BIS_fnc_timeToString

Notes

Report bugs on the Feedback Tracker and/or discuss them on the Arma Discord or on the Forums.
Only post proven facts here! Add Note
Posted on 2006-08-04 - 12:02
hardrock
Notes from before the conversion:
Not to be confused with the SQS variable _time. Within an SQS script, the reserved local variable _time returns the time elapsed since the script started running. Note that the value of _time is not saved when the mission is saved and so will be reset to zero when a mission is restarted from a saved position. The value of time is saved correctly and will resume from where it was.
_time has only special meaning in SQS scripts, in SQF script it is just another variable. --Killzone_Kid
Posted on 2007-01-05 - 12:24
Giova
Notes from before the conversion:
time works properly in sqf called with execVM command. In an other hand, _time does not works in sqf called with execVM command.(Arma v1.02.5103GER)
Posted on 2010-10-02 - 12:02
teaCup
On overloaded servers (below ~10 server FPS), time readings are unreliable. Seconds actually take longer. While the clients keep a steady tempo, server time lags behind, resulting in considerable offset between client and server time (easily 30 minutes for a 2 hour game). Client time is synchronised to server time during JIP, but other than that it runs independently.
Posted on 30 Oct 2013
Dr Eyeball
Arma 3 JIP bug:
As of Arma 3 v1.02, for JIP clients 'time' value will start off counting from 0, not the real 'time' value. After about 2.5sec (on average), it will then jump to a high value and synchronise with the real 'time' value, which could be 900, for example. Therefore, do not use 'time' for any start of mission init timeouts; it is unreliable. (It's odd that it doesn't synchronise at the same time as public variables.)
Posted on 2016-09-01 - 18:18 (UTC)
Demellion
In MP: Since per-client time and server time is unconsistant I strongly recommend execution of time-critical tasks from server-side scripts and with remoteExec or remoteExecCall (Since only A3 1.50 alternative may be publicVariableClient with pre-defined handler) as this will eliminate any time calculation lags and make it reliable.