Time
Jump to navigation
Jump to search
The time in FlightGear and the properties affecting it are represented internally as properties in the /sim/time/ property subtree. The time can be manipulated using simulation rate/speed-up, to increase or decrease the speed of the simulation, and time warp/warp delta, to speed up or reverse local and UTC time.
The terminology used in FlightGear is a bit inconsistent even within the GUI. For the one used in this article, see #Terms used in this article.
Key bindings
| Keys | Binding | Remarks | |
|---|---|---|---|
| A | ⇧ Shift+A | Increase / decrease simulation rate | Affects /sim/speed-up
|
| W | ⇧ Shift+W | Increase / decrease the warp offset | Affects /sim/time/warp
|
| T | ⇧ Shift+T | Increase / decrease time warp in steps | Affects /sim/time/warp-delta
|
Simulation rate vs. time warp
Simulation rate and time warp manipulates the speed of the simulation and time in FlightGear. The simulation rate affects how much faster or slower the FDM appears to run and the time warp affects how fast local and UTC time changes. Neither simulation rate or time warp will affect for example the airspeed of the aircraft.
Simulation rate
When the simulation is sped up and slowed down, the integer factor /sim/speed-up will increase and decrease. The aircraft will appear to fly /sim/speed-up times faster over the terrain. When running FlightGear at normal simulation rate /sim/speed-up is one.
This will only affect the speed of the simulation, not the local and UTC time.
FDM rate
|
The FDM runs at 120 Hertz and with a fixed time step. However, we play one small trick to make that happen. We take the time that has elapsed since the last frame, compute how many whole iterations of the FDM will fit in that time slice (at 1/120th of a second per iteration.) Then we invoke the FDM that many times with a time step of 1/120th of a second. Finally we save out the remainder and add that into the next time slice. This can produce a small amount of temporal jitter between the graphics and the fdm if the graphics frame rates are not a diviser of 120. In the best case scenario, you've locked your graphics frame rate to 60 hz so the FDM runs exactly 2 iterations every time it is invoked and there is no temporal jitter at all, ever. One thing to keep in mind is that handing a different size time slice to the FDM every frame (and sometimes that time slice could be 1 second or more?) can lead to instabilities in the math. So our approach is intended to avoid that potential problem. As far as the FDM is concerned, it *is* running asyncronously, at a fixed time step. But, we are playing a little trick on the FDM (it doesn't care) in order to handle the unfortunate possibility of non-fixed and highly variable frame rates on PC hardware running consumer grade operating systems. — Curtis Olson (Oct 24th, 2007). Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes.
(powered by Instant-Cquotes) |
|
|
|
the autopilot in FG should be running at a fixed framrate (/sim/model-h) these days. That is, fixed in simulated time, which is all that should matter. (As an aside our time management is still pretty messy and lots of things that ought to use simulated time seems to be using real time instead - try increasing the simulation rate and see how many virtual things that do not speed up...) — Anders Gidenstam (Oct 7th, 2011). Re: [Flightgear-devel] autopilot frame rate.
(powered by Instant-Cquotes) |
|
Time warp
When time of day is sped up or reversed using time warp, /sim/time/warp-delta seconds are added or subtracted to /sim/time/warp each second. In essence, the former is not a factor and the latter is an offset. When running FlightGear at normal time warp /sim/time/warp-delta is zero, and when running in real time, /sim/time/warp is also zero.
This will only affect the local and UTC time, not the speed of the simulation. The aircraft will fly just as fast over the terrain, but the sun and clock hands will speed up or reverse.
|
|
/sim/speed-up is now included in dt, unless you use ‘real dt’ - which is only for user-interface and other things that should work while paused? (I have a long-standing task to make view direction animation use real-dt so you can look around at normal rate while paused or using sim/speed-up) |
|
|
|
Note the /sim/time/warp value may not be completely accurate, but should be close enough for what it’s used for (time of day), but to cumulative rounding as that is updated each frame. But the actual dt values should be completely accurate. |
|
Warp vs. speedup
|
|
I find two separate concepts exposed in two different properties: sim/time/warp & sim/time/speed-up. The difference is also made in the user interface, where you can set time warping and speed-up independently. Apparently, speed-up affects the aircraft only (physics & instrumentation), and warp affects the environment only (ephemeris, for example). This effectively establishes two independent timelines inside and outside the aircraft, so there is no single value for "elapsed simulated time", i.e. it depends whether we are talking in or out the plane! — Anton Gomez Alvedro (Oct 30th, 2013). [Flightgear-devel] Time warping.
(powered by Instant-Cquotes) |
|
|
|
speed-up is primarily related to the rate the FDM sees; instruments and autopilot also see the increase since I moved them to run in lock-step with the FDM (to avoid AP instability when using speed-ups which otherwise break the PID parameters). Speed-up is used to speed-up or slow-down how fast the simulation engine is running the local aircraft, in effect, but anything written in Nasal would need to handle it explicitly. We probably *could* factor sim/speed-up into simDt, but this would need to be done with great care since there's probably code using it which does not expect to see a speed-up. None of the above cares about 'wall clock times' or 'dates', only about dt intervals. - warp is about how fast we're updating our simulate 'time+date of the world'. Hence it affects things that refer to time of day such as ephemeris. The goal, I guess, was interactive adjustment of the calendar time to fly in the evening/morning, and indeed that's what the dialog suggests. Warp is really a warp-rate and a warp-offset - the offset is exactly the delta from system clock time to simulated world time, and we adjust it by the warp-rate each frame/update. |
|
Framerate throttling
|
|
There is also a frame rate throttling option, but it's pretty buried /sim/frame-rate-throttle-h Also consider setting your "sync to vblank" option in your video hardware. That can help limit FlightGear to run at your display's refresh rate. — Curtis Olson (Oct 7th, 2011). Re: [Flightgear-devel] autopilot frame rate.
(powered by Instant-Cquotes) |
|
|
|
If you sync to the vblank signal in FlightGear (and have enough cpu/graphics hp) you can run at a very solid 60h (or whatever rate your display refreshes at.) If you don't quite have that amount of hp consistently for all situations, there is a throttle-hz property you can set to force a slower update rate (maybe 30 or 20 fps ... ideally you want an even divider into your display update rate.) If consistent frame rates are your goal, there are ways to achieve that. However, because of the variability of systems and personal preferences, we don't turn a lot of this on by default. — Curtis Olson (Aug 5th, 2009). Re: [Flightgear-devel] Multithreading support.
(powered by Instant-Cquotes) |
|
News
|
|
First the good news : I have managed to generalise the existing ‘speed up’ function (accessed via a/A keys) to work for many more parts of the simulator than before. (This is the feature which allows time to run faster or slower than normal) This should make flying with speed up on autopilot more reliable, and solves my specific use-case of the testing the AI traffic code easier, since I can speed up how fast the AI aircraft move and update. This also allowed various special cases in the instruments and Nasal to be removed. For those who care about details, the ‘dt’ value passed to subsystems is now scaled by the speed-up factor. This is consistent with the existing behaviour when paused (dt = 0, no sim time is passing). If you are working code which needs the ‘real’ dt, typically because you want to animate something while the sim is paused, the ‘real dt’ is available as it always way. However, any such code in this category would already have been incorrect when froen / paused, so I’m not too worried about such cases. Now the question: as well as sim/speed-up, we have the /sim/time/warp property which defines the offset in seconds from system time to simulator time. This is how we implement the various time of day options, and with Richard’s change, adjusting the date as well. — James Turner (Jan 6th, 2016). [Flightgear-devel] Speed-up vs time-warp.
(powered by Instant-Cquotes) |
|
Precision
As of October 2015 there is only one floating point property, /sim/time/elapsed-sec, which tells how long FlightGear has been running. This property is not affected by simulation rate or time warp. Most of the other properties are integers, thus only able to show full seconds.
Getting sub-second local and UTC time
| Note Yet to be tested |
Sometimes you could want sub-second precision time that is affected by time warp. This could for example be if you want a cockpit clock to have a sweeping second hand or if you are logging test data in smaller intervals than one second while wanting those times to correlate to other data.
As clock hands often only use elapsed seconds to animate the hands, the following example will produce two such properties.
One way to get sub-second precision UTC and local time could be by declaring two floating point properties and a property rule in the aircraft-set.xml file for example like below. Using property rules will update the values at frame rate, while using autopilot functions would update them at FDM rate.
<?xml version="1.0" encoding="UTF-8"?>
<PropertyList>
<!-- ... -->
<sim>
<!-- ... -->
<time>
<!-- type="double" will make the properties non-integer. The initial zero values will change when FlightGear is running. -->
<utc-sec type="double">0</local-sec>
<local-sec type="double">0</local-sec>
<time>
<!-- ... -->
<systems>
<!-- ... -->
<property-rule n="100"> <!-- "n" needs to be unique and >= 100 to avoid overwriting other predefined global rules (in particular the environment ones) -->
<name>Sub-second precision UTC and local time</name>
<path>Systems/precision-time.xml</path>
</property-rule>
<!-- ... -->
</systems>
</sim>
<!-- ... -->
<PropertyList>
Add property rules/autopilot filters adding /sim/time/elapsed-sec, /sim/time/warp and /sim/time/offset-local like below:
<?xml version="1.0" encoding="UTF-8"?>
<PropertyList>
<filter>
<name type="string">Sub-second precision UTC time</name>
<type>gain</type>
<gain>1</gain>
<input>
<expression>
<sum>
<property>/sim/time/elapsed-sec</property> <!-- The only non-integer time -->
<property>/sim/time/warp</property> <!-- The offset between local and clock time -->
</sum>
</expression>
</input>
<output>/sim/time/utc-sec</output>
</filter>
<filter>
<name type="string">Sub-second precision local time</name>
<type>gain</type>
<gain>1</gain>
<input>
<expression>
<sum>
<property>/sim/time/utc-sec</property> <!-- Using output from the above filter -->
<property>/sim/time/local-offset</property> <!-- The offset between UTC and local time -->
</sum>
</expression>
</input>
<output>/sim/time/local-sec</output>
</filter>
<PropertyList>
Terms used in this article
The terms used in the source code, keyboard binding descriptions and Time Settings dialog labels are a bit inconsistent. Therefore, in this article these terms (mostly from the Time Settings dialog) will be used:
- clock time
- The local system time as represented by the
/sim/time/real/property subtree. - local time
- The in-sim local time as represented by
/sim/time/gmt+ the offset represented by/sim/time/local-offset. - real time
- When running FlightGear with zero warp, so that local time is equal to clock time, and zero time warp so that local time is at the same speed as clock time.
- simulation rate
- Simulation rate speed-up factor as represented by
/sim/speed-up. This is not related to the FDM rate, the speed at which the flight dynamics model is run. - time warp
- Local and UTC time change rate as represented by
/sim/time/warp-delta. - UTC time
- The in-sim UTC time as represented by
/sim/time/gmtand the/sim/time/utcproperty subtree. In essence the time shown on many cockpit clocks. - warp
- The offset between local time and clock time as represented by
/sim/time/warp.
Nasal scripting
maketimer()settimer()- FDM coupled
Ongoing Developments
Date selector
| Note See also MR #42 (fgdata) |
|
|
sad that it is pretty difficult to set another date while in-simulator (via property menu), so I took the time selector and changed it a bit to have a date selector. |
|
|
|
What do you all think about adding a date control to the Time Settings dialog in the Environment menu (and then maybe rename it to "Time and Date Settings")? Currently the only way to set the date while in sim is via the property editor using "/sim/time/gmt". This would as useful as having time controls to play with the amount of daylight since the date influences the position and maximal height of the sun, particularly in very northern or southern places. Personally, I think it would be great to give users the chance to set it in sim without fussing with the debug tools, just like we currently do with time. — Gilberto Agostinho (Jan 3rd, 2016). [Flightgear-devel] Time settings dialog.
(powered by Instant-Cquotes) |
|
|
|
I ran into a problem: the property that needs to be altered to change the year, month and day, as well as time, is "/sim/time/gmt", and its value is a single string. Unfortunately my knowledge of XML as well as of the capabilities of our dialogs isn't very fancy (I just did some simple things for the c172p so far), and I really don't know how could I create several buttons to change the date parameters individually and then have them concatenated into a single string in the format required by the mentioned property... If we had a single property for each parameter this would be easy peasy, but I am kind of stuck right now. — Gilberto Agostinho (Jan 3rd, 2016). Re: [Flightgear-devel] Time settings dialog.
(powered by Instant-Cquotes) |
|
|
|
I've just added some text input boxes to the dialog for year,month,day to the dialog https://sourceforge.net/u/r-harrison/fgdata/ci/3e667c0b443a06d167d63c9447b6d8442f6aca57/ Merge request created. https://sourceforge.net/p/flightgear/fgdata/merge-requests/39/ (Not quite sure why it says 0 commits on the request - maybe I was a bit quick creating the merge request as possibly it hadn't finished pushing). I can redo the merge request if needed. Also added a checkbox for the warp easing as I'm always having to do this with the property tree. — Richard Harrison (Jan 4th, 2016). Re: [Flightgear-devel] Time settings dialog.
(powered by Instant-Cquotes) |
|
|
|
I've been working on the time dialog. At first it was a quick fix just to add date entry, but it's grown from that. This is what it is currently: http://i.imgur.com/QDuyDLD.png I wasn't sure about sliders on year,month,date at first, but the sliders actually work really effectively - which surprised me. IMHO this approach works better than the dropdown calendar that we've all seen before. The day of month is limited to the maximum number of days for the currently selected month and it takes leap years into account. I prefer to run with easing turned off which is another reason I added a checkbox for easing. I rather suspect I'm not alone in this view. The time slider partially removes the need for the warping. It's also neat adjusting the date with the sliders and seeing the effect changes can be found here: https://sourceforge.net/u/r-harrison/fgdata/ci/435b81bf2464b4c64b6e69ec966406ea45fea797/tree/gui/dialogs/timeofday.xml I've limited the range for the year from 1971 to 2037 (i.e. within completely safe 32bit time_t range). — Richard Harrison (Jan 7th, 2016). Re: [Flightgear-devel] Speed-up vs time-warp.
(powered by Instant-Cquotes) |
|
|
|
[we] are debating his proposed changes to the time dialog: https://sourceforge.net/p/flightgear/fgdata/merge-requests/42/ I’m fine with functionality (mostly) but don’t like his choice of widgets, although as ever he is constrained by what PUI does and doesn’t offer. Can some other people, ideally with UX experience, review and comment? I don’t want to make a unilateral decision since I’m aware I’m usually at one extreme end of the ‘less is more’ Johnny Ive school of interface design :D As ever I would ask people reviewing to apply the UI learnability measure of ‘if I’d never seen this screen before or used FlightGear for more than five minutes, would the choices and controls in this dialog make sense to me? If not, what could be added / changed so they do?' — James Turner (Jan 7th, 2016). [Flightgear-devel] Additional perspectives needed on time dialog.
(powered by Instant-Cquotes) |
|