Linux playground

[Matias Saibene]

WOW! Is this real? Orbiter is actually really meeting Arch!!
I mean, it's just both on this planet , but it's even more than that too me.

For years I have been playing with Orbiter on Windows. In recent years, I became a total Linux geek too (especially Arch).
And I also have already experimented with my existing Orbiter 2016 instance in Wine, which already worked almost seamlessly with really decent performance (it worked using a DirectX to Vulcan port if I am right), with only some really small tweaks.

But clearly what we are talking about here looks like a native Linux build (ELF instead of EXE) from the Beta open source version if I am seeing it correctly. That's really amazing (still many credits go to Martin Schweiger for all his years of work of course!).

However, can I ask a question? The thing is, installing from AUR is great, but this generally installs Orbiter on in a centralized way on your system.
On Windows I am used to the fact that I can maintain multiple copies from Orbiter in separate directories.
What options do I have for this on Linux? Can I maintain multiple instances? (What I now about many Linux binaries is that these are often built and linked to specific library paths that cannot be changed, but maybe I can still have multiple user configurations or something like that?).

I usually have several installations of Orbiter on Linux, simply following @Gondos' instructions in the first post and then I can copy and paste the orbiter_test folder wherever I want. Think of the AUR version of Orbiter as an MSI that installs to \ProgramFiles\.

 

[johnnymanly]

WOW! Is this real? Orbiter is actually really meeting Arch!!
I mean, it's just both on this planet , but it's even more than that too me.

For years I have been playing with Orbiter on Windows. In recent years, I became a total Linux geek too (especially Arch).
And I also have already experimented with my existing Orbiter 2016 instance in Wine, which already worked almost seamlessly with really decent performance (it worked using a DirectX to Vulcan port if I am right), with only some really small tweaks.

But clearly what we are talking about here looks like a native Linux build (ELF instead of EXE) from the Beta open source version if I am seeing it correctly. That's really amazing (Still many credits go to Martin Schweiger for all his years of work of course! And amazing too is the fact that he decided to share his code with the community and make it open source, not everyone would do that).

However, can I ask a question? The thing is, installing from AUR is great, but this generally installs Orbiter on in a centralized way on your system.
On Windows I am used to the fact that I can maintain multiple copies from Orbiter in separate directories.
What options do I have for this on Linux? Can I maintain multiple instances? (What I now about many Linux binaries is that these are often built and linked to specific library paths that cannot be changed, but maybe I can still have multiple user configurations or something like that?).

The makepkg doesn't install anything, pacman does. Just don't run pacman after you build the package. Instead copy the relevant package files to whatever orbiter directory.

 

[Eduard]

I usually have several installations of Orbiter on Linux, simply following @Gondos' instructions in the first post and then I can copy and paste the orbiter_test folder wherever I want. Think of the AUR version of Orbiter as an MSI that installs to \ProgramFiles\.

Ah, thanks. Alright, that's a separate build. Looking at the PKGBUILD would probably also work.
Great time for me to actually start learning a bit more about cmake one day. I have written in C and C++ on moments in the past (mostly not related to Orbiter), but not yet used cmake.
And I have also compiled some existing open source applications by hand in recent years, but just not cmake yet, or they silently had, but I did not need to touch it directly
(I am a software engineer, but mostly in other programming languages, although I have really touched a ton of things)

 

[Eduard]

The makepkg doesn't install anything, pacman does. Just don't run pacman after you build the package. Instead copy the relevant package files to whatever orbiter directory.

Thanks for your good intentions, but I really know Arch very well, my question was really because I just discovered this thread yet and I just started questioning and exploring how things would work for Orbiter specifically.

 

[johnnymanly]

Thanks for your good intentions, but I really know Arch very well, my question was really because I just discovered this thread yet and I just started questioning and exploring how things would work for Orbiter specifically.

Very good.

 

[Col Brubaker]

Thank you MuttonChops2010. But at the moment I have not enough space on my disks. And I don't want to start with Arch another project.

But now I also have a Kali with Orbiter and I am able to make a .iso from it. Well, now I have remove the big planets. But it works.
If somebody is interested, please ask me.

​

 

[johnnymanly]

I reported, a while ago, that I couldn't control a vessel class written in Lua with the numpad. RCS was fine just no control surfaces.
I just compiled a vessel class (a .so) and I have the same problem. No control surfaces with the numpad. Joystick is fine and stock vessels are fine.
Any similar experiences?

 

[Matias Saibene]

I reported, a while ago, that I couldn't control a vessel class written in Lua with the numpad. RCS was fine just no control surfaces.
I just compiled a vessel class (a .so) and I have the same problem. No control surfaces with the numpad. Joystick is fine and stock vessels are fine.
Any similar experiences?

Have you tried ALT+/ to activate the control surfaces? It happened to me with my I.Ae 37.

 

[johnnymanly]

Have you tried ALT+/ to activate the control surfaces? It happened to me with my I.Ae 37.

That was it!
Very clever...

 

[Matias Saibene]

One suggestion: I think we should have UACS on Orbiter Linux instead of UCSO.

 

[Sword7]

One suggestion: There is Ajaja's SPICE for Orbiter module on GitHub so that this Orbiter can have full solar system with Pluto, etc.

I got SPICE toolkit from NAIF website and you can compile SPICE into a shared library as spice.so. Ajaja's module can link spice.so for function calls like spkgeo_c, etc.

 

[Jordan]

It would be better to include the entire build log. But paste it as CODE don't just copy it into your comment.

 

[MuttonChops2010]

Please test our build on an Archlinux distribution (or a derivative of it) with the command:

yay -S orbiter2016-git

 

[Sword7]

I reviewed entire orbiter and OpenGL client source codes. I now learned that Orbiter uses left-handed rule for math because its original Direct3D interface uses left-handed rule as default. Physics uses right-handed rule. I googled some and now learned about left-hand and right-hand coordinate systems.

OpenGL uses right-handed rule as default. If you use right-handed rule, everything will be in reversal image. To convert to right-handed rule, just negate Z values or use glm:: perspectiveLH function call. I saw UpdateProjectionMatrix function call in Camera.cpp uses 1.0 in m22 as left-handed rule. For best results and ways, use glm:: perspectiveLH for projection matrix in graphics client to keep Orbiter source codes in preservation (UpdateProjectionMatrix function call already uses own custom formula for left-handed perspective).

 

[Matias Saibene]

I reviewed entire orbiter and OpenGL client source codes. I now learned that Orbiter uses left-handed rule for math because its original Direct3D interface uses left-handed rule as default. Physics uses right-handed rule. I googled some and now learned about left-hand and right-hand coordinate systems.

OpenGL uses right-handed rule as default. If you use right-handed rule, everything will be in reversal image. To convert to right-handed rule, just negate Z values or use glm:: perspectiveLH function call. I saw UpdateProjectionMatrix function call in Camera.cpp uses 1.0 in m22 as left-handed rule. For best results and ways, use glm:: perspectiveLH for projection matrix in graphics client to keep Orbiter source codes in preservation (UpdateProjectionMatrix function call already uses own custom formula for left-handed perspective).

Excuse my ignorance, but if the Orbiter coordinate system is changed to one that is right-based, would the change have to be updated in all add-ons?

 

[Sword7]

Excuse my ignorance, but if the Orbiter coordinate system is changed to one that is right-based, would the change have to be updated in all add-ons?

Yes, that is right.

 

[n72.75]

Excuse my ignorance, but if the Orbiter coordinate system is changed to one that is right-based, would the change have to be updated in all add-ons?

Please no. I've already dedicated my life to Orbiter's quirky lefthandness.

Worst case, getting a new addon or new code to work is a case of adding a negative sign or swapping y and z.

Getting everything to work in some big conversion effort would be a nightmare. Many things could be broken in ways that are not obvious or easy to test.

 

[Sword7]

Please no. I've already dedicated my life to Orbiter's quirky lefthandness.

Worst case, getting a new addon or new code to work is a case of adding a negative sign or swapping y and z.

Getting everything to work in some big conversion effort would be a nightmare. Many things could be broken in ways that are not obvious or easy to test.

Yeah. That is right. We have to use left-handed perspective to keep everything unchanged.

 

[n72.75]

And I realize my "no way. never ever" attitude may be a bit heavy handed.

However, we have a working OpenGL client under Linux, and @Artlav had a working OpenGL client as far back as 2009 It doesn't seem like handedness is a roadblock to OpenGL.

I'm aware that my Newenglish "if it ait't broke, don't fix it" is a particular bias, but I don't see the benefits to changing:

• The dynamic state propagators
• The aerodynamic force model
• The way moments of inertia add together with docked structure
• Gravity gradient torque
• Nonspherical Gravity
• Animations
• Gravity gradient torque
• All addons that rely on left-handedness

I think think it's pretty small price to pay to just write some transformation (which really is just flipping a sign bit, if the compiler is worth its salt) into the graphics client, so we don't have to change all of that. And I say that partially because if put to the task, I'm not confident I could actually do all that--at least not without getting burned out and giving up--and partially because there are probably far better ways for us to spend our time.

 

[Artlav]

I think think it's pretty small price to pay to just write some transformation (which really is just flipping a sign bit, if the compiler is worth its salt) into the graphics client, so we don't have to change all of that. And I say that partially because if put to the task, I'm not confident I could actually do all that--at least not without getting burned out and giving up--and partially because there are probably far better ways for us to spend our time.

Hm.
If i'm getting the conversation correctly, you are mixing two things.

On the level of graphics client, it's literally setting up the model matrix to be mirrored on Z axis. Nothing else (give or take some normal/tangent shenanigans).

On the level of add-ons, modules, physics, it's "rewrite everything", because stuff assumes that moving a specific way requires specific coordinate transforms. You can't get away from it with a simple conversion at a single point.
Like, there are math and geometry and physics functions written under the assumption of left handedness. They would have to be changed in the code.