Orbiter 2024 Launch readiness

[Lucy]

Another thing needed for the documentation is a list of the (major) new features and bug fixes. Any takers?

Also, IMO the scenarios in the "2024 Edition" folder should highlight the new stuff, instead of just being the same as in Orbiter 2016.

We had briefly touched on this point in the Discord chat, but were a little unclear on the main feature differences aside from "Orbiter is open-source now and this is the first open-source release" - I know there has been much work done and many fixes made, but in terms of something you could build a scenario around....

 

[n72.75]

@GLS, list of new features:

probably needs some cleanup

I was in fact wrong about how easy this would be haha. I'm still doing it though.


Here's a first pass attempt at a change-log. It will need some cleanup and some distinction between major/minor/bugfix/etc.

Also, there are some major changes to Lua and to D3D9 Client. I still need to add those in.

Orbiter Beta Changes since O2016 Release

Bug fix: VESSEL::GetStatus and VESSEL::GetStatusEx now respect the modified meaning of the arot and vrot vessel parameters for landed vessels (arot: rotation angles relative to planet frame, vrot.x: vessel CoG altitude above elevated ground). Should fix this problem.
Bug fix: Log error message DDERR_BLTFASTCANTCLIP resolved. Should fix this problem.
D3D7client::clbkBlt now tries Blt if BltFast fails
Atlantis: AscentAP: turn off RCS thrusters on AP disengage [issue #1238]
Bug fix: config texture dir now respected by new-style planetary texture and elevation maps. Addresses this problem, although the HTexDir value is still not being used.
API: New flag recognised by oapiGetObjectParam: OBJPRM_PLANET_MINELEVATION (exposes new MinElevation config tag)
Bug fix: visual artefact with rendered horizon haze on Mars (lower edge visible from hellas plantita). Should fix this problem.
Bug fix: DG: Command dialog (Ctrl-Space) not working correctly [issue #1266]
Bug fix: time acceleration keyboard commands (R, T) are now copied to the Time acceleration dialog if open.
Bug fix: SetAttitudeRotLevel: would have no effect in some circumstances [issue #1271]
Bug fix: DGS: glass cockpit fuel mass readout used scram tank instead of main tank
Bug fix: DG: Airfoil selector dial in VC didn't react to keyboard shortcuts [issue #1263]
Bug fix: Scenario editor: editing state vectors for landed vessel caused spurious orientation and angular velocity
API: added function oapiSimulateBufferedKey and oapiSimulateImmediateKey (C++) and oapi.simulatebufferedkey and oapisimulateimmediatekey (Lua)
Lua API: proc.wait_xxx functions extended to accept an optional function argument
Fixed Atlantis autopilot demo and a few other scenarios
Elevation system: now provides support for non-unity scaling factors
Planet config files: now parse ElevationResolution tag for rescaling elevation data to a target resolution (exposed to graphicsclients via oapiGetObjectParam)
Earth and moon config: switched default elevation resolution to 0.5
API: new function oapiGetGbodyParent and oapiGetGbodyChild
DG: Thermal subsystem implemented
Bug fix: DG: landing/docking light switch anomaly in VC
Bug fix: SurfTile: rescaling bug for elevation mod tiles with scale factor != 1
Bug fix: Vessel: transient thruster level was reset erroneously on IncThrusterGroupLevel
Flight recorder: default stepsize reduced from 4 to 2s
Atlantis: modified mass and thrust parameters [issue #1300]
Atlantis: slight modification to AP launch profile to account for new specs
Atlantis: payload attachment mass is now added to orbiter mass
Atlantis: airfoil activation now separated from RCS activation. Automatic switch from RCS to airfoils at dynamic pressure > 1kPaduring entry
Surface MFD: bug fix: now uses airspeed instead of groundspeed vector for AOA calculation
meshc: now allows parameters specified on command line ("meshc /H" for help). Quoted paths should work
HST launch scenario: now uses correct launch date. AP parameters preset for correct target orbit insertion
Surface-relative parameters (including position, altitude, ground and airspeed, atmospheric parameters) for each component of aSuperVessel immediately after assembly of the SuperVessel. For docked assemblies at simulation start this means that the surfaceparameters are up to date at the first clbkPreStep [issue #1374]
DeltaGlider: Insignia: layout geometry slightly altered and smaller font for winglet markings so that lower-case charactersextending below baseline are not clipped [issue #1361]
DeltaGlider: bug fix: creating a new DeltaGlider or DG-S instance in a simulation that already contained a DeltaGlider(non-scram) instance would corrupt the fuel display, and prevent the scram throttle levers from showing. This was caused by meshedits that were not cleared before the new instance was initialised, leading to cumulative mesh modifications. [issue #1323]
DeltaGlider: bug fix: fuel level indicators and fuel readouts corrupted in 2D panel mode when switching between vessel instances[issue #1323]
DeltaGlider: bug fix: airbrake status indicator blinking together with retro door indicator when airbrake set at 1/2 position[issue #1322]
Atlantis: Launch autopilot: implemented SSME throttle-down for max dynamic pressure between MET 35s and MET 77s, andthrottle-down for 3g max acceleration at the end of the burn. Adjusted launch attitude profile to account for modified thrustvalues. [issue #1300]
Bug fix: vessels landed at simulation start did not scan for gravity sources and therefore returned a zero weight vector [issue#1318]
PanelElement::Reset2D() now has panelid parameter so that instances can decide if they need to reset.
Mesh: group is re-initialised after edit with Mesh::EditGroup so that visibility volume is updated (issue #1356)
API: oapiWriteLogV: all output now prepends timestamp (issue #1339)
API: new function oapiWriteLogError() for consistent error output to log file
Bug fix: Inconsistent save/load of vessel AF mode to/from scenario file. Default mode for both saving and loading is now"disabled" (0) [issue #268]
Local light sources: sources with VIS_COCKPIT visibility flag are now skipped in external views, and sources with VIS_EXTERNALare skipped in cockpit views to avoid filling the available slots with inactive lights [issue #1319]
Orbiter server now runs without a 2d graphics surface: Fixes usage of g_pane without testing pointer validity.

OpenOrbiter Changes:

Made some corrections to the ShuttleA meshes, so everything fits together and looks better.
Also, fixed the vessel name being overwritten in the crew module, when more than 1 instance of the vessel was present.
There are more issues "inside" of the vessel (aux pod position switch loads "pressed" in VC, propellant displays overwrite/visual bug? in 2D panel, displayed propellant flow rate from tanks doesn't match displayed usage in thrusters, change to GDI logic to Sketchpad), but I just don't have the time to fix them right now... sorry.

Command Line: Parsing is now done in a seperate singleton class
Command Line: a new Config structure (CfgCmdlinePrm) holds the command line parameters
command line options have precedence over interactive settings in case of conflicts
Command Line: additional command line parameters have been added
    Enforce loading of plugins
    Enforce specific parameters (e.g. fixed time step length)
    Terminate simulation run after a fixed time

NG version: allow proper work from interactive console
    Server version of Orbiter changed to use CONSOLE subsystem
    will now reuse existing console if launched from one
    Allows proper stdout logging for tests
    Allows running/interacting with NG version directly in Visual Studio console
    Downside: flicker of console window on launch (visual only)

Pick graphics client directly from video page.

XRSound: implemented six more sound manipulation methods for XRSound 3.0
    Added SetPan, GetPan, SetPlaybackSpeed, GetPlaybackSpeed, SetPlayPosition, GetPlayPosition functions for XRSound 3.0
    Fixed some post-build event copy commands.
    Fixed the copyright year in a few files.
    Cleaned up the code in a few places.

SetClickZone_Quadrilateral: checking for coplanar 4th point, and offsetting along plane normal if required.
Added missing normalization to vertex normals in Shipedit.
Added logic to reset scenario variables to avoid, e.g., the context value being carried over from one scenario run to the next one.

Merge D3D9Client repository with whole history
    D3D9Client with full development history added
    All D3D9-relevant items have been moved to OVP/D3D9Client except for gcCoreAPI.h and gcGUI.h
    CMake is not yet integrated (will be added to separate PR)
    D3D9Client remains licensed under LGPL, added note to README

fix ShiftCG() in out-of-focus vessel shifting the vc click areas of the in-focus vessel, as reported in https://www.orbiter-forum.com/threads/orbiter-beta-r90-suspected-bug-with-shiftcg-call-and-vc-click-spots.40308/

Backport fixes from TransX V2014.04.26

Orbiter now searches for graphics client plugins within an optional module subfolder

shuttlea airlock
    outer airlock hatch now opens inward, hinged on the side
    inner airlock hatch is now functional (operated with Ctrl-O)
    some mesh adjustments
    mesh is now scanned with meshc to extract labelled mesh group indices

Added User Engine (THGROUP_USER) Sound to XRSound
Corrected position of DG RCS exhausts to match the mesh.
Fixed typos in .scn files
Implement Tesseral Gravity Perturbations
    C++ version of Pine's singularity-free harmonic gravity.
    Models included for: Mercury, Venus, Earth, Mars, Vesta
    Default coefficient cutoff is 10x10, configurable in the celestial body's config file
    Added section to gravity technote

Scene: emit warnings if data files (stars, constellations) are missing
    Missing data files for celestial sphere visuals (Star.bin, Constell.bin, Constell2.bin) are currently skipped silently.
    Issue a warning in the log file to make it easier to debug.
    Also fix potential memory leaks on load failures.

Hipparcos spectral type
    added spectral type information to star database (Star.bin)
    graphics clients read spectral data and convert it into colour variations for rendering
    default star visualisation parameters adjusted for increased brightness

Shuttle-A:
    now deletes sketchpad resources on exit (omission caused log file warnings).
    replaced all remaining GDI drawing calls with Sketchpad versions and removed GDI resources.

Deltaglider: Fix for wrong visors being hidden when hiding a passenger.

constellation boundaries
    Added data file for constellation boundaries
    Added support for rendering of constellation boundaries to inline/D3D7/D3D9 clients
    Moved data files out of root directory to clean up the root

D3D9Client: apply tgt_res to the rescale and offset values of elevation mod tiles.


Update video tab dialog elements to reflect selected client.
    Rescan video devices on switch.

API: Expose force vector and object axis display options
    Allows access to the vessel force vector and object frame axis display dialog options via GetConfigParam
    Implements force vector and frame axis display in D3D7 client
    Updates D3D9Client to retrieve the display options from the default GraphicsClient interface. Removes the workaround of hooking into the visual helpers dialog message loop from OapiExtension.
    General cleanup of force vector and object axis rendering code in inline client.
    Still to do: vector labels in D3D7 client (deferred to a separate branch implementing improved text label rendering).

stellar background
    Adds the option to render background stars as a texture map in addition to pixel rendering. This has been implemented for inline and D3D7 clients. Still to do: D3D9 client.
    Celestial sphere display options can now be hot-changed during a simulation session via the Options dialog (F6). The plan is to expand the options dialog in the future to include other parameters currently set outside the simulation session in the Orbiter Launchpad dialog.

Added planetarium option for displaying local (camera) horizon grid (azimuth/elevation), effectively an artificial horizon projected onto the celestial sphere.

Provides tick labels for coordinate grids projected on the celestial sphere.
    local horizon grid: azimuth and elevation scales
    celestial grid: right ascension and declination
    ecliptic grid: ecliptic longitude and latitude
    galactic grid: galactic longitude and latitude


Additional options moved from Launchpad to Options dialog.
Launchpad "Parameters" and "Visual effects" tabs merged into "Settings".

API: Add general purpose VESSEL::CreateAirfoil4 and AirfoilCoeffFuncEx2 functions to vessel API
Implemented a use of D3D9on12 driver to address issues on some intel graphics chips such as (Iris Xe Graphics)
Bug fix: Inconsistent graphics/physics elevation above LVL 14
Bug fix: Vessel sunlight bug near sun
Bug fix: Fixed flickering "doors" in DG in planetarium mode.
Bug fix: Max mesh resolution set to 32 to avoid out of video memory
Bug fix: Fixed TerrainToolKit multi-byte text display issue.
Bug fix: Added warning for missing planetary textures. Popup window if gravity-ref is missing textures.
Bug fix: Fixed sun-glare visibility near sun.
Bug fix: Fixed sunlight occlusion by body other than the closest one
Bug fix: Fixed a problem of moon being lit in a shadow of a planet by adding (accurate) support for eclipses.
Bug fix: Made a tile name appear on red in TerrainToolKit if the tile doesn't exists.

 

[n72.75]

Back in documentation-land, now making corrections and updates!

First up: markers.
The planetary surface markers were updated in 2016 to the quad-tree format, and the previous format was left for backwards compatibility. This is noted correctly in the documentation.
The celestial markers are indicated in the documentation as also having been updated to the quad-tree format... but I don't think that is true... can anyone confirm this story either way?

Also, in the .mkr files (the old format files) the ColourIdx parameter is limited from 0-5 in the code, and this is correctly noted in the docs. But looking deeper in the code (function CelestialSphere::MarkerColorFloat) it seems it can support index 6, which would be the color white. Should this be upgraded to allow the white markers, or left as is?
This is only relevant if the celestial markers are "stuck" with this format, otherwise we should move forward.

More, there lots of .mkr files for the planetary surface markers in the Config folder.... shouldn't this have been converted to the quad-tree format, given it is the "new" (and maybe better) format?

Finally, @jarmonik or anyone with write permissions on the Orbiter repo: could the latex_doc_update branch be updated with the latest main? It is currently 4 months behind.

I briefly looked through the code and it doesn't look like the celestial sphere markers use the quad-tree format, unless I'm missing something not obvious.

Regarding keeping branches up to date, this is why I keep my own fork of projects I work on--not that this is the only way to do it. I typically fetch and merge (--ff-only if possible) from upstream whenever new commits are merged.

 

[GLS]

Regarding keeping branches up to date, this is why I keep my own fork of projects I work on--not that this is the only way to do it. I typically fetch and merge (--ff-only if possible) from upstream whenever new commits are merged.

Yes, I also have an Orbiter fork to work on PRs. The (potential) issue here is that will make a PR on a branch, not on master, and if I update my branch by myself, I'm afraid the PR will then show my changes plus the ones on the master.
But if that happens I guess I can always throw the PR away, and copy just the documentation changes to a new branch, and PR from it.

 

[GLS]

Got the ball rolling on the PR, but gave up on updating my branch with the master, as there are conflicts with the documentation build changes.... somehow I have a feeling I should be working on SSV instead of this...

 

[n72.75]

Yes, I also have an Orbiter fork to work on PRs. The (potential) issue here is that will make a PR on a branch, not on master, and if I update my branch by myself, I'm afraid the PR will then show my changes plus the ones on the master.
But if that happens I guess I can always throw the PR away, and copy just the documentation changes to a new branch, and PR from it.

Got the ball rolling on the PR, but gave up on updating my branch with the master, as there are conflicts with the documentation build changes.... somehow I have a feeling I should be working on SSV instead of this...

Let me see if I can untangle this one with a combination of rebasing and cherry-picking. Documentation is the only thing left for the release so hopefully this isn't too hard.

 

[n72.75]

Let me see if I can untangle this one with a combination of rebasing and cherry-picking. Documentation is the only thing left for the release so hopefully this isn't too hard.

@GLS: I've resolved the merge conflict, and created an amalgamated branch of both commits, rebased on top of the current orbitersim/main. I can't get the MikTex part of teh equation to work for me right now, so double check that.

GitHub - n7275/orbiter at latex_doc_update_fixd

Open-source repository of Orbiter Space Flight Simulator - n7275/orbiter

github.com

You should be able to checkout that ^ branch, then git checkout -b and create your own branch that can be worked on and PR'd when its done.

 

[GLS]

@GLS: I've resolved the merge conflict, and created an amalgamated branch of both commits, rebased on top of the current orbitersim/main. I can't get the MikTex part of teh equation to work for me right now, so double check that.

GitHub - n7275/orbiter at latex_doc_update_fixd

Open-source repository of Orbiter Space Flight Simulator - n7275/orbiter

github.com

You should be able to checkout that ^ branch, then git checkout -b and create your own branch that can be worked on and PR'd when its done.

First of all, thanks!
Although it seems to work, when creating the PR to the master, it is adding all the doc changes (again)...


If I point the PR to the latex_doc_update branch, github says it can't merge, but will still accept the PR... and also shows tons of changes...

Maybe the best solution is for the latex_doc_update branch to be updated with the master from inside the project, leaving the PR with just these doc changes.



Anyway, does Orbiter need a vc redistributable to be installed, so that is mentioned in the docs?

I briefly looked through the code and it doesn't look like the celestial sphere markers use the quad-tree format, unless I'm missing something not obvious.

Same here, so I guess I'll change the text to reflect the actual implementation.



In the file Orbiter User Manual/SOL.tex there are tables with the some parameters for the planets, and I had a TODO in there to adding the data of minor planets. A quick check shows that Orbiter only has Vesta included, which is considered an asteroid... I thought Ceres (minor planet) was also included, but apparently not.
Not sure if the Vesta data should be added to the table...

 

[misha.physics]

@Gondos, I'd like to ask if its possible to see changes in game (in realtime) during edited Lua script (for example during mesh animation tuning or any other)? I mean editing Lua script in Lua MFD/Lua console. And if it's possible to get a DLL vessel from the Lua one (at least in the future) without compiling it myself?

 

[Gondos]

@Gondos, I'd like to ask if its possible to see changes in game (in realtime) during edited Lua script (for example during mesh animation tuning or any other)? I mean editing Lua script in Lua MFD/Lua console. And if it's possible to get a DLL vessel from the Lua one (at least in the future) without compiling it myself?

I did some tests to see if live coding was something feasible but it imposes lots of constraints on the way the module must be architectured.
You basically reload the script without exiting the scenario and it updates every functions, but it also reexecute everything in the global scope.Also it won't call e.g. the setclasscaps function so you will end up desynchronized between your existing objects and the code.
It can be worked around but as I said it would have a huge impact on the way the module must be defined...

The goal of Lua scripting is to get rid of the DLLs, I'm not sure what you have in mind. You want to have a DLL that embeds the script and the interpreter? Maybe you want to hide your code?

 

[misha.physics]

Thank you.

It can be worked around but as I said it would have a huge impact on the way the module must be defined...

Well, so if I understand correctly, we can change some parameters in Lua script in game and immediately see the results, but something we can't. What about mesh animations? Can we change, for example, the rotation point coordinates, rotation angle, rotation speed selecting the right values in real-time?

The goal of Lua scripting is to get rid of the DLLs, I'm not sure what you have in mind. You want to have a DLL that embeds the script and the interpreter? Maybe you want to hide your code?

Not to hide my code or have a DLL that embeds a script and the interpreter. I just read (in Orbiter Help), that vessels based on the Lua configuration file work slowly compared to ones based on their own DLL module, and that's not good for big complicated vessels. So, I mean: we create a Lua script for a vessel, since it's easier and doesn't require compiling, then use some external (or integrated into Orbiter) tool that converts the Lua script into a DLL module, so we get a vessel based on a DLL module without compiling, and this vessel doesn't require the Lua interpreter anymore. Could this make sence?

 

[Gondos]

I just read (in Orbiter Help), that vessels based on the Lua configuration file work slowly compared to ones based on their own DLL module, and that's not good for big complicated vessels.

I see. So far the only place where I saw a significant impact versus C++ is when manipulating big NTVERTEX arrays (in the SolarSail for example). One of the reasons to port the DeltaGlider to Lua was to see how a non trivial vessel would perform and I haven't seen that big of a performance hit (YMMV).
If it becomes necessary, there is a just in time compiler available for Lua (see this experimental branch).

 

[GLS]

Is 4GB RAM and 200 GFlops really the minimum requirement for Orbiter? Judging from my end, half of those values would probably still be a bit on the high side...

 

[n72.75]

Is 4GB RAM and 200 GFlops really the minimum requirement for Orbiter? Judging from my end, half of those values would probably still be a bit on the high side...

I can't imagine running Windows in 2024 with any less than 8GB. Orbiter is (for now, limited to a 32 bit address space). I wouldn't be inclined to chance it, personally, but I have no opposition to changing it to something more accurate.

 

[GLS]

I can't imagine running Windows in 2024 with any less than 8GB. Orbiter is (for now, limited to a 32 bit address space). I wouldn't be inclined to chance it, personally, but I have no opposition to changing it to something more accurate.

Remember, this minimum should be Windows+Orbiter only, without a browser with 20 open tabs or some other memory-hog.
Assuming at least Windows 10 is used, which (officially) requires a minimum of 1 GB of RAM, a 2 GB limit would leave the other 1 GB for Orbiter, which seems to be more than enough (in my experience). Obviously Windows will "stretch its legs", but some of that usage can be moved to the paging file if a program needs RAM... it is a bit subjective without actually trying it... anyone?
We could also use a different metric: RAM needed by Orbiter, without Windows or other stuff. In that case, 500 MB / 1 GB would probably be a decent minimum, and 2 GB the recommended value.

Certainly the GPU could be 100 GFlops... mine doesn't get to 3 digits, and with my visual settings at probably ~50% of max, performance is more than acceptable.

 

[diogom]

Remember, this minimum should be Windows+Orbiter only, without a browser with 20 open tabs or some other memory-hog.
Assuming at least Windows 10 is used, which (officially) requires a minimum of 1 GB of RAM, a 2 GB limit would leave the other 1 GB for Orbiter, which seems to be more than enough (in my experience). Obviously Windows will "stretch its legs", but some of that usage can be moved to the paging file if a program needs RAM... it is a bit subjective without actually trying it... anyone?
We could also use a different metric: RAM needed by Orbiter, without Windows or other stuff. In that case, 500 MB / 1 GB would probably be a decent minimum, and 2 GB the recommended value.

Certainly the GPU could be 100 GFlops... mine doesn't get to 3 digits, and with my visual settings at probably ~50% of max, performance is more than acceptable.

Far as I've seen too, 500 MB probably works, with 1 GB being on the safe side, but wanna say you'd need some hefty addons to get close to that? But what's relevant is the stock scenarios with stock planet textures, looks like you can run those under 500 at a glance.

In concept at least a value separate from the OS sounds good, even if almost everyone discovering Orbiter will be on Win 10/11, I'd bet there's still people out there on 7 or something. As far as RAM goes it feels like if you can have a browser open with a couple of Youtube tabs, you're probably good, but I don't know how well that translates.

 

[n72.75]

I don't have a strong opinion on what minimum system requirements should be, other than something that we can point people to when they say "orbiter doesn't run [well]". We should be able to point to the system requirements, and meeting them should be a solution to that problem.

 

[GLS]

Well, this minimum requirements discussion can be turned into a game: how low can you go?

This is how it currently stands:

 

[Urwumpe]

Well, this minimum requirements discussion can be turned into a game: how low can you go?

This is how it currently stands:
View attachment 40768

Did somebody already try a Raspberry Pi?

 

[Gondos]

Did somebody already try a Raspberry Pi?