Roadmap proposal - Orbiter development

[Urwumpe]

A good way to reach out to the community might be to place a link to Google Forms on all orbiter sites.
The form could be very simple, with just a few questions to know how the sim is used (version, how much time spent per week, what type of flights, what add-ons).
It could be a nice introduction for the Council.

Can't we also create a series of polls here? Would be in-house and could allow more interaction with the players than just a cold "marketing poll".

 

[JDat]

Keyboard cowboys! Answer on simple question: how should look Orbiter from user perspective. What user, not programmer, need/want? Instead of making noise about coding.

 

[Urwumpe]

Keyboard cowboys! Answer on simple question: how should look Orbiter from user perspective. What user, not programmer, need/want? Instead of making noise about coding.

Well, tell me, what do you want to see there?

Of course, I am add-on dev, I know what technical issues annoy me, when I want to add the content to Orbiter that I want to see there. For example, I would rather complain in 2016 about not being able to use procedural terrain generators for a fictional planet during run-time and instead would need to generate gigabytes of data for download.

 

[supersonic71]

Well, tell me, what do you want to see there?

imo single biggest feature from user perspective would be something similar to maneuver nodes in KSP

 

[Abloheet]

Yes, I would love to see procedural terrain in orbiter. I think, the possibility to implement procedural or rules based friction coefficients for the surface terrain will also improve the realism by a great amount, for example, runways and taxiways will have a relatively smooth surface to allow proper taxiing. But the rest of the surface should be much more rough to simulate crashing when the craft goes off the runway at high speeds. I remember I used to run the DG at 300m/s over the surface of the Earth in 2010?

Also scripted bases, like face's ascension ultra project, but maybe implemented through Lua instead of a hard coded dll. It will make the orbiter universe come alive and make it hugely interactive. In that way it can persist across scenarios, and not be a vessel to be loaded in the scenario.

Regarding scenarios and surface bases, I know there is already a provision of time periods, where the bases will have a different configuration based on the date in the sim. This can simulate historical events more accurately, and to improve the immersion and realism, the terrain and textures can be also made to change with the date

The stock base building elements provided by orbiter can be expanded and made more useful and detailed and interactive as well, which ties into the concept of scripted bases

Also, improving the collision and damage failure simulation is a high priority.

Eventually we may have "surface bases" in orbit, which is to say, fancy space stations which persist across scenarios

For the rest of orbiter, I will say that orbiter already does a great job of simulating celestial mechanics very accurately, but still there will always be room for improvement. Maybe relativistic effects can be added later.

D3D9 will become the primary graphics engine, unshackled by the limitations of dx7. The current d3d9 client is mostly a wrapper for dx7 calls, with added goodies. A graphics engine built from the ground up for d3d9 will be great! It could be improved later with built-from-scratch vulkan client as well, with volumetric clouds in multiple layers and fog, maybe finally helping orbiter go multi threaded and 64 bit and platform agnostic

 

[Urwumpe]

imo single biggest feature from user perspective would be something similar to maneuver nodes in KSP
View attachment 28390

Yeah, but on the effort side, they would be much harder to do in Orbiter than in KSP (multibody physics and non-spherical gravity vs patched conics and spherical gravity) and would also interfere with the realism of many add-ons, like for example NASSP. Just as reminder, not to block this suggestion. If we would do something exactly like that, it would be a lot of work for the community to realize and support it.

So, as negotiation: Would it be OK for you, if we would design something like that:

1. A flight plan data format supported within Orbiter, that can be exchanged between different modules
2. An API in the VESSEL class to access the associated flight plans for a vessel and modify them, that can be used by MFDs, other vessels and graphical clients
3. A visualization standard within the graphical clients, that allows displaying the current flight plan of the focus vessel (or all vessels?) in planetarium mode
4. A default plugin for Orbiter, that allows to create new flight plans in a bare-boned way.
5. The possibility to use custom, better plugins by the community, including KSP-like or much smarter solutions.

A prototype for 1 & 2 could be done in a framework library outside Orbiter initially. The rest could then follow, once the prototype got accepted to be integrated into Orbiters core.

 

[N_Molson]

I agree something has to be done with surface bases, they are like the poor relation of the family. They should support animations like vessels do, local lights and so on.

 

[Thymo]

Yeah, but on the effort side, they would be much harder to do in Orbiter than in KSP (multibody physics and non-spherical gravity vs patched conics and spherical gravity) and would also interfere with the realism of many add-ons, like for example NASSP. Just as reminder, not to block this suggestion. If we would do something exactly like that, it would be a lot of work for the community to realize and support it.

So, as negotiation: Would it be OK for you, if we would design something like that:

1. A flight plan data format supported within Orbiter, that can be exchanged between different modules
2. An API in the VESSEL class to access the associated flight plans for a vessel and modify them, that can be used by MFDs, other vessels and graphical clients
3. A visualization standard within the graphical clients, that allows displaying the current flight plan of the focus vessel (or all vessels?) in planetarium mode
4. A default plugin for Orbiter, that allows to create new flight plans in a bare-boned way.
5. The possibility to use custom, better plugins by the community, including KSP-like or much smarter solutions.

A prototype for 1 & 2 could be done in a framework library outside Orbiter initially. The rest could then follow, once the prototype got accepted to be integrated into Orbiters core.

Yeah something like that could work. If realism is a concern you can always add it as an option to the launchpad to turn it off.
For NASSP it wouldn't really be an issue as we have our own ecosystem of calculating maneuver data. So it wouldn't work with those maneuver nodes anyway.
If this gets introduced maybe the RTCC could be extended to export these 'flightplans' so you can get a visual representation if you're still learning things, but I'm not sure if people using NASSP will make much use of this feature.

 

[n72.75]

So to be clear @DarkWanderer , what you're proposing with item #1 would essentially constitute the final x86 release, or should this be item #0 or something to that effect.

Lots of good feature proposals in this thread. It's nice to see people excited about development. In addition to discussing these features we should also probably discuss how they fit into the roadmap.

 

[Blake]

First, thanks to those who are pushing Orbiter forward, I have been involved for a long time and would hate to see it die. My thoughts:

I think a final x86 release is important, as that is where all the existing addons run (speaking of 2016 version). This should be as simple to download and run out of the box on modern hardware/versions of Windows as we can make it since this is where community engagement will begin. I'd like to see it contain a 'first steps' guide that will help new users understand what Orbiter is, and how it differs from other similar apps.

We then need a 64 bit branch that should be API compatible with the x86 version. We need to make it easy to port active addons to the 64 bit version to encourage that migration. A point will come when most of the addons (that will) will have migrated, and use of the x86 version will wane. If the initial step to 64bits is cumbersome we will lose addons.

The third area will be where the cool new stuff happens. There will always be tension here between compatibility and new things we want to do, but if we just jump in here and ignore the other areas I believe the larger community will suffer, and Orbiter with it.

As far a big cool things I'd like to see:

• Dependency and asset management (meshes textures) built into the game.
• In game builder support. Construction of bases and simple vessels using available assets. More easily engage peoples creativity.

I think most of this is in line with what has been outlined. I look forward to being involved in the process.

 

[Thymo]

I love all the ideas.
I would suggest that everyone not get ahead of themselves and focus on the x86 release first. We can work from there.
It would be a shame if all these ambitious ideas are made and most of them never seeing the light of day.

 

[Arvil]

There are 2 Facebook pages relating to Orbiter. David Courtney has gone elsewhere for now, the other one is Orbiter Space Flight Simulator page, started in 2012, and hasn’t been active since ‘17. This may be our best advertising for Orbiter for free, if the owner, if still around, could post the latest state of development, and periodic postings of the latest. Those of us who are FB users could follow and share postings, spreading it around. It could include some of the subgroups such as NASSP and so forth. Might pick up some new blood with it. Not sure if it’ll go ‘viral’, but might spread the word.

 

[n72.75]

There are 2 Facebook pages relating to Orbiter. David Courtney has gone elsewhere for now, the other one is Orbiter Space Flight Simulator page, started in 2012, and hasn’t been active since ‘17. This may be our best advertising for Orbiter for free, if the owner, if still around, could post the latest state of development, and periodic postings of the latest. Those of us who are FB users could follow and share postings, spreading it around. It could include some of the subgroups such as NASSP and so forth. Might pick up some new blood with it. Not sure if it’ll go ‘viral’, but might spread the word.

There is actually an NASSP facebook page. @Tschachim gave me admin rights to manage it a few years ago, Thymo as well I think.

There's also a semi-active reddit community, r/orbiter that seems to be made up of a few seasons users/forum members and a bunch of people who have never even heard of OF.

 

[Longjap]

Just my 2 cents which would improve my experiences from a user perspective: Better camera controls and modes. The camera in all the different modes doesn't behave like expect it to, or what is standard in other games/ sims. For launches, a free cam would be great. For following spacecraft, movement which is conform other games would be great. I'm not sure what is off exactly, but maybe other users can fill me in here.

Maybe also scratch the launcher, and make it like starting a game with a start screen. Possibilities to edit scenario files from within the application. Maybe simplify scenario editor by a UI where you can add ships and their locations, define orbits in a simple manner, and without having to fiddle in scenario.txt files.

 

[OvalDreamX]

You are right. I get the impression that the people here are the only one left from the community, though. The question is: how do we reach out to the "community" to ask what they want, if they are not on the forums to discuss it like in this thread?

Hey kinda late, but some of us are here. Just not actively participating on the forum (aka stalking around). But I think the discord could be a good place if you want to reach into the masses, lots of games center around their discord server. Also I completely agree with 4throck, I've tried to model things for Orbiter (dragonfly for ex) but some of the files like generic base structures and such are not available in msh format. I think improving those base's meshes could help a long way into getting the game looking better. Also, allowing bump or normals into the pads and runways without bleeding into the ground would look nice hah.

But I think that what most people are going to ask is easier navigation ("like ksp") and more attention to the vc, like better models and inertial head/camera movement

 

[OvalDreamX]

Just my 2 cents which would improve my experiences from a user perspective: Better camera controls and modes. The camera in all the different modes doesn't behave like expect it to, or what is standard in other games/ sims. For launches, a free cam would be great. For following spacecraft, movement which is conform other games would be great. I'm not sure what is off exactly, but maybe other users can fill me in here.

Maybe also scratch the launcher, and make it like starting a game with a start screen. Possibilities to edit scenario files from within the application. Maybe simplify scenario editor by a UI where you can add ships and their locations, define orbits in a simple manner, and without having to fiddle in scenario.txt files.

I agree, especially in the last item: Fleshing out one of Orbiter's strengths, the sandbox

 

[n72.75]

So what needs to be done for the x86 release?

 

[Urwumpe]

So what needs to be done for the x86 release?

I am torn. I don't want to get too much involved into Orbiter core development, since I see myself on the API side of the universe, but I could maaaaaybe start by onboarding, getting an Orbiter workspace on my computer and checking if the COMPILE instructions work.

Does something already check the test coverage? I see from the CMakeLists that we utilize Tests.

And does the CMake setup of Orbiter also produce a the necessary data to include Orbiters SDK into add-ons using CMake? I could test this, would really simplify my search script here.

Also I see we have three pull requests waiting, but the maintainers are already at it.

 

[GLS]

So what needs to be done for the x86 release?

IMO, the next release should be just what was done since Orbiter 2016 (a.k.a. Orbiter BETA), plus any bug fixing that can be done in a reasonable timeframe (I'll again mention the tickets from the old Orbiter-Forum). New features can come later, after the house is clean.
Worst case scenario, if development stalls, we would left with a "fully working" Orbiter.

 

[n72.75]

IMO, the next release should be just what was done since Orbiter 2016 (a.k.a. Orbiter BETA), plus any bug fixing that can be done in a reasonable timeframe (I'll again mention the tickets from the old Orbiter-Forum). New features can come later, after the house is clean.
Worst case scenario, if development stalls, we would left with a "fully working" Orbiter.

100% agreement here.