# Roadmap proposal - Orbiter development

#### Abloheet

Yes, the priority should be to get a release of 'Orbiter 2022' out of the gate, as martins wanted

After that the future is in our hands

#### Linguofreak

##### Well-known member
As far as Linux goes, a good first step might be getting Orbiter to compile under winelib.

As far as UI/maneuver nodes, etc, for vessels that do not emulate the avionics of a specific real (or fictional) spacecraft, and thus would be dependent on MFDs in classical orbiter, it might be good to have a modernized MFD mechanism, on which a new set of standard navigational MFDs could be built (including perhaps something implementing KSP-style maneuver nodes). The fixed number of side buttons on MFDs is somewhat limiting, having "touchscreens" as the basic spacecraft UI element might give more flexibility. The legacy MFD system would need to be kept for back compatibility. Development time allowing, I suppose you could implement a third UI style: "DSKY", meant for 60s-era spacecraft (or spacecraft fitting that aesthetic), but not implementing their own avionics (as NASSP does). This would mostly be for flavor, rather than usefulness: retrofuturistic addons (for example, Space Odyssey inspired) might favor the use of an even-sparser UI than classic MFDs.

As for Orbiter vs. KSP, the small size of the remaining community, etc, it somewhat strikes me that Orbiter is almost an engine in want of a game. The remaining community seems fairly addon-developer-heavy, and maybe the best thing is to position Orbiter as a general space-sim engine upon which more specific projects could be built, maybe with a couple proofs-of-concept.

#### Arvil

##### Well-known member
imo single biggest feature from user perspective would be something similar to maneuver nodes in KSP
View attachment 28390
I do kinda like the navigation planner in KSP, however, it's sometimes difficult to move the 'camera' to positions to get a good look at certain parts of the planned orbit. Also, it would be helpful to have a popup window at the side showing the four parameters digitally and tweakable (sorta like the scenario editor) for greater precision. It's hard to click and drag one of the handles and get just a couple of kilometers movement in the planned orbit.

#### n72.75

Tutorial Publisher
Donator
KSP may not have the most precise navigation tools, but they are darn intuitive, especially for people who aren't long-time orbiter users.

To be fair, default orbiter nav tools aren't super precise.

Both Orbiter and KSP get away with this by having a generous helping of DV.

Maybe we should have a seperate thread for "proposed improvements to Orbiter's default mfds" would good, because there seems to be a lot of interest in the subject.

This could be another one ventures fairly close to the "features that should be addons" zone.

#### Felix24

##### Active member
Yes, the priority should be to get a release of 'Orbiter 2022' out of the gate, as martins wanted

I agree. Releasing "Orbiter 2022" is the top priority.

Taking a step back, in my opinion the biggest challenge facing Orbiter right now is the lack of users and developers. So after releasing Orbiter 2022, bringing in more users should be the top priority. More users would mean a percentage with skills who would take an interest in developing for Orbiter. More developers would mean more addons and features (which we love), which would in turn bring in more users.

So what kind of features would attract people? Here are my new feature ideas, informed by others' ideas. 3 basic categories: Ease of installation, learning curve, and immersion.
• Release new versions regularly- every 6 to 12 months, so that it is apparent that Orbiter is being actively developed and not abandonware.
• Make installation and first run easier, so that Orbiter works and looks as pretty as the screenshots out of the box without having to install dependencies, enable modules, etc. Things like:
• graphics client pre-installed, enabled by default (hopefully in Orbiter 2022)
• audio client pre-installed, enabled by default (hopefully in Orbiter 2022)
• joystick auto-detection and button assigments
• redesigned launchpad application to look more like a modern game (don't shoot me- really all I mean is fullscreen with nice screenshots, new interface elements, and a prettier scenario browser)
• Make the learning curve easier. Things like:
• Scenario builder/editor built into the launchpad
• Orbit visualizations in the sim
• Autopilot or Flight Director MFD that works with the HUD to tell you where to point to get to the specified orbit or landing zone (if this already exists, then cool!)
• Focus on features that will increase immersion. Things like:
• Vessel to vessel collisions
• Better exhaust and re-entry effects
• In-game goals and interactive scenario scripts- allowing things like
• audio callouts saying "nominal orbital insertion" if your final orbit is within parameters
• scripted Apollo missions with goals and interactive comms from the actual missions
• Upgraded visuals for default spacecraft: ISS, DeltaGlider, Space Shuttle, etc.
• Scenario builder that can automatically add real-world spacecraft in actual orbits based on current TLEs
• new "touchscreen" MFDs
• VR support. I dare to dream!
• More default spacecraft: Soyuz, Dragon, Starliner, Dreamchaser, Apollo, Gemini, Mercury
There are lots more cool ideas for increasing realism, but other people are better at coming up with those ideas than me.

And then there are ideas like making videos discussing Orbiter as a realistic alternative to KSP. I'm pretty sure there's a lot of new people who play KSP but don't know enough about Orbiter, who would be interested in something different.

After that the future is in our hands
Love it!

#### N_Molson

Donator
More default spacecraft: Soyuz, Dragon, Starliner, Dreamchaser, Apollo, Gemini, Mercury

I think there's nothing wrong having vessels as add-ons, what we have to do as addon devs is to make sure we share some "standards" : a decent documentation, some quality-control (from testing to spelling), a SDK sample, scenarios sorted and named in a way that makes some sense...

#### n72.75

Tutorial Publisher
Donator
If you're interested in expanding our user base it's probably worth investigating exactly where people get stuck on the road between learning about Orbiter and becoming a regular users. We also have to remember that this forum is a subset of the user base.

Also, maybe at the beginning of the month we should reëvaluate the roadmap based on the proposals in this thread, and go from there. Releasing something in 2022 seems like an attainable goal.

#### Urwumpe

##### Not funny anymore
Donator
I think there's nothing wrong having vessels as add-ons, what we have to do as addon devs is to make sure we share some "standards" : a decent documentation, some quality-control (from testing to spelling), a SDK sample, scenarios sorted and named in a way that makes some sense...

I think installing add-ons for Orbiter should be as easy as installing an app on a smartphone at least. But that isn't a core topic yet - a lot of the work could be done as external tool first and later be integrated into Orbiters default distribution, as long as the licenses are compatible (ideally the same).

#### N_Molson

Donator
I think installing add-ons for Orbiter should be as easy as installing an app on a smartphone at least. But that isn't a core topic yet - a lot of the work could be done as external tool first and later be integrated into Orbiters default distribution, as long as the licenses are compatible (ideally the same).

The idea of a mod manager makes sense. There's Vortex that works well for games such as Skyrim or Fallout. Ideally we need something like that that can browse OrbitHangar. Then yes, it could be integrated to the launchpad.

#### gamer19

##### Well-known member
• Vessel to vessel collisions
this should probably be a top priority
people love to see stuff blowing out
in space or elsewhere

I'm joking. mostly sorry

#### Majid

##### Active member
Personally I really like how Orbiter core is very thin and the meat and butter of the sim is provided through community add-ons. Speaking of add-ons, there are thousands or even hundreds of thousands of man hours worth of work sitting on OH unused because of version incompatibility. Imo a path to allow that work to be used again and more focus on backwards compatibility in the future would be really good for Orbiter.

I'm imagining a world where I can dump everything from OH into my root orbiter directory, and use some sort of in-game builder to make use of the thousands of meshes on OH to build planetary systems, surface bases, space stations, etc.

It'd be nice if I can peruse OH/other mod sources in game and click to install.

#### Gondos

##### Active member
Personally I really like how Orbiter core is very thin and the meat and butter of the sim is provided through community add-ons. Speaking of add-ons, there are thousands or even hundreds of thousands of man hours worth of work sitting on OH unused because of version incompatibility. Imo a path to allow that work to be used again and more focus on backwards compatibility in the future would be really good for Orbiter.

I'm imagining a world where I can dump everything from OH into my root orbiter directory, and use some sort of in-game builder to make use of the thousands of meshes on OH to build planetary systems, surface bases, space stations, etc.

It'd be nice if I can peruse OH/other mod sources in game and click to install.
Sadly, these thousands of man hours are slowly becoming bitrot ; it'll be even more so after the switch to 64bit. Perhaps going toward pure lua modules (ala factorio) may alleviate the problem, I'm not really sure...

Working on a native linux orbiter build, off the top of my head I'd say that the most painful things that would be nice to have changed are :
• Windows native dialogs : not good for anything but windows builds obviously. I played with Dear ImGui but it creates a big dependency between the orbiter core and the modules. It also requires creating the main window before starting the launchpad.
• GDI leftovers : there's still some code using the Windows API instead of the Sketchpad API
• MSVC types (DWORD, LPVOID...) : just use standard C++ ones
• DirectInput : replace with a multipatform framework (GLFW/SDL/...)
• Inline DX7 GC : need to remove it and all DX7 dependencies from the core
• an OpenGL based graphics client
• DllMain : explicitly call InitModule/ExitModule from the core instead of relying on DllMain mechanism
• Embedded resources (.rc) : use explicit files instead of embedded bitmaps
• Virtual filesystem : keep a clean separation between module resources. May be used to work around slash/backslash and case sensitivity issues too...
• Native sound : OrbiterSound is nice but relying on closed source material is obviously a no-go when porting to another platform. With XRSound part of the repository, it would be nice to embed it in the core (instead of a shared object) along with a nice OAPI interface. Also replacing irrlicht with something else (OpenAL?) would remove the static linking license issue
• Native socket support (for NASSP)
• Native joystick support
Of course I'm not expecting any of this soon (or ever), but if multiplatform builds are on your agenda (just imagine making Orbiter run on a Raspberry Pi, you'll get all the traction you need?), something will need to be done there.

#### Arvil

##### Well-known member
A difficulty with OH is that many of the add-ones do not specify which version of Orbiter it is compatible with. I know there is one or more threads here which lists compatibility. It would be helpful if each add-on page included something like an infobox listing versions and a check mark if it is compatible with each version.

#### Urwumpe

##### Not funny anymore
Donator
A difficulty with OH is that many of the add-ones do not specify which version of Orbiter it is compatible with. I know there is one or more threads here which lists compatibility. It would be helpful if each add-on page included something like an infobox listing versions and a check mark if it is compatible with each version.

I think the best option to fix this is having a community project that produces an catalog of such add-ons and the information how to use and install them.

Including a way to describe alternatives for modern versions, like having an Entry in a YAML-style manifest file like:

YAML:
AlternativesFor:
- Project Mercury
- Mercury Deluxe
- Mercury Ultra

#### Kyle

##### Armchair Astronaut
KSP uses CKAN to manage mods; is something similar what we're proposing here for Orbiter?

#### N_Molson

Donator
Something that doesn't require the end user to compile a software would be nice.

#### AtomicTech

##### New member
Well, as a KSP player who has some interest in Orbiter, I'd be glad to see it adopt some of KSP's design choices so that this game's able to walk the line between great, accurate simulation while still being fun. There's some of that in the RSS/RO community but there's more room for improvement and maybe y'all could take advantage of that gap!

#### GLS

##### Well-known member
Orbiter Contributor
I have nothing against games, but Orbiter Space Flight Simulator isn't a game, and IMO it should not be turned into a game. I have no problem is an addon wants to have keep a high score on something, or have Tetris in running in a MFD to pass time while in transit to another planet, but that should not be the concern of Orbiter itself.

#### Urwumpe

##### Not funny anymore
Donator
I have nothing against games, but Orbiter Space Flight Simulator isn't a game, and IMO it should not be turned into a game. I have no problem is an addon wants to have keep a high score on something, or have Tetris in running in a MFD to pass time while in transit to another planet, but that should not be the concern of Orbiter itself.

I agree there as well. Orbiter should stay general purpose and not simply open world. Sure some ideas can be adopted from games. But why compete with game studios at all?

A stable open source simulation/visualization for any kind of spaceflight project would be something more unique. Even if its a game - or a Soyuz mission.

But who here really is in team simulation?

#### jedidia

##### shoemaker without legs
But who here really is in team simulation?
I think most people are. As far as I can see, most references to KSP are not about mechanics, but about interface, and that's not strongly coupled to the purpose. Maybe it would be fair to say that it would be great for the orbiter core to provide a solid UI layer?

Replies
7
Views
806
Replies
17
Views
3K
Replies
2
Views
322
Replies
1
Views
212
Replies
50
Views
5K