Flight Wrong orbital elements on hyperbolic trajectories

[schlosrat]

I've noticed that in some cases the orbital information associated with the active vessel's current orbit is just dead wrong. This is bizzare, and I'm not sure if it's related to the 0.1.2 patch, but I only just noticed it and hadn't checked for it previously in 0.1.1 or before. Here's an example of a craft on an obviously hyperbolic flyby trajectory about the Mun. I'm using the Maneuver Node Controller mod to be able to see some of the orbital elements for the active vessel, but this is just displaying the information that's in game, not computing anything.

In this example, we see the craft with a Pe of 163km and yet e = 0.966? That simply can't be true as for any hyperbolic orbit the e > 1

 

By burning prograde and raising my Pe I can get to a different hyperbolic flyby orbit where e is correctly > 1 (not claiming e is correct, merely that it being >1 is correct...)

 

The mod I'm using is simply obtaining and displaying activeVessel.Orbit.eccentricity, so apparently the game is incorrectly setting the orbital parameters for the active vessel's current orbit in some cases.

Edited April 13, 2023 by schlosrat

[Dunas Only Moon]

Very odd... 

[schlosrat]

Perhaps related to this, the info displayed below the Nav Ball for Ap and Pe conflict with what's shown on the orbit's Pe tag, and there is no Ap tag on a hyperbolic orbit (which is a good thing!). The orbit's Pe tag agrees with the activeVessel.Orbit.Periapsis, and clearly a hyperbolic orbit should have a negative Ap - so the Nav Ball info is wrong even in this case where e is > 1. I suspect the topic should be changed to be: Wrong Orbital Elements on Hyperbolic Orbits

Curiously, the Nav Ball is showing the Pe that was true PRIOR to the burn I made to raise Pe! In the shot above (game paused, but post burn) the Nav Ball reported Pe is 163.410 km. In the first shot way above the Pe was reading out as the same value! So I ran the game burning prograde to raise my Pe, and at the end of that burn (throttle is zero above and I'm coasting) the Nav Ball has the Pe from before the burn.

There is clearly something wrong here!

Edited April 13, 2023 by schlosrat

[schlosrat]

@Dakota I wanted to call this to your attention. It would seem there's something really wrong in patch 0.1.2. There are also a lot of things really right, too; but I want to make sure you guys are aware of this so you can investigate.

Are you guys already aware of this? It seems really serious to me and may have far ranging consequences.

Closer inspection gives this clue. In the first image you can see that MNC reports the Pe as 163.410 km. That's the Pe before my burn. In the next image, the MNC Pe is reported as 246.611 km, which corresponds to what the KSP2 orbit PE tag shows, but the Nav Ball's reported Pe is 163.410! So, after having performed a seat of the pants burn (point prograde, press Z, wait till happy, press X), the Nav Ball is showing the pre-burn Pe.

I suspect that the activeVessel.Orbit info is holding the previous orbit's info, so this may not be limited to hyperbolic orbits as I originally assumed. I suppose I may have entered the Mun's SOI on an orbit with e = 0.966 and Ap 20,956.126 km, which was then being reported by activeVessel.Orbit as the current info. Then I performed my seat-of-the-pants Pe raising maneuver and I find that e = 1.056, Pe is what it was before the burn, and Ap is at least negative as it should be.

I'm willing to bet that my mods are not the only thing in the game relying on activeVessel.Orbit to have the correct current orbit info. I would not be surprised to find that IG uses that info in lots of places. If it's stale, as I now suspect, you're going to have all sorts of issues popping up all over the place.

Edited April 13, 2023 by schlosrat

[schlosrat]

Scratch the previous hypothesis. I went back to my save where I entered the Mun's SOI and played around with small seat-of-the-pants burns (no node), and a small burn using a node (in case the creation/deletion of the node had anything to do with it). Turns out, nope. But if I burn gently prograde and watch e (via either MNC or Micro Engineer, they report the same info) then it goes > 1 at about a Pe of 199km as shown here. Once the e goes above 1 then things look OK (though they didn't in the shot above).

Not sure now what's going on, but there are at least some conditions where the activeVessel.Orbit info is demonstrably wrong. I can supply a save file if you like.

Edited April 14, 2023 by schlosrat

[schlosrat]

Further inspection shows that the information being delivered for the orbit in the post-burn patch is actually the orbit info for the orbit you'll have once you leave the SOI you're in. So, if you're on a hyperbolic flyby orbit, then you will certainly be leaving the SOI at the end of your current patch. If you have a maneuver node to modify your flyby, for example to adjust your closest approach or change your inclination, then the information for the orbit you'll have after the burn is being set to the orbital info for your trajectory when you leave the SOI you're in.

[LeroyJenkins]

33 minutes ago, schlosrat said:

Further inspection shows that the information being delivered for the orbit in the post-burn patch is actually the orbit info for the orbit you'll have once you leave the SOI you're in.

This makes me wonder how the activeVessel.Orbit data is organized and tracked for each patch. It would be good to be able to know which patch pre or post maneuver, and now inner SOI and after leaving SOI the current values are for. KSP1 had this a bit better organized in the orbit parameter readout, in the lower left hand corner of the UI, and one could select which parameters (before or after maneuvers). This would help with understanding the values when doing a gravity assist fly- by orbit planning.

 

Edited April 16, 2023 by LeroyJenkins

[schlosrat]

Yeah, it definitely seems odd in how its organized internally - perhaps due to the lack of docs for such things. It’s pretty easy to get a list of all the patched conic sections associated with the active vessel, and patches have links for the next and previous patch, but when you go trolling through the data you find there’s the current patch (which has info for when you leave the current SOI), but the patch that’s prior to that one has nulls for all the info fields. So where does the info come from that the map is displaying? Could this have something to do with the bug where we can’t get accurate return trajectories?

[schlosrat]

Well, this is embarrassing...

On further investigation the tools I was using to observe the orbital elements were looking in the wrong place. Apparently what I've observed and reported is not a bug, but an aspect of a design decision that results in a fairly confusing way to store this information. One might *think* that since you can ordinarily get the orbital elements from the active vessels's Orbit class, then that would be to place to look for them when you're on a flyby, but apparently not. The correct information is in there, it's just really confusing and obscure to find it.

I retract my bug report. Sorry for the confusion.