Arrowstar

Thanks for helping out, everyone. It's been a really busy couple of weeks for me and I just haven't had the time. I promise v1.1.8 is coming whenever I can manage to get things packaged up...

Any new pictures to show us, RoverDude? :-D

Can you post your bodies.ini file online somewhere so I can try myself?

Glad you like it! It considers both the delta-v needed to depart and the delta-v needed to "arrive," but the arrival delta-v is more of an approximation because the final orbit isn't known. It's still more than good enough for planning purposes though. And yes, the intent for everything in the maneuver planning tools section is that it ultimately feeds into the Mission Architect. Yes, the reason is that multi-revolution Lambert solvers are hard. A mult-rev Lambert solver solves Lambert's problem while allowing the spacecraft to go around the central body (say, the Sun) N times (N > 0) before arriving at the destination. However, they are much more complex than their single-rev brothers, hence why I didn't implement one. Please let me know if you have any questions. Mission Architect in general can be difficult to learn at first, but I'm happy to help!

Wow, nice! I'm really looking forward to this, RoverDude. Keep up the great work.

Pre-release 3 is up. Please let me know if you find any issues. My plan is to make this build the actual release unless bugs are found.

Want to share some details with your adoring fans? ;-)

Good suggestion, I'll do that. Thanks! Btw, sorry for the delay on v1.1.8, everyone. This weekend was crazy and next is shaping up to be crazy, too. I'll get it out when I can. In the mean time, enjoy 0.25 and the KSPTOT v1.1.8 pre-release I linked to above. EDIT: And KSPTOTConnect seems to be fine with KSP 0.25, but let me know if you find anything.

Hey, sounds cool. I've probably done a bunch of this in KSPTOT, let me know if I can answer questions to help you along. :-)

Thanks! I've added the apo/peri altitudes to the tooltip, it will be in the next version/pre-release.

Here's the fix. The issue you have with the Celestial Body Catalog is there are more parameters in the bodies.ini since the last release of KSP TOT (v1.1.7). The beep sound you heard was because you're missing those parameters when the Celestial Body Catalog opens and tries to find them but can't. When you start this release of KSP TOT, you can load the bodies.ini file I've included in the ZIP. Also, the data in the bodies.ini file is stored with each Mission Architect MAT file, so you might need to start a new MAT file until I get an "MAT upgrade" feature into v1.1.8. Yay prerelease software. Oh, last thing, the Mission Animator UT box for the scroll bar is very much under construction and does not work. Everything else should be okay. I'm going out for the weekend, though, so I'm getting this to you before I go in whatever state I have it in. Apologies if other stuff is broken. Let me know what you find. "Real" astrodynamicists always use radius (that is, from center of body) in their work, never altitude. Altitude is a foreign language to us. It's not something I often think in, but KSP defies a few real conventions for the sake of gameplay. If you want, I can add periapsis/apoapsis altitude to the tooltip, too.

Okay. This sounds like a good v1.1.9 feature. I'll investigate incorporating then. Thanks, I look forward to getting it.

Okay, found the bug with the calculator. Thanks for finding that. Can I get a MAT file for the second (Ike) image? I've got the radius of Duna as exactly 320 km. Is that not correct?

If you would like to test, then test you will! Here is the first v1.1.8 pre-release. I am doing pre-releases on this version because the aerobraking code is very new and I want feedback before it goes "live." I would encourage those testing (Gaiiden ) to please try the aerobraking first with stock aerodynamics (no FAR/NEAR). Because of the complexity here, that's the first goal. Once I get that done, we can move on to attempting to approximate NEAR/FAR. One other major feature in this release is the ability to set the camera source/target positions in Mission Animator while using "Spacecraft Fixed" mode. So now you can point the camera from your spacecraft to the KSC, or from that other geostationary s/c to your spacecraft, or frankly any combination of anything and anything. It's pretty neat, take a look! Please note that this is a pre-release. There are probably lots of bugs to be found. Finally, the following features are still missing: 1) UT entry for the Mission Animator playback bar; and 2) Scaling the Mission Animator playback bar with the warp factor. These are both minor features, so I'll get to them tomorrow probably. I didn't see any reason to hang up the pre-release because of them. Please tell me what you guys think. Thanks!

The idea was for it to be easy, yes. As Gaiiden describes below, just hyperedit your craft into orbit, plow throw the atmosphere, punch in some numbers, and viola, drag coefficient. I don't think it'll work well with FAR, though I could be mistaken. I say that because I had to come up with the math for the stock KSP drag formula and put that in, but the formula used by FAR/NEAR is much more realistic. Not sure how it will behave as I don't use FAR/NEAR myself. I'm afraid you might have to do the same here, but we'll see. You can test that out for me lol. Thanks, I strive for genius with Mission Architect. You are correct, any trajectory will do. Heck, I used HyperEdit and Trajectories myself to get my craft into orbit and test out aerobraking maneuvers (respectively). It works well. I'll fix the spelling mistakes, thanks for catching it!

I'll take that as a compliment. The only input to the Aerobrake maneuver event in Mission Architect is drag coefficient. However, that's a rather nebulous number at best, so tonight I worked on a brief calculator to allow users to approximate their drag coefficient better. The think the instructions are fairly self-explanatory, but I'd love some feedback or questions if you guys have any. Thanks!

Just a small aerobraking teaser, don't mind me... *whistles*

Got it. I'm hoping the new "Range Offset" slider/value will be of some use here. Same as above. The range slider allows you to expand the render distance some, which should be helpful for the asteroids issue. Got it, not a bad idea. I'll implement it tonight. Ah, well, you're quite welcome then. Sure, I can help. I'll need to know what tool you're in and how you're using it to date. Can I get some screenshots? If you're using the main porkchop plot tool, try increasing the number of synodic periods to plot in the Options menu.

I was able to get a Pol intercept easily by changing Event 6 (Coast to Apo) to a "Goto True Anomaly" type burn with bounds 170-190 degrees. Give that a shot and let me know if it works. In other news, I implemented some of the suggestions I read tonight: (By the way, a combination of Rng Offset and View Angle works like a zoom function. )

I'll take a look and see if I can make any progress with it. Any luck since posting it? I can look into the size issue. It might just help if I thinned out the orbit arc line, but we'll see. Actually, changing the colors of the spheres is non-trivial in MATLAB, believe it or not. There is one colormap for each figure, and if I want to use multiple colormaps in a figure, I have to concatenate separate color maps together and then delimit which segments of each color map go with each sphere. It's a pain in the neck. I'm looking at doing a simple version of it for v1.1.8, but the colors of the bodies will still correspond to their designated colors in the bodies.ini file. Yes, to both suggestions. Thanks for the input! As a note, the Custom camera is actually identical to the Fixed camera at the moment. I had plans for Custom, but I think it may just disappear in the next version because those plans got absorbed into the Fixed camera (more or less). Thanks for the time check. As noted above, I am going to add a Zoom parameter, which should help I think. Dragging the view isn't really possible because the camera position/rotation has to be recomputed at each time step, and I have no way of computing camera offsets in both position and rotation (for now). See below, I'm going to add some sliders to handle all this. I ran your Kerbin to Duna mission and didn't see any issues with the SoI transition. But it's right up at the end, and if you were maxing out the timewarp, it's possible you timewarped through the SoI transition and then the player reset back at the start position. Try stopping the animation and slowing down the time warp when you get close to an SoI transition. I also ran the asteroids case and I suspect it's a render distance thing. I'll need to investigate more. I don't render all of space around the central body in question because it really stresses MATLAB out to have to render spheres thousands of kilometers across many hundreds of thousands of kilometers away. What probably happened is that the child bodies you were looking for were simply outside the render distance. 1) Yes, I can add the ability to specify UT position directly. 2) I can add the ability to record from the location of the playback bar. Would you suggest this be default behavior or do I need an option? 3) This is something I can look into. Hadn't thought of anything like that, but I'll look into it and see if it works out in a reasonable way. 4) Yes, I agree. I will work on getting sliders in there with the text boxes. Yeah, I suspect I know what causes that. I'll look into it. Thanks! 1) That's an interesting idea. I'll investigate. It shouldn't be too hard. 2) So... the whole "plot to the same figure" behavior isn't actually by design. You discovered an accidental feature! Given that, while I won't correct the issue such that you can't plot to the same figure (as you seem to like it), I'm also not going to pursue adding any "undo" functionality as A) it'd be pretty hard because I don't track handles to the data series at the moment and it was never supposed to work like that in the first place. So it's actually really hard to approximate a finite maneuver with an impulsive maneuver (as both KSP and KSP TOT use right now). I could certainly add a feature that splits the delta-v into X maneuvers separated by Y seconds of coast. Do you think this would be useful? I'm not sure it would accurately reflect the "real" maneuver, but it would be (somewhat) more accurate that the single-impulse approximation anyway. Huh, never noticed that. Thanks for pointing it out! I'll take a look and add it to the list of corrections. Thanks! I appreciate your feedback and I'm glad you like KSP TOT. Negative epochs aren't allowed in KSP TOT because, at least in stock KSP, you can never get to a negative epoch anyway. It's a safety measure to make sure that solvers don't go flying off into an obviously infeasible part of the trade space. How does RSS work in this respect? Why are negative epochs required? Thanks for the great feedback everyone. Sorry for the delay in responding, I had a busy weekend. V1.1.8 will hopefully incorporate much of your feedback and, assuming I can demonstrate its correctness and utility, a new "Aerobraking Maneuver" event type. Thanks!

Hi all! The v1.1.7 OSX build is now online and available from the OP. Please thank bk2w for his help in getting this together for you all.

That's a good idea. I can certainly look into it! EDIT: As for preventing it, I would encourage you to use the "go to true anomaly" coast and optimize on that as opposed to optimizing the UT of the burn. See if that does anything for you.

Thanks for the report! Something weird is going on with your burn but I haven't figured out what yet. I'll look into it... EDIT: In the mean time, check out Mission Animator; you'll see that the spacecraft goes around once before the SoI change, meaning that the picture is rendered correctly. It's just unusual to go a full rev before actually getting to the Mun... EDIT^2: Yup, okay, a bit of investigation later and it appears that there's nothing formally wrong. Mission Architect is doing what I told it to do, which is to search out more than one period for an SoI transition. (The number of periods it goes out is computed and, in this case, actually looks like it's 2.0.) You just got very lucky (unlucky?) to have the optimizer find the SoI transition on the second orbit around Kerbin instead of the first. This "search more than one revolution" feature is more for safety than anything else. I can't always predict how many revs the user expects the SoI search code to go out, and so I set it to a compromise between not having enough (such as always just going 1 rev) and too many (going, say, 5-10 revs). Given that this is the first time I've seen this happen, I'm not sure what to say except "congrats!" I'll solicit input in the thread here as to what people think Mission Architect should do in this case. If you have a thought, please post here. Thanks!

Hi everyone, This evening I am pleased to announce the release of KSP Trajectory Optimization Tool v1.1.7! This is a nice update with the following features: Major improvements to the KSPTOTConnect netcode courtesy of RadarManFromTheMoon. These improvements significantly increase the robustness and speed of KSP TOT Connect, making it much more enjoyable to use. Thanks, RadarManFromTheMoon! New Mission Architect Tool: Mission Animator. Mission Animator is a multi-purpose visualizer and animation creation tool for Mission Architect. Three new objective functions in Mission Architect: maximize inclination, maximize eccentricity, and "satisfy constraints". 2x speed up of Mission Architect script execution when using Strict SoI Search Time may now be specified in Earth units or Kerbin units. NOTE: Kerbin units are HIGHLY experimental. Report any issues with KSP TOT while using Kerbin units immediately. Bug fixed with MA Graphical Analysis tool when plotting against MET. New "Distance Traveled" option in MA Graphical Analysis. Fixed two bugs with Maneuver Exec Assistant The download is available in the OP, as always. Please note that this release is for Windows only at this time. I rely on bk2w to supply the Mac releases, and he provides me a Mac package at his convenience. Please report any issues with the following new features: KSPTOTConnect; Mission Animator; and Kerbin time units. Have at it, everyone, thanks! I'm looking forward to seeing some sweet animations in the future. Oh, quick announcement about what's on the plate for v1.1.8. This update will be the Aerobraking Update and should hopefully include an aerobraking delta-v model that I will begin to incorporate into Mission Architect next week. Stay tuned!

Thanks for the note, I will!