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, #6
_______
#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

 

[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

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).

 

[misha.physics]

Hi, I just wanted to ask if there are any ideas about the gravity instability near the Mars surface (so-called Ephemeris modules issue) in OpenOrbiter? Maybe I can help somehow to solve this if the solution is known. Seems it can be a good update for OpenOrbiter afrer the release of January 14.

 

[n72.75]

Hi, I just wanted to ask if there are any ideas about the gravity instability near the Mars surface (so-called Ephemeris modules issue) in OpenOrbiter? Maybe I can help somehow to solve this if the solution is known. Seems it can be a good update for OpenOrbiter afrer the release of January 14.

I have some ideas on it. I keep meaning to make a placeholder thread. Essentially what we need to do is replace the ephemerides module for one of the moons of Mars (Phobos?), because its 32 but only and we don't have the source. A lot of the groundwork is already done, it's just having the time to work on it.

 

[misha.physics]

@n72.75, thanks.

 

[gattispilot]

Something that is odd is my shuttle and SLS which are MS2015 never leave the pad even though thrusters are applied

 

[misha.physics]

#6
A graphic feature which is related to lighting (as observed). Try: Scenarios->Delta-glider->Docked at ISS. Then undock and rotate the craft using Num. 4/Num. 6 keys. Noticed both in OpenOrbiter x32 and x64.

 

[misha.physics]

#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).

There is a wonderful Low Resolution Earth Map for Map MFD by @asbjos. Maybe we can include his file, for example, coast.vec3 file into Orbiter build on github to replace the default coast.vec which leads to FPS dropping? And naybe we need to manually edit this file a little more, removing or replacing some areas from the Earth map like:



Although, this:

#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).

causes FPS drops even with this simplified coast.vec3. Maybe we should to completely remove some small areas from the map?