[WIN/MAC/LINUX] KSP Trajectory Optimization Tool v1.6.10 [Major LVD Improvements!]

[Arrowstar]

2 hours ago, Sppion1 said:

Just saw that --'

I'm afraid this is not the only thing to fix.... Still far away from eve, look a lot more like duna to me...

But just by tweaking time (adding something like 12mns to the maneauver node), I get an encounter of eve. So I get it to work ? Maybe ?

In the orbit display, it's a lot like it jump from one segment to another, with not the same position between all segment, like in the end of the second segment, the ship is close to kerbin orbit, in the third, from beginning to end it is close to eve, while in the fourth it does travel from kerbin to Eve. So did I set patch point right ? Or did I messed up something ?

Still this link, if you want to look at this : https://drive.google.com/file/d/1-z_PtvkVjMEjlSYP-XcsQ3tbenDArjKz/view?usp=sharing

 

I've fixed up your mission a bit.  Here's what I changed:

1. I set the objective function to be maximize total spacecraft mass.  You had it set to minimize, which would try to make the optimizer use more fuel.
2. I set the constraint scale factors.  The position constraints got scaled by 1E5, the velocity constraints by 10, and the time constraints got scaled by 1E6.  This is really important to do in order to make FMINCON work better.
3. I set the Events Plotting Style to "View All" and not "View By SoI Grouping".  This way you can see all events in one go, which is really helpful for these kinds of missions.  You edit this in the View settings.
4. I ran the optimizer (FMINCON) and let it converge, which it did fairly quickly.

Here's your mission back.  Let me know if you can't open it in LVD (if it throws an error or whatever).  I'm using what's basically v1.6.8 pre-release 9, which I would highly encourage you to download and try out if you're not already.

[Sppion1]

5 hours ago, Arrowstar said:

I've fixed up your mission a bit.

Yep, seems a lot better.

2 => I thought those constraints was like :  "position continuity between those events" like "make event x and y have the same position".  So I want to understand : what is the point of the scale factor ?

3 => To make the display with nive curve and not just straight line, all fixes you said was enough ? Or was there another thing to tweak ?

4 => The optimizer is the "optimize mission" in the optimisation menu ? Or I missed something ?

[Arrowstar]

4 hours ago, Sppion1 said:

2 => I thought those constraints was like :  "position continuity between those events" like "make event x and y have the same position".  So I want to understand : what is the point of the scale factor ?

Yes, the purpose of the constraints is to tell the optimizer to achieve particular things about the trajectory while also trying to minimize or maximize some quantity.  The purpose of scale factors is to make the numerical side of the problem easier for the optimizer.  Optimizers like to have objective functions and constraints whose values are between -1 and 1 generally.  (They also like to have variables whose values are between -1 and 1 too, but I actually handle that under the hood without the user needing to worry about it.)  Scale factors work by dividing the actual value of the constraint by that number.  It has the added value of making the value of each constraint roughly the same order of magnitude when the optimizer sees it, meaning that you won't have some constraints be "more important" than others just by virtue of their natural numeric magnitudes (e.g. position vector values are usually a lot bigger than velocity vector values).

Quote

3 => To make the display with nive curve and not just straight line, all fixes you said was enough ? Or was there another thing to tweak ?

Oh yes, I did forget that.  I just set the propagator back to Force Model.  You could achieve a similar effect by setting the integrator output step size to a positive number, maybe 10000 seconds for the longer coast periods.

Quote

4 => The optimizer is the "optimize mission" in the optimisation menu ? Or I missed something ?

Yes, that's the one.

[Arrowstar]

20 hours ago, Sppion1 said:

Still this link, if you want to look at this : https://drive.google.com/file/d/1-z_PtvkVjMEjlSYP-XcsQ3tbenDArjKz/view?usp=sharing

By the way, if you re-download your file that I provided back to you yesterday, you'll see that I've managed to find an even better solution that saves something like 3 mT of propellant.  I did this by:

1. Perturbing the trajectory by 1% or so a few times;
2. Switching the optimizer to NOMAD and letting that run until it had converged on something, more or less; and then
3. Switching back to FMINCON and using the SQP algorithm to get the final trajectory. 

Take a look and let me know if you have any questions.

Edited July 2, 2021 by Arrowstar

[Sppion1]

18 hours ago, Arrowstar said:

Take a look and let me know if you have any questions.

Thanks !!

At the moment I'm good, I'll just play for 24 more days ingame, and I'll rerun all that with the real orbit (time adjusting), to fine tune it. Should be good

Your help and tools are very much appreciated !

[dlrk]

Could someone walk me through planning a polar orbit rendezvous? I'm trying to plan a flight from Kerbin orbit to dock with a station in a polar orbit of the Mun

[Drew Kerman]

On 7/3/2021 at 1:30 PM, dlrk said:

Could someone walk me through planning a polar orbit rendezvous? I'm trying to plan a flight from Kerbin orbit to dock with a station in a polar orbit of the Mun

basic steps for a basic mission:

1. use LVD to design a launch into an equatorial parking orbit
2. use Rendevous Maneuver Sequencer to get an ejection path towards Mun
3. use Mission Architect or LVD to plot remainder of mission:
   1. enroute to Mun, plane change and adjust orbital insertion to match station inclination
   2. enter into Mun polar orbit
   3. use RMS to meet up with station

[Arrowstar]

3 hours ago, Drew Kerman said:

basic steps for a basic mission:

1. use LVD to design a launch into an equatorial parking orbit
2. use Rendevous Maneuver Sequencer to get an ejection path towards Mun
3. use Mission Architect or LVD to plot remainder of mission:
   1. enroute to Mun, plane change and adjust orbital insertion to match station inclination
   2. enter into Mun polar orbit
   3. use RMS to meet up with station

Thanks, @Drew Kerman!  This is basically correct.  @dlrk, if you have any particular questions, please let me know.  Thanks!

[sjsharks39]

@ArrowstarI ended up figuring out the basics! Using Multiple Flyby Manuever Sequencer, in RO, I can get my LV into a desired parking orbit that MFMS plans. I wanted to do an Earth > Venus > Jupiter > Pluto mission. using the correct Inclination and RAAN from MFMS I launched into that exact orbit above Earth, reran MFMS with the newly precise orbit my craft was in, and input the precise burn departure time and orbital/normal/radial burn information from MFMS. Unfortunately the burn got me nowhere near Venus and I had to tweak the burn time significantly from what MFMS gave me for it to get anywhere near Venus, which of course kinda screws up the whole thing. I can try and record a whole video for you if that helps but I hope to have described it well enough here. Can you imagine any reason why there's always a discrepancy between what MFMS gives me for the departure burn time/amounts and the trajectory I end up getting in game?

[Arrowstar]

22 hours ago, sjsharks39 said:

Can you imagine any reason why there's always a discrepancy between what MFMS gives me for the departure burn time/amounts and the trajectory I end up getting in game?

Yep, it's a combination of two things probably:

1. The zero-radius SoI assumption that goes into MFMS and most of the other sort of similar calculations.  Basically, KSP models actual, finite-sized SoIs when the game is running, but MFMS and other similar tools just assume that the SoI radius of Earth is 0.  This simplifies a ton of math but introduces some error; and
2. It's possible that something funny happened with the code that tries to sync up the mean anomaly of your vehicle at the start with the departure mean anomaly to figure out how long to coast before burning.  I would try to hit the departure true anomaly and not worry about the time so much, to be honest.  The true anomaly is going to be more accurate.

If you can create a high-res video that shows what you described, please do!  I'll take a look and see if anything is broken.  Thanks!

[Arrowstar]

This afternoon I've built KSPTOT v1.6.8 pre-release 10.  This is a pretty major pre-release update with the following changes in the change log:

• LVD: Major change to the Set Kinematic State action and the associated GUI.  You can now set the states of the individual vehicle components, including stages, engines, tanks (and their associated tank masses!), electrical powers sources, sinks, and storage (including battery state of charge).
• Astrodynamics Tools UI migrated to App Designer framework
• Edit Event UI migrated to App Designer framework.
• Edit Event UI now has buttons to cycle back and forth through the events list.
• Edit Event Termination Condition UI migrated to App Designer framework.
• Non Sequential Event UI migrated to App Designer framework.

The first bullet point on this list really needs to be checked by more people than me, so if you find any bugs, please let me know!

[Arrowstar]

Hi everyone,

This morning I've built KSPTOT v1.6.8 pre-release 11.  This is a relatively minor update to PR10 that includes some bug fixes and one new feature: LVD plugins can now be used as constraints, objective functions, and Graphical Analysis output.  I'll explain more below, but here's the change log:

• LVD: Plugins can now be used as objective functions, constraints, and graphical analysis output.
• LVD: All UIs should now render centered on the screen.
• LVD: Double clicking an available task in GA now adds it to the list of tasks.
• LVD: Outputting the propagation time to console now includes a breakdown of time needed for propagation and actions.
• LVD: Missing LVD cases don't show up in the recent cases list (File menu) anymore.

This is the last PR before the final v1.6.8 release and I consider this PR to be a release candidate for the full release.  I could really use some help testing LVD to make sure there aren't any boneheaded bugs in it.  If you find any, please let me know ASAP!  Thank you!

So let's talk about using plugins as constraints, objective functions, and as Graphical Analysis output for a bit.  First, how does one go about setting up a plugin for use like this?  It's quite easy really.  Let's start with an example and I'll walk through it.

The code for this plugin is as follows:

%We can use comments in plugin code
if(execLoc == LvdPluginExecLocEnum.BeforeProp)
    kGmu = lvdData.celBodyData.kerbin.gm; %get Kerbin grav parameter
    str = sprintf('This note was set by a plugin.\n\nKerbin GM: %0.6f\n\nPlugin last executed at: %s', kGmu, datestr(now()));
    lvdData.notes = str; %set the string in the notes field
     
    userData = struct(); %create a structure for use with user data
    userData.T = [];
    
elseif(execLoc == LvdPluginExecLocEnum.AfterTimestep && not(strcmpi(flag,'init')) && not(strcmpi(flag,'done')))
    arry = userData.T;
    arry(end+1,:) = [t(1), y(1)]; %add time and first element of state to the user data
    userData.T = arry;
    
elseif(execLoc == LvdPluginExecLocEnum.AfterProp)
    writetable(array2table(userData.T),'test.csv'); %print user data to file test.csv
    
elseif(execLoc == LvdPluginExecLocEnum.Constraint || execLoc == LvdPluginExecLocEnum.GraphAnalysis)
    ue = stateLogEntry.getCartesianElementSetRepresentation().convertToUniversalElementSet().convertToFrame(frame);
    value = ue.c3;
end

In all plugin code, the execLoc variable is used to tell the code where it's being executed.  See the line near the bottom where we test the following: execLoc == LvdPluginExecLocEnum.Constraint || execLoc == LvdPluginExecLocEnum.GraphAnalysis?  That is testing if the plugin is used as a Constraint (or objective function) or as a Graphical Analysis task.

You'll notice that code block creates a value called "value" that is populated by the current C3 value of the spacecraft orbit.  That's the output that will be used as a constraint or objective function or Graphical Analysis output.  To use plugins in this manner, you basically need to populate a variable with the name "value" with some scalar double value.  Note that all data in KSPTOT is in units of kilometers, seconds, radians, and metric tons.

Finally, note that there are two new inputs into the plugin function call to be aware of.  The final two inputs are "stateLogEntry" and "frame".  The first is the relevant spacecraft state that should be used for evaluation.  Basically, if your plugin computes C3 energy like mine does here, then it ought to compute the C3 for that state and that's the value that should be returned.  Frame tells you what reference frame values should be computed in, if it's applicable.

Using plugins in this capacity is just a matter of adding a Constraint or Objective Function of the type "plugin value."  For example:

You'll notice our example plugin is used here by selecting it at the top in the "Plugin" field.  You must have at least one plugin available to create a plugin value constraint or objective function.  Speaking of which, here's that same plugin used as part of an objective function.

Finally, let's talk about using plugins as part of Graphical Analysis.  If you have at least one plugin, you can create a task like this in GA:

When we go to plot that task and compare it to actual C3, we'll see we get the same thing:

This proves that our plugin is working correctly and is providing the same information as the built in data type.  Of course we could have programmed our plugin to provide any data type!  This was just selected as an example.

So what do you think?  Could this sort of functionality be useful to you?  If so, how?  Please let me know, and happy orbiting!

[Arrowstar]

Hi everyone!

This morning I'm happy to announce the release of KSP Trajectory Optimization Tool v1.6.8!  This is a major release that primarily focuses on adding additional functionality to Launch Vehicle Designer (LVD).  A couple of the more interesting new items in LVD are:

• The "Halo Orbit Constructor".  This is a tool that allows users of Principia and other "N-body" gravity mods to generate approximations for halo orbit that can then be easily exported to the rest of LVD for mission design and planning purposes.
• The "geometry system".  This is a component of LVD which allows users to define and work with geometric elements in their LVD scenarios for graphical/view, optimization, vehicle steering, and Graphical Analysis.  You can read more here.
• Celestial bodies can now be numerically integrated.  This is useful when using "N-body" gravity mods such as Principia as they don't use the two-body motion for celestial bodies that stock KSP does.

This release also showcases the migration of many of the KSPTOT user interface windows to MATLAB's new App Designer framework.  Finally, and perhaps most importantly, this release migrates KSPTOT to MATLAB R2021a! 

The new LVD UI in the App Designer framework

Here's the full change log:

• LVD: The function to export a kOS CSV file has been updated to allow users to select the event(s) they want to export.
• LVD: Introduction of the geometry system.  Points, vectors, planes, angles, coordinate systems, and reference frames are now all user definable and can be integrated with views, optimization, and Graphical Analysis.
• LVD: The "launch vehicle" menu is now called "scenario," and the "edit launch vehicle" menu beneath it is now called "edit vehicle configuration."
• LVD: Added three new constraints: ground object elevation, azimuth, and range.
• MA: Mission Animator now properly rotates central celestial bodies.
• LVD: Added a new vector, vector projected onto a plane, to the geometry system.
• LVD: A few bug fixes and performance improvements.
• LVD: T2W throttle model now checks minimum throttle T2W as well as maximum.
• LVD: Sim Driver now warns if integrator output event index (ie) is empty.
• LVD: When editing non-seq events, the event UI now greys out any non-relevant widgets.
• LVD: Added a flight path angle event termination condition.
• LVD: Added a new "vector magnitude" constraint type.
• LVD: Added a new "angle magnitude" constraint type.
• Upgrade MATLAB version to R2021a.
• LVD: Incorporation of surrogate optimizer as an optimization method.
• LVD: New optimizer output for NOMAD and PatternSearch optimizers.
• LVD: Different steering models can be selected for each Euler angle now using the Selectable Model steering mode.
• LVD: All constraints now support the ability to evaluate themselves relative to the value of the same quantity at the end of another event.  This is in addition to evaluating them relative to fixed bounds as well.
• Fixed an issue with importing the UT from KSPTOTConnect into the main KSPTOT user interface (the porkchop plot).
• LVD: Bug fixes to the 3rd body gravity model.
• LVD: Bug fixes to optimizing Cartesian elements.
• LVD: Graphical Analysis is now using the App Designer framework and sports a new look.
• LVD: All fluid types are now their own GA tasks.
• Main KSPTOT user interface window is now ported over to App Designer framework.
• LVD: Constraints and objective functions now are aware of and respect user selected reference frames when evaluating values.
• LVD: Added halo orbit examples.  The L2 halo orbit example is a full mission from low Kerbin orbit to the halo orbit around the Mun!
• LVD: Added third body gravity validator that checks to see if third body gravity sources are active with no force model or if the 3rd body gravity force model is active with no bodies.
• LVD: Extrema, Calculus Calculation objects, ground objects, and geometry objects now respect reference frames when computing their values.
• LVD: View Settings dialog now moved over to App Designer framework and sports a new look!
• LVD: Added Halo Orbit Constructor tool (Tools -> Halo Orbit Constructor menu)
• LVD: Performance improvements to frame conversions.
• LVD: GA task list area now has a search box.
• LVD: Formal continuity constraints are replaced with state comparison constraints for position, velocity, and time.
• LVD: Event termination conditions now have ref frame awareness.
• LVD: Halo Orbit Constructor now shows arrival/departure transfer orbits too.
• LVD: Event actions can now be executed before or after propagation on events.
• LVD: Constraints can now be evaluated at either the initial state or final state of an event.  Same goes for the state comparison constraints and the node of the comparison event.
• Converted a whole bunch of the standalone analysis tools (MFMS, RMS, OTBOC, etc) over to the App Designer framework.
• Celestial bodies can now be propagated using numerical integration in addition to two body propagation.
• LVD: Added an Open Recent Mission item to File menu
• LVD: Migrated main UI and numerous other UIs to App Designer framework.  There are still a number of LVD UIs that still need to be migrated, but this is a start.
• LVD: Plotting state logs should now be a bit faster due to updated frame rotation behavior.
• Added UI progress bars when opening all tools from main KSPTOT UI.
• LVD: Major change to the Set Kinematic State action and the associated GUI.  You can now set the states of the individual vehicle components, including stages, engines, tanks (and their associated tank masses!), electrical powers sources, sinks, and storage (including battery state of charge).
• Astrodynamics Tools UI migrated to App Designer framework
• LVD: Edit Event UI migrated to App Designer framework.
• LVD: Edit Event UI now has buttons to cycle back and forth through the events list.
• LVD: Edit Event Termination Condition UI migrated to App Designer framework.
• LVD: Non Sequential Event UI migrated to App Designer framework.
• LVD: Plugins can now be used as objective functions, constraints, and graphical analysis output.
• LVD: All UIs should now render centered on the screen.
• LVD: Double clicking an available task in GA now adds it to the list of tasks.
• LVD: Outputting the propagation time to console now includes a breakdown of time needed for propagation and actions.
• LVD: Missing LVD cases don't show up in the recent cases list (File menu) anymore.
• Numerous bug fixes and performance enhancements, especially in LVD.

NOTE: If you are upgrading from KSPTOT v1.6.7 or earlier, you MUST download the R2021a MATLAB Compiler Runtime (MCR)!  KSPTOT v1.6.8 will not run without this!  You can find the R201a MCR download for your platform here: https://www.mathworks.com/products/compiler/matlab-runtime.html

Finally, if you enjoy using KSPTOT and its many applications (the Porkchop Plotter, Multi-Flyby Maneuver Sequencer, Mission Architect, Launch Vehicle Designer, and all the rest), please consider buying me a coffee via my Ko-Fi account to support KSPTOT's development. As I note in the first post of this thread, KSPTOT is a labor of love that I have put many, many hundreds of hours into for the benefit of the KSP community. The best part of it for me, aside from knowing that KSPTOT is the premier mission design tool for KSP, is all the thank you notes I've received over the years. I offer this as another way to say "Thank you!", if you so desire.

As usual, the release can be downloaded from the first post of this thread. Please let me know if you have any questions or find any bugs. Thanks, and happy orbiting!

Edited August 20, 2021 by Arrowstar

[Arrowstar]

By the way, everyone, I should mention that it's likely that we won't spend a lot of time on MATLAB R2021a.  I've gotten a chance to play with the R2021b pre-release in a professional environment and there are some enticing new functions and functionality that I think I might want to bring into KSPTOT, especially Launch Vehicle Designer.  I don't think I can say what right now (pre-release NDA) but when it releases next month I'll have a better idea of if it will be worth it.  Stay tuned.

Edited August 20, 2021 by Arrowstar

[Razgriz1]

The new Graphical Analysis task system is so nice! Also App Designer FTW! I've been migrating some of my tools at work to the App framework and its very nice.

I am seeing a strange bug with adding engines to the LVD though. I haven't tried the last few release candidates so I'm not quite sure quite when it started. I've raised the issue on GitHub.

[Arrowstar]

17 hours ago, Razgriz1 said:

The new Graphical Analysis task system is so nice! Also App Designer FTW! I've been migrating some of my tools at work to the App framework and its very nice.

I am seeing a strange bug with adding engines to the LVD though. I haven't tried the last few release candidates so I'm not quite sure quite when it started. I've raised the issue on GitHub.

I believe I've fixed the issue and have uploaded the new executables.  Can you go to the first post and re-download KSPTOT from the link there?  Once you've done that, please let me know if that resolves your issue.  Thanks!

[Razgriz1]

3 hours ago, Arrowstar said:

I believe I've fixed the issue and have uploaded the new executables.  Can you go to the first post and re-download KSPTOT from the link there?  Once you've done that, please let me know if that resolves your issue.  Thanks!

That looks to have fixed it 

[Arrowstar]

Just now, Razgriz1 said:

That looks to have fixed it 

Thanks for the report!

[Razgriz1]

Another couple of bugs 

• Attempting to add a new sequential event while having anything but the first event selected deletes all events and adds the new event in place of the first event
• None of the events can be edited. The UI opens up, but the changes are not saved. The error thrown in the log looks to be pretty much the same as the one from the engines issue I posted about
• Events cannot be deleted, and the 'Delete Events' button is greyed out. Saving and reopening the mission file allows events to be deleted, but only until one of the above actions is attempted
• Editing an engine that already has a tank connection defined causes extra <that engine to tank> connections to appear in the connections list. Once this happens, the connections can't be deleted.  Deleting the engine does remove the connections.

Looks to be a similar issue to the engine thing I saw earlier.

 

[Arrowstar]

29 minutes ago, Razgriz1 said:

Another couple of bugs 

• Attempting to add a new sequential event while having anything but the first event selected deletes all events and adds the new event in place of the first event
• None of the events can be edited. The UI opens up, but the changes are not saved. The error thrown in the log looks to be pretty much the same as the one from the engines issue I posted about
• Events cannot be deleted, and the 'Delete Events' button is greyed out. Saving and reopening the mission file allows events to be deleted, but only until one of the above actions is attempted
• Editing an engine that already has a tank connection defined causes extra <that engine to tank> connections to appear in the connections list. Once this happens, the connections can't be deleted.  Deleting the engine does remove the connections.

Looks to be a similar issue to the engine thing I saw earlier.

Thanks for the report.  I think I've got all of them fixed and I'll get a new build out ASAP.  Turns out they were pretty straight forward.

[Arrowstar]

1 hour ago, Razgriz1 said:

Another couple of bugs 

• Attempting to add a new sequential event while having anything but the first event selected deletes all events and adds the new event in place of the first event
• None of the events can be edited. The UI opens up, but the changes are not saved. The error thrown in the log looks to be pretty much the same as the one from the engines issue I posted about
• Events cannot be deleted, and the 'Delete Events' button is greyed out. Saving and reopening the mission file allows events to be deleted, but only until one of the above actions is attempted
• Editing an engine that already has a tank connection defined causes extra <that engine to tank> connections to appear in the connections list. Once this happens, the connections can't be deleted.  Deleting the engine does remove the connections.

Looks to be a similar issue to the engine thing I saw earlier.

 

Alright, go ahead and re-download from the first post again.  Let me know if that fixes the issue.  Thanks!

[Razgriz1]

On 8/27/2021 at 9:29 PM, Arrowstar said:

Alright, go ahead and re-download from the first post again.  Let me know if that fixes the issue.  Thanks!

Yep that seems to have done it! Thanks for your quick turnaround with these fixes. I absolutely love this tool and am glad to see that you're still improving it!

[Arrowstar]

6 hours ago, Razgriz1 said:

Yep that seems to have done it! Thanks for your quick turnaround with these fixes. I absolutely love this tool and am glad to see that you're still improving it!

No problem, glad everything is working better now.  Thanks for the bug reports.

[Arrowstar]

Alright, feature question for you all.  Would anyone get any use out of being able to model spacecraft sensors in Launch Vehicle Designer (LVD)?   I'm thinking things like cameras, x-ray telescope things, and the like. The idea would be that a sensor would be fixed to the spacecraft.  Users could create sensor targets (either single points or lat/long grids on/above the surface of a celestial body) and Graphical Analysis could tell you when a target is in view and (for grids) how much of the grid has been viewed by the sensor over the course of the simulation.

Some use cases I've come up with include:

• How much of that celestial body can I scan (think Scan Sat or similar mods) with a given sensor and orbit altitude in a given time?
• How often can I see a comm relay?
• For people who use that weapons mod, maybe there's a laser lock application?

So a few questions.  First, would anyone actually use something like this when they play KSP?  Be realistic, as this could potentially be a lot of effort.  And second, are there any other uses you can come up with that you might want to be able to do with this sort of functionality?

For the visually minded, here's a concept of what it might look like in the display.  Red sphere is the planet, green cone is the sensor field of view, and the green dots on the surface represent surface points the sensor can see.  What do you all think?

[Arrowstar]

Hey everyone,

Tonight I've built KSPTOT v1.6.9 pre-release 1.  This update is more or less purely cosmetic in that it finalizes the conversion of KSPTOT over from the old "GUIDE" UI framework to the new App Designer framework.  Here's the change log:

• Converted all remaining maneuver planning tools to App Designer.
• Converted all remaining Launch Vehicle Designer UIs to Ap Designer.
• Converted a few misc UIs to App Designer.
• A few minor bug fixes.

Note that Mission Architect and the KSPTOT Real Time System (RTS) UIs will not be ported over to App Designer, at least not at this time.

If you're running the KSPTOT v1.6.8  release, could you please update to this new PR?  It's functionally identical to 1.6.8, and I could use some help with testing the new UIs since as we've seen they are not always bug free.

Please let me know if you find any bugs, and happy orbiting!