warp speed limit on atmospheric flying?

[Riojax]

Some time ago a bug report was opened due that atmospheric flying at high warp speed (time acceleration) can crash the orbiter process.

This bug was fixed (on d3d9client branch) but some simulations errors are still present at more than x10 warp speed due very intensive real time calcs.

We are thinking about to limit the warp speed only on atmospheric flying using the dynamic pressure data, the idea is only allow x10 speed on the hardest calc part (for example, in the Earth at less 100km) but allowing unlimited time pass at ground. This method only checks when the user selects a new warp speed, by that it is not very "intrusive" and the performance impact is near none.

What do you think?

 

[n72.75]

Some time ago a bug report was opened due that atmospheric flying at high warp speed (time acceleration) can crash the orbiter process.

This bug was fixed (on d3d9client branch) but some simulations errors are still present at more than x10 warp speed due very intensive real time calcs.

We are thinking about to limit the warp speed only on atmospheric flying using the dynamic pressure data, the idea is only allow x10 speed on the hardest calc part (for example, in the Earth at less 100km) but allowing unlimited time pass at ground. This method only checks when the user selects a new warp speed, by that it is not very "intrusive" and the performance impact is near none.

What do you think?

Could you give a little background on who "we" are and what you're trying to do. Some finer control over time acceleration with some "safety features" wouldn't be a bad idea, but being a simulator, users should still have control over the simulation.

 

[jedidia]

A reasonable plan, very simple to implement as an independent module. Go right ahead!

 

[N_Molson]

You could even set custom warp speeds suited for atmospheric flight like x2 or x5

 

[Riojax]

Could you give a little background on who "we" are and what you're trying to do. Some finer control over time acceleration with some "safety features" wouldn't be a bad idea, but being a simulator, users should still have control over the simulation.

We: the bug reporter and I. Also as an active contributor this possibility was started to being discussed on github with other members and once that a working PR was sent, the idea was to know what the community as a whole think about this.

P.S. Thank you for your feedback.

 

[Max-Q]

If this goes into the Orbiter core, in my opinion it must be configurable and optional. Personally, I vote for the external module option. Maybe even an external module that ships with orbiter? And what about other planets with atmospheres?

 

[Riojax]

If this goes into the Orbiter core, in my opinion it must be configurable and optional. Personally, I vote for the external module option. Maybe even an external module that ships with orbiter? And what about other planets with atmospheres?

It works without problems on other planets as it uses dynamic pressure data to know when limit the time warping. About your vote, it's in the ballot box

 

[n72.75]

Cool idea. We have something similar for NASSP. Definitely think it should be configurable, and maybe even allow control over what t and r do.

The reason I asked who "we" were is because I thought you might be part of an external organization that was interested in contributing to Orbiter.

 

[jedidia]

We: the bug reporter and I. Also as an active contributor this possibility was started to being discussed on github with other members and once that a working PR was sent, the idea was to know what the community as a whole think about this.

Oh, this goes into the core? Then I'd agree, needs a launchpad option to turn it off somewhere.

 

[Riojax]

Oh, this goes into the core? Then I'd agree, needs a launchpad option to turn it off somewhere.

The first proposal was on core, but clearly now or it will have an option on launchpad or will be an external addon (or module).
Now the decision is if it must to be shipped with orbiter or not.

 

[Face]

Now the decision is if it must to be shipped with orbiter or not.

Is there a reason why it has to be in a distribution? Most module-like addons in Orbiter so far were examples of its extensibility. Is this bringing something new to that table?

As I see it, this one can perfectly live as just another addon. I'd also suggest to make it a startup-module with launchpad options, so the nature of core-extension is preserved.

 

[supersonic71]

Imo it should be in distribution since accuracy is an important marketing point of Orbiter. With an option to turn on/off and adjust parameters.

Maybe a related bug :
Open delta glider -> Animated control surface scenario and set thrust to zero. Now press "T" 3 times (1000x wrap) in quick succession. It wraps into space.

Is this due to terrain collision being inaccurate at high wrap speeds?

 

[Face]

The warp bugs in Orbiter always depend on machine and scenario setup. Fundamental property of the main loop implementation, I'd say. By means of restricting the simulation acceleration, the (lack of) precision of the system is not improved at all, you just hide it from the user.

Preventing the over-use of time acceleration is perfectly fine if you approach it from the game designer POV (e.g. KSP has such a feature), but I think it is not appropriate for a simulator. Compare it to MSFS: you can easily accelerate too much there, to a point where your plane is uncontrollable and will ruin your flight path. Yet there is no mechanism that somehow calculates a ceiling acceleration based on the vessel's properties.

This brings me to a question: is the proposed system taking all simulation objects into account? It is certainly rather intuitive if all you have is e.g. a Deltaglider flying in atmo, but IMHO it gets a bit tricky if you have multiple objects like e.g. Atlantis start with boosters falling back to atmo and simultaneously running Mars atmo trips with Shuttle-A. The acceleration ceiling would need to be global to hide the effects of precision (for all objects), creating a situation where the example Atlantis coast phase needs to be done in e.g. x10, lest the trajectories of the falling boosters get imprecise due to being in atmo. Until they disappear, of course. Then it would suddenly be allowed to x100 again.