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
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
OpenOrbiter Roadmap Proposal
1.SDLC and infrastructure
- 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
- 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?)
- Linux build support
- decouple build from hardcoded "Visual Studio 2019" generators
- finalize Linux compilation under Wine
- replace WinAPI functions with cross-platform C++ equivalents
- 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.)
- 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)
- Enable C++ exceptions globally
- Rework logging infrastructure - introduce an external logging library
- Obtain full administrative access over repo...
2.Backward compatible release
- Cut off "release/2022/01" branch, focus backward compatibility work there
- Perform comparison of symbols exported by 2016 Orbiter.exe and (Open)Orbiter.exe using dumpbin.exe /EXPORTS
- may be part of automated build checks
- Perform testing of current Orbiter addons - whether they work with OpenOrbiter
- XR fleet
- NASSP
- MMU?
- Deploy OpenOrbiter release on mirrors once/if ready
3.Graphics development
- Perform revision of d3d9 branch. Merge D3D9 client into
main
, update building instructions in repo - Decommission D3D7 graphics client and all the "ifs" surrounding it. Orbiter core should not depend on DirectX in any way
- "Server" Orbiter should become the default executable
- Ideally, D3D9-specific files should live in D3D9-specific directory (see Moddability section)
4.Moddability support
- Create "virtual filesystem" support, so an addon (vessel, textures) can be installed to a separate directory without polluting the root
- Support packaged addons (e.g. zip or custom format)
5.Testing
- 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
- Integration tests with addons
- (stretch goal)Devise a way to check test coverage
6.Input library
- There should be central support for configuration of custom inputs in addons
- Using input functions directly (e.g. reading keyboard/joystick state using WinAPI) should be discouraged
Last edited: