# Roadmap proposal - Orbiter development

#### DarkWanderer

##### Active member
Orbiter Contributor
Donator
Hi,

Given the positive reception proposals outlined in Council thread, I think we may be able to move forward and start outlining possible future directions in Orbiter development. Below text first and foremost describes my personal vision of how the project may progress - but I am hoping that it can serve as the basis for consensus.

I really wanted to be able to create this discussion in GitHub, however it seems we lack the required access to make it happen - so for the moment, forums will have to do. Let's roll

### 1.SDLC and infrastructure​

1. Introduce branching model. git-flow is a modle best suited for UI-style apps where there's no risk of users running outdated binaries. Given long release lifecycle, this model feels best suited - cut a branch, test & stabilize in it, then release from it
2. Create installer which will allow to install latest OpenOrbiter build. This installer should either utilize an existing installation of Orbiter - possibly by overwriting the executable - or have an external source from which to download the whole directory (OF-hosted?)
3. Linux build support
1. decouple build from hardcoded "Visual Studio 2019" generators
2. finalize Linux compilation under Wine
3. replace WinAPI functions with cross-platform C++ equivalents
4. Create a way to have x64 and x86 builds in same Orbiter installation - by having _x64 suffix and/or different directory (e.g.: Orbiter_x64.exe, Modules64 directory, etc.)
5. Move core code from Orbiter.exe into Orbiter.dll - so that addon code may actually refer to a .DLL and not to .EXE (important for tests)
6. Enable C++ exceptions globally
7. Rework logging infrastructure - introduce an external logging library
8. Obtain full administrative access over repo...

### 2.Backward compatible release​

1. Cut off "release/2022/01" branch, focus backward compatibility work there
2. Perform comparison of symbols exported by 2016 Orbiter.exe and (Open)Orbiter.exe using dumpbin.exe /EXPORTS
• may be part of automated build checks
3. Perform testing of current Orbiter addons - whether they work with OpenOrbiter
• XR fleet
• NASSP
• MMU?
4. Deploy OpenOrbiter release on mirrors once/if ready

### 3.Graphics development​

1. Perform revision of d3d9 branch. Merge D3D9 client into main, update building instructions in repo
2. Decommission D3D7 graphics client and all the "ifs" surrounding it. Orbiter core should not depend on DirectX in any way
3. "Server" Orbiter should become the default executable
4. Ideally, D3D9-specific files should live in D3D9-specific directory (see Moddability section)

### 4.Moddability support​

1. Create "virtual filesystem" support, so an addon (vessel, textures) can be installed to a separate directory without polluting the root
2. Support packaged addons (e.g. zip or custom format)

### 5.Testing​

1. Devise and implement a set of test cases
• Basic mechanics (object created with these ephemeris must have these coordinates and velocity)
• Orbit stabilization with time acceleration
• Animations
• Thrusters
• Aerodynamic forces
2. (stretch goal)Devise a way to check test coverage

### 6.Input library​

1. There should be central support for configuration of custom inputs in addons
2. Using input functions directly (e.g. reading keyboard/joystick state using WinAPI) should be discouraged

Last edited:

#### GLS

##### Well-known member
Orbiter Contributor
Introduce branching model. git-flow is a modle best suited for UI-style apps where there's no risk of users running outdated binaries. Given long release lifecycle, this model feels best suited - cut a branch, test & stabilize in it, then release from it
Pardon me not being up-to-date on the latest development models but, shouldn't releases always be done from the main/master/trunk branch? Feature ABC gets developed in a branch and once it is done, it gets merged to the trunk. Same for large bug fix XYZ, etc. Once enough goodies are in the trunk, or the release target is achieved, a release gets made from there.

Cut off "release/2022/01" branch, focus backward compatibility work there
How far back? How much "sacrifice" should new/current features suffer to keep something for Orbiter 2010 working?

Create "virtual filesystem" support, so an addon (vessel, textures) can be installed to a separate directory without polluting the root
This is a good idea! As for meshes and textures, the addons can create their own folder, so collisions there are usually self-inflicted, but they are inevitable in Bases and terrain tile mods so further isolation is a plus, as long as it isn't air-tight and prevents addons from using, e.g., a Shuttle-A cargo pod mesh for something. Perhaps extending the scenario "Context" feature would be a start.

Something that needs to be handled are the several bugs that were reported in the ticket system of the old forum. Maybe this shouldn't be the nº 1 priority, but it should be a high priority.

#### DarkWanderer

##### Active member
Orbiter Contributor
Donator
Pardon me not being up-to-date on the latest development models but, shouldn't releases always be done from the main/master/trunk branch? Feature ABC gets developed in a branch and once it is done, it gets merged to the trunk. Same for large bug fix XYZ, etc. Once enough goodies are in the trunk, or the release target is achieved, a release gets made from there.
This works well in following cases:
• You have comprehensive test coverage which gives you close to 100% confidence nothing is broken
• You can rollback releases really rapidly - e.g. just redeploy from previous commit
• You have low cost of error - e.g. a button of wrong color is not a show-stopper, or you publish a library and clients can just opt to use previous version
For applications which have a lot of features, incomplete test coverage, long time required to test and high price of error (financial sphere is my experience), it is much less disruptive to stabilize the release branch separately, while "mainline" branch continues with ongoing development. It is possible to work with releases from "mainline" - by alternating between "feature integration" and "stabilization" phases, but it increases time between "feature complete" and "feature merged" - which is the opposite of what GitHub PR flow is trying to accomplish

How far back? How much "sacrifice" should new/current features suffer to keep something for Orbiter 2010 working?
I don't think it's possible to support something from Orbiter 2010, as Git repo history starts from something slightly later than 2016. Unfortunately full SVN history was not imported to GitHub

Something that needs to be handled are the several bugs that were reported in the ticket system of the old forum. Maybe this shouldn't be the nº 1 priority, but it should be a high priority.
That would indeed be something which should be looked at - is there a link?

Last edited:

#### Urwumpe

##### Not funny anymore
Donator
I agree, that git-flow would be the model which should satisfy most requirements for add-on developers and users and should be tolerable for those who want to contribute to Orbiter.

The feature branches should be especially helpful to stabilize the Orbiter API during the release process, while Orbiter development can continue. Of course, git-flow requires a lot more discipline by those who want to contribute.

I am not sure if an external logging framework for C++ would satisfy our demands. Essentially, we want to have event streams for each vessel, MFD instance, etc. This can be done by existing libraries, but would always be a terrible work around and possible threat to performance. I think improving the Orbiter API to provide a better logging function would be the way to go.

Linux support is important, but should better be done by its own subproject. The main Orbiter development should only focus on removing impediments.

Substituting the DLLs with something that works in both Linux and Windows would require a project to provide common build tools for both OS. Or an intermediate language like C# as API base, that could also be run using Mono on Linux. But I fear, this latter architecture could be much more effort and could have minor performance impacts.

#### GLS

##### Well-known member
Orbiter Contributor
The feature merge would effectively be done in the branch, with merges from the trunk to the branch (to keep the branch updated with trunk changes), so when time comes to merge the branch to the trunk, it should pretty much be a copy with no conflicts.
In my concept of things, the trunk is always in a "releaseable state", or very very close to it, and branches only merge back when they have their "i"s dotted and their "t"s crossed.
(now it might be obvious why I like the "trunk" nomenclature, instead of "master" or "main" ?)

That would indeed be something which should be looked at - is there a link?
Whatever the ticket system was, it isn't compatible with XenForo, so it is not available anymore, but it was saved by the forum staff somewhere for future work. The future is now.

#### N_Molson

Donator
Linux support is important, but should better be done by its own subproject. The main Orbiter development should only focus on removing impediments.

I agree.

#### GLS

##### Well-known member
Orbiter Contributor
First webpage I open about gitflow https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
Gitflow is a legacy Git workflow that was originally a disruptive and novel strategy for managing Git branches. Gitflow has fallen in popularity in favor of trunk-based workflows, which are now considered best practices for modern continuous software development and DevOps practices. Gitflow also can be challenging to use with CI/CD. This post details Gitflow for historical purposes.

This didn't helping in me buying it...

#### GLS

##### Well-known member
Orbiter Contributor
Linux support is important, but should better be done by its own subproject. The main Orbiter development should only focus on removing impediments.
I think first we need to answer the question: What should the relation Orbiter-Linux be like? Should Orbiter just compile and run in Wine, or should it run natively in Linux? Or both?
Decreasing the dependency on Windows isn't a bad thing IMO, and it would unlock the door to other OSes. It's something that could be done in the background...

#### Urwumpe

##### Not funny anymore
Donator
First webpage I open about gitflow https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
Gitflow is a legacy Git workflow that was originally a disruptive and novel strategy for managing Git branches. Gitflow has fallen in popularity in favor of trunk-based workflows, which are now considered best practices for modern continuous software development and DevOps practices. Gitflow also can be challenging to use with CI/CD. This post details Gitflow for historical purposes.

This didn't helping in me buying it...

Well, git-flow is still best used for VERSION-ORIENTED development. Which really sucks with CD and which sure no company would recommend, that sells CI/CD tools.

If we are not using git-flow for Orbiter, we would still likely recreate around 50% of it functions by manual labor. We need a process in the repository to finalize the API before release while integration of pull-requests and other development goes on, we need a way to produce patch releases in the same style..

So, maybe we should discuss this here: Are we developing towards a fixed version? like limiting the scope of development towards the release of Orbiter 2024? Or are we aiming at releasing a new version of Orbiter at least every year?

#### Urwumpe

##### Not funny anymore
Donator
I think first we need to answer the question: What should the relation Orbiter-Linux be like? Should Orbiter just compile and run in Wine, or should it run natively in Linux? Or both?
Decreasing the dependency on Windows isn't a bad thing IMO, and it would unlock the door to other OSes. It's something that could be done in the background...
Not sure, since a lot of the modding requires DLL modules. if we could replace that by another OS-independent format, that would be great but a lot of extra work. The Lua API is already a small step forward there, but I think Lua isn't really fast enough for replacing the DLLs.

Maybe we can do some experiments there in finding a better way to program Orbiter, like a Labview or Cuneiform like visual interface.

#### GLS

##### Well-known member
Orbiter Contributor
So, maybe we should discuss this here: Are we developing towards a fixed version? like limiting the scope of development towards the release of Orbiter 2024? Or are we aiming at releasing a new version of Orbiter at least every year?
A release every 2 weeks IMO isn't a good idea, and in the other end of the spectrum, a release per decade also isn't a good idea. A target could be release whatever is in the trunk (which would always be releaseable and work fine) every 6 months to 1 year.
Forcing feature XYZ to be in the next release is probably going to delay things, as "real life" happens and people might not have the needed time.

#### DarkWanderer

##### Active member
Orbiter Contributor
Donator
I agree, that git-flow would be the model which should satisfy most requirements for add-on developers and users and should be tolerable for those who want to contribute to Orbiter.

The feature branches should be especially helpful to stabilize the Orbiter API during the release process, while Orbiter development can continue. Of course, git-flow requires a lot more discipline by those who want to contribute.

I am not sure if an external logging framework for C++ would satisfy our demands. Essentially, we want to have event streams for each vessel, MFD instance, etc. This can be done by existing libraries, but would always be a terrible work around and possible threat to performance. I think improving the Orbiter API to provide a better logging function would be the way to go.

Linux support is important, but should better be done by its own subproject. The main Orbiter development should only focus on removing impediments.

Substituting the DLLs with something that works in both Linux and Windows would require a project to provide common build tools for both OS. Or an intermediate language like C# as API base, that could also be run using Mono on Linux. But I fear, this latter architecture could be much more effort and could have minor performance impacts.
Please note that what I'm suggesting isn't "git-flow", but a model which combines "mainline" development - where features are merged into main - with branches cut off for specific releases. This allows both to patch old releases if necessary, and maintain tempo of development in main
The feature merge would effectively be done in the branch, with merges from the trunk to the branch (to keep the branch updated with trunk changes), so when time comes to merge the branch to the trunk, it should pretty much be a copy with no conflicts.
In my concept of things, the trunk is always in a "releaseable state", or very very close to it, and branches only merge back when they have their "i"s dotted and their "t"s crossed.
(now it might be obvious why I like the "trunk" nomenclature, instead of "master" or "main" ?
In the ideal world, every feature and every bugfix is always fully complete and contained. In the real world, in complex codebase (which Orbiter is), a bugfix merge may fix one thing and break two others; two features which worked separately may be completely incompatible once merged
A release every 2 weeks IMO isn't a good idea, and in the other end of the spectrum, a release per decade also isn't a good idea. A target could be release whatever is in the trunk (which would always be releaseable and work fine) every 6 months to 1 year.
Forcing feature XYZ to be in the next release is probably going to delay things, as "real life" happens and people might not have the needed time.
"Forcing feature XYZ to be in next release" is exactly what happens with releasing from main. One set of people is trying to stabilize codebase for release, then someone else merges a feature - and the release is now delayed again.

P.S. I take it apart from git development models "holy war" there's nothing else to add to the roadmap?

#### Urwumpe

##### Not funny anymore
Donator
P.S. I take it apart from git development models "holy war" there's nothing else to add to the roadmap?

If you ask me for features that could be included ANYTIME in development (since it is only me speaking for only me right now), I would suggest the following:

1. Soft docking/hard docking support
2. Multiple star systems with Newtonian phyics between them.
3. A standardized way of low-level inter-vessel and inter-MFD communication, platform independent
4. A virtual file system and module system for add-ons, allowing to manage which parts of an add-on other add-ons may use or reuse.
5. A better way to specify, which vessel, base or planet add-ons should be used in which scenario, to allow more modularity.
6. Integrated sound support, since most sound plugins are too closely linked to their add-ons right now.
7. Better joystick / gamepad support
8. A substitute for windows help - luckily only few add-ons made use of the in-game help feature.
9. A test framework for vessel add-ons, allowing to use special pre- and post-condition extensions to a scenario file to test a vessel in Orbiter automatically, while replaying events from the flight recorder.
.
.
.

1000000000. An multi-level option to enable relativistic physics based on scenario requirements and configuration of Orbiter. (A scenario using vessels without relativity in the world should never use relativity, even if the player enabled it, but instead display an discreet warning). Add-ons supporting relativity should be allowed to mess with its parameters to simulate Warp or jump drives. Hyperspace will be simulated later.

#### N_Molson

Donator
Vessel-to-vessel collisions, I still think this is very important if we want to "dust off" Orbiter a little bit. And the more people have fun with Orbiter, the more potential brainpower for development. ?

#### GLS

##### Well-known member
Orbiter Contributor

#### N_Molson

Donator
And that's just another crazy idea but... weather ?️

#### jedidia

##### shoemaker without legs
Vessel-to-vessel collisions, I still think this is very important if we want to "dust off" Orbiter a little bit.
This might be a bit of a problem with backwards compatibility, though. Vessels would have to provide a collision mesh... but it could just be deactivated if entirely if the vessels does not.

All that said, it would be rather interesting to integrate bullet into the orbiter core to handle local kinematics. There's all kinds of potential that would open up. I know somebody once made a proof of concept add-on that used bullet, so it would seem possible. Also, the zlib license is pretty much the same as MIT, so that would seem fine too.
It'd probably need a new VESSEL5 interface though to make full use of it, but just getting it in the core and adding a more intimate layer to the physics could be a lot of fun.
Would probably require another rework of attachment points, though.

#### N_Molson

Donator
I like that idea! Finally, launches could be scrubbed for upper level winds, flight through precip, etc!

I was thinking more to massive Martian dust storms, Venusian global thunderstorms like a neverending flak barrage and alien Titan ethane-chemistery, but yeah, that too

#### n72.75

Tutorial Publisher
Donator
Please be careful with dependencies. Make sure theres a good reason not to just write our own.

Replies
7
Views
421
Replies
17
Views
3K
Replies
2
Views
229
Replies
1
Views
143
Replies
50
Views
5K