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

[diomedea]

Played a bit with KSP TOT v.1.1.7, so far so good . Time in Kerbin units shows fine in all modules I tested till now (couldn't yet check all due to lack of time, will do at the earliest possibility).

Mission Animator is very nice, though I could not find a way to change the "camera" distance (so to enlarge/restrict the view), and rotation of the view could only happen by changing values in the angles boxes (would be more intuitive to rotate dragging the view). Minor issues really, that module is a beauty already.

[Drew Kerman]

I do have some suggestions to make the process a bit easier:

- When looking at the whole Joolean system with child bodies visible, the child bodies are so small that they visually merge with the arc of their orbits. I end up having to show SoI radius and popping the orbit display out so I can make it larger, before I can finally locate Pol and Bop. So it would be useful to make child bodies a minimum size and a contrasting color in order to make them visible.

- With multiple burns in the Joolean system, I see the locations of child bodies at multiple points on their orbits. I'm presuming these are the body locations at each event. However, it's difficult to tell which location correlates to which event. Could we color the bodies according to the event location corresponds to?

I second these. Although planets/moons themselves already have their own coloration so instead just text labels near the body that correspond to the event(s) in the script should be good. Yea, it's obvious what event comes before what once you figure out which way things are rotating, but I still like the idea of easier correlation.

So, got some 1.1.7 hands on time myself!

Mission Animator seems to not like SOI transitions when animating? Check out the three movies I made from my latest Duna MAT (also included) - didn't do anything but open the animator, set the warp to x10000 and switch the view type. Of course, it may also just be me not knowing how to properly set up the camera.

I failed to see any children bodies or other spacecraft as well when they were checked visible (animation was stopped). Here's what I get:

I included the MAT file for this as well, I imported a few asteroids (actively being tracked in game) from the SFS file - one is the main craft you see here, the rest are Other Spacecraft.

Again, some of these issues may just be plain misuse by me.

Now some suggestions:

- adding the ability to specify the UT position of the playback bar

- being able to record from the location of the playback bar, instead of always from the Initial State of the script

- have the playback bar arrows scale with the warp factor. Set the warp to x1 and clicking the arrows advances the playback 1 second. Set the warp to 100x and each click is 100 seconds, etc

- all the camera settings text boxes would be way better as sliders, no need to worry about constraint input on your end

Also a bug - while animating if you close the window a blank graph window will pop up:

Additional non-animator feedback:

- Allowing a "Get UT from SFS" import option for time fields

- Being able to undo graphical analysis

The second one may require an example, which is the case where I thought of it. I was checking out the new Distance Traveled graphical analysis and realized if I really wanted to be accurate I couldn't just use the initial version of my Duna mission file, since that file has me performing a burn out of LKO but not the exact trajectory I ended up on. Then I do a correction burn that also isn't exactly as in the original mission file. However I save a new file when I update my orbit after a maneuver so I simply worked backwards. I took the mission file after my heliocentric correction burn and got distance up to the current game time. Then I went back to my post TDI burn MAT and got distance until the time of my correction burn. Then I went back to my initial LKO MAT and got distance until the time of my TDI burn.

So far my spacecraft has traveled 38,137,782km! Awesome

To get back to the Undo suggestion, when I went to overlay the third graph, I mistakenly set the background color instead of the line color and had to do it all over again - for this nice picture anyways. A more serious error tho would be an accidentally wrong Dependent/Independent variable that would make you have to redo the whole graph.

BTW to anyone who didn't realize it yet, you can overlay multiple lines from multiple mission files and times and whatnot so long as you leave the graph window open. You can also alt-click to create multiple data points.

[hab136]

I have a probe with an ion engine headed to Dres. The burn is something silly like an hour (bad design, I know, but it's already launched). It would be a lot more efficient to break this up into several smaller burns, LADEE-style.

It would be great if KSPTOT had a generalized "break a maneuver into x number of smaller maneuvers to achieve the same result" function. Or for my needs, if just the main porkchop plotter supported multiple departure burns. As far as I know, there's no way to figure this out with KSPTOT right now; please correct me if I'm wrong. If there's some other tool to use (or just a spreadsheet where I could plug in numbers), that would work too.

Unrelated, and I've been too lazy to write a post just for it, but since I'm writing a post anyways - there's a minor issue in "Rendezvous Maneuver Sequencer", in the "Initial Epoch" time field - you can't right-click and pick "get UT from KSP" like you can in other time fields. Huge deal, I know.

KSPTOT is fantastic. Keep up the good work!

Edited September 27, 2014 by hab136

[FanaticalFighter]

Negative epochs don't work with the rendezvous planner, which means it is impossible to use this for planning stuff to the Moon in RSS. Any idea how to remedy this?

[Arrowstar]

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.

[Arrowstar]

I'm making progress with Mission Architect in my attempt to swing by Jool and intercept Pol. I'm having a lot better luck getting a solution by using the Jool-flyby to lower the apoapsis to somewhere around 400Mm, then burning at api to raise periapsis to near Pol's orbit. The Optimizer can then take over and tune those two burns to get close to Pol. Mission file is here; I'm still playing with it as it doesn't reach Pol quite yet.

I'll take a look and see if I can make any progress with it. Any luck since posting it?

I do have some suggestions to make the process a bit easier:

- When looking at the whole Joolean system with child bodies visible, the child bodies are so small that they visually merge with the arc of their orbits. I end up having to show SoI radius and popping the orbit display out so I can make it larger, before I can finally locate Pol and Bop. So it would be useful to make child bodies a minimum size and a contrasting color in order to make them visible.

- With multiple burns in the Joolean system, I see the locations of child bodies at multiple points on their orbits. I'm presuming these are the body locations at each event. However, it's difficult to tell which location correlates to which event. Could we color the bodies according to the event location corresponds to?

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.

The Mission Animator is particularly interesting, and has the potential to be a really useful visualization tool.

- Can you add the option to display orbit arcs for child bodies? This would make identifying which body is which easier.

- When using "Custom" camera position, can you add a "zoom" capability? It seems that the Custom camera creates a 3D box the size of the entire SoI.

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).

Played a bit with KSP TOT v.1.1.7, so far so good . Time in Kerbin units shows fine in all modules I tested till now (couldn't yet check all due to lack of time, will do at the earliest possibility).

Mission Animator is very nice, though I could not find a way to change the "camera" distance (so to enlarge/restrict the view), and rotation of the view could only happen by changing values in the angles boxes (would be more intuitive to rotate dragging the view). Minor issues really, that module is a beauty already.

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.

Mission Animator seems to not like SOI transitions when animating? Check out the three movies I made from my latest Duna MAT (also included) - didn't do anything but open the animator, set the warp to x10000 and switch the view type. Of course, it may also just be me not knowing how to properly set up the camera.

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 failed to see any children bodies or other spacecraft as well when they were checked visible (animation was stopped). Here's what I get:

http://i.imgur.com/6Eq7saC.png

I included the MAT file for this as well, I imported a few asteroids (actively being tracked in game) from the SFS file - one is the main craft you see here, the rest are Other Spacecraft.

Again, some of these issues may just be plain misuse by me.

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.

Now some suggestions:

- adding the ability to specify the UT position of the playback bar

- being able to record from the location of the playback bar, instead of always from the Initial State of the script

- have the playback bar arrows scale with the warp factor. Set the warp to x1 and clicking the arrows advances the playback 1 second. Set the warp to 100x and each click is 100 seconds, etc

- all the camera settings text boxes would be way better as sliders, no need to worry about constraint input on your end

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.

Also a bug - while animating if you close the window a blank graph window will pop up:

http://i.imgur.com/ofXm7ei.png

Yeah, I suspect I know what causes that. I'll look into it. Thanks!

Additional non-animator feedback:

- Allowing a "Get UT from SFS" import option for time fields

- Being able to undo graphical analysis

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.

It would be great if KSPTOT had a generalized "break a maneuver into x number of smaller maneuvers to achieve the same result" function. Or for my needs, if just the main porkchop plotter supported multiple departure burns. As far as I know, there's no way to figure this out with KSPTOT right now; please correct me if I'm wrong. If there's some other tool to use (or just a spreadsheet where I could plug in numbers), that would work too.

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.

Unrelated, and I've been too lazy to write a post just for it, but since I'm writing a post anyways - there's a minor issue in "Rendezvous Maneuver Sequencer", in the "Initial Epoch" time field - you can't right-click and pick "get UT from KSP" like you can in other time fields. Huge deal, I know.

Huh, never noticed that. Thanks for pointing it out! I'll take a look and add it to the list of corrections.

KSPTOT is fantastic. Keep up the good work!

Thanks! I appreciate your feedback and I'm glad you like KSP TOT.

Negative epochs don't work with the rendezvous planner, which means it is impossible to use this for planning stuff to the Moon in RSS. Any idea how to remedy this?

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!

[Arrowstar]

I'm making progress with Mission Architect in my attempt to swing by Jool and intercept Pol. I'm having a lot better luck getting a solution by using the Jool-flyby to lower the apoapsis to somewhere around 400Mm, then burning at api to raise periapsis to near Pol's orbit. The Optimizer can then take over and tune those two burns to get close to Pol. Mission file is here; I'm still playing with it as it doesn't reach Pol quite yet.

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. )

[Drew Kerman]

I ran your Kerbin to Duna mission and didn't see any issues with the SoI transition.

It was more the wonky default camera not even showing my ship and such that I was having issues with, actually.

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.

Ah. No worries, I just didn't have another good scenario handy to test out the animator with for multiple spacecraft. I built myself a simulation in Universe Sandbox to throw my asteroids into

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?

Options are always best. In this case, when the user selects to record the video it could just be a dialog prompt to start from the beginning or the current position.

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.

Ah well, I will just have to be careful when I plot It's a very useful "feature". Another example from my Duna mission is when I told the graphical analysis to plot my distance from Kerbin and my distance from Duna. Overlaid on top of each other I could pull up a data point at the intersection and find out exactly when I would be closer to Duna than Kerbin along my route I can also overlay the Line of Sight plots for my two interplanetary communications satellites atop each other - an unbroken line at the top means I have constant communication with Mission Control.

Given this use wasn't intended, give yourself a pat on the back for the foresight of allowing us to set the colors of lines!

[FanaticalFighter]

@Arrowstar: Negative epochs in RSS exist because the game starts around quite a bit of time after the initial orbit data (I think), so the epochs are negative. IDK why this is so, though.

Also, after a bit more use, I've found that KSPTOT just won't calculate nice trajectories for anything. e.g., a Earth-Mars transfer would take 11km/s or so of delta v, with a prograde of around 2 kms and a radial of around 10. At a similiar time that the launch window planner with KSPTOT says that this is the case, with the same orbit as I fed into the burn calculator, with a bit of fiddling with the manoeuvre nodes, I can find transfers that only take around 3.5 kms. Any ideas what may be messing up?

[Arrowstar]

It was more the wonky default camera not even showing my ship and such that I was having issues with, actually.

Got it. I'm hoping the new "Range Offset" slider/value will be of some use here.

Ah. No worries, I just didn't have another good scenario handy to test out the animator with for multiple spacecraft. I built myself a simulation in Universe Sandbox to throw my asteroids into

Same as above. The range slider allows you to expand the render distance some, which should be helpful for the asteroids issue.

Options are always best. In this case, when the user selects to record the video it could just be a dialog prompt to start from the beginning or the current position.

Got it, not a bad idea. I'll implement it tonight.

Ah well, I will just have to be careful when I plot It's a very useful "feature". Another example from my Duna mission is when I told the graphical analysis to plot my distance from Kerbin and my distance from Duna. Overlaid on top of each other I could pull up a data point at the intersection and find out exactly when I would be closer to Duna than Kerbin along my route I can also overlay the Line of Sight plots for my two interplanetary communications satellites atop each other - an unbroken line at the top means I have constant communication with Mission Control.

http://i.imgur.com/BFe5Ad0.jpg

Given this use wasn't intended, give yourself a pat on the back for the foresight of allowing us to set the colors of lines!

Ah, well, you're quite welcome then.

@Arrowstar: Negative epochs in RSS exist because the game starts around quite a bit of time after the initial orbit data (I think), so the epochs are negative. IDK why this is so, though.

Also, after a bit more use, I've found that KSPTOT just won't calculate nice trajectories for anything. e.g., a Earth-Mars transfer would take 11km/s or so of delta v, with a prograde of around 2 kms and a radial of around 10. At a similiar time that the launch window planner with KSPTOT says that this is the case, with the same orbit as I fed into the burn calculator, with a bit of fiddling with the manoeuvre nodes, I can find transfers that only take around 3.5 kms. Any ideas what may be messing up?

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.

[Arrowstar]

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

[Drew Kerman]

0_0 ^ inf (and beyond!)

[Arrowstar]

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!

Edited October 2, 2014 by Arrowstar

[diomedea]

...

The think the instructions are fairly self-explanatory, but I'd love some feedback or questions if you guys have any.

That is a stroke of pure genius ! A rather easy way to find the drag coefficient, so it can be applied to the "real" maneuvers in MA.

And, I guess, that would also be independent from the aerodynamics model used in KSP (so, usable with rather good confidence also in case the model is modified by ferram4's FAR or NEAR add-ons).

You will probably remember one other tool for KSP that actually computes aerobrakes (Komputron, by Elington). That tool also uses numerical methods to find the solution, and is very precise, but suffers from this limitaton: the user can input a drag coefficient of his choice, but has no way to know what that value is. With stock KSP most parts have drag coefficient = 0.2, and therefore using 0.2 provided good solutions in most cases with the stock model. But not with FAR, and I had to make experiments setting that coefficient so to simulate (afterwards) what effect I experienced from an aerobrake, hoping the same would apply to the next.

[Drew Kerman]

yup seems straight forward enough. Hyper-edit a craft around a planet, burn to drop into the atmosphere and record the results. At first I was annoyed because I thought you had to place your craft on the planned trajectory, not any trajectory.

Oh and slight spelling mistake in Step 6

[Arrowstar]

A rather easy way to find the drag coefficient, so it can be applied to the "real" maneuvers in MA.

And, I guess, that would also be independent from the aerodynamics model used in KSP (so, usable with rather good confidence also in case the model is modified by ferram4's FAR or NEAR add-ons).

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.

You will probably remember one other tool for KSP that actually computes aerobrakes (Komputron, by Elington). That tool also uses numerical methods to find the solution, and is very precise, but suffers from this limitaton: the user can input a drag coefficient of his choice, but has no way to know what that value is. With stock KSP most parts have drag coefficient = 0.2, and therefore using 0.2 provided good solutions in most cases with the stock model. But not with FAR, and I had to make experiments setting that coefficient so to simulate (afterwards) what effect I experienced from an aerobrake, hoping the same would apply to the next.

I'm afraid you might have to do the same here, but we'll see. You can test that out for me lol.

That is a stroke of pure genius !

Thanks, I strive for genius with Mission Architect.

yup seems straight forward enough. Hyper-edit a craft around a planet, burn to drop into the atmosphere and record the results. At first I was annoyed because I thought you had to place your craft on the planned trajectory, not any trajectory.

Oh and slight spelling mistake in Step 6

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!

[Drew Kerman]

Not sure how it will behave as I don't use FAR/NEAR myself.

I'll be able to test that for you then

[Arrowstar]

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!

[Drew Kerman]

only had time for a brief single test of the aerobrake functionality

Javascript is disabled. View full album

[Arrowstar]

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?

[hab136]

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.

I'm not sure I understand the difference between a finite maneuver and impulsive, but I think we're on the same page.

Let's say I've calculated that I need a 600 m/s burn prograde at periapsis (to make it easy). I want to break that up into:

200 m/s burn prograde at periapsis

coast for 3000 seconds to return to periapsis

200 m/s burn prograde at periapsis

coast for 6000 seconds to return to periapsis (because orbit is bigger now)

200 m/s burn prograde at periapsis (at the time the original burn would have been)

If it's not 100% accurate due to dividing it up, that's ok - it will still be way more accurate than trying to do a 600 m/s burn.

I've tried to do the above manually, but I've not been able to do it right.

[Drew Kerman]

I've got the radius of Duna as exactly 320 km. Is that not correct?

Craaaap I keep forgetting the tooltip Pe/Ap readout is measured from the center of the body. It's not done like that anywhere in the game so I'm used to Pe/Ap from the surface

i think I saved the mat file, will check when back at the comp later tonight. If not, I do have the game scenario saved so can prob recreate

[Arrowstar]

I'm not sure I understand the difference between a finite maneuver and impulsive, but I think we're on the same page.

Let's say I've calculated that I need a 600 m/s burn prograde at periapsis (to make it easy). I want to break that up into:

200 m/s burn prograde at periapsis

coast for 3000 seconds to return to periapsis

200 m/s burn prograde at periapsis

coast for 6000 seconds to return to periapsis (because orbit is bigger now)

200 m/s burn prograde at periapsis (at the time the original burn would have been)

If it's not 100% accurate due to dividing it up, that's ok - it will still be way more accurate than trying to do a 600 m/s burn.

I've tried to do the above manually, but I've not been able to do it right.

Okay. This sounds like a good v1.1.9 feature. I'll investigate incorporating then.

Craaaap I keep forgetting the tooltip Pe/Ap readout is measured from the center of the body. It's not done like that anywhere in the game so I'm used to Pe/Ap from the surface

i think I saved the mat file, will check when back at the comp later tonight. If not, I do have the game scenario saved so can prob recreate

Thanks, I look forward to getting it.

[Drew Kerman]

I just checked and didn't save it. Since I need to recreate I might as well just do the whole aerobrake test over again too so can you get me a hotfix for the altitude issue?

And what's the point of displaying Ap/Pe from the center of the body anyways? This is not knowledge most people have off the top of their heads so to get the proper altitude we'd see in the game we need to use the Body Catalog and subtract the radius. Just seems like a pointless extra step to me

And speaking of the Celestial Body Catalog I just tried to open it in 1.1.8 to make sure the radius measurements were in fact there and it pops open and closed with a system beep but no error message or anything

Edited October 4, 2014 by Gaiiden

[Arrowstar]

I just checked and didn't save it. Since I need to recreate I might as well just do the whole aerobrake test over again too so can you get me a hotfix for the altitude issue?

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.

And what's the point of displaying Ap/Pe from the center of the body anyways? This is not knowledge most people have off the top of their heads so to get the proper altitude we'd see in the game we need to use the Body Catalog and subtract the radius. Just seems like a pointless extra step to me

And speaking of the Celestial Body Catalog I just tried to open it in 1.1.8 to make sure the radius measurements were in fact there and it pops open and closed with a system beep but no error message or anything

"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.