Orbiter is now open source

[martins]

It's been a while ...

Dear Orbiter users and developers,

I haven't been around this place in quite some time, and for personal reasons haven't been able to push Orbiter development along for a few years now. In order to keep Orbiter alive and allow others to work on it, I have decided to publish the sources under an open source license:

GitHub - orbitersim/orbiter: Open-source repository of Orbiter Space Flight Simulator

Open-source repository of Orbiter Space Flight Simulator - GitHub - orbitersim/orbiter: Open-source repository of Orbiter Space Flight Simulator

github.com

This is essentially the 2016 Edition with some minor (and at least one major) fixes. I hope this is of use to somebody. The code is somewhat unorganised and sparsely documented, but it should compile and leave you with a working Orbiter installation. Note that the repository doesn't include all the required planetary textures, so you need to install those separately (e.g. by reusing an existing Orbiter 2016 installation - this is explained in the Readme and only requires setting a CMake option before configuring the build).

I am still hoping to work on future enhancements of Orbiter, but I can't make any promises or commitments. One of the most pressing issues is switching the code over to 64-bit, but this requires ditching the DX7 dependency (and ideally replacing it with DX11), but that is a major undertaking which I may or may not be able to do).

Please let me know of any compilation problems or any other issues with the repository, either here or by raising an issue on github. I am also happy to consider merge requests.

Happy coding!

 

[IronRain]

Hey, glad to see you again!
This is quite some news, I'm excited to see what this will bring for the future of Orbiter!
@Xyon really time we finish the new OHM ^^

Thanks for sharing and take care!

 

[Xyon]

Hi Martin! Great to see you around, even in this limited sense! Thank you for opening the source code up. Hopefully this will allow Orbiter to continue to grow and evolve even as personal lives become more complex and hard to manage!

 

[GLS]

* creates github account *... well, in a few days

First, welcome back and thank you! I'm very low on time, but I'm sure I will find some to contribute.

So, is this build on r90 in the svn repository or it branches earlier?

Also, how will future releases be handled?

 

[Urwumpe]

OK, It is not the First of April, right? Really?

 

[Urwumpe]

Hey, its based on CMake Thank you!

 

[Marijn]

Thanks for all your work!

 

[Urwumpe]

@martins Can you maybe create a project at Github for the migration to x64 and DX11? Then it would be easier to group issues related to this and sort the work to be done.

I am all for a very conservative approach to extending Orbiter, but migrating to x64 will likely also break some older add-ons. In this case, the open-source approach might be really good for also making sure the add-on developers are heard and can contribute to the next generation API.

 

[GLS]

Could the Orbiter tickets posted in the previous OF version be inserted in github?

@martins Can you maybe create a project at Github for the migration to x64 and DX11? Then it would be easier to group issues related to this and sort the work to be done.

I am all for a very conservative approach to extending Orbiter, but migrating to x64 will likely also break some older add-ons. In this case, the open-source approach might be really good for also making sure the add-on developers are heard and can contribute to the next generation API.

Wouldn't a branch work? The "tickets" in github seem very flexible, and a branch would prevent a "version split" in the future where people would keep working the 32b version instead of moving to the 64b. A dedicated thread here in OF for general discussion does make sense.

 

[dbeachy1]

Good to see you, Martin! And thanks again for making this amazing simulator!

 

[JMW]

Oh Martins, this is personally very sad news as you have done such excellent work creating and sustaining Orbiter.
Your humility in dealing with us comparative zombies has been outstanding.
Thank you sooooo much !
Best wishes for the future. I hope you resolve any issues that are troubling you, and look forward to seeing you when you can.
???

 

[DaveS]

Could you maybe update the official Orbiter website with news of this?

 

[Face]

I haven't been around this place in quite some time, and for personal reasons haven't been able to push Orbiter development along for a few years now. In order to keep Orbiter alive and allow others to work on it, I have decided to publish the sources under an open source license:

GitHub - orbitersim/orbiter: Open-source repository of Orbiter Space Flight Simulator

Open-source repository of Orbiter Space Flight Simulator - GitHub - orbitersim/orbiter: Open-source repository of Orbiter Space Flight Simulator

github.com

Incredible news! Thank you very much, Martin!

I hope you and your relatives are OK and with good health in these days, and whatever the personal reasons, I wish you all the best now and for the future.

 

[jacquesmomo]

So I will be able to continue to improve the Kourou Space Center (and the French Guyana ) for years to come.

A big thank you for all these years of happiness with Orbiter

 

[n72.75]

Martin! It's so good to see you back here. I hope all is well, given the state of the world.

There is no doubt that Orbiter has had a profound influence on several generations of simulator-users, and developers alike. I fully support the move to open source. I have a great deal of respect, and admiration for your dedication to the vision to Orbiter development over the past 21+ years, and I hope that can continue where life permits.

Thank you.

 

[Urwumpe]

Could the Orbiter tickets posted in the previous OF version be inserted in github?



Wouldn't a branch work? The "tickets" in github seem very flexible, and a branch would prevent a "version split" in the future where people would keep working the 32b version instead of moving to the 64b. A dedicated thread here in OF for general discussion does make sense.

Well, I think there are little reasons today to stay on a x86 architecture and be bound to legacy subsystems of Windows and emulators. But sure, it would be OK to have a x86 branch, if somebody can maintain it.

If we have limited manpower and committment, one branch will be hard enough. And I think, I would rather support martins wishes there.

 

[n72.75]

Well, I think there are little reasons today to stay on a x86 architecture and be bound to legacy subsystems of Windows and emulators. But sure, it would be OK to have a x86 branch, if somebody can maintain it.

If we have limited manpower and committment, one branch will be hard enough. And I think, I would rather support martins wishes there.

Orbiter 2016 and prior can serve as the legacy, x86 Orbiter. 64 bit all the way, for the future, agreed.

 

[GLS]

Well, I think there are little reasons today to stay on a x86 architecture and be bound to legacy subsystems of Windows and emulators. But sure, it would be OK to have a x86 branch, if somebody can maintain it.

If we have limited manpower and committment, one branch will be hard enough. And I think, I would rather support martins wishes there.

I think you got me backwards: I think if the 64b development is made in a new project, as you suggested, it would allow "2 Orbiters" to exist (which is bad IMO). Keeping Orbiter under one roof, and doing the 64b work in a branch, which eventually gets merged to the trunk/master and becomes the standard, is IMO the way to go. There would be 32b support all the way to the merge, and a "last 32b release" could be made as a send off before the merge.

 

[Urwumpe]

I think you got me backwards: I think if the 64b development is made in a new project, as you suggested, it would allow "2 Orbiters" to exist (which is bad IMO). Keeping Orbiter under one roof, and doing the 64b work in a branch, which eventually gets merged to the trunk/master and becomes the standard, is IMO the way to go. There would be 32b support all the way to the merge, and a "last 32b release" could be made as a send off before the merge.

I think you misunderstand the term project. In github, you can group multiple issues, features, userstories, etc to a overarching project, to keep track of it and put some priorization to the work. This is not the same as a branch or a fork, it is just a way to keep track of things - the way to x64 will be complicated and many complex problems will be discovered along the way and require solving. A project for this makes it easier to discover which tasks exist for this goal and where the project as whole stands.

 

[kuddel]

So, is this build on r90 in the svn repository or it branches earlier?

It looks to be almost r90.

For the API (which in a way defines the version ) it is r90, except for the Lua changes & a new method in GraphicsAPI.h:

class OAPIFUNC GraphicsClient: public Module {
    // ...
    bool PlanetTexturePath(const char* planetname, char* path) const;
    // ...

So maybe more like Orbiter 2016-P1