Time in FlightGear
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.
|A||⇧ Shift+A||Increase / decrease simulation rate||Affects |
|W||⇧ Shift+W||Increase / decrease the warp offset||Affects |
|T||⇧ Shift+T||Increase / decrease time warp in steps||Affects |
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.
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.
|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)
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.
|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
|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.
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/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
- local time
- The in-sim local time as represented by
/sim/time/gmt+ the offset represented by
- 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
- UTC time
- The in-sim UTC time as represented by
/sim/time/utcproperty subtree. In essence the time shown on many cockpit clocks.
- The offset between local time and clock time as represented by
- FDM coupled
|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.
|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.
|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).
|[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)