Roadmap proposal - Orbiter development

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
37,588
Reaction score
2,312
Points
203
Location
Wolfsburg
Preferred Pronouns
Sire
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

Active member
Joined
Sep 6, 2010
Messages
105
Reaction score
74
Points
43
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

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
37,588
Reaction score
2,312
Points
203
Location
Wolfsburg
Preferred Pronouns
Sire
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.
 

Abloheet

Addon Developer
Addon Developer
Joined
Apr 18, 2009
Messages
212
Reaction score
40
Points
43
Location
Kolkata,West Bengal
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
 
Last edited:

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
37,588
Reaction score
2,312
Points
203
Location
Wolfsburg
Preferred Pronouns
Sire
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

Addon Developer
Addon Developer
Donator
Joined
Mar 5, 2010
Messages
9,271
Reaction score
3,244
Points
203
Location
Toulouse
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

I like breaking things
Addon Developer
Joined
Jun 26, 2016
Messages
120
Reaction score
148
Points
58
Website
nassp.space
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

Move slow and try not to break too much.
Orbiter Contributor
Addon Developer
Tutorial Publisher
Donator
Joined
Mar 21, 2008
Messages
2,687
Reaction score
1,337
Points
128
Location
Saco, ME
Website
mwhume.space
Preferred Pronouns
he/him
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

Addon Developer
Addon Developer
Joined
Mar 9, 2009
Messages
225
Reaction score
104
Points
58
Location
Lehi, Utah
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 like breaking things
Addon Developer
Joined
Jun 26, 2016
Messages
120
Reaction score
148
Points
58
Website
nassp.space
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

Well-known member
Joined
Apr 20, 2008
Messages
400
Reaction score
315
Points
78
Location
Pennsylvania, USA
Preferred Pronouns
he/him
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

Move slow and try not to break too much.
Orbiter Contributor
Addon Developer
Tutorial Publisher
Donator
Joined
Mar 21, 2008
Messages
2,687
Reaction score
1,337
Points
128
Location
Saco, ME
Website
mwhume.space
Preferred Pronouns
he/him
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

Active member
Joined
Jun 8, 2011
Messages
191
Reaction score
41
Points
28
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

Active member
Joined
Sep 16, 2019
Messages
85
Reaction score
164
Points
33
Location
Bariloche, Patagonia Argentina
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

Active member
Joined
Sep 16, 2019
Messages
85
Reaction score
164
Points
33
Location
Bariloche, Patagonia Argentina
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

Move slow and try not to break too much.
Orbiter Contributor
Addon Developer
Tutorial Publisher
Donator
Joined
Mar 21, 2008
Messages
2,687
Reaction score
1,337
Points
128
Location
Saco, ME
Website
mwhume.space
Preferred Pronouns
he/him
So what needs to be done for the x86 release?
 

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
37,588
Reaction score
2,312
Points
203
Location
Wolfsburg
Preferred Pronouns
Sire
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

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,873
Reaction score
2,868
Points
188
Website
github.com
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

Move slow and try not to break too much.
Orbiter Contributor
Addon Developer
Tutorial Publisher
Donator
Joined
Mar 21, 2008
Messages
2,687
Reaction score
1,337
Points
128
Location
Saco, ME
Website
mwhume.space
Preferred Pronouns
he/him
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.
 
Top