> The other day I opened this bug:> 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?
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.
> 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 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.
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