Arrowstar

Hi there! There isn't a manual, but I can get you started: Open up KSPTOT and use the Tools -> Maneuver Planning -> Multiflyby Maneuver Sequencer menu item. This will open up MFMS. First thing I would do is just tap "Compute Flyby Maneuver Sequence" and watch the application go. Take a look at the data it gives you (all of the orbits plus maneuver data). From there, start playing with the waypoints list on the left. There are no hidden menus or anything in MFMS, so what you see is what you get. It's very straightforward once you've spent a bit of time with it. I will warn you up front that this is only going to get you 95% of the way there, though. The zero-radius SoI assumption that tools like MFMS (and similar tools in other mods) use does not account for the patched conics system that KSP uses. The maneuver plans you get out of MFMS will therefore bit a bit off. You'll need to hand tune them a bit in KSP with the maneuver nodes. If you are actually after high-fidelity mission planning then Launch Vehicle Designer is your best bet, but LVD is far more difficult to pick up and use. Master MFMS first and then give that a try. Give me a shout here in this thread if you have any questions or problems!

Hi everyone, Tonight I've built KSPTOT v1.6.8 pre-release 8. This is a pretty big update with a fair number of new things. Here's the change log: LVD: 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. The last two of this list are the most critical. First, if you regularly use any of the Maneuver Planning tools or the Vehicle Sizer tool in KSPTOT, please give them a shot in this PR and help me make sure that the migration to the new App Designer framework went as planned. Second, yes, you read correctly: KSPTOT can now numerically propagate the motion of celestial bodies in addition to the normal "two body" method of computing position and velocity (the latter is how KSP works). Why would we want to be able to do this? Well, if you use Principia or any other n-body motion mod for KSP, then the two body motion dynamics will not hold up. This functionality is what you'll need to use instead. There are a few tricks to getting this to work, though. First, there's a new entry to each body's information in the bodies.ini files: propType This parameter can take one of two values, as explained at the top of the default bodies.ini file: propType = analytic_two_body propType = numerical_integration The default, "analytic_two_body" behaves as KSP expects it to. The second one enables numerical integration of the equations of motion for that body. You can do this on a per-body basis, but the recommendation is to set all bodies to one or the other. What happens when you do this? Well, it would be too CPU intensive to compute the position of the body at every time its needed everywhere in KSPTOT, so upon starting KSPTOT or loading a bodies.ini file with a celestial body that is using numerical_integration, KSPTOT will create a "state cache" where it propagates the states of all numerically integrated bodies and stores them. Splines are then used to fit the data later for rapid calculation of position and velocity at any arbitrary point within the bounds of the state cache. The default state cache bounds start at UT = 0 sec and end at UT = 100 (Earth) days. Trying to get a state for a numerically integrated body outside of these bounds will throw an error. So what happens if you want to go beyond 100 Earth days? Fortunately there's a solution! A new tool will allow you to set the bounds of the state cache. This tool is available in two different places right now. The main KSPTOT UI: Edit -> Configure Celestial Body State Cache Launch Vehicle Designer: Settings -> Configure Celestial Body State Cache The tool is also required to be accessible in LVD because the celestial body data there is likely not the same as what's in the rest of the application, particularly if you have just loaded a mission case from disk. So if you get an error telling you that you need to adjust your state cache bounds, you can use this tool to do so easily. Finally, you can tell if a particular body is integrated or uses two body motion by opening the Celestial Body Catalog (now also available from the main KSPTOT UI). I think that's it for now! Any thoughts or questions? Happy orbiting.

Hi everyone, I want to introduce a few new features in Launch Vehicle Designer. First, the paradigm for event actions is changing a bit. As many of you know, event actions occur after the event has finished propagating. However, I have made a modification which enables the user to select which side of propagation the actions should occur: before the start of propagation or after it (the current behavior). The default selection for this is the current behavior, "Execute Actions After Propagation." Existing mission plans therefore should not require updates. Hopefully this will provide a bit more flexibility. As an example, in the past when a Set Kinematic State action was used it was necessary to make that action a zero duration propagation and then begin propagation from the new state in a new event. This is no longer necessary, since you can execute the Set Kinematic State action prior to propagation now. The next feature I want to present is the new ability to evaluate constraints at either the start or end of an event. You'll notice two new line items in the Edit Constraint dialog "Event Node" and "Comparison Node." This allows you to select if you want to evaluate the constraint at the final state (after propagation and actions) or the initial state (before propagation and actions). Uses for selecting initial state generally include comparing state parameters between the start and end of an event. The current behavior of grabbing the final state for a constraint is the default behavior so no updates should be necessary to existing mission plans. Let me know if you have any questions, and happy orbiting!

Thank you! Halo orbits have been a point of personal and professional curiosity for me for some time now, and so I sat down to learn a bit about them recently. I'm glad the new tool worked out as well as it did! It doesn't take all of the work out of planning halo orbit missions, but it does make it a lot easier to get started, and that's what I was after. If you have any thoughts on how it could be improved, please let me know.

Hi everyone, Tonight I've built KSPTOT v.1.6.8 pre-release 7. This is a fairly large pre-release with a number of new features. Here's the change log: 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. Let's talk about the Halo Orbit Constructor tool for a moment! This is the new big feature I've been working on and will be very handy to those using Principia (or other n-body gravity mods for KSP). Halo orbits are a special kind of orbit that only appear in the circular restricted 3 body problem. They have a lot of special uses, but in general, you can think of them as orbits that are designed to stick around Lagrange points, or points where gravity between two celestial bodies sort of "balances". We see a few things here. Halo orbits are always constructed around a primary body and a secondary body that orbits it. In this case, I've selected to create a halo orbit near the Kerbin-Mun system. The Libration point (or Lagrange point) is the location around which the halo orbit will be closest. L2 is on the far side of the Mun from Kerbin. L1, the other option, is on the near side of the Mun. The "Z Amplitude" is an estimate of the height of the halo orbit above the plane of the Mun's orbit around the Mun. That "height" can be positive or negative depending on if you select a Northern or Southern sense. The differential corrector parameters allow you to adjust how the orbit is solved for. The Step Size Factor is used to provide numerical stability at the cost of longer computations. The smaller the number (> 0), then slower the code will run but it should not diverge as frequently. The Coordinate to Adjust defines which part of the initial estimated position vector the solver will adjust to compute your halo orbit. You can get very different results by changing this parameter. On the right you'll see the completed calculation results displayed. The blue line is the approximated halo orbit (derived from something called Richardson's 3rd Order method), the yellow line is what would happen if we propagated the approximated halo orbit directly, and the green line is the final result after using the differential corrector to make the orbit periodic. The green line is the final product of the calculations. On the results tab we have the initial state of the halo orbit you can use in LVD along with instructions on how to use it properly. Basically you can use it as an initial state or put it into a Set Kinematic State Action and away you go. You will need to do a bit more optimization with an LVD optimizer to get an actual periodic orbit, but it's not too hard if you follow the instructions. And if you do, magical things like this are possible: This is a full up mission to a halo orbit from LKO. You can see the green initial orbit line around Kerbin, the cyan coast out to the Mun, the blue Munar flyby orbit, and the orange halo orbit. The halo is actually moving clockwise and so the spacecraft turns around a bit down at the apoapsis, but that's okay. And where did the idea for this mission profile come from? NASA, of course! Check out this image that they're using for getting out to the Moon. Look familiar? Happy orbiting everyone! Feedback on the PR7 release is highly sought, especially for all the new bits that use App Designer now as well all the new items in LVD using reference frames. EDIT: PR7 download link now available!

Did anyone order a Near Rectilinear Halo Orbit? A while back I mentioned that I had fixed the 3rd body gravity model code in LVD. The past few days I've been working on a new tool within LVD called "Halo Orbit Approximator" which will allow users to construct these orbits fairly easily. It's not ready to be shown yet (I only have code now, no UI), but I should be able to get it into the next pre-release. I'm not sure how many people here use the Principia mod for KSP (the n-body gravity mod), but if you do, I would certainly appreciate real feedback from this new tool!

Hey everyone! Last week I found a pretty serious bug in the 3rd body gravity model within LVD. I fixed the bug and I'm happy to report that you can now create those fun halo orbits and the like in KSP, as if you were using Principia (for example). Happy orbiting!

Hi everyone, Tonight I want to share some changes that are coming to Launch Vehicle Designer's Graphical Analysis tool. This is the system in LVD that lets users extract data from an LVD mission, plot it, and export it to CSV files. As usual, the easiest way to start is to just show how things look now. There are two new elements to this system. First, you'll notice on the left a list of Tasks. These tasks are what GA will execute when you tap the "Plot Graphical Analysis Tasks" button on the bottom. Each task line item has two parts: the name of the task and the associated reference frame. This brings me to the second new element. Each task now has a reference frame associated with it. What this means is that if you want to compute, for example, the position of your spacecraft in any available reference frame, you can do it. That's what's shown in the example above. Here I'm outputting the position of the vehicle in the Kerbin Centered Inertial frame as well as the Kerbin-Mun two body rotating frame. Most tasks respond to the reference frame at this point. Right now, the two still outstanding on my list are related to extrema values and calculus values. There are some peculiarities with these two so I'm still considering how I might go about it. Critically, though, anything associated with vehicle kinematics (position, velocity, and all Keplerian, Geographic, and Universal Elements, plus related quantities) now handle GA task reference frames correctly. This means that if you want to output SMA in a rotating frame, or longitude in an inertial frame, you can! It might not make any sense, but you can. Of course, some tasks are frame independent. The density of the atmosphere does not care about what frame it's in, for example. All of the usual buttons and check boxes and inputs from the original LVD GA are still there, of course, just on the right instead of the left. They all work the same way they did before. Lastly, you might notice that the appearance of this UI looks a bit different from before. I've migrated this UI over to MATLAB's new (sort of) UI system, App Designer. The old system, GUIDE, is going away at some point in the future, so presumably at some point every UI in KSPTOT will get this treatment. I'm starting with simple UIs that have no outputs, since that actually doesn't work yet (MATLAB doesn't allow UIs in App Designer to return values yet, ugh!). I expect the main KSPTOT UI (the porkchop plot) and many of the single UI, standalone tools will get this treatment for the next version too. Mission Architect will likely not be updated in this way. It will still run, of course, no worries there, it will just be a bit harder to update in the future if I need to. Please let me know if you've got any questions! Happy orbiting.

Hi everyone, I decided to get out the v1.6.8 pre-release 6 build earlier than I thought I might. Here's the change log: 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). Please let me know if you find any bugs, especially with the two new features as they are certainly experimental at this point!

Looks like I missed one. I have fixed it and I'll try to put out a PR6 with it fixed tomorrow. Thanks for the report!

Hi everyone, I have another KSPTOT update I want to share this evening. Coming to LVD in the next pre-release is going to be the ability to set constraints to not only fixed values and bounds, but also to an equivalent value in another event. Here's what I mean. Note the new "evaluation type" drop down menu is set to "state comparison. In this mode, the quantity to be constrained (here, delta-v expended over an event) at the end of Event 1 will be compared to the delta-v expended over Event 2. The constraint is satisfied when the two values are equal (in this case). You can also set the constraint to be satisfied when the quantity in Event 1 is greater than or less than that of Event 2. Let's take a look at an example of how this works in practice. In this example, I have three burn "parts." The first two burn prograde and the third burns retrograde. I want the expended delta-v in the first segment to be exactly 0.05 km/s, and I want the delta-v in the second segment to be equal to exactly that. In the third segment, I want to return the SMA back to what it was at the start of the mission, 700 km, by burning retrograde. Notice that when states are compared instead, new tooltip text appears that shows you which state the constraint is using for comparison (always the last state of an event, same as with bound constraints). It also shows you the value of both quantities at the end of their respective events and indicates how the comparison is being done (equals to, greater than, or less than). What do you all think? Happy orbiting!

Hi everyone, I know there's been a bit of a break in KSPTOT development over the past month or two, but tonight I want to share a neat feature update for Launch Vehicle Designer. To date, all steering models have been pretty fixed in their format. For example, if you select polynominal steering, then everything is going to be a polynomial. If you select linear tangent steering, then pitch is linear tangent and everything else is polynomial. And so on. This has always bothered me a bit, and so tonight I have the solution: selectable steering models for each Euler angle. Right now I have all three major steering model types implemented: polynomial, linear tangent, and sum of sines. The fourth, attitude interpolation, needs to stay it's own thing because it relies on controlling all three angles directly. As you can see here, you can now set roll to use a linear tangent law, pitch to use sum of sines, and yaw can be a polynomial. In addition, the polynomial steering has gotten a lot more flexible (for this application - the old three term steering is still there if you select it). You can now create as many terms as you want and optimize their coefficient and exponent directly. See here: In this case, this is a linear function that varies the angular rate at 2.0 deg/s. I know it's linear because the exponent is 1.0 and I know the rate is 2.0 deg/s because the coefficient is 2.0. You can also have non-integer exponents, negative exponents, and all that. It's pretty cool! Because this supersedes the sum of sines steering model that I had in there directly, I'm going to be turning off the ability to select that option in the next pre-release. Instead, to get to this UI, you select the "Selectable Model" steering model in the list box prompt. Please let me know if you have any questions!

Issue has been resolved and I've updated the v1.6.8 PR5 download with the updated executables. Thanks for the report!

Do you have a copy of MATLAB R2017b or R2021a for MacOS?

The person who volunteered to build the MacOS version for me has not been around for some time (since maybe version 1.1 or so). I don't own a Mac and so basically my options were either to let the last built version stay up or ask people to use a VM. Using a VM will definitely cause a hit to performance, but it's the best I've got. I don't think this is true though! You can run the KSPTOTConnect plugin on MacOS in KSP and then just figure out what 192.168.x.y your Linux VM and main machine are at, and then connect accordingly. Or I think anyway. Long story short, you shouldn't need to run KSP in a VM to get this to work.

Just a heads up, I found a bug in the PR5 build that caused certain listbox UIs to not appear when opened. This was due to the upgrade to R2021a. I've resolved the issue and rebuilt PR5. Please redownload when you have a chance. Thanks!

You can but there's no need to.

Hi everyone! Tonight I'm excited to announce the release of KSPTOT v1.6.8 pre-release 5. This is a major update, not for the features that it brings, but because it marks KSPTOT moving to a new release of MATLAB after ~4 years on the venerable R2017b! As of PR5, we will be on the latest and greatest, R2021a! In order to use this release, and all releases going forwards, you will need to download and install the MATLAB Compiler Runtime for R2021a (MATLAB 9.10) for your operating system at this link: here. The R2017b MCR will not run PR5 and later. Why move to R2021a? Because I saw a ton of performance improvements across the board. In LVD, I was seeing a ~25% decrease in run time in my "Two Stage to Orbit" example just by moving to this version. It was simply too good to ignore and not pass on to you. And as an added bonus, the KSPTOT downloads are now 50% smaller than before. It's really win-win all around. Here's the change log. It's pretty minimal because most of my development time has been spent checking out R2021a. Upgrade MATLAB version to R2021a. LVD: Incorporation of surrogate optimizer as an optimization method. LVD: New optimizer output for NOMAD and PatternSearch optimizers. A bunch of bug fixes and tweaks all around. Because this is a new MATLAB release, and because it's impossible for me to test everything, I would certainly appreciate if everyone could please take a look at this release, test it out, and report back any bugs. Thank you! Happy orbiting.

I'm just glad it's been dealt with!

Hi everyone, Good news! The Reddit admins were able to restore my account to me. Needless to say, I am very grateful and have turned on 2 factor authentication so this doesn't happen again. I've also cleaned out the filth that the hijacker posted. Unfortunately it looks like all of my posts were basically deleted. I've asked to see if they can be recovered, but I suspect that the answer is no. Anyway, I will likely be deactivating the /u/Arrowstar2 account in the near future, so please don't follow that one or anything. Thanks!

Hi everyone, I wanted to make the KSPTOT community aware today that my Reddit account (/u/Arrowstar) that I've previously used to discuss KSPTOT on the KSP subreddit was hijacked last week. I am trying to get it back and have emailed the support people to see if they'll work with me. Unfortunately, at this time it looks like whoever now controls it has started to post NSFW content. This is not me. They also deleted the past 4 years of my posts, including KSPTOT postings as well as other personal things I've done (RIP to my paintings on /r/HappyTrees). Needless to say, I was pretty hurt when I saw this happen. I've created a (hopefully temporary) new account, /u/Arrowstar2. Obviously I don't have much KSPTOT stuff to post at the moment, but I wanted to make everyone aware so you didn't think terrible things of me or anything. If I get the account back, I'll update this post with more information. Thanks for understanding, everyone.

I appreciate the shout out, @Curveball Anders! Madman, genius, either works. For the record, @Dr. Kerbal, if you want to use KSPTOT for this, the tool you're looking for is the Multi-flyby Maneuver Sequencer. Here's an example of what you can get out of that:

I'm currently re-uploading KSPTOT v1.6.8 pre-release 4 with a fix for the LVD bug @Tacombel found. This is the only difference between the previously released PR4. Give it 10-15 minutes from this post and then re-download it if you'd like the fixed version. The bug had to do with optimizing the new flight path angle termination condition, so if you don't need that, then there's no need to download this build.

No, the MAT file you sent was an LVD file.

I can after I fix the bug you found. I'll push out a fix tomorrow.