Orbiter is now open source

[Lucy]

I'd be right in assuming that porting to x64 will break all existing x86 DLL addons, right?

 

[Urwumpe]

I'd be right in assuming that porting to x64 will break all existing x86 DLL addons, right?

Yes, very likely yes. There is an option for mixed DLLs, but this seems to open many cans of worms more.

 

[Face]

I'd be right in assuming that porting to x64 will break all existing x86 DLL addons, right?

I'd think so, yes. Usually you can't load x86 DLLs into a x64 process. However, it might be possible to build a process separation bridge, but the performance would be questionable.

 

[Fabri91]

To be honest from a "user's perspective" if there's a time to have this break now would seem like it. It's not like this won't be a watershed of sorts anyway.

Sure, it would be nice to be able to load addons for previous versione, but it's not like previous compiled versions won't be available anymore.

 

[meson800]

Wanted to hop back on and say that this is super exciting! Thanks for all of the hard work Martin throughout the years! I wish I had more dev time nowadays :/

Naive question for those who have looked at this more/have more experience on the plugin loading stuff (I've made cross-platform CMake projects before, but they never involved dynamic library loading at runtime), besides the actual rendering, how much is preventing orbiter_ng from being a native Linux build? Grepping for HINSTANCE reveals a lot of strings, is this at the "insurmountable" level or within the realm of (lots of hours) of possibility?

 

[BenSisko]

Martin, since 2002 Orbiter has provided me countless hours of enjoyment. Thank you for the opportunity to see Earth from orbit, explore our solar system, and to fly the spacecraft of dreams. I wish you and your family the best. Rest assured Orbiter and its community will be here when you are able to return. God bless and be well.

 

[jedidia]

I'd be right in assuming that porting to x64 will break all existing x86 DLL addons, right?

I'd guess that most would only need to be recompiled. So legacy add-ons whose developers are not active anymore and that are not open source would likely be lost for an orbiter x64 build (but many of them are already not working in O2016), but the rest should catch up pretty quickly.

 

[Kyle]

Thank you so much for making Orbiter!

The RSS/RO/RP-1 Team are partially working on making a open-source spaceflight simulator like KSP. Now that Orbiter is open-source, is it possible for them to use Orbiter for their project? Would be nice to have KSP/Orbiter joint work.

I doubt it. The kerbal team seems more interested in just focusing on Kerbal. I messaged the KSP subreddit for permission to post about Orbiter being open source and they told me to basically to kick rocks.

 

[Fabri91]

This may not be out of the question: what Krishnan is referring to, if I understand correctly, is the development of a new simulator by one of the more notorious KSP modding groups, without any direct KSP affiliation.

In principle this group could well use bits of orbiter, even taking the license into account. Whether doing so makes sense is more of a technical question for said group, no?

 

[Lisias]

This may not be out of the question: what Krishnan is referring to, if I understand correctly, is the development of a new simulator by one of the more notorious KSP modding groups, without any direct KSP affiliation.

In principle this group could well use bits of orbiter, even taking the license into account. Whether doing so makes sense is more of a technical question for said group, no?

More or less… KSP is highly moddable (as much or even more then Orbiter sometimes), all the game's assets are provided openly - in a way not too different from Orbiter (the meshes uses a proprietary binary format thought).

And that code is intimately and probably irremediably tied to Unity - for the good and for the evil...

I think very unlikely that they could use something from Orbiter other than the graphic assets. Even a new n-Body gravitation model (to replace the "rails" simplified one) is being made for KSP, the Principia project.

On the other hand, I think the other way around is pretty possible - reusing some things from KSP on Orbiter is plausible now. (and perhaps a MacOS/Linux port?)

 

[yitianetie]

Hi Martin,

Glad to hear news from you. Maybe we could expect a port of Orbiter for Linux, as several users among us (not the majority) use it on their favorite linux distribution.

Happy coding yes !

 

[n122vu]

I wish I'd logged onto the forum yesterday. This was, without question, the best Tuesday ever. Thank you, Dr. Schweiger, for all of your work throughout the years, and for the years to come. I for one understand family and personal issues getting in the way, and for that reason have been mostly absent for the last few years and have not done any development. I hope things improve for you and you can again focus your passion into this great sim. Regardless, she's in good hands here, I firmly believe.

 

[IronRain]

To keep things organized and help collaboration, we've decided to open a dedicated sub-forum and some Discord channels.
New sub-forum + announcement: https://www.orbiter-forum.com/threads/new-era-new-sub-forum.40025/

 

[jedidia]

The RSS/RO/RP-1 Team are partially working on making a open-source spaceflight simulator like KSP. Now that Orbiter is open-source, is it possible for them to use Orbiter for their project? Would be nice to have KSP/Orbiter joint work.

Legally, yes. The MIT license even allows you to use the code in commercial projects, as long as proper attribution is provided.

 

[wedesoft]

Thanks for releasing the code and thanks for developing this awesome simulator. I am trying to make a small space simulator (github.com/wedesoft/sfsim25) and I guess I should have a look at the Orbiter source code.

 

[Max-Q]

How is this going to affect addon compatibility? Martin, will your "ready to use" versions still be available for those who don't want to build their own?

 

[Ripley]

 

[Fabri91]

Inevitably, a question regarding feature requests, possibly remotely connected to the x64 transition - the way Orbiter currently handles controllers is very basic: a single controller can be selected and on this only the throttle axis can be selected from a dropdown menu:


This is a bit of a problem since many modern HOTAS systems, both basic and advanced, actually are two wholly separate controllers, not to mention rudder pedals. These can now be "merged" by using for example the Fly-By-Wire module, which probably wouldn't be able to interface with a 64bit Orbiter.

In short, it would be very convenient to be able to freely re-assign at least the main axes such as pitch, roll, yaw and throttle.

Bonus points for including hover/retro and RCS controls, both the axis functionality (think 6-DOF mouse!) as well as the normal button functionality as per keyboard numpad.

I'd like to create a more detailed description of the request so that it's actually useful, but would a post in "Orbiter Development" be appropriate or maybe an issue on a GitHub page?

 

[jedidia]

How is this going to affect addon compatibility? Martin, will your "ready to use" versions still be available for those who don't want to build their own?

Open source does not mean that a project doesn't have release cycles. Every active open source project distributes release builds just as any other software in ongoing development. Orbiter being open source does not mean that everybody has to build it themselves.
As for add-on compatibility, I'm sure the community will take care to be as little disruptive as possible. The main issue right now is, though, that Orbiter should enter the 64bit era sooner rather than later, because it's easier to do the earlier it's done. This means that add-ons that contain dlls will need to be recompiled. So the next version of Orbiter version will probably break a lot of stuff. Most of it will be very simple to fix by their developers, but the question is if they're still around to do it...

 

[n72.75]

So the next version of Orbiter version will probably break a lot of stuff. Most of it will be very simple to fix by their developers, but the question is if they're still around to do it...

I, personally think there should be a 2016-p1 release based on R90/what's in github now, before we jump to Orbiter x64. NASSP, and the versions of ummu/orbitersound5/DGIV that Dan was working on are all built against the Beta. This would allow releases of these addons, that dont rely on the svn install of orbiter, while x64/D3D11 development progresses. Just my 2 cents.