time: Difference between revisions

From Bohemia Interactive Community
Jump to navigation Jump to search
m (Text replacement - "\[\[Category:[ _]?Scripting[ _]Commands[ _]Take[ _]On[ _]Helicopters(\|.*)?\]\]" to "{{GameCategory|tkoh|Scripting Commands}}")
m (Text replacement - "<sqf>([^↵][^<]*↵[^<]*)<\/sqf>" to "<sqf> $1 </sqf>")
 
(53 intermediate revisions by 2 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


|gr1= Time |GROUP1=
|game3= arma1
|gr2= Mission Information|GROUP2=
|version3= 1.00
____________________________________________________________________________________________


| Returns time elapsed since mission started (in seconds). The value is different on each client. If you need unified time, use [[serverTime]]. |DESCRIPTION=
|game4= arma2
____________________________________________________________________________________________
|version4= 1.00


| [[time]] |SYNTAX=
|game5= arma2oa
|version5= 1.50


| [[Number]] |RETURNVALUE=
|game6= tkoh
|version6= 1.00


|x1= <code>[[private]] _future = [[time]] + 30;
|game7= arma3
[[waitUntil]] { [[time]] >= _future };  {{cc|continue after 30 seconds}}</code> |EXAMPLE1=
|version7= 0.50
 
|gr1= Time
|gr2= Mission Information
 
|descr= Returns time elapsed since mission started (in seconds). The value is different on each client. If you need unified time, use [[serverTime]].
 
|s1= [[time]]
 
|r1= [[Number]]
 
|x1= <sqf>
private _future = time + 30;
waitUntil { time >= _future };  // continue after 30 seconds
</sqf>


|x2= Wait until mission fully started:
|x2= Wait until mission fully started:
<code>[[waitUntil]] { [[time]] > 0 };</code> |EXAMPLE2=
<sqf>waitUntil { time > 0 };</sqf>
____________________________________________________________________________________________


| [[date]], [[daytime]], [[serverTime]], [[skipTime]], [[accTime]], [[dateToNumber]], [[timeMultiplier]], [[setTimeMultiplier]], [[missionStart]], [[diag_tickTime]], [[diag_deltaTime]], [[systemTime]], [[systemTimeUTC]], [[BIS_fnc_timeToString]] |SEEALSO=
|seealso= [[date]] [[dayTime]] [[serverTime]] [[skipTime]] [[accTime]] [[dateToNumber]] [[timeMultiplier]] [[setTimeMultiplier]] [[missionStart]] [[diag_tickTime]] [[diag_deltaTime]] [[systemTime]] [[systemTimeUTC]] [[BIS_fnc_timeToString]]
}}
}}


<h3 style="display:none">Notes</h3>
<dl class="command_description">
<dl class="command_description">
<!-- Note Section BEGIN -->


<dd class="notedate">Posted on August 4, 2006 - 12:02
<dt><dt>
<dt class="note">[[User:Hardrock|hardrock]]
<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>
<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.
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]]  
::''_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 January 5, 2007 - 12:24
<dd class="notedate">Posted on 2007-01-05 - 12:24</dd>
<dt class="note">[[User:Giova|Giova]]
<dt class="note">[[User:Giova|Giova]]</dt>
<dd class="note">''Notes from before the conversion:''<br>
<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)
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 October 02, 2010 - 12:02
<dd class="notedate">Posted on 2010-10-02 - 12:02</dd>
<dt class="note">[[User:TeaCup|teaCup]]
<dt class="note">[[User:TeaCup|teaCup]]</dt>
<dd class="note">
<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.
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 class="notedate">Posted on 30 Oct 2013</dd>
<dt class="note">[[User:Dr_Eyeball|Dr Eyeball]]
<dt class="note">[[User:Dr_Eyeball|Dr Eyeball]]</dt>
<dd class="note">'''Arma 3 JIP bug:'''<br>
<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.
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.)
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 September 1, 2016 - 18:18 (UTC)</dd>
<dd class="notedate">Posted on 2016-09-01 - 18:18 (UTC)</dd>
<dt class="note">[[User:Demellion|Demellion]]</dt>
<dt class="note">[[User:Demellion|Demellion]]</dt>
<dd class="note">
<dd class="note">
Line 60: Line 74:
</dd>
</dd>


<!-- Note Section END -->
</dl>
</dl>
<h3 style="display:none">Bottom Section</h3>
[[Category:Scripting Commands|{{uc:{{PAGENAME}}}}]]
[[Category:Scripting Commands OFP 1.46|{{uc:{{PAGENAME}}}}]]
[[Category:Scripting Commands OFP 1.96|{{uc:{{PAGENAME}}}}]]
[[Category:Scripting Commands OFP 1.99|{{uc:{{PAGENAME}}}}]]
{{GameCategory|arma1|Scripting Commands}}
{{GameCategory|arma2|Scripting Commands}}
{{GameCategory|arma3|Scripting Commands}}
{{GameCategory|tkoh|Scripting Commands}}

Latest revision as of 19:42, 3 September 2024

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.