The bugs need checking and reporting (OpenOrbiter)

[misha.physics]

Open noticed issues (to be editing) for the current latest build (Orbiter-x64.zip):
#2, #3, #4, #5
_______
#1
Launchpad -> Scenarios -> Checklists -> Quickstart -> F3 -> GL-02 -> Apply -> start increasing traction (main or hover) -> DG is shaking a lot and goes into outer space.

#2
Launchpad -> Scenarios -> Delta-glider -> Brighton Beach -> select 2D main panel -> enter some (above ground level) height value (clicking the left mouse button on "+") on the hold alt autopilot panel -> press A (by default) or "HOLD ALT" button in standart cockpit -> craft doesn't take off -> this is not synchronized with "HOLD" button on the autopilot panel (the last button works correctly and craft is gaining the set height). Related feature-request: it would be nice to assign two keyboard keys (in the "keymap.cfg" file) for changing the autopilot value without mouse clicking on "+"/"-".

 

[n72.75]

#1 sounds like: https://github.com/orbitersim/orbiter/issues/243

I believe it's caused by a few 32 bit DLLs that are feeding NaNs into the grav source part of the state propagation.

These DLLs will need to have modules written for OpenOrbiter. I believe they were originally contributed by @Chode.

Please correct me if I'm wrong...

 

[jedidia]

Would make a lot more sense to use the github issue tracker for the reporting...

 

[misha.physics]

#1 sounds like: https://github.com/orbitersim/orbiter/issues/243

Yes, it seems to be exactly the same issue.

Would make a lot more sense to use the github issue tracker for the reporting...

Of course. However, it might make sense to discuss some cases here at first.

 

[kuddel]

If it is "just" the issue of Ephemeris modules compiled as 32-bit, the question is: Is there any reason for that?
Or is the conversion just not yet completed?

EDIT: The issue here has all the info already We "just" need some more sources

 

[misha.physics]

As I can guess, fixing of this problem requires some programming skills. Or maybe is it "routine" work that just takes time? I'd like to help, but I don't know how. My "programming practice" is limited to some simple physics simulations on C++ with gnuplot (in Linux terminal) (code, cycles, formulas ), although I'd like to start doing something for the OpenOrbiter development (improving). First probably with the basic build. And I'm not familiar with graphic design at all.

 

[Urwumpe]

Maybe we can replace the old historic planet modules with something newer, that makes more use of data files with tables or directly using JPL SPICE kernels. If we could support the same data sources as this python project, we should be fine:

The planet module — pykep documentation

esa.github.io

 

[n72.75]

Maybe we can replace the old historic planet modules with something newer, that makes more use of data files with tables or directly using JPL SPICE kernels. If we could support the same data sources as this python project, we should be fine:

The planet module — pykep documentation

esa.github.io

I believe @Ajaja has done a bunch of work on this already. https://www.orbiter-forum.com/threads/improved-tesseral-gravity-model.40266/post-602936

 

[misha.physics]

#3
Press Ctrl + I. The game frames don't change during the left mouse button is clicked and holding in these position (1st screenshot). It's quite inconvenient during scrolling the window. This "feature" is also present in Orbiter 2016 and Orbiter Beta. It seems that isn't a bug, but it would be nice to repair this.

#4
It's a well known problem in OpenOrbiter, Orbiter 2016 and Orbiter Beta. It's due to "complicated" coastlines in the default Map MFD, which causes FPS drops: 58, 56, 53, 54, 55,... (FPS) (VSync is enabled). It was solved here, but It would be nice to correct this in the basic build (for the default Map MFD).

#5
The same as #4, but for the Map window (Ctrl + M) (2nd screenshot). The same coastlines cause FPS drops (especially during the map dragging with the left mouse button pressed).