theAstrogoth

I can try to help you get it to work! Let's chat via PM or in the relevant thread so that we don't clutter up the discussion here.

I can't say what specifically went wrong here, but here are a couple of thoughts: One thing to keep in mind is that in KSP1, all maneuvers are considered instantaneous when predicting future orbits. This means that even if you execute a node *perfectly*, the resulting orbit won't be exactly the same as the one that was predicted. The app works the same way, so the only maneuver node that you'd reasonably be able to copy and paste without needing to adjust too much is the first one. All of the later maneuvers will either need to be manually adjusted or recalculated based on intermediate orbits. When making manual adjustments for flybys, the most important thing to match is the periapsis of the flyby arc. You can add additional course correction maneuvers during your transfer orbits around Kerbol for fine-tuning your trajectory. TLDR: errors in the app's calculations get worse for each successive maneuver, so manual adjustments are probably needed for any maneuver after the first one. Transfer/Flyby windows should still be correct in general.

Thanks! I think I've fixed the issue. It was caused by a few asteroids orbiting around some planets you'd added with mods, but I've made it so that the app ignores bodies that it doesn't have info for. Now loading your savefile should let you select a craft to automatically fill its details in for a starting/target orbit. I was able to do it with "Looj", and it seems to work as intended. For anyone who might come across this kind of issue in the future... For stock planets or any of the planet packs build into the app (Outer Planets Mod, JNSQ, RSS), just select the solar system you'd like to use before loading your savefile, and everything should work correctly. If you want to plan a mission to a modded-in planet, or you want to get info about something orbiting a modded-in planet, you have to set them up in the Solar System Editor before loading your save.

That's part of the problem, I think. You'll need to convert your Mean Anomaly at Epoch from degrees (used by KSPTOT) to radians (used by KTI and the game). For your case, 242.51106834404 degrees should become 4.232616615132491 radians. I'd like to fix this if I can! If you share your save file, I can take a look at why the app might be failing to read it.

Thanks for the info! I noticed that your starting orbit has a Mean Anomaly at Epoch of 242 rads. Did you type or copy/paste your starting orbit manually, or did you use the "Load Save" button in the app? Unlike the other orbit parameters, the game uses radians (which are generally between 0 and 6.28) for this value, and it looks like there might be an extra/missing conversion between radians and degrees (242 degrees is about 4.2 radians). If you loaded your save in the app, there is likely a bug, although it seems I am not able to recreate it with any of my own saves. If this is the case, would you mind sharing your savefile with me via a PM, so I can figure out what causes the problem? Also, if you want burn info that is accurate in game, make sure you press the "Refine Trajectory" button. It makes small changes to your trajectory to account for some things (like planet spheres of influence) that the original trajectory search ignores for the sake of speed. Other than that, the timing of the maneuver is sometimes *slightly* off if, as in your case, you're planning a maneuver several years in the future. You might have better results if you timewarp to within at least a year of your maneuver, update the orbit information (the epoch and Mean Anomaly at Epoch will change), and recalculate your transfer/multiflyby. Otherwise, you should be able to manually adjust the timing of your maneuver node by a small amount to get an intercept.

Would you mind sharing a link to the problem (press the “Get Link” button and paste here), or at least some details about your inputs? As it stands I’m not sure what the problem is.

I've thrown together an update that adds support for KSP2 save files. As with KSP1 saves, orbiting crafts can be loaded into the Transfer Planner, Flyby Planner, and/or Flight Planner after selecting your save file with the "Load Save File" button. Unlike KSP1 saves, the comm signal strengths of crafts are not loaded from KSP2 saves. I'd need some assistance collecting the "partName" for each of the available antennas (and cockpits/probe cores) in the game and matching them with their corresponding signal strengths before I can put this together. I noticed from the small amount of testing I was able to do that orbits calculated after maneuver nodes in KSP2 don't closely match those in the Flight Planner (which are the same as KSP1). The only example I have is a particular maneuver node for a vessel in LKO that raised its in-game apoapsis to 1,597 km, for which the app predicts an apoapsis of 1,623 km, an error of ~2%. This is either a bug, I'm misunderstanding what I can see of the new UI, or KSP2 has added finite burn calculations to its maneuver nodes (which would be really cool!).

True! I haven't yet gotten around to using ion thrusters with BetterTimeWarp, but trying them out for very long/low-thrust burns could be fun!

Interstellar travel should be interesting! I'm excited to dig into the math behind sustained-thrust trajectories. Colony management should be a fun addition, too!

Great! I haven't done much testing with comets, but I think that when you're working with the really large distances of a comet's orbit and the really small size of the comet itself, sometimes even a floating point error (basically rounding error) can make it necessary to fine tune your maneuvers a bit. You would likely need to make small course corrections even with a "perfect" result, since instantaneous maneuver nodes introduce some error anyways.

It depends on some of the particulars of the comet's orbit. If the inclination is low, there won't be much of a difference. Otherwise, it depends on exactly how the orbit is "tilted" relative to Kerbin's orbit. I'd try both options and pick whichever gives you better results. Mean anomaly at epoch is part of defining the timing of an object's position in its orbit. In case you're interested in what it represents... The "epoch" is just a reference time in seconds (usually the current in-game time when an orbit is calculated). "Mean anomaly" is a number that represents how far along an object is in its orbit in terms of the total time it takes to complete a full revolution. It's given in radians in-game and in the app, so 0 means the object is at the periapsis, and pi means the object is at the apoapsis. The mean anomaly of an orbiting object changes over time, as its position changes. The "mean anomaly at epoch" is the mean anomaly at a particular time (the epoch), so its value doesn't change over time as long as the orbit itself doesn't change. Changing the mean anomaly at epoch (or the epoch) keeps the "shape" of the orbit the same, but changes the times when the object passes through the periapsis. If you're starting in LKO and leaving Kerbin's sphere of influence during a mission, timing of your starting orbit likely won't result in any noticeable difference in the porkchop plot. The period of the starting orbit is rather short (~30 minutes), so you're departure times might change by a few minutes, but everything else would mostly stay the same. For rendezvous with a comet, changing the timing of the comet would cause a horizontal shift in the porkchop plot and strongly affect the success of your mission. You might end up in the right place at the wrong time (e.g. at the comet's apoapsis, but the comet is near its periapsis), and you would end up missing the comet entirely. If you're on PC, I'd recommend loading the comet's orbit from your savefile so that you don't run into this problem. Unfortunately, I don't think it is possible to get the timing parameters for an orbit if you're playing on console, so you could 1) use the results from the app as a starting point and make large adjustments to the timing and position of your departure maneuver node, or 2) use the positions of the planets relative to the comet to approximate the timing parameters for the comet (making sure things in the app look similar to things in the game) in order to get a more accurate flight plan from the app.

All the dates are in Kerbin format. It cheats a little bit by avoiding optimizing the departure delta-v. It requires that the periapsis of the departure orbit intersects with the starting orbit (which means there will be no radial component to the burn for a circular parking orbit), which gives you enough information to fully define the shape of the outgoing orbit (from the energy at the SoI exit and the imposed periapsis). Then you just have to perform some rotations to make sure the departure orbit exits in the right direction and you're done! For non-circular parking orbits, you can use this approach and iterate the departure periapsis height a few times to make sure that the parking orbit and departure orbit intersect at the right spot. The relevant code is here, in case it's helpful for understanding what I'm trying to do. Sorry if it's a little opaque, since helper functions are defined elsewhere. I was somewhat leery of using this approach, since it does not explicitly optimize for delta-v, but it is fast, which is great for a web app, and it does great for near-circular parking orbits, which are what I imagine users will input most of the time.

Here are the details for the solution I’d found. You can see plots of the trajectory here if you scroll down a bit. It also uses a fully specified, equatorial orbit, and the departure burn is still mostly prograde. The powered flybys are rather inexpensive (<50 m/s)

That's part of the point I was trying to make! As far as I understand it, you can't have 1) a really large space of flight times and departure dates, 2) fast search time, and 3) a guarantee of a good solution. No matter what, there are going to be some drawbacks to our default options for the things that affect these. No criticism of the MFMS intended Since I enjoy digging into the cases where our tools "fail", in case there is an interesting reason or an opportunity for improvement, I spent a little time fiddling this some more. In case anyone wants to replicate any of these tests, here are the "general parameters" (using Kerbal time) for the trajectory as obtained from the video earlier in the thread: Kerbin -> Eve -> Kerbin -> Kerbin -> Jool Kerbin departure: Y2, D160 Kerbin->Eve duration: ~199 days Eve->Kerbin duration: ~406 days Kerbin->Kerbin duration: ~695 days Kerbin->Jool duration: ~1661 days Note that this one is outside the default range in the MFMS. Why does Kerbin->Jool have the shortest maximum duration? Ignore cost of arrival burn The video uses unpowered flybys with deep space maneuvers, but they're very small course corrections, so the powered flyby approach could be reasonable as well. Assuming there's not a problem with my initial result, we already have a similar trajectory using powered flybys. I revisited the MFMS to double check that the parameters I was using were correct, and I kept getting the same results as before. When I tried to provide a very narrow set of search parameters, working backward from a known solution (from either the tutorial video or the result from the KTI), it fails to find valid flyby trajectories and displays a warning. Relaxing the search parameters, it ends up back in the 3+km/s range. I'll note that after retesting with the KTI a few times, I think that it's likely that my first result was a particularly lucky optimization run. Most of the time I end up with a result around 2km/s, unless I shrink the search space to a relatively small region around the known solution. Enabling DSMs seemed to make the search slightly more reliable. Maybe this particular case might be one that benefits from the use of DSMs? That would explain why Krafpy's MGA Planner tends to do a good job even when the user doesn't narrow the search space very much.

This is spot on. There's no way to guarantee that a globally optimal solution, at least that I'm aware of. If you already have some idea of where a good solution lies, you can shrink the search space (i.e. specifying a smaller range of departure dates / transfer leg times) in order to have a better chance of finding a good solution in that region. @Eddy119 You're right, if you use the default 10-year departure time interval, it typically finds a flight plan with ~1700m/s. When I restricted departure times to year 2, it recreated the trajectory in the tutorial, with ~1100m/s . There's a chance I just got lucky; you might need to re-run the search a few times to find a good solution. Side note: I was curious about whether or not the search strategy that @Krafpy and I use holds up to the one used by the KSPTOT, and it seems like the KSPTOT MFMS also struggles to find this particular solution. Using the same range of departure times and using the same mission settings (i.e. ignoring the cost of an arrival burn), the KSPTOT's best solution cost ~3000m/s, even after a few repeated searches. I'm confident that the MFMS can find the desired solution in theory, it's just that global optimization is difficult. You could try increasing the population size for the genetic algorithm in the MFMS (bottom right corner), but this can become computationally expensive. My guess is that the particular solution you were aiming to recreate is very sensitive to small changes in timing for some reason. This makes it somewhat less likely that the global search techniques we're using are able to find it.