Orbiter 2024 Launch readiness

[GLS]

What do you mean, it doesn't account for the planet mass?

From the old doc: This figure does not take account of the target's gravity, which typically will pull the craft in, and make the actual approach closer than this.
This is noticeable even doing a lunar transfer, where an initial target of, say 100km Pe, will result in a new crater.
There are another "periapsis" and "closest approach" distance values in other views, as well as times for those, usually showing different values from each other.

There are certainly some limitations that probably can't be avoided from a mission planing standpoint. Even IMFD with its lambert solver, I think it would be a real struggle to come up with the Voyager 2 mission plan, without prior knowledge of it. gmat still wins in the end. I think an approximate solution is fine here.

Of course I'm not expecting perfection, which does not exist, and in other scenarios this "issue" is quite manageable, but if some precision is required (like a Voyager flyby), it gets really difficult as the encounter gets shifted several days in the last few months before the encounter.
I think I got the Earth departure trajectory +/- nailed, and without any TCMs the vessel gets to Jupiter. From there, if I meet Jupiter at the right time and get the correct Pe, I'll get all the satellite flybys and get thrown in the general direction of Saturn, which gets fine-tuned with some more TCMs. Same trick of using the historical data at Saturn, and more good flybys ensure. In this, TransX was used not really as a source of data, but more of a "how a I doing" check. The user has to provide the target, as a plan keeps shifting.
And just to be clear, in the other 2 "tutorials" (to Moon and Mars) the user starts with a clean plan and has to input the data to get to the target, but for this one I would have provided a pre-loaded trajectory to +/- follow Voyager-2, so the user would just have to perform TCMs to correct injection errors, and the inevitable math precision limitations.

Also... I've finished reading through the Orbiter manual. it's looking excellent from what I can see. it's probably been about 15 years since I read the manual cover to cover.

Thanks! There will be a few more additions, but that one is almost done.

 

[GLS]

Hmm, is a CTD expected when typing something like v.get_name() in the lua console? (note the "." instead of ":")

 

[Gondos]

Hmm, is a CTD expected when typing something like v.get_name() in the lua console? (note the "." instead of ":")

I guess it's a rhetorical question... Yes there are lots of places were the inputs are not or incorrectly validated and it'll produce a CTD. Using . instead of : on vessel objects is a recipe for disaster in the current version.
Edit: for your particular case, it should show a "too few arguments" error

 

[GLS]

I guess it's a rhetorical question... Yes there are lots of places were the inputs are not or incorrectly validated and it'll produce a CTD. Using . instead of : on vessel objects is a recipe for disaster in the current version.
Edit: for your particular case, it should show a "too few arguments" error

Can any quick checks be added in 2 weeks? If not, then a ticket needs to be open to improve this for future releases, as it seems a bit harsh to CTD because my finger slipped from the Shift key, and a '.' came out instead of ':'...

 

[Gondos]

Can any quick checks be added in 2 weeks? If not, then a ticket needs to be open to improve this for future releases, as it seems a bit harsh to CTD because my finger slipped from the Shift key, and a '.' came out instead of ':'...

If I try in a Lua console, v.get_name() returns an "invalid number of arguments" error. To have it crash I need to pass a dummy argument (v:get_name(1) for example). I doubt that's what you did.
Extracting VESSEL * from a Lua parameter is usually gated behind a lua_tovessel_safe function. That name is misleading because it's not safe at all to use the result with no further checks...
Adding a test to throw a Lua error in this function should be trivial. However, for a Lua error to be caught properly and not explode into a CTD, the top call into the Lua VM must be a "protected" call. I'm almost sure there are some places where is not done and a Lua error will lead to a CTD instead of an error message.

 

[GLS]

To have it crash I need to pass a dummy argument (v:get_name(1) for example). I doubt that's what you did.

Yeah, I was probably playing with the quadcopter functions, which require arguments.

 

[Gondos]

Yeah, I was probably playing with the quadcopter functions, which require arguments.

OK that makes sense, the QC does not perform any validation in its Lua bindings. I added some checks in this PR. Can you play with it and see if you still get CTDs ?

 

[GLS]

OK that makes sense, the QC does not perform any validation in its Lua bindings. I added some checks in this PR. Can you play with it and see if you still get CTDs ?

Probably only tomorrow... I'm trying to get the TransX "tutorial" done, and I think I found a few more answers to recent concerns there.

From the old doc: This figure does not take account of the target's gravity, which typically will pull the craft in, and make the actual approach closer than this.

It seems this is true, but only sometimes... or, in some displays to be more accurate. Apparently the mass of the celestial body is taken into account, but only if it is the celestial body of focus in that particular stage.
So in a "simple" Earth-to-Mars trip, the gravity of Mars will only be used for calcs in the last stage (Mars-centered), and the second stage (Sun-centered) will assume Mars to have no mass, so the displayed close approach value will be larger that what will happen in reality.
So the planning for the Voyager-2 got a bit more complex, now that 2 MFDs are needed (edit the plan in one, and read the result in the other), but it seems that it will work.

 

[GLS]

OK that makes sense, the QC does not perform any validation in its Lua bindings. I added some checks in this PR. Can you play with it and see if you still get CTDs ?

I'm sorry it took a while... lack of time and some issues building XRSound, which seems to be a hard requirement for the lua stuff.
Anyway, it looks good, no CTD!

 

[n72.75]

I finially made it through the developer manual. I didn't see any issues. Other than the TransX part, I think we're go on documentation?

 

[GLS]

I finially made it through the developer manual. I didn't see any issues. Other than the TransX part, I think we're go on documentation?

Thanks!

There are still a few open items: https://github.com/orbitersim/orbiter/issues/440
Not in there is the XRSound documentation... maybe that should have a section in the User Manual and another in the Developer Manual?


As for the TransX... I can't make the whole Voyager-2 flight to fit, so it will be "cheated". I'll have to finish it this weekend, as I'm so tired of the daily Earth-Jupiter commute.

 

[n72.75]

Thanks!

There are still a few open items: https://github.com/orbitersim/orbiter/issues/440
Not in there is the XRSound documentation... maybe that should have a section in the User Manual and another in the Developer Manual?


As for the TransX... I can't make the whole Voyager-2 flight to fit, so it will be "cheated". I'll have to finish it this weekend, as I'm so tired of the daily Earth-Jupiter commute.

Oh awesome. I didn't know/forgot that we have an items to complete list.

XR sound should probably get a short section in both. As long as it's in its own TeX file/and document section, I think that's fine. @dbeachy1 is there anything that we can pull in from the 2016 version to make writing this easier?

As for TransX, I see no problem with the way you're doing it.

I will do my best to help get get things done. I would've been more involved, but my job has been taking all my nights and weekends since about June. There are only 4 Tuesdays left in 2024....

 

[Urwumpe]

Is there any new section about the Orbiter command line interface?

 

[GLS]

There are only 4 Tuesdays left in 2024....

I've been doing the same countdown for sometime now.

Is there any new section about the Orbiter command line interface?

Yes, that is section 19 of the Orbiter User Manual.

 

[GLS]

Orbiter User Manual, just out of the oven https://gofile.io/d/aGVNGd

 

[dbeachy1]

XR sound should probably get a short section in both. As long as it's in its own TeX file/and document section, I think that's fine. @dbeachy1 is there anything that we can pull in from the 2016 version to make writing this easier?

Hmm, not sure what you mean? If you're asking if you can pull in documentation from the XRSound User Manual to make a section in the official Orbiter 2024 documentation, sure, I'm fine with that. We could even ship the entire XRSound manual with the Orbiter documentation if you'd like. I still need to update it (and the XR vessels, but they are separate) for the official Orbiter 2024 build, but that won't take long (in theory).

 

[GLS]

New version (https://gofile.io/d/aGVNGd), now with the TransX "tutorials" and corrections to tables for command line parameters, config parameters, and key mapping.
I've attached the new TransX scenarios, so they can be tested against the documentation (section 10.12.2). I'm sure it could be much better, and there is lots missing, but tempus fugit.

 

[Ripley]

Hi fellow Orbiteers.
I often read about TransX tutorials and its documentation in many of these latest posts.
Which version of TransX do these posts reference to?
I remember, some eons ago, that the default-included Flytandem's TransX was a bit buggy, and Enjo transformed it quite a lot with the AutoCenter feature and many other things (ModuleMessaging and such).

 

[GLS]

Hi fellow Orbiteers.
I often read about TransX tutorials and its documentation in many of these latest posts.
Which version of TransX do these posts reference to?
I remember, some eons ago, that the default-included Flytandem's TransX was a bit buggy, and Enjo transformed it quite a lot with the AutoCenter feature and many other things (ModuleMessaging and such).

The version is the one included in Orbiter.
From the included readme file:

TransX V3.14.1 for Open Orbiter

TransX V3.14.1
--------------
This is a derived version of TransX that has been included on Open Orbiter. It is a fork from the original TransX 3.13.2 with backports from version V2014.04.26 using only MIT sources and contains no new features.

As some components are not MIT licensed they are not included in this fork, for example Auto-Min™, Auto-Center™ and ModuleMessaging functions are not present in this version.

 

[GLS]

So, this is a mostly final version (in terms of architecture) of the Orbiter User Manual (https://gofile.io/d/aGVNGd), with "only" these issues remaining https://github.com/orbitersim/orbiter/issues/440
I've split the orbital mechanics subsection into a new (full) section (and deleted a mostly duplicate section from Orbiter Developer Manual), and added small sections on the smaller vessels: Solar Sail, Carina and Leonardo. BTW, eventually the Solar Sail could benefit from some work, as the control interface is a bit clumsy, and the roll seems to be coded backwards.

Anyway, I'm now checking the parameters listed in the Orbiter Developer Manual, and probably that will be it, as I don't think there is time do a deep run thru the "how to make an addon" sections.