Orbiter 2024 Launch readiness

[jarmonik]

I played with this and found that although it rotates the font with quite good results, it seems to not be respecting the requested angle (while rotating a char, it starts to slow down, and then jumps like 30º). Also, the function seems to take in degrees and not radians, as advertised in the header comment.
Only tried it in D3D9 (using GDI in MOGE).

That's kinda odd. I checked the code and couldn't find anything obvious. Have you tried Sketchpad::SetWorldTransform2D() and regular TextOut() function.

 

[DaveS]

Here's the question I think many non-developers want to ask but isn't: What is the gate-keeping item that prevents a first official release of OpenOrbiter? Anything special or is it just a collection smaller items?

 

[jarmonik]

Here's the question I think many non-developers want to ask but isn't: What is the gate-keeping item that prevents a first official release of OpenOrbiter? Anything special or is it just a collection smaller items?

Documentation.

 

[Urwumpe]

Documentation.

Any contributions, that can help there?

 

[GLS]

I played with this and found that although it rotates the font with quite good results, it seems to not be respecting the requested angle (while rotating a char, it starts to slow down, and then jumps like 30º).

That's kinda odd. I checked the code and couldn't find anything obvious.

Disregard this: it was my mistake.
I apologize.

Also, the function seems to take in degrees and not radians, as advertised in the header comment.

This one is real. I was going to make a simple PR, but I don't know what to do: update the function description to indicate degrees, or switch the code to radians...?

 

[n72.75]

Radians would be the natural unit of angle to work in. My opinion is that anything in degrees should specify that usage as part of the function name, just to be super obvious.

 

[Urwumpe]

Radians would be the natural unit of angle to work in. My opinion is that anything in degrees should specify that usage as part of the function name, just to be super obvious.

Exactly, also almost all other libraries for math in the world use radians. Using degrees somewhere is odd and should be treated like an extraordinary additional feature (that must be screamed loud on the bazar = name the function accordingly and write it in the comments), not the standard case.

Additionally: what about writing a simply text file into the SDK sources or better, that defines some basic principles how the Orbiter API should be like. This case above is a good principle to develop and keep for the future, regardless what you agree on. I am sure you can also find more principles to apply in development. That way you have transparency and can avoid many Poetterings in the future. If somebody wants to break the principles then, he has the options to change the principles globally or make the deviation from the principles explicit.

 

[Arvil]

Do the math in radians, calculate degrees for display purposes. Likewise, for those who use SAE units ( like we Americans) do the math in metric, convert to SAE for display. Don’t be the Mars Polar Lander.

 

[N_Molson]

Yeah, I mean it isn't a drama if you have to code things in radians, but what really matters is consistency, you don't want to mix both.

 

[misha.physics]

I propose to implement a free camera view for the virtual cockpit (like for the ground view (camera point offset)). For example I can't see an astronaut from the fixed seat views, but I only see him during swithching between them the views:

 

[Urwumpe]

I propose to implement a free camera view for the virtual cockpit (like for the ground view (camera point offset)). For example I can't see an astronaut from the fixed seat views, but I only see him during swithching between them the views:

You know that you can also shift your view position in the VC since VCs got introduced? I think its CTRL + SHIFT + Arrow.

 

[misha.physics]

You know that you can also shift your view position in the VC since VCs got introduced? I think its CTRL + SHIFT + Arrow.

"CTRL + SHIFT + Arrow" doesn't work. Maybe you mean "CTRL + ALT + Arrow". Yes, I know that. Actually that's how I made the screenshot above.

 

[GLS]

I propose to implement a free camera view for the virtual cockpit (like for the ground view (camera point offset)). For example I can't see an astronaut from the fixed seat views, but I only see him during swithching between them the views:

View attachment 40409

a) I've thought about this for SSV, and it seems doable with the current vc API... but now looking at that image, I realized one also has to consider the "landed state", in which you can't rotate and translate as freely as in 0g.
A "convex hull" defining the interior volume of the vc would be needed to limit the translation, plus 12 keys to control the 6-degrees of freedom. The effects of inertia should be simulated, so the user would be sent towards a wall during a vehicle rotation or translation. The user would only have translation control if there are things close by, so if you are flying in the middle of that huge Skylab volume, speed and direction should remain constant.
Also, the vc positions in seats, or locations with restraints like in LEM, should be kept so one is able to "sit" in them, to prevent from being stuck against the aft bulkhead during an engine burn.
b) IMO, this topic shouldn't be in the 2024 release thread, but instead it have its own thread and these posts moved to there.

 

[n72.75]

a) I've thought about this for SSV, and it seems doable with the current vc API... but now looking at that image, I realized one also has to consider the "landed state", in which you can't rotate and translate as freely as in 0g.
A "convex hull" defining the interior volume of the vc would be needed to limit the translation, plus 12 keys to control the 6-degrees of freedom. The effects of inertia should be simulated, so the user would be sent towards a wall during a vehicle rotation or translation. The user would only have translation control if there are things close by, so if you are flying in the middle of that huge Skylab volume, speed and direction should remain constant.
Also, the vc positions in seats, or locations with restraints like in LEM, should be kept so one is able to "sit" in them, to prevent from being stuck against the aft bulkhead during an engine burn.
b) IMO, this topic shouldn't be in the 2024 release thread, but instead it have its own thread and these posts moved to there.

Agreed. Not a 2024 feature. This is already technically possible and NASSP already has a "free cam". This should have its own thread before we get too far off topic though.

 

[Fabri91]

How much does one need to be familiar with C++ or the Orbiter innards to be able to help?

 

[Gondos]

How much does one need to be familiar with C++ or the Orbiter innards to be able to help?

With the RC1 build available, you can help with the testing part. It's really important and there's no need to be a C++ guru for that.
If you want to go down the rabbit hole and provide feedback on PRs and/or working on the code base, you'll need to setup a visual studio environment first (It can be a real chore).
The code is mostly C++98 (i.e. "C with classes") so no need to be a C++ template metaprogramming hero there. We may work on modernizing some aspects of it but it'll have to wait for after the release.
The addon oriented architecture makes it easier to work on isolated bits and get a feeling for the code flow without being overwhelmed from the get go.
Just remember, apart from Martin who designed it, we're all in the same predicament

 

[misha.physics]

help with the testing part

Maybe you could clarify a little what kind of testing is required (needs a higher priority/attention). Today I installed the RC1 version, it feels very nice.

 

[Gondos]

Since this has been cooking for quite some times, I cannot tell you exactly what was added since Orbiter 2016 but it's more than lilely that regressions were introduced. Just go ahead and use the version, and report anything unusual.
Personally, I worked on making Lua support more extensive, if you have questions or find issues in this regard, I'll gladly help you with that.

 

[GLS]

Back in documentation-land, now making corrections and updates!

First up: markers.
The planetary surface markers were updated in 2016 to the quad-tree format, and the previous format was left for backwards compatibility. This is noted correctly in the documentation.
The celestial markers are indicated in the documentation as also having been updated to the quad-tree format... but I don't think that is true... can anyone confirm this story either way?

Also, in the .mkr files (the old format files) the ColourIdx parameter is limited from 0-5 in the code, and this is correctly noted in the docs. But looking deeper in the code (function CelestialSphere::MarkerColorFloat) it seems it can support index 6, which would be the color white. Should this be upgraded to allow the white markers, or left as is?
This is only relevant if the celestial markers are "stuck" with this format, otherwise we should move forward.

More, there lots of .mkr files for the planetary surface markers in the Config folder.... shouldn't this have been converted to the quad-tree format, given it is the "new" (and maybe better) format?

Finally, @jarmonik or anyone with write permissions on the Orbiter repo: could the latex_doc_update branch be updated with the latest main? It is currently 4 months behind.

 

[GLS]

Another thing needed for the documentation is a list of the (major) new features and bug fixes. Any takers?

Also, IMO the scenarios in the "2024 Edition" folder should highlight the new stuff, instead of just being the same as in Orbiter 2016.