time: Difference between revisions
Jump to navigation
Jump to search
Lou Montana (talk | contribs) m (Text replacement - "_{10,} " to "") |
Lou Montana (talk | contribs) m (Text replacement - "<sqf>([^↵][^<]*↵[^<]*)<\/sqf>" to "<sqf> $1 </sqf>") |
||
(52 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
{{ | {{RV|type=command | ||
| ofp | | |game1= ofp | ||
|version1= 1.00 | |||
|1.00 | |game2= ofpe | ||
|version2= 1.00 | |||
| | |game3= arma1 | ||
| | |version3= 1.00 | ||
| | |game4= arma2 | ||
|version4= 1.00 | |||
| | |game5= arma2oa | ||
|version5= 1.50 | |||
| | |game6= tkoh | ||
|version6= 1.00 | |||
| | |game7= arma3 | ||
|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: | ||
< | <sqf>waitUntil { time > 0 };</sqf> | ||
| [[date]] | |seealso= [[date]] [[dayTime]] [[serverTime]] [[skipTime]] [[accTime]] [[dateToNumber]] [[timeMultiplier]] [[setTimeMultiplier]] [[missionStart]] [[diag_tickTime]] [[diag_deltaTime]] [[systemTime]] [[systemTimeUTC]] [[BIS_fnc_timeToString]] | ||
}} | }} | ||
<dl class="command_description"> | <dl class="command_description"> | ||
<dd class="notedate">Posted on | <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 | <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 | <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 | <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 56: | Line 74: | ||
</dd> | </dd> | ||
</dl> | </dl> | ||
Latest revision as of 19:42, 3 September 2024
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
Examples
- Example 1:
- Example 2:
- Wait until mission fully started:
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.
Categories:
- Scripting Commands
- Introduced with Operation Flashpoint version 1.00
- Operation Flashpoint: New Scripting Commands
- Operation Flashpoint: Scripting Commands
- Operation Flashpoint: Elite: Scripting Commands
- ArmA: Armed Assault: Scripting Commands
- Arma 2: Scripting Commands
- Arma 2: Operation Arrowhead: Scripting Commands
- Take On Helicopters: Scripting Commands
- Arma 3: Scripting Commands
- Command Group: Time
- Command Group: Mission Information