Discussion OpenOrbiter project fork

[Xyon]

Hello Orbinauts and developers alike.

In recent weeks, I sent Martin a DM here asking several questions about the use of the "Orbiter" name for open-source continuations of the project, but haven't had an answer back (which I did expect).

As a result, to facilitate future releases of the codebase, I've pulled together a new Github organisation to house a fork of the codebase now officially named OpenOrbiter - you can find the repo here.

Shortly I will be establishing a site hosted on the same server as the forum, which will give some project info and access to the project itself, and some more infrastructure around housing OpenOrbiter builds, to make obtaining a copy of the project slightly more straightforward.

Questions, comments, suggestions, are all welcome as to how this should move forward beyond the vague outline I have laid out above.

 

[Thymo]

I very much do not see the point in doing this. There already is an Orbiter organisation on GitHub to which members on this forum have administrative privileges.
Orbiter has been made open source to allow others to continue it's development. Your concern is the use of the name "Orbiter" for the continued development of the same product. This would only be a valid issue if the name "Orbiter Spaceflight Simulator" is trademarked, which it is not.

My fear in forking Orbiter is that you will lose reputation that has been built under the original name for so many years and that it will cause a divide in both users and developers, some of them continuing with Orbiter, others with your fork of OpenOrbiter. I urge the persons that have been granted maintainer privileges to Orbiter to exercise them and to continue the development of Orbiter under its current name.

 

[Xyon]

I very much do not see the point in doing this. There already is an Orbiter organisation on GitHub to which members on this forum have administrative privileges.
Orbiter has been made open source to allow others to continue it's development. Your concern is the use of the name "Orbiter" for the continued development of the same product. This would only be a valid issue if the name "Orbiter Spaceflight Simulator" is trademarked, which it is not.

My fear in forking Orbiter is that you will lose reputation that has been built under the original name for so many years and that it will cause a divide in both users and developers, some of them continuing with Orbiter, others with your fork of OpenOrbiter. I urge the persons that have been granted maintainer privileges to Orbiter to exercise them and to continue the development of Orbiter under its current name.

I appreciate your thoughts, and your concerns, and I should note that I am also one of the maintainers of the orbitersim organisation itself.

The thing is, there's already a disconnect here, the terms "Orbiter" and "OpenOrbiter" have been used more or less interchangeably since the project went open-source, which leads to a bit of confusion about what pertains to what.

In addition, while we have maintainer privileges to the repository, only martin has Owner rights to the orbitersim organisation. We can't add any new maintainers, nor any new projects, any scaffolding around the repository as it currently is within that organisation. Moving the "official" FOSS effort to a new organisation allows us to add additional Owners who can perform those duties and gives us the flexibility to add supporting structures around the project like I outlined in my first post.

Remember too that, while the projects are in different repositories, contributions to the original repository can be brought into this one using GitHub's Pull Request feature. We needn't create any sort of divide. Instead the forked project just has a little more capacity to move forward as its own entity, not confined by the issues I noted here.

 

[n72.75]

Ideally martin would have given owner privlages to someone else, so I think this is a workable compromise.

I like the idea of a webpage. I do think we should continue to refer to the project as Orbiter as much as possible.

It's probably worth revisiting the roadmap thread and organizing the ideas there into a coherent list.

What do we need to do so that we can package and release a 32 bit Orbiter2022? It would be so cool if our NASSP install instructions didn't involve svn or symbolic links for textures.

 

[n72.75]

I think there needs to be more discussion about what's going on for development. I see a lot of effort going into several projects.

There is absolutely nothing wrong with forking the repo and going off in your own direction, but that's not what I think anyone intends to do. I think all of the people currently working on Orbiter intend for it to merge together into one release.

The only other open source project that I have worked on is NASSP. We are a small team of developers, and we obviously work on it when we have free time and life permits, but, when we're working on adding features or improving some aspect, we discuss our progress on our IRC channel almost every day. Orbiter is potentially a much larger project and I think it needs some more immediate discussion. Forum posts are great, but I forsee trouble down the road, where people try to merge features that they've been working on for a while, without discussing potential conflicts.

We have a discord, and a channel for development. We should talk more there.

Also, revisiting the roadmap thread. We need to answer what our next release is going to look like and consist of, and what items we need to check off to make that happen. I don't think it will be too hard to make this happen, given how much work the community has already been able to put into it.

 

[Abloheet]

At the moment, I think it's best to release Martin's last upload to GitHub as is with XRSound integrated. The main thing pending is a well rounded documentation. This can be the first step for releasing Orbiter 2022, and it is going to be the last to support MOGE.

Before releasing Orbiter 2022, let Jarmonik chime in whether he has the time to support updated d3d9 client for this last build of Orbiter 2022.

Also, whether it is possible to integrate frameworks like VesselBuilder and Orbiter Crews/OMMU/UCSO into Orbiter 2022 release, or better to let them remain as add-ons for this release. They can be integrated in a future release of OpenOrbiter, which can then drop MOGE and have dx9 integrated; we can then also implement proper collisions into OpenOrbiter. The support for surface bases will be improved too. Currently Orbiter graphics clients like d3d9 client don't have support for animated base elements like trains, monorails, etc implemented. A call needs to be taken whether they be dropped or reworked and expanded in future.

Some minor planets like Ceres and Pluto should also be part of Core Orbiter distribution with the updated surface features labelling, since Vesta is already included, and the add-ons for Ceres and Pluto already exist on Orbiter Hangar.

For now however, it is important to release Orbiter 2022 with whatever changes Martin made after R90 with XRSound integration and updated documentation.

 

[4throck]

Having a complete solar system would be very nice, especially because Orbiter is mostly about space navigation.

I think the integration process into the core for these non-code assets like planets (texture, meshes, markers, etc) should be by releasing first to OH.
Ideally, we should have a "core contribution" category for these addons, and a way to give "co-autorship" to the Orbiter dev team. (If not it can be explicitly mentioned in the description text...)

This would allow testing and quick updates as usual, without overloading Orbiter devs with extra tasks. Authorship and authorization issues are also solved.
Once integrated these addons should be removed from OH (the dev team can do it because they were added as co-authors on uploading).

 

[Urwumpe]

I think we need to differ there between Orbiter as engine and Orbiter the distribution. Things like solar systems, vehicles, tutorial scenarios, etc could be handled by the distribution aspect of it, instead of making it mandatory part of Orbiters engine and all its forks.

 

[IronRain]

I'd like to propose the following then:
Orbiter, the main one (https://github.com/orbitersim/orbiter), will receive patches and new core features.
And think I I've got merge rights, so maybe I'll need to take a look at the PRs.

Xyon and I started with something called OpenOrbiter a while back, we could use that as a distribution version.
Every 6 months we build a new release, including the latest version of whatever we include in the distro.

 

[n72.75]

I think that makes sense.

 

[OvalDreamX]

Xyon and I started with something called OpenOrbiter a while back, we could use that as a distribution version.
Every 6 months we build a new release, including the latest version of whatever we include in the distro.

That would be perfect. Orbiter and OpenOrbiter are names easily distiguished one from the other and OpenOrbiter is pretty clear in that it means the version derivated from open sourcing it

 

[IronRain]

As always, I've underestimated my available free time again.
I'll try to set it up this week!

 

[IronRain]

Working on it now, setting up Actions to get everything compiled.
At the same time I'm working out a roadmap for everyone to follow along.

 

[Sword7]

I cloned OpenOrbiter from GitHub and checked out with d3d9client branch.

Yay! I successfully build all on OpenOrbiter project (64-bit mode) with Visual Studio 2022.

I executed Orbiter and selected one. It told me that no graphics client.

How do I add D3D9 client to Orbiter configuration file?

I noticed that PDF files are not compiled. I enabled it in cmake setting but it stopped as build failure after successfully built each PDF file. I installed D3D9 SDK, Doxygen, Miktek and LibreOffice. CMake recongized and found them.

 

[supersonic71]

@Sword7
Check the videos tab in the launchpad, there should be a dropdown for d3d9.
If you are still having issues,
Try installing these two - https://www.microsoft.com/en-us/download/details.aspx?id=8109 and https://www.microsoft.com/en-us/download/details.aspx?id=6812
Btw I did Build -> Build All and then Build -> Install Orbiter
Then Orbiter installation was in <your code directory>/out/install/

 

[Sword7]

Got it now. I installed DX9 legacy drivers and SDK package on Windows 10. I executed "build all" and "install orbiter". I did not see Orbiter.exe but Orbiter_NG.exe. I checked Video tab but Orbiter did not see 3D hardware as detection. I tried to select D3D9 client but It still told me no graphics client and running in server mode.

I installed Orbiter 2016 distro (32-bit mode) and it can see 3D hardware as detection.

My video card is EVGA Nvidia GTX 1080.

Update: I checked Orbiter.log and noticed that it failed to load D3D9 client module with error code 126. I succesfully compiled and installed D3D9 client into Modules/Plugin.

**** Orbiter.log
000000.000: Build Jul 29 2022 [v.602931718]
000000.000: Timer precision: 1e-07 sec
000000.000: Found 0 joystick(s)
000000.000: Module AtlantisConfig.dll .... [Build 220729, API 220729]
000000.000: Module AtmConfig.dll ......... [Build 220729, API 220729]
000000.000: Module DGConfigurator.dll .... [Build 220729, API 220729]
000000.000: ============================ ERROR: ===========================
000000.000: Failed loading module Modules\Plugin\D3D9Client.dll (code 126)
000000.000: [Orbiter::LoadModule | M:\Projects\orbiter.vs\orbiter\Src\Orbiter\Orbiter.cpp | 574]
000000.000: ===============================================================
000000.000: ============================ ERROR: ===========================
000000.000: Failed loading module Modules\Plugin\D3D9Client.dll (code 126)
000000.000: [Orbiter::LoadModule | M:\Projects\orbiter.vs\orbiter\Src\Orbiter\Orbiter.cpp | 574]
000000.000: ===============================================================

Update 2: I figured them out and decided to re-install DX9 SDK with runtime drivers. It successfully loaded and run D3D9 client! Everything worked! I noticed blank surface and now have to install planet database files.

**** Orbiter.log
000000.000: Build Jul 29 2022 [v.602931718]
000000.000: Timer precision: 1e-07 sec
000000.000: Found 0 joystick(s)
000000.000: Module AtlantisConfig.dll .... [Build 220729, API 220729]
000000.000: Module AtmConfig.dll ......... [Build 220729, API 220729]
000000.000: Module DGConfigurator.dll .... [Build 220729, API 220729]
000000.000: ---------------------------------------------------------------
000000.000: BaseDir    : M:\Projects\orbiter.vs\orbiter\out\install\x64-Debug\Orbiter\
000000.000: ConfigDir  : M:\Projects\orbiter.vs\orbiter\out\install\x64-Debug\Orbiter\Config\
000000.000: MeshDir    : M:\Projects\orbiter.vs\orbiter\out\install\x64-Debug\Orbiter\Meshes\
000000.000: TextureDir : M:\Projects\orbiter.vs\orbiter\out\install\x64-Debug\Orbiter\Textures\
000000.000: HightexDir : M:\Projects\orbiter.vs\orbiter\out\install\x64-Debug\Orbiter\Textures2\ [[DIR NOT FOUND!]]
000000.000: ScenarioDir: M:\Projects\orbiter.vs\orbiter\out\install\x64-Debug\Orbiter\Scenarios\
000000.000: ---------------------------------------------------------------
000000.000: D3D9 DLLs  : C:\WINDOWS\SYSTEM32\d3d9.dll [v 10.0.19041.1806]
000000.000: ---------------------------------------------------------------
000000.000: Module D3D9Client.dll ........ [Build 220729, API 220729]
000000.000:
000000.000: **** Creating simulation session
000000.000: D3D9: [DirectX 9 Initialized]
000000.000: D3D9: 3D-Adapter.............. : NVIDIA GeForce GTX 1080
000000.000: D3D9: MaxTextureWidth......... : 16384
000000.000: D3D9: MaxTextureHeight........ : 16384
000000.000: D3D9: MaxTextureRepeat........ : 8192
000000.000: D3D9: VolTexAddressCaps....... : 0x3F
000000.000: D3D9: NumSimultaneousRTs...... : 4
000000.000: D3D9: VertexDeclCaps.......... : 0x30F
000000.000: D3D9: MiscCaps................ : 0x2FCEF2
000000.000: D3D9: Vertex Texture.......... : Yes
000000.000: D3D9: Separate AlphaBlend..... : Yes
000000.000: D3D9: Shadow Mapping.......... : Yes
000000.000: D3D9: D3DFMT_A16B16G16R16F.... : Yes
000000.000: D3D9: D3DFMT_A32B32G32R32F.... : Yes
000000.000: D3D9: D3DFMT_D32F_LOCKABLE.... : Yes
000000.000: D3D9: D3DFMT_A2R10G10B10...... : Yes
000000.000: D3D9: D3DFMT_L8............... : Yes
000000.000: D3D9: D3DDTCAPS_DEC3N......... : No
000000.000: D3D9: D3DDTCAPS_FLOAT16_2..... : Yes
000000.000: D3D9: D3DDTCAPS_FLOAT16_4..... : Yes
000000.000: D3D9: Runs under WINE......... : No
000000.000: D3D9: D3D9Build Date.......... : 220729
000000.000: D3D9: Available Texture Memory : 4081 MB
000000.000: D3D9: [3DDevice Initialized]
000000.000: D3D9: [Loading Constellations]
000000.000: D3D9: [D3D9Client Initialized]

 

[jedidia]

Just a quick question concerning the thread here:

SDK Question - Can someone please post the old Sketchpad2.h file?

Well, what the title says. I was trying to build SSU and it needs it

www.orbiter-forum.com

It does indeed look like Sketchpad2.h is not included in OpenOrbiter. However, some add-ons apparently need it to build. Is there a specific reason the file was left out of the OpenOrbiter build?

 

[Abloheet]

For the forum adminstration, any news or updates about the status of the planned OpenOrbiter distro? Has it been built, with its own website?