From: James T. <zak...@ma...> - 2013-10-30 09:10:21
|
On 30 Oct 2013, at 08:20, Anton Gomez Alvedro <gal...@gm...> wrote: > The other day I opened this bug: > http://code.google.com/p/flightgear-bugs/issues/detail?id=1248 > > I have started to look into it to see if I could provide a patch. The cause was actually quite easy to spot around line 200 in Time/TimeManager.cxx > > ... > dt = double(multiLoop)/double(_modelHz); > > realDt = dt; > if (_clockFreeze->getBoolValue() || wait_for_scenery) { > simDt = 0; > } else { > simDt = dt; > } > ... > > The code does not take into account time warping/speedup. Now, when I look in the code at how time warping works, 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! > > Could someone shed some light on the rationale behind this approach? The reasons are for differing user requirements, although the result and user-interface is not ideal: - 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. I think the above is reasonably accurate but I'm sure people will correct me if I have any fine details wrong. Now, combining these two would break some use cases - arguably when you use speed-up we should adjust the warp too, so things stay in sync, but we shouldn't make the reverse link - you need to be able to warp time-of-day without the simulation seeing a massive speedup (16x or 32x or more, those kind of values tend to mess things up) Combing sim/speed-up into sim_dt would be nice (and makes sense given our handling of pause), but to repeat what I said above, it would probably be an intrusive change. If you wanted to work on it, or ensuring the when in speed-up mode, we also adjust the warp-offset correctly, I would be happy to advise and help. Another approach would be UI improvements to make this clearer to the user. Regards, James |