Set Descent Profile Settings from VAB/SPH

[DBooots]

The TrajectoriesVesselSettings part module could be made to have a context menu button when in the editor that would allow setting the descent profile from the editor that would then persist into launched vessels of that type.

This could even be done on a per-command part basis (for example, a dreamchaser-type vessel where the top re-enters prograde and the reusable booster re-enters retrograde). Since the Descent Profile fetcher looks for FirstOrDefault it would find the appropriate one on each of the two component vessels after stage separation. *Note that any changes afterwards to the descent profile in the flight settings window would overwrite all of these in the DescentProfile.Save() method.

[DBooots]

Recommend adding the 'Enhancement' label.

I'll give this a shot and hopefully have a pull request ready in time for the inevitable 1.4.1 compatibility update. ;)

[neuoy]

You are welcome to give this a shot, but I'm not sure it will work to set different settings on each command module. If I remember correctly (but it's been a long time now), settings are written on all command modules of the current vessel while in flight, so that when parts are detached, they keep a copy of the last used settings. But if it causes issues with what you want to do, this behavior can be changed of course.

[PiezPiedPy]

neuoy is correct, if settings are to be set in the VAB/SPH they will apply to all control modules on a craft.

[DBooots]

I'd say only sort of correct. The values in all TrajectoriesVesselSettings are currently only set when DescentProfile.Save() is called. From what I can tell, this is only called when the current DescentProfile is modified. So the settings set in the editor would persist until the user modified something in the GUI in flight. Reading through the initialization process, it looks like it pulls the settings from .FirstOrDefault() and doesn't then re-Save them. So the window will have the primary one and the rest would have their values from the editor unless the current settings are changed. So when parts are detached they'll keep a copy of the last used settings unless they have a command source with saved settings AND the main settings have not been changed since launch.
I'm working on this right now, so I'll keep you posted. If I'm wrong, there could also be an option to tell it to resist changes in flight once it's set in the editor unless it is the primary module.

[PiezPiedPy]

I was assuming in my reply that you would be using DescentProfile.Save() to store the settings.

If you are going to save the settings in a different manner then what you say will be correct.

May I suggest you start a branch for your commits in your fork so we can be nosey parkers and watch the development 😜

[DBooots]

I made a branch and threw in a commit. The GUI doesn't show up like I thought it should, but I'm sure that's just a minor bug. Also, my GUI code is super ugly and could certainly be made better (I was trying to hack something together from what you already had).

I'm just saving the settings directly in the PartModule of the part whose context button was clicked. This will then save through the stock persistence ConfigNode saving system. I'm also setting the Initialized field to true so that it doesn't get set to defaults when first seen by the plugin in flight.

[PiezPiedPy]

Sweet, I'll have a look later tomorrow, 12:30am here in the UK, time for bed ⏲

KSP's popup dialog system is a pain to work with, many a time I wanted to wring its neck lol, have fun.

[DBooots]

DBooots@e90c383 works. Sort of. The Localization in the Editor GUI doesn't work for some reason and I can't drag the windows around, but the changed settings do persist into flight.

For testing, I added a probe core to the first stage of the KerbalX stock craft, set it to re-enter prograde and the capsule to re-enter retrograde. Sitting on the launchpad, the GUI shows the retrograde setting (makes sense, since the capsule is the root part and thus, first found). After staging, the capsule still shows retrograde but the first stage shows prograde.

In the update to 1.4, we should see if we can select the settings in the same order as the naming/icon priority order that they added.

[DBooots]

Just following up on this. If you're putting out a new release for 1.6, might I suggest this as a relatively easy enhancement to roll into that?