Strangeness at Gilly. Also execute next node takes excessive time to turn off

[richardemaine]

There's lots of strangeness apparently specific to Gilly. Been so for a long time and I tend to just work around them, but decided to finally submit an issue for one. In this case, telling maneuver planner to change inclination to 90 at the cheapest AN/DN crossing results in a maneuver that throws us onto an escape trajectory out of Gilly (granted that doesn't take a lot). Deleting all nodes and telling it to change the inclination at the nearest (instead of cheapest) crossing gives a reasonable maneuver. KSP 1.12.5 and McJeb dev 2.14.3.0-1355. Liink to Player.log attached (if I managed to do that correctly). BTW, this log doesn't show it, but I've long seen oddities with McJeb landing guidance land at a target on Gilly. It gets to about the 500 meter point and then keeps figuratively bouncing up and down around that forever; I tend to work around that by aborting the autoland at a point and then telling it to just land somewhere, which then works ok (or I just forget about autoland at Gilly as it's pretty trivial to do manually). Anyway, back to this log file. It also shows a phenomenon new to very recent dev versions that's had me downgrading because it hits pretty much every execute next node (which I use a LOT - not just at Gilly). After executing a node, it just sits there at 0 meters/sec remaining for so long it almost seems hung; wait long enough and it eventually ends. This log file should show that after the "good" inclination change, which I went ahead and executed.https://www.dropbox.com/scl/fi/nxfag6bt9wph9mfmie3rn/Player.log?rlkey=5m2qysptmtnqf0hfcbukpvsc1&dl=0

[lamont-granquist]

• That's the Player.log not the KSP.log, the latter is the useful thing.
• Not surprising landing guidance is useless on Gilly, its very well known that MJ Landing guidance is poor and needs a complete rewrite.
• The behavior of the maneuver planner doesn't really make any sense, I can't see the bug in the code -- the value returned by the time selector is being used to compute the maneuver and place the maneuver node. and if it works for "nearest" it should work for "highest/cheapest".
• I can't really parse the issue with the node executor.

[lamont-granquist]

Is the problem with the node executor that the dribble-throttle code dribbles down to effectively zero before the node has made a 90 degree angle with the ship (so the blue circle is still visible somewhere in the forward hemisphere on the navball?)

[richardemaine]

Ah. Sorry about the wrong log file. I get confused about which to use as I can't make much sense of either one. Have since overwritten the file from that instance, but I here's another. I'm not overly excited about the Gilly stuff. I can work around it and I don't tend to be at Gilly much anyway (though this playthrough I'm trying to make a base there as a staging point for going to moho with a lot less dv than from Kerbin). But the node executor thing is a serious drag. No, the blue circle (well, crosshatch) is not in the forward part of the navball. There's a blue pointer to its presumed location elsewhere and that pointer wanders all around. I'd think it of particular note that it always shows a remaining burn time on the order of 4 days while this is happening. Anyway, for the attached ksp.log, I started at a circular orbit around 62 km up. Asked for a change inclination to 45 at cheapest point. The resulting burn would have (according to precisemaneuver - love that mod) taken me to an orbit with periapsis 12, apoapsis 112, and inclination 107). Deleted that node and asked for the same thing at nearest point, which gave a fine maneuver. Executed that maneuver ok, except for the usual excessive ending. https://www.dropbox.com/scl/fi/dv9ycu0ulfejm0ervfmex/KSP.log?rlkey=bx2evunoixcz1eudi79yfse7d&dl=0

[lamont-granquist]

No, the blue circle (well, crosshatch) is not in the forward part of the navball. There's a blue pointer to its presumed location elsewhere and that pointer wanders all around. I'd think it of particular note that it always shows a remaining burn time on the order of 4 days while this is happening.

That still isn't really computing in my brain. Unfortunately I don't think the node executor logs anything particularly useful so the KSP.log won't help at all.

Screenshots might help, video would certainly help.

[richardemaine]

Took me a while to figure out how to capture a video. Not much into that and have literally never done so before. Turned out I had the game bar thing in windows turned off. Anyway, here's a short video of executing a trivial maneuver to add 1 m/s prograde to a probe in mun orbit. Maneuver is fine; end is a bit long and wild. https://www.dropbox.com/scl/fi/v1z7txk9ul73gk774zu1k/Kerbal-Space-Program-2023-11-22-19-02-13.mp4?rlkey=ad3pstr4tvuq60o6c7li9jqtm&dl=0

[lamont-granquist]

Is it firing RCS and trying to ullage or is it actually using the engines?

[lamont-granquist]

oh nevermind, i can see the engine throttle up a tiny bit.

[richardemaine]

Engines. I don't have any RCS on it.

[richardemaine]

Ah. New data. I'd stopped playing for a while because I found the issue with node execution so annoying. Happened for literally every node. Decided to try again today with latest dev version. Issue still there, but I noticed a lot of comments here about RCS. I basically never have RCS on my vehicles (unrealistic, I know). Tried adding some. Bingo. If I add RCS jets (and some fuel for them), all works much better. Seems like the node executor really wants to use RCS for the last bit, and things don't go well if there isn't any RCS available. Ok, well I can now work around that; I just need to start including some RCS jets. But also that might give you a hint about how to keep the problem from happening.

[lamont-granquist]

1878 should help with that

[richardemaine]

Yep. Looks much better. Based on a very limited test, running the same maneuver before and then after applying the update. But considering how pervasive the problem was before, I think that's enough data. Thanks.