Discussion Orbiter User Requirements and Post-2024 Development

[TorchDesigner]

Disclaimers​

This is a new account, but I've been a user since 2008, starting with Orbiter 2006. I've taken the past few weeks to catch up on the previous threads of development planning and I've tried to systematically understand where (Open) Orbiter is going.

I'm 25, and I had some inkling of the Orbiter 2010 heydays, but the main version with which I've learned to fly is Orbiter 2016. More accurately, I couldn't get far with the Orbiter manuals, so I tried KSP and then David Courtney got me over the finish line.​

Except for Altea Aerospace's XR series, I've not used any addons. I never saw Orbiter as a playground, it was a bootcamp sergeant who would only accept the cold hard realism of physics. KSP was the playground.​

Why I Care?​

I originally came to use Orbiter because I want to be an astronaut. Orbiter is my companion to keep my skills sharp until I am ready to apply for selections and do it in real life.

I work in the UK aerospace industry as a spacecraft engineer. After joining the industry, I noticed we don't have any "simulated test environments" like the aeronautical industry does. No 6-axis cockpit simulators. So, the space industry asks it's "How can we do X?" questions using complex software like Ansys STK, ESATAN and lots of other specialised, ancient and closed source software.

I've used Orbiter 2016 to figure out how to operate CubeSats in Earth Orbit. I've found that there are trajectories one can fly in an XR1 that keep re-entry temperatures below 1100 C, allowing a steel hull to survive without a thermal barrier. Orbiter allows professional exploration and discovery.

I care for Open Orbiter's future because of how I use it. I want to be able to trust Orbiter to the point that "If it works in Orbiter, it’s worth spending money on to prototype it in the real world". It's not just the simulation; it’s the lived experience of real spaceflight which only Orbiter provides.​

What is Orbiter's Purpose?​

From the point Dr Schweiger open-sourced Orbiter, the discussion has been led by addon developers and has largely focused on codebase improvements and API clean-up. After agreement in 2022, Orbiter 2024 focused mainly on code level changes and not user-oriented changes.

Orbiter 2024 has vastly improved performance and brought better documentation, achieving the goals set in 2022. However, I’ve not seen a coherent user-oriented discussion by the developers. The best example is a very short thread on the advantages of Orbiter. In the launch readiness discussion of Orbiter 2024, some people tried to move the conversation in this direction but it wasn’t successful. It is important to note that the proposed Orbiter Council comprises mainly of Addon Developers and Forum Admins, which means user feedback would be missing in that council.

With Orbiter 2024’s release goals fulfilled; this thread is for the questions that remain: Who is Orbiter for? What features should it have?
​

External Factors for Orbiter Development​

Political Emerging US-China Space Race European Plans for Indigenous Hardware New National Space Agencies	Economical​ Reduced Cost to Access Space​ Commercial Moon Missions​ Introduction of Space Tourism​
Social Reduced Public Funding for Space Little Awareness of Space Technology Declining Interest in STEM Careers	Technological​ Usage of Consumer Earth Tech in Space​ R&D is Closed Source/Unreproducible​ Earth Tech Better than Space Tech​
Legal Lack of Teaching Aids for Spaceflight Development of Space Laws Unclear Limits on Operations in Space	Environmental​ Alarming Increase in Space Debris​ Initiatives to Understand Space Weather​ Radiation and Zero-G Effects Studies​

Internal Influences on Orbiter Development​

Strengths Existing Realism in Physics Modelling Low Footprint and High Performance Robust API and Modding Techniques	Weaknesses​ Steep Learning Curve​ Hurdles in User Experience and Interface​ Complex Addon Development Process​
Opportunities Adding Open-Source Industry Software Accurate Operations Simulations Community R&D and Outreach Tool	Threats​ Reliance on Old Addons and Releases​ Declining User Base​ Fragmented and Obsolete Code Base​

Initial Points to Get the Discussion Started​

1. Linking Code Base Improvements to User Improvements: For example, 64-bit support can coincide with Orekit integration. Moving to an industry standard library means less maintenance on the Orbiter core and more community acceptance for professional use. Another example, OpenGL graphics front end can use meshes designed and exported from KSP, effectively letting users build complex spacecraft in KSP and fly them in Orbiter.

2. Better UI/UX: Orbiter is missing visualisation tools. TransX with trajectory visualisation, like GMAT or an extension of DrawOrbits, would become comparable to KSP’s manoeuvre nodes. The glass cockpit needs more functionality and documentation to become comparable to the 2D panel cockpit. Touchscreen MFDs with changes to reduce pilot workload, 3D views, and less acronyms would be helpful.​

3. Redundancy Removal: XR1 and DG can eventually merge. The number of fictional vessels could be reduced, and configurable generic vessels of different types could be included. The scenario tree can be cleaned up, to reduce confusion and only include frequently used scenarios. Addons considered essential can be merged into the source, for example, Burn Time MFD, Aerobrake MFD etc.​

4. Update and Upgrade Physics Models: I’m not clear if the old physics models have updated versions as of 2024. There are open issues on Github requesting updates to aerodynamics and re-entry modelling. Realistic re-entry graphics have been missing since the first release of Orbiter. Current research is interested in the dynamics of space debris clouds and the impact of space weather/radiation on satellite components. These phenomena are not currently modelled. Same goes for satellite constellations.

5. Trade-off Ease of Use with Performance: Orbiter was written in 2000 and design decisions to prioritise performance over usability are no longer strongly justified with the increased computing power of today’s hardware. The minimum specifications can be increased, and Orbiter can be made more user oriented. Python scripting support and higher-level programming interfaces for Addon development would be useful, both for people trying to get into STEM and space professionals (Lua is known by few in this industry). Developers should acknowledge that new users might not know or appreciate compatibility with older features or Addons.​

6. Operations Oriented Simulation: Orbiter could have a planning mode where the user makes a flight and operations plan. Then there would be a simulation mode where the plan is shown as a checklist, and the user relies on Orbiter to tell them if the plan is achievable or not as they run through the scenario. Such simulation could directly inform sensible requirements for real space missions. This feature would require an overhaul of the scenario recorder feature.​

7. Streamline Addon Development: Orbiter development could move towards code-free/compile-free development for most applications, especially for new vessel programming. KSP could be used as a GUI interface to build spacecraft models and export them into Orbiter. GUI configuration tools to configure the flight model, animations and system operations might complement that. For things like detailed system modelling, high-fidelity control etc. the C++ API would still be the best tool. Considered the improved speed of modern hardware and compilability of Python, applications using C++ could be discouraged for maintainability. Otherwise, the Python API could be a front end to a future internal only C++ API.​

My Potential Contributions​

I have C++ and Python development experience, as well as spacecraft design and operations experience. That is my day job, so I’m not keen to do the same thing for Orbiter but I can offer feedback and input.

Starting 2026, I’m happy to volunteer technical project management and planning services to Open Orbiter. I’m also happy to explore funding from UKSA to develop Open Orbiter into a community tool for the space industry for very early-stage mission planning and for public engagement.

I’m also happy to contribute funds directly, to the tune of £1,000 each year. By the end of 2026, I’m planning a successor to the Go Play in Space book and David Courtney’s YouTube tutorials, by writing a 20-scenario training manual for Open Orbiter (+ XR1) and teaching people at Harwell’s Space Cluster to fly the spacecraft they build.​

 

[misha.physics]

A very interesting and "global" thread.

By the way, are you familiar with Reentry? It may be interesting for you:

Reentry - A Space Flight Simulator

Also, I have many suggestions for improvement and expansion Orbiter development in various aspects. Some are ambitious, other seem to be quite feasible. Maybe we need to compose some points for future development, form a plan, distribute work, test it, etc. I'd just like to note that it would be desirable to save the uniform style and beauty of the Orbiter. I mean style of MFDs, etc.

 

[Urwumpe]

I think some many of the points simply don't look at the details good enough to really be an option, like Orekit being written in Java and thus can't be linked to Orbiter or the XR series being @dbeachy1 own copyright (which doesn't end just because its open source) and the vanilla DG intentionally being kept as "intermediate example" for learning how to make add-ons, which makes it distinct, different use-case. Or Orbiter currently not using Python at all, but Lua. Also some solutions require a much larger community of developers if they should not end in development hell. Remember, we can't play by the video game industry rules, one free-time developer in Orbiter still means less velocity than a full-time developer in the industry, also in terms of available tools. I'd prefer in thinking in smaller steps regarding the solutions, even if there are great shared visions.

But I generally appreciate the effort you have put into this. Maybe we can find more common ground if you consider more what Orbiter is right now.

 

[TorchDesigner]

I think some many of the points simply don't look at the details good enough to really be an option, like Orekit being written in Java and thus can't be linked to Orbiter or the XR series being @dbeachy1 own copyright (which doesn't end just because its open source) and the vanilla DG intentionally being kept as "intermediate example" for learning how to make add-ons, which makes it distinct, different use-case. Or Orbiter currently not using Python at all, but Lua. Also some solutions require a much larger community of developers if they should not end in development hell. Remember, we can't play by the video game industry rules, one free-time developer in Orbiter still means less velocity than a full-time developer in the industry, also in terms of available tools. I'd prefer in thinking in smaller steps regarding the solutions, even if there are great shared visions.

But I generally appreciate the effort you have put into this. Maybe we can find more common ground if you consider more what Orbiter is right now.

Thank you for your feedback! My points are meant to start discussion like this one. The features proposed here could take multiple versions to reach, they just must be helpful to the community. My thinking is in the 2030-35 time frame. I appreciate your input, your short term solution planning means everything is covered.

Orekit is not a good idea on further investigation, the C++ Java Bindings will be a pain. The interesting thing is that the NASA GMAT core is in C++ and @n72.75 and people have already linked that to 64-bit development and done some implementation planning.

It's not clear from the documentation and scenarios that the DG is now meant for Addon development, but it makes sense to keep them separate then. The XR1 operates and flies in a more realistic fashion, could that be the default? It of course is up to dbeachy1, but more clear documentation and scenarios that might help that in future releases.

I think the Lua issue is more tricky. The decision to upgrade to Lua 5.4 seems inconclusive. There were some arguments to not upgrade things for the sake of upgrading them, as the user benefits were unclear. I think all those same considerations apply to moving (slowly) toward Python instead as its better known in the space industry. This library will enable a slow transition, letting the Lua 5.1 core stay-in place:

GitHub - bastibe/lunatic-python: A two-way bridge between Python and Lua

A two-way bridge between Python and Lua. Contribute to bastibe/lunatic-python development by creating an account on GitHub.

github.com

In the long term, wouldn't Python be the better language to support? GMAT, Orekit, Blender, FreeCAD etc all have Python interfaces. As for the Lua to Python transition, they have very similar syntaxes and the transition might be doable with AI tools for a first pass. @Thunder Chicken could you please weigh in?

For your last comment, over the years multiple developers have avoided the move to funded development. If we can get funding (£50k-ish for 2-3 people full time for one year) to develop Orbiter as a community tool, say from the UK Space Agency, is there a harm? It would increase Orbiter's profile and attract the next generation of users and Addon developers. This is a unique thing Orbiter can capitalise on, being open source and having "heritage".

@misha.physics I know you had lots of good suggestions in the old roadmap thread, could you please update those requests and post them here? To have it in one place? Then we can start the planning, informed by the comments and feedback of the developers. @Felix24 made a similar post, which is useful to reference here too.

 

[Thunder Chicken]

In the long term, wouldn't Python be the better language to support? GMAT, Orekit, Blender, FreeCAD etc all have Python interfaces. As for the Lua to Python transition, they have very similar syntaxes and the transition might be doable with AI tools for a first pass. @Thunder Chicken could you please weigh in?

If we want a robust add-on ecosystem for Orbiter to develop, the methods to make add-ons need to stabilize. Orbiter has been around for decades, but a lot of early addons are dead because they were compiled for earlier versions of the Orbiter API and the source code may no longer be available. Allowing a scripting capability would at least ensure that the code remains with the add-on, so in theory it could be updated using just a text editor to be compatible with more recent Orbiter releases.

The folks working on Orbiter just put a mountain of effort into getting Lua method equivalents and documentation to their C++ API counterparts. Unless there is some compelling computational reason under the Orbiter hood to effect such a change I'd say leave it be. If we're going to up-end the scripting infrastructure every couple years, breaking all the related add-ons, there really isn't much point in having scripting alternatives.

One technical concern I have about Python is that Python leans heavily on external 3rd party libraries for a lot of what would be basic functionality in other codes, like math functions, and so a Python script defining a vessel add-on would rely on the end user having those libraries installed. I haven't played with Python in a while and don't know if there is a way to enforce a script to use pure Python syntax and ignore these 3rd party libraries. Otherwise there may be a problem with users being unable to run Python add-ons because they don't have the correct libraries being used by the add-on developers.

Also, if the above can be resolved, would it have to be an either/or thing? If someone really wanted to build out a Python interpreter for Orbiter that could be used in parallel with the Lua interpreter, what would hinder that?

 

[misha.physics]

@misha.physics I know you had lots of good suggestions in the old roadmap thread, could you please update those requests and post them here? To have it in one place?

I could review and collect my request notes and publish them here a little later. I'll do that. Just to introduce them to others. (Now I'm just close to finish and release some my add-on projects that are in progress.)

In general, I probably look more closely at solving a lot of local issues in the short term (the world becomes unpredictable) and suggestion some new features that are less or more difficult to implement

Actually, I'm really satisfied with the Orbiter 2024. I really like how its performance and graphics look now.

 

[Urwumpe]

In terms of development, I would prefer having more high-level frameworks available, maybe also with the option of defining event handlers in a scripting language, for faster prototyping, but generally allowing to create reusable C++ components.

I think the main problem isn't if its a scripting language or not, but how much boilerplate code actually repeats in each add-on and how little code is needed to make a difference. I also think, Orbiter would be a great environmnet to try a Maven like build system with "convention over configuration", but the recent motion towards the industry standard CMake is already a good step in the right direction.

 

[TorchDesigner]

I thought to wrap things up on this thread, as it's not been active. In summary, the points that I've mentioned aren't the right fit for Orbiter development currently.

There is a strong push to get Orbiter working on Linux, and improve the UI/UX and implement Ray Traced graphics. See the Github PR Activity for more.

My main observation after researching this forum is that currently there are no science-focused feature updates in development. So people considering to contribute could consider extending Orbiter's core science simulation capabilities. Those are points 4 and 6 in the Original Post.

My current plan is a Lua-SDL2 based addon to get basic joysticks working with Orbiter 2024 until the next release when SDL3 and advanced Joystick support gets included natively. I'll get started on this in mid-2026. Next, I'll look at improving the GUI/UX of TransX. Then I'll focus on the science in Orbiter.

I'm still open to the UKSA angle and officially funding OpenOrbiter development, so if there is interest later, I'd like to be involved.

 

[DaveS]

My main observation after researching this forum is that currently there are no science-focused feature updates in development. So people considering to contribute could consider extending Orbiter's core science simulation capabilities. Those are points 4 and 6 in the Original Post.

That's because everything that has to do Orbiter with is ancient! D3D9Client is still compatible with the default graphics client (using DirectX 7, first released in December 1999) written by Martin back in 1999/2000, which predates the first flight of the so called "glass cockpit" of the Space Shuttle which was in May 2000 and the only orbiter to have it was Atlantis. The rest of the fleet (Columbia, Discovery and Endeavour) still had their original early 1980's instrumentation. So Orbiter exists teetering on obsolescence and is just one decision away by MS to kill DX7 compatibility altogether from being dead.

 

[Urwumpe]

That's because everything that has to do Orbiter with is ancient! D3D9Client is still compatible with the default graphics client (using DirectX 7, first released in December 1999) written by Martin back in 1999/2000, which predates the first flight of the so called "glass cockpit" of the Space Shuttle which was in May 2000 and the only orbiter to have it was Atlantis. The rest of the fleet (Columbia, Discovery and Endeavour) still had their original early 1980's instrumentation. So Orbiter exists teetering on obsolescence and is just one decision away by MS to kill DX7 compatibility altogether from being dead.

Not at all. Orbiter also removed the much older GDI stuff from its API in 2016 without dying. Which broke a lot of add-ons, but resulted in a (more) platform-agnostic API. The only things that still really mentions the old DX7 is the left-handedness of Orbiter and the texture format. A Vulkan (Next generation OpenGL) client would be nicer, since its also open source, but who would like to create it? I doubt I can learn to do it in 2025....

 

[jarmonik]

I thought to wrap things up on this thread, as it's not been active. In summary, the points that I've mentioned aren't the right fit for Orbiter development currently.

My main observation after researching this forum is that currently there are no science-focused feature updates in development. So people considering to contribute could consider extending Orbiter's core science simulation capabilities. Those are points 4 and 6 in the Original Post.

I have had some science focused plans in the past. When LunarTransferMFD was created I was working on a simple trajectory propagator that could be used for trajectory analysis. Also, I have been thinking about resurrecting my old 25 years dead linux application MathPlanner and building a bridge to the Orbiter. Both are easy to use tools but far behind a professional tools. Probably good for education but not so good for hard science.

But since the Orbiter graphics started suffering from problems I moved working on that side and haven't got a break to get back to Math.

My current plans are:
1) Get Vulkan running
2) Upgrade Orbiter's DX7 minded graphics API to Vulkan standards.
3) Get the Virtual cockpit rendering upgrade finished.
4) Build user friendly development tools for vessels.
5) Hopefully get back to Math.

I think the Lua issue is more tricky. The decision to upgrade to Lua 5.4 seems inconclusive.

Ideas about 5.4 has been presented but the actual developers working on lua are not so keen about it. It seems that people who actually write the code are making the decisions in the end.

 

[DaveS]

I have had some science focused plans in the past. When LunarTransferMFD was created I was working on a simple trajectory propagator that could be used for trajectory analysis. Also, I have been thinking about resurrecting my old 25 years dead linux application MathPlanner and building a bridge to the Orbiter. Both are easy to use tools but far behind a professional tools. Probably good for education but not so good for hard science.

But since the Orbiter graphics started suffering from problems I moved working on that side and haven't got a break to get back to Math.

My current plans are:
1) Get Vulkan running
2) Upgrade Orbiter's DX7 minded graphics API to Vulkan standards.
3) Get the Virtual cockpit rendering upgrade finished.
4) Build user friendly development tools for vessels.
5) Hopefully get back to Math.



Ideas about 5.4 has been presented but the actual developers working on lua are not so keen about it. It seems that people who actually write the code are making the decisions in the end.

Could a 4B be added to the list: Build user friendly development tools for bases?

 

[Urwumpe]

Ideas about 5.4 has been presented but the actual developers working on lua are not so keen about it. It seems that people who actually write the code are making the decisions in the end.

Also its pretty hard to argue against using LuaJIT, should it work in Orbiter, since its performance is really very good and makes a good trade-off to the better language specification of 5.4.

 

[Urwumpe]

Could a 4B be added to the list: Build user friendly development tools for bases?

Could also be done as add-on tool for the start like ar81s add-on. Just more up-to-date, not using VisualBasic and properly internationalized...

 

[Matias Saibene]

Could a 4B be added to the list: Build user friendly development tools for bases?

In my case, I'm working on the Linux port of TileEdit and will soon be testing the Windows version. Both use Qt, and while they don't currently support creating bases, I think it would be nice to add support for creating bases, tiles, and elevation.

 

[misha.physics]

Above I promised to revise my issue/ideas notes and post them here to show to the community. Probably many graphics issues like shadows and map drawing performance will be automatically resolved with global changes like the plan by @jarmonik or/and UI rework by @Gondos in the future development.

ISSUES (Green means non-actual)

Default Map MFD drops FPS due to complicated coastlines on the map.

Map window (Ctrl+M) drops FPS during dragging the map due to complicated coastlines on the map.

HOLD button on 2D main panel of DG is not synchronized with key A and HOLD ALT button on glass cockpit. Setting some alt value on 2D panel and pressing key A or HOLD ALT button on glass cockpit does not activate the autopilot, whereas pressing HOLD button on 2D main panel activate it correctly.

Joystick is unactive when an external Orbiter window is focused.

Cubic interpolation does not work with the terrain flattening.

Shadows of the default objects like BLOCK, HANGAR; vessel shadow, exhaust shadow; runway object, landing pad object; solar and lunar disks shine through the ground (hills, mountains).

Local lights (for example, of DG) shine through objects like BLOCK, HANGAR.

Shadows from objects like BLOCK are flat in mountains and are located underground.

Pixelation of Earth atmosphere at far distance.

Low refresh rate in Generic Camera MFD.

Colored spots of Moon microtextures.

"Max. resolution level (1-21)" on the launchpad seems to be broken.

*_metal.dds additional map is applied to all meshgroups.

Default HANGAR3 object is broken for texturing.

"D3D9 Debug Controls" function disappears after severel relaunching a scenario.

Too large vessel name covers the planet name in Scenario Editor.

White pixel flickering at top of the screen on the Mars surface.

The "Dv" parameter of the Transfer MFD does not change during burning after switching interior view by F8 key.

UPDATED August 7, 2025

A thin disk mesh placed on the ground is not visible all when terrain flattening is used.

Clicking two times on "Labels only" makes menu panel at top of the screen invisible.

UPDATED August 15, 2025

Description on the "Quickstart" scenario says that "Shift ," or "Shift ." can be used for switching MFD modes, but it doesn't work in Orbiter 2024.

Script MFD API-Test causes Lua errors when activated (enable ScriptMFD module).

Spaces in some words of scenario descriptions are presented, but they are not in the corresponding SCN files.

Undocking is still possible in Playback (Replay mode) scenarios.

The default \Scenarios\Tutorials\DG stunts scenario uses scram engines in Replay mode, but the engines don't work after getting the controls of the DG (on Earth surface).

The default \Scenarios\Tutorials\Space Shuttle to ISS scenario ends in a strange place (there are not docking notes in the correspondings annotation file).
There is an audible click after every thruster cut-off.

IDEAS

Customizable water microtextures like distance of visibility if looking from above at right angle, "transparency" relative to surface (that is water) tiles, size of specular ripples (waves), their animation speed.

Maybe non-flat water, namely elevations for water.

Customizable surface microtextures like distance of visibility.

Using light sources for base lighting instead of night lights painted on mask tiles.

Option to set the distance at which tiles of the given level are visible.

Atmosphere tuning to make it brighter (for example, like in FlightGear).

Customizable weather like rain, storm, fog.

Customizable distance of view.

3D clouds, various clouds (color).

Using night (*_n.dds) textures for custom meshes not only default objects like BLOCK.

Add custom path for textures for default objects like BLOCK to use custom folders for the textures, not only /Textures directory.

Customizable transparency of MFDs in glass cockpit.

Autogeneration of buildings, trees on Earth and rocks on Moon, Mars.

Assigning hot keys for custom camera presets for fast switching between them, for example, for quick look to the left, right, back in internal and external views without animation.

Customizable wind power.

Add a key for killing hover engines like * for main engines.

Improving aerodynamics of atmospheric flight.

Collisions between vessels, stations in space.

Automated animated traffic like trains, cars for bases.

Autopilot and traffic editor for vessels to pursue them.

Delete calling the "Configure menu bars" menu when clicking at top of the screen since it can be happen accidentally during camera rotation. It is better to assign a key for calling this menu.

Assigning separated keys for 3D VC, 2D panels, glass cockpit internal views since F8 key just cyclically switches them.

Adding the mouse view mode for camera rotation without holding the right mouse button. Assign a key, for example, the middle mouse button to enable/disable the mode.

Adding an option for the default Map MFD to hide other vessels.

Show hud indications during camera rotation in glass cockpit like in 3D VC.

Assign keys for changing the default DG autopilots values without mouse clicks on 2D panel.

Add an option to delete selected tiles in Terrain Tool Kit that will be very useful for removing tiles that contain pure water.

More ships with complex systems for manual launch and setup.

More controllable rovers.

More space stations located at a small distance for short vessel flights between them without time acceleration.

Astronaut flights between nearby ships and stations in space. Astronaut with arms and legs motion animations.

Astronaut spacewalk for ship and station repair/building in space. Flexible cable connecting the astronaut to the ship/station.

Flights by vessels and rover transfers between nearby land bases.

Astronaut walks on the ground, space base maintenance.

Free astronaut movement within space stations and big ships (without leaving their boundaries) with internal working 3D cockpit, so we just could go to the station panel and run some command, check and research something, send data to Earth. Moving with both gravity on and off at the station/ship.

Mission Control Center to control automatic (unmanned) ships, satellites, rovers.

UPDATED August 2, 2025

Make FoV independent in VC and glass cockpit.

UPDATED January 25, 2026

For now (Orbiter 2024) left and right MFDs are just copies and the right MFD overwrites the left one after pressing F8 key.

 

[Arvil]

If I thought enough, I could probably come up with a few things, but, there is one thing I would wish for. The DG has the Dock/Land light. I like to move tubes and cubes around the ISS and Mir, docking them. It takes twice as long to do so when not being able to work on the night side. So, Dock/Land lights for the Shuttle A and the TUG, as well as other vessels, perhaps with a rheostat on the panel to control brightness.

 

[Boxx]

I originally came to use Orbiter because I want to be an astronaut. Orbiter is my companion to keep my skills sharp until I am ready to apply for selections and do it in real life.

Wish you the best and, if so, do not forget this community!

It's always cool to have this kind of brainstorming from time to time. Here are my 2-cents, because I'm deeply involved in the dev of C++ add-ons (although I'm not part of the core-team of Orbiter's devs... not yet...).

After agreement in 2022, Orbiter 2024 focused mainly on code level changes and not user-oriented changes.

We have been all needing Orbiter's core to be taken over. Maybe it is now time to think of user-oriented features indeed. My feeling is that the core-team is highly concerned about what should be in the core and what should not, and that's right.

For instance:

Orekit integration

As you noted later, Orbiter does not like Java (which is known to be much appreciated by OPEX people). I'm not a fan at all of Java but I would like "streams" to be an interface for Orbiter's core. E.g.: at the moment, you must inject ephemerides of gravitational bodies at the start of a simulation, but why not allowing ephemerides on-the-fly from streams (either because their computation is complex before hand or because it comes from outside of Orbiter... in real-time for instance, like TLE for Earth orbiting objects).

missing visualisation tools.

That's really up to add-ons' dev, IMHO. We (add-ons' dev) only need a robust interface with the core and that's were the focus should be.

DrawOrbits

?!

Current research is interested in the dynamics of space debris clouds and the impact of space weather/radiation on satellite components. These phenomena are not currently modelled. Same goes for satellite constellations.

a "collision" model has been discussed many times. I am considering a model for my OMX gameplay -> i.e. at Add-on level. Is this the best way?

Orbiter was written in 2000 and design decisions to prioritise performance over usability are no longer strongly justified with the increased computing power of today’s hardware. The minimum specifications can be increased, and Orbiter can be made more user oriented. Python scripting support and higher-level programming interfaces for Addon development would be useful, both for people trying to get into STEM and space professionals (Lua is known by few in this industry). Developers should acknowledge that new users might not know or appreciate compatibility with older features or Addons.

That's a critical example about "inside or outside the core".

Personnaly I am strongly against the philosophy that allows dirty coding (e.g. python) "just because" the computing efficiency is higher. I think that's a shame. Thus, for sure no python in the core, please, never! We need robustness. And for Add-ons, @Thunder Chicken already assessed the concern of the optional [and/or dirty-coded] libraries (sometimes even only for Windows, that will become an issue for Linux portability), that will worsen the situation of many non-reliable add-ons.

Although I've never played with LUA, it does not look so much popular but the learning-curve does not look to hard neither.

6. Operations Oriented Simulation

Not in the core, IMHO, which should remain the "physics engine". Flight plans are at add-ons' level: Orbiter shall always behave as you fly, not as you plan to fly.

By the end of 2026, I’m planning a successor to the Go Play in Space book and David Courtney’s YouTube tutorials, by writing a 20-scenario training manual for Open Orbiter (+ XR1) and teaching people at Harwell’s Space Cluster to fly the spacecraft they build.

Yeah! That is so much needed. I would follow your channel.

In OMX (fork of OMP), "flying schools" features are in the dev roadmap: "flying in double-command". That could/should be a key factor of the economy of OMX (and Orbiter?).

 

[jedidia]

Could also be done as add-on tool for the start like ar81s add-on. Just more up-to-date, not using VisualBasic and properly internationalized...

The development tools should certainly be on the add-on side. However, a more capable and extendable interface for bases, similar to what vessels have, would be worth considering as a core feature...

 

[palebluedot]

Many years ago jedidia made a science fiction addon that could create scenarios of other star systems with custom planets. I think it could also simulate jumping from one system to another but Orbiter had to be restarted with the new system in the new scenario as it can simulate only one system at one time.
Which got me thinking that could(hypothetically speaking), a graphics client be made, that was outside the Orbiter process? It would load Orbiter with a star system and then when the user wants to jump to another system, quietly load and connect to another instance of Orbiter which is running the new system? So the user sees a seamless transition.
For example if I wanted to simulate the Breakthrough Starshot project