warp speed limit on atmospheric flying?

Riojax

New member
Joined
Jan 13, 2022
Messages
4
Reaction score
3
Points
3
Location
CIEES
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

Move slow and try not to break too much.
Orbiter Contributor
Addon Developer
Tutorial Publisher
Donator
Joined
Mar 21, 2008
Messages
2,687
Reaction score
1,337
Points
128
Location
Saco, ME
Website
mwhume.space
Preferred Pronouns
he/him
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.
 

N_Molson

Addon Developer
Addon Developer
Donator
Joined
Mar 5, 2010
Messages
9,271
Reaction score
3,244
Points
203
Location
Toulouse
You could even set custom warp speeds suited for atmospheric flight like x2 or x5
 

Riojax

New member
Joined
Jan 13, 2022
Messages
4
Reaction score
3
Points
3
Location
CIEES
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

99 40
Addon Developer
Joined
Jul 5, 2021
Messages
765
Reaction score
1,181
Points
108
Location
Cislunar Space
Website
www.orbiter-forum.com
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

New member
Joined
Jan 13, 2022
Messages
4
Reaction score
3
Points
3
Location
CIEES
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

Move slow and try not to break too much.
Orbiter Contributor
Addon Developer
Tutorial Publisher
Donator
Joined
Mar 21, 2008
Messages
2,687
Reaction score
1,337
Points
128
Location
Saco, ME
Website
mwhume.space
Preferred Pronouns
he/him
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

shoemaker without legs
Addon Developer
Joined
Mar 19, 2008
Messages
10,842
Reaction score
2,105
Points
203
Location
between the planets
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

New member
Joined
Jan 13, 2022
Messages
4
Reaction score
3
Points
3
Location
CIEES
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.
 
Last edited:

Face

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 18, 2008
Messages
4,390
Reaction score
577
Points
153
Location
Vienna
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

Member
Joined
Sep 20, 2021
Messages
59
Reaction score
86
Points
18
Location
Asia Pac
Website
github.com
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

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 18, 2008
Messages
4,390
Reaction score
577
Points
153
Location
Vienna
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.
 
Top