> Well, is this really a bug? Should /sim/time/elapsed-sec contain elapsed _simulated_ time?

I don't know! :D It looked like so after this short discussion: http://forum.flightgear.org/viewtopic.php?f=14&t=21020&start=30#p192454

The comments in the code suggest a different concept however:

class FGGlobals {
    // Number of milliseconds elapsed since the start of the program.
    double sim_time_sec;

But the name given to the variable again suggests "simulated time in seconds", not milliseconds since start.

In practice, the variable doesn't grow when the simulator is paused, so the comment doesn't really hold, and it doesn't honor either speed-up nor warp settings, so it doesn't represent simulated time inside nor outside the aircraft. ??? :D

If it is not a bug, I guess we can agree that the context surrounding this property is, at least, confusing.

Personally, I tend to agree with James' explanation. It makes sense to me, assuming the ability to warp environment time independently of local aircraft time is a feature. How each system should interact with this concept, even how both timelines should interact to each other, I guess that requires careful thinking.


On Wed, Oct 30, 2013 at 10:58 AM, Renk Thorsten <thorsten.i.renk@jyu.fi> wrote:
> Property sim/time/elapsed-sec should contain elapsed simulated
> time in seconds. However, that property does not honor the speed-up
> settings and grows always in real time proportions.

Well, is this really a bug? Should /sim/time/elapsed-sec contain elapsed _simulated_ time?

Note that any time speedup is unphysical and not realistic, so it's not obvious a priori what really should be done here.

There's a lot of things we never speed up because we probably can't  easily or because it wouldn't be desirable - the visible environment in terms of water waves, trees moving in the wind, raindrops falling or (currently not active) clouds forming  is done in real-time no matter what time warp or speed up is set. We would be simply incapable of simulating the dynamics of convective cloud formation much faster than in real time.

So keeping track of the elapsed real time makes sense for a few things.

I can really only think of two reasons to have time speedup:

a) I want to fine-tune the time of the day, in which case I _only_ want to change sun position and lighting

b) I want to shorten my remaining 3 hour flight to 20 minutes because I'm going to have dinner soon and am on AP anyway. So that gives you a plane rendered as blazing away at hypersonic speeds across the terrain. Do we really want to speed up wave motion, raindrop velocity, tree movement,.. accordingly?

> 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,

Depends completely on what you have in mind - if you want to keep your simulated arrival time (i.e. you're scheduled to arrive at sunset), then yes. If you want to jump effectively ahead of physics, then no.

But note that with two independent switches, you can always get the desired effect - you can first speed up your flight, then speed up the sun position time to get that back into sync. I find two independent controls much more intuitive than some link that makes a particular assumption of how an unphysical situation *should* be simulated.

* Thorsten
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
Flightgear-devel mailing list