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

[Arrowstar]

Now, that new feature is impressive. Would like to know if the mission animator will be limited to one mission segment at a time, or will automatically switch segments as time goes for the whole mission.

Yes, as your spacecraft jumps SoI, so does the camera view.

[ANWRocketMan]

@Arrowstar: I managed to import the Real SOlar System bodies. Yay!

Now a question, I've been playing around with the p[lots and mission planner. And I'm wondering how I can determine the best desired initial orbit to be able to achieve the desired/optimal transfer? I'm having trouble finding what the best inclinations and such should be if I'm flying from Earth(Kerbin) to Mars(Duna) for example.

Edited September 19, 2014 by ANWRocketMan

[AppleDavidJeans]

Ok so I tried to uninstall Java 8. Still can't figure it out. Can't you just update the tool to work with R2014a?

[Arrowstar]

@Arrowstar: I managed to import the Real SOlar System bodies. Yay!

Now a question, I've been playing around with the p[lots and mission planner. And I'm wondering how I can determine the best desired initial orbit to be able to achieve the desired/optimal transfer? I'm having trouble finding what the best inclinations and such should be if I'm flying from Earth(Kerbin) to Mars(Duna) for example.

It's a multi-step process:

1) Use the porkchop plotter to find a good pair of departure and arrival dates.

2) Use the Compute Departure button next to the porkchop plot to figure out (roughly) the interplanetary trajectory between Earth and Mars and the departure burn.

3) Once you know when you're leaving and which way to point the engines, fire up Mission Architect and start adding coasts and burns like this:

• Coast to true anomaly (whatever the burn true anomaly in Compute Departure was). Make sure you have the optimization flag checked.
  
• DV_Maneuver: enter the delta-v vector from Compute Departure. Make sure optimization flags are checked.
  
• Coast to SoI transition (no optimization)
  
• Coast to Periapsis (no optimization, and add +1 rev (you'll see why))
  

Now, open the Mission Optimizer up (cntl-O). Select the objective function as minimizing the distance to Mars in event 5, the coast to periapsis event. Leave the constraints empty for now. Run the optimizer and let your spacecraft smash into Mars.

If you don't see your distance to Duna dropping to ~0 after a bit, stop the optimization, accept the results, and see if any of your variables are against their bounds (MA warns you on the main MA GUI if this happens). If that's the case, widen up those bounds a bit and try optimizing again.

If you still can't get it, send me the MAT file (File -> Save Mission As) and I'll take a look.

Ok so I tried to uninstall Java 8. Still can't figure it out. Can't you just update the tool to work with R2014a?

Sadly, it's not this easy. You can only compile MATLAB programs for the version of MATLAB you are running. In my case that's R2013a. Now, luckily for you, I'm considering going to R2014b whenever The MathWorks decides to release it (will be soon, matter of days or weeks I think). If I do, that should help you out I think.

Brian, any thoughts to help him out in the mean time?

[Drew Kerman]

Hey Arrowstar you see this note I made a page back? Sorry to drop more on your plate but aerobraking would be the icing on the cake! I do understand the complexities involved though, for an external program. It's not just simulating the atmosphere but would involve reading the craft file to see how the profile would affect a pass through it. The mod in question no doubt leverages a lot of in-game data to perform its calculations. If it's not possible/feasible to do this within MA, then I would suggest perhaps being able to reverse the orbit import - have a state that coasts near to Duna, then allow the state to be exported to the game through KSPTOTConnect and be applied to an existing craft. Then use the ingame aerobraking tool to see the effects. Then the new orbit can be brought back into MA through KSPTOTConnect as a new state, and mission planning could continue within MA from there (or the process repeated if another aerobrake pass is needed).

[Drew Kerman]

OMG the mission visualizer is going to be a godsend for my Duna mission I just realized. I have to drop a ballistic atmospheric probe that only has a 500km antenna (that won't burn up on entry). So I need to dump it from a high orbit so that by the time it hits atmosphere my transfer craft has burned into a lower orbit and swung back around the planet so it can relay data through to KSC as it passes over the probe descending through the atmosphere. Being able to see this play out will be amazingly helpful in planning, since I see you can have more than one craft in the animation. It would also be cool if you could set more annotation options that are available from the graphical analysis tool - like distance to target spacecraft. Then I could also make sure I'm within 500km long enough to relay data properly as I fly over

[Arrowstar]

Hey Arrowstar you see this note I made a page back? Sorry to drop more on your plate but aerobraking would be the icing on the cake! I do understand the complexities involved though, for an external program. It's not just simulating the atmosphere but would involve reading the craft file to see how the profile would affect a pass through it. The mod in question no doubt leverages a lot of in-game data to perform its calculations. If it's not possible/feasible to do this within MA, then I would suggest perhaps being able to reverse the orbit import - have a state that coasts near to Duna, then allow the state to be exported to the game through KSPTOTConnect and be applied to an existing craft. Then use the ingame aerobraking tool to see the effects. Then the new orbit can be brought back into MA through KSPTOTConnect as a new state, and mission planning could continue within MA from there (or the process repeated if another aerobrake pass is needed).

Unfortunately, aerobraking (or aerobreaking ) is not something that could make it's way into MA. Mission Architect uses a patched conics model for its trajectory propagation and that is strictly incompatible with any kind of other force (beyond central body gravity). I suppose I could write an new KSP TOT application for it, but I have no idea how the KSP aerodynamics model works, and I'd only ever want to deal with simple drag and none of that complex lift stuff. Basically it would only be good for high altitude stuff.

OMG the mission visualizer is going to be a godsend for my Duna mission I just realized. I have to drop a ballistic atmospheric probe that only has a 500km antenna (that won't burn up on entry). So I need to dump it from a high orbit so that by the time it hits atmosphere my transfer craft has burned into a lower orbit and swung back around the planet so it can relay data through to KSC as it passes over the probe descending through the atmosphere. Being able to see this play out will be amazingly helpful in planning, since I see you can have more than one craft in the animation. It would also be cool if you could set more annotation options that are available from the graphical analysis tool - like distance to target spacecraft. Then I could also make sure I'm within 500km long enough to relay data properly as I fly over

Eventually something like that should be possible, yes. This is a pretty complicated feature, though, so there's no telling how long the development for something like that would take. But I'll keep it in mind as I'm writing code!

[Drew Kerman]

Unfortunately, aerobraking (or aerobreaking ) is not something that could make it's way into MA. Mission Architect uses a patched conics model for its trajectory propagation and that is strictly incompatible with any kind of other force (beyond central body gravity)

Handling it inside the program may not be doable as I suspected, but I noticed you didn't mention my import/export idea - did I explain that well enough? I realize now you don't even need the aerobrake mod, just export the orbit so you're set up for your atmo pass, let the game run, then import the new orbit after exiting the atmosphere. MA could treat it as a special dV maneuver that produces the forces to place the craft on the new orbit but doesn't expend any fuel mass.

[ANWRocketMan]

@Arrowstar:

Thanks for the help. Got the optimization figured out. I now have my mission plan to a 150kmx200km orbit around Mars from Earth. Thanks!

Is tehre any way to set the optimisation to alter the initial spacecraft properties? I'm sure I can have a much better initial orbit than I can figure out manually. Could be quite usefull.

[dacamp66]

Arrowstar: just had an idea, use it or tell me to get lost, your choice.

idea: what about making, or talking to someone who knows how to make, an instructional "how to" video covering the features of this tool? Coughscotmanleycough?

[Drew Kerman]

Arrowstar: just had an idea, use it or tell me to get lost, your choice.

idea: what about making, or talking to someone who knows how to make, an instructional "how to" video covering the features of this tool? Coughscotmanleycough?

If he sets up a wiki, I'd be happy to contribute

[Arrowstar]

Handling it inside the program may not be doable as I suspected, but I noticed you didn't mention my import/export idea - did I explain that well enough? I realize now you don't even need the aerobrake mod, just export the orbit so you're set up for your atmo pass, let the game run, then import the new orbit after exiting the atmosphere. MA could treat it as a special dV maneuver that produces the forces to place the craft on the new orbit but doesn't expend any fuel mass.

Well, to be honest, couldn't you just do this now? I'm not sure why I'd have to do anything special in MA in order for you to let the game run through an atmosphere and import an orbit on the other side. And there's no need to "export" an orbit if you import your current orbit in KSP in MA first.

@Arrowstar:

Thanks for the help. Got the optimization figured out. I now have my mission plan to a 150kmx200km orbit around Mars from Earth. Thanks!

Is tehre any way to set the optimisation to alter the initial spacecraft properties? I'm sure I can have a much better initial orbit than I can figure out manually. Could be quite usefull.

There is not. You do have to have a known set of initial conditions for the optimizer to work. There are just too many factors in the initial conditions and the odds of you ending up with an "optimal" starting condition that isn't feasible or some such thing is actually pretty good. So just take your best shot at figuring out where you'll roughly be in orbit and go from there.

Arrowstar: just had an idea, use it or tell me to get lost, your choice.

idea: what about making, or talking to someone who knows how to make, an instructional "how to" video covering the features of this tool? Coughscotmanleycough?

I actually tried sending him a link to this thread on Reddit once but I didn't get a response. I'd love it if Scott did a video on KSP TOT though, would be very cool. Feel free to suggest it to him.

If he sets up a wiki, I'd be happy to contribute

I actually have no idea how to do that. I'd be fine with setting one up (assuming I learn how), but I don't think I'd have the time to contribute content, to be honest...

[Arrowstar]

Playing around with lighting and camera settings...

[Arrowstar]

Hi Gaiiden,

I think I may have found the longitude issue with Kerbal Engineer. I wasn't able to find the call out for spacecraft longitude, but I was able to find it for impact longitude (whatever that is). Anyway, it shouldn't matter, because if they're not being computed the same the results would be inconsistent, and I have to believe that KER has an internally-consistent longitude calculation. So here it is:

 //calculate time to impact
impacttime = vessel.orbit.timeToPe - timetoperiapsis(impacttheta);
//calculate position vector of impact site
Vector3d impactpos = radiusdirection(impacttheta);
//calculate longitude of impact site in inertial reference frame
double impactirflong = 180 * Math.Atan2(impactpos.x, impactpos.y) / Math.PI;
double deltairflong = impactirflong - currentirflong;
//get body rotation until impact
double bodyrot = 360 * impacttime / vessel.mainBody.rotationPeriod;
//get current longitude in body coordinates
double currentlong = vessel.longitude;
//finally, calculate the impact longitude in body coordinates
impactlong = normangle(currentlong - deltairflong - bodyrot);

Notice that the initial rotation of the body never shows up in the code. It appears the code assumes that at t=0, the body's x-axis is always aligned with inertial x. I suspect that this is the source of the discrepancy. What do you think? (Btw, the code above starts at line ~500 of FlightEningeer.cs in the KER github repo.)

[ANWRocketMan]

@Arrowstar: Damn. Thanks.

Figured out how to get the initial orbit in the same plane as the ejection though. Not sure if it's the perfect way to do it but it seems to work.

Thanks for the help!

EDIT: Just another question, sorry. Is there any way to determine when a reference ground station moves underneath the spacecraft orbit? I can determine this using several plots with the graphical analysis tool and distance to ground station and using the lowest distance as a guide(say below 200km it's more or less above it) but I need to run a minimum of 35 of these to get this accurately. Is there a quicker way to do this?

Sorry for bothering so much.

Edited September 21, 2014 by ANWRocketMan

[Arrowstar]

EDIT: Just another question, sorry. Is there any way to determine when a reference ground station moves underneath the spacecraft orbit? I can determine this using several plots with the graphical analysis tool and distance to ground station and using the lowest distance as a guide(say below 200km it's more or less above it) but I need to run a minimum of 35 of these to get this accurately. Is there a quicker way to do this?

Sorry for bothering so much.

Hey, no worries, the more questions the merrier! Keep them coming (it's not a bother at all).

So is it possible? Yes. But is it easy? Not really, no. What you would have to do is find the plane of orbital motion (defined by its orbital angular moment vector) and then determine the great circle on the sphere of Kerbin that represents the intersection of the orbital plane and the sphere. Once you have that, you could write a function that describes the inertial position of your ground station w.r.t. time. Finally, you would find when your position function lands on the orbital plane great circle and back out the time of the crossing from there.

As I said, not really easy.

Now if you're just interested in when the spacecraft is above the ground station, then just look for when your latitude/longitude match the ground station lat/long and away you go.

Let me know if that helps any.

[bk2w]

Sadly, it's not this easy. You can only compile MATLAB programs for the version of MATLAB you are running. In my case that's R2013a. Now, luckily for you, I'm considering going to R2014b whenever The MathWorks decides to release it (will be soon, matter of days or weeks I think). If I do, that should help you out I think.

Brian, any thoughts to help him out in the mean time?

At this point, I'm down to googling around for similar problems.

So far I see that to install MCR R2013a you need:

- Java 6 SE (available from http://support.apple.com/kb/DL1572?viewlocale=en_US&locale=en_US)

- no other MCR version installed (uninstall instructions: http://www.mathworks.com/help/compiler/working-with-the-mcr.html#bs6mchw-1)

I'm unable to remove Java 6 from my machine (Apple made it darn near impossible), so I can't really replicate the problem that AppleDavidJeans is running up against. All I can suggest is to delete all version of MCR, make sure that Apple's Java 6 SE is installed, and try to install MCR R2013a.

-Brian

[ANWRocketMan]

Hey, no worries, the more questions the merrier! Keep them coming (it's not a bother at all).

So is it possible? Yes. But is it easy? Not really, no. What you would have to do is find the plane of orbital motion (defined by its orbital angular moment vector) and then determine the great circle on the sphere of Kerbin that represents the intersection of the orbital plane and the sphere. Once you have that, you could write a function that describes the inertial position of your ground station w.r.t. time. Finally, you would find when your position function lands on the orbital plane great circle and back out the time of the crossing from there.

As I said, not really easy.

Now if you're just interested in when the spacecraft is above the ground station, then just look for when your latitude/longitude match the ground station lat/long and away you go.

Let me know if that helps any.

it does, in some ways. Thanks!

For extra challenge I will write that code in assembly language on an 8051 micro.

[Arrowstar]

it does, in some ways. Thanks!

For extra challenge I will write that code in assembly language on an 8051 micro.

I look forward to seeing that code in action.

Here's another view of what I've whipped up this afternoon with the Mission Animator. It's coming along nicely, don't you think?

[Drew Kerman]

Well, to be honest, couldn't you just do this now? I'm not sure why I'd have to do anything special in MA in order for you to let the game run through an atmosphere and import an orbit on the other side. And there's no need to "export" an orbit if you import your current orbit in KSP in MA first.

Ah, I see what you're getting at. What I was describing however was solely a planning method prior to mission launch, not actually something occurring during the mission itself - in which case yea what you said. For better context I'll start from the beginning of a theoretical Eve mission plan, with a rough idea of how this might be implemented in MA. You run the porkchop plot, get your departure burn and set up MA so you're hitting Eve's SOI, then optimize down until your Pe is within the atmosphere. So you have four states: SET_STATE (Initial State), COAST (to True Anomaly), DV_MANEUVER (Proscribed), COAST (to Pe). Now, you select a new state from the drop-down: "Aerobrake Maneuver" under the Maneuvers list (c'mon you know you wanted something more there ;P). MA prompts you "Select a craft for aerobrake", which pulls up a list of orbiting vessels via KSPTOTConnect. It also supplies a Delta UT field, which is how long prior to Pe you want to insert the craft. We'll say our Eve Pe is only a few km into the atmosphere so 10 minutes prior will be far enough to be out of the atmosphere when the craft loads. After you supply the delta time, you pick the craft and KSPTOTConnect adjusts that craft's orbit to be on the trajectory of your MA plot into Eve's atmosphere. (Like Hyperedit does to place craft in orbits). You then let the game run the craft through the atmosphere. Once out, you can return to MA, which is waiting for you to answer the "Aerobrake pass complete?" dialog. With "Yes" ("No/Cancel" would cancel and remove the event) it will fetch the new orbit of the craft. Now you can insert a COAST (to Ap) event after the Aerobrake event to see the effect the aerobrake had on your trajectory. The Aerobrake event itself, as far as MA is concerned, would be a computed dV maneuver that doesn't subtract any fuel mass. In other words MA would treat it as you did a burn at Pe to get onto your new orbit. So the final mission plan at this point would be SET_STATE (Initial State), COAST (to True Anomaly), DV_MANEUVER (Proscribed), COAST (to Pe), AB_MANEUVER, COAST (to Ap). If you wanted to do additional dips, just replace the COAST (to Ap) event with COAST (to Pe) and repeat the process with another AB_MANEUVER event.

Note that I'm aware to place the craft the UT of the game would need to be adjusted - obviously this process of performing the "simulated" aerobrakes would take place in a save file that isn't a user's main save.

Again the idea behind this is a pre-planning method to work aerobraking into the entire mission plan prior to launch instead of having to just aim for the atmosphere while planning, stop planning and work things forward from there once you're actually flying the mission and are back out of the atmosphere to see the effects. Unless that's how you guys really do it

I actually have no idea how to do that. I'd be fine with setting one up (assuming I learn how), but I don't think I'd have the time to contribute content, to be honest...

Yea me neither. You're not on GitHub so can't make use of the project wiki. A basic one however shouldn't be too troublesome to set up. As far as maintaining goes - I wouldn't expect you to bother spending time on contributing content. You develop the software, we use it - we can write stuff on it. You can continue to answer questions that will help us write better docs and also review the wiki to ensure things are accurate.

I think I may have found the longitude issue with Kerbal Engineer... What do you think?

I think I suck at math (actually I know I do) so I can't really confirm your observations. Definitely posit it to the Engineer folks as they did admit such a thing was probably present in the rough code used for the alpha version I had loaded for testing.

Here's another view of what I've whipped up this afternoon with the Mission Animator. It's coming along nicely, don't you think?

Better than I ever imagined 0_0

[Arrowstar]

Ah, I see what you're getting at. What I was describing however was solely a planning method prior to mission launch, not actually something occurring during the mission itself - in which case yea what you said. For better context I'll start from the beginning of a theoretical Eve mission plan, with a rough idea of how this might be implemented in MA. You run the porkchop plot, get your departure burn and set up MA so you're hitting Eve's SOI, then optimize down until your Pe is within the atmosphere. So you have four states: SET_STATE (Initial State), COAST (to True Anomaly), DV_MANEUVER (Proscribed), COAST (to Pe). Now, you select a new state from the drop-down: "Aerobrake Maneuver" under the Maneuvers list (c'mon you know you wanted something more there ;P). MA prompts you "Select a craft for aerobrake", which pulls up a list of orbiting vessels via KSPTOTConnect. It also supplies a Delta UT field, which is how long prior to Pe you want to insert the craft. We'll say our Eve Pe is only a few km into the atmosphere so 10 minutes prior will be far enough to be out of the atmosphere when the craft loads. After you supply the delta time, you pick the craft and KSPTOTConnect adjusts that craft's orbit to be on the trajectory of your MA plot into Eve's atmosphere. (Like Hyperedit does to place craft in orbits). You then let the game run the craft through the atmosphere. Once out, you can return to MA, which is waiting for you to answer the "Aerobrake pass complete?" dialog. With "Yes" ("No/Cancel" would cancel and remove the event) it will fetch the new orbit of the craft. Now you can insert a COAST (to Ap) event after the Aerobrake event to see the effect the aerobrake had on your trajectory. The Aerobrake event itself, as far as MA is concerned, would be a computed dV maneuver that doesn't subtract any fuel mass. In other words MA would treat it as you did a burn at Pe to get onto your new orbit. So the final mission plan at this point would be SET_STATE (Initial State), COAST (to True Anomaly), DV_MANEUVER (Proscribed), COAST (to Pe), AB_MANEUVER, COAST (to Ap). If you wanted to do additional dips, just replace the COAST (to Ap) event with COAST (to Pe) and repeat the process with another AB_MANEUVER event.

Note that I'm aware to place the craft the UT of the game would need to be adjusted - obviously this process of performing the "simulated" aerobrakes would take place in a save file that isn't a user's main save.

Again the idea behind this is a pre-planning method to work aerobraking into the entire mission plan prior to launch instead of having to just aim for the atmosphere while planning, stop planning and work things forward from there once you're actually flying the mission and are back out of the atmosphere to see the effects. Unless that's how you guys really do it

Okay, I understand what you're looking for. As great as it sounds, I'm not sure that trying to run MA and KSPTOTConnect next to each other would be a great idea. Trying to optimize a mission plan would be a nightmare in network lag (compared to the speed of other calculations), for example. It also just feels... clumsy, maybe that's the right word? I think it's just the idea of having to have people use KSP and KSPTOTConnect to use what's otherwise a nominally off-line only tool that bothers me.

However. What you're really after is just aerobraking calculations, right? Okay. Go ahead and take a look at this document. It turned up in a bit of Googling that I did just now and describes an analytic model for approximating delta-v due to drag during an aerobraking maneuver. I would certainly be open to investigating adding something like this to Mission Architect. A few caveats:

1) Users would be required to provide the C_d * A for their spacecraft, though I could provide a small calculator for this if you try some experiments in KSP and provide the relevant data;

2) I would be modeling the delta-v due to drag as a point delta-v. Therefore the trajectory modeled would only be reasonable outside of the atmosphere. This is because the drag affects your spacecraft at all times while you're in the atmosphere, but a point delta-v only affects the spacecraft at one instant.

3) I'd have to add atmospheric scale heights to the bodies.ini file (and get KSPTOTConnect to spit it out when you ask to build a bodies.ini file from KSP itself), but that shouldn't be too much work.

How would this work for you?

Yea me neither. You're not on GitHub so can't make use of the project wiki. A basic one however shouldn't be too troublesome to set up. As far as maintaining goes - I wouldn't expect you to bother spending time on contributing content. You develop the software, we use it - we can write stuff on it. You can continue to answer questions that will help us write better docs and also review the wiki to ensure things are accurate.

I'm looking at moving to Github whenever it becomes feasible for MATLAB code to be hosted there. I think the upcoming version of MATLAB, R2014b, should have native Git support, and if it does (and I decide to pick up said version of MATLAB), I'll create a repo. We can add the wiki there.

I think I suck at math (actually I know I do) so I can't really confirm your observations. Definitely posit it to the Engineer folks as they did admit such a thing was probably present in the rough code used for the alpha version I had loaded for testing.

Can you link me to the post where the admit that? I need some context...

Better than I ever imagined 0_0

Great! Here's another screenshot that I thought turned out nicely.

Also, I'm delighted to announce that since Mission Animator is coming along so nicely, I'll (probably) be releasing an early working version (what you see here, basically) with v1.1.7 (instead of waiting until v1.1.8 and disabling it in the mean time)! Good times!

[Galane]

Hey, no worries, the more questions the merrier! Keep them coming (it's not a bother at all).

So is it possible? Yes. But is it easy? Not really, no. What you would have to do is find the plane of orbital motion (defined by its orbital angular moment vector) and then determine the great circle on the sphere of Kerbin that represents the intersection of the orbital plane and the sphere. Once you have that, you could write a function that describes the inertial position of your ground station w.r.t. time. Finally, you would find when your position function lands on the orbital plane great circle and back out the time of the crossing from there.

As I said, not really easy.

Now if you're just interested in when the spacecraft is above the ground station, then just look for when your latitude/longitude match the ground station lat/long and away you go.

Let me know if that helps any.

MechJeb's Landing guidance does that. If the orbit is angled enough so that the chosen target will cross the orbit plane it'll warp until it's in the right spot to land without changing inclination. If the target won't cross the orbit it will do a course correction - usually. Sometimes it just gives up partway through. It also has some issues starting landings (and doing other things) below 100KM altitude. Works best when the starting orbit is circular.

Sooo, yeah, hard to do but not impossible.

[Arrowstar]

Another teaser. I added the ability to show the spacecraft defined in the Mission Architect "Other Spacecraft" dialog box. I think it looks pretty neat, and I'm sure you could do some interesting visual analysis with it, as well.

[AppleDavidJeans]

Another teaser. I added the ability to show the spacecraft defined in the Mission Architect "Other Spacecraft" dialog box. I think it looks pretty neat, and I'm sure you could do some interesting visual analysis with it, as well.

http://i.imgur.com/IfPzL8m.gif

So like it could even predict flybys of other satellites and maybe even collisions? lel

[Drew Kerman]

Okay, I understand what you're looking for. As great as it sounds, I'm not sure that trying to run MA and KSPTOTConnect next to each other would be a great idea. Trying to optimize a mission plan would be a nightmare in network lag (compared to the speed of other calculations), for example. It also just feels... clumsy, maybe that's the right word? I think it's just the idea of having to have people use KSP and KSPTOTConnect to use what's otherwise a nominally off-line only tool that bothers me.

Still a teeny bit of misconception between us I think I'm pretty sure I know where it is though. When I said the user would return to MA and prompt it to fetch the new orbit, I didn't mean to imply that during the time the game is running MA is continually streaming anything via KSPTOTConnect. Here's a flowchart I hacked together real quick:

So the idea is you have the original orbital state (A) - which is what MA calculated to get your craft Pe just outside the atmosphere, and then you are providing MA a second orbital state (, which is the new orbit of the craft after exiting the atmosphere in the game. The only real legwork MA has to do is to calculate the dV needed to get your craft from state A to state B. I don't mean for that to sound simple, because it probably isn't. But that's all I was meaning for MA to do - possibly with an internal run of the optimizer that uses the new orbital parameters as constraints. Again this would appear to MA as a burn at Pe that doesn't use any fuel mass.

I just created a Duna mission to 30km Pe and set the COAST event to 10 minutes prior to Pe. However when I tried to load a craft onto this orbit using the Final State data and Hyperedit, it told me the craft was out of Duna's SOI. I tried manually editing the save file (looked up the parameters in the KSP wiki to make sure proper info was being assigned) and the game just deleted the craft. I wanted to run the craft through the atmosphere, and then import the new orbit into a new SET_STATE and see how MA reacted. I think I just didn't set the parameters right for a hyperbolic orbit.

So instead I Hyperedited a craft high around Kerbin and burned to lower my Pe within the atmosphere. I loaded this orbit into MA, coasted a few mins prior to Pe, then created a new state once the craft had left the atmosphere with the new orbit. MA reacted by saying my ship landed and took off again. In the aerobrake scenario I described, it would properly connect the orbits.

Both mission files are uploaded here.

However. What you're really after is just aerobraking calculations, right? Okay. Go ahead and take a look at this document. It turned up in a bit of Googling that I did just now and describes an analytic model for approximating delta-v due to drag during an aerobraking maneuver. I would certainly be open to investigating adding something like this to Mission Architect. How would this work for you?

If my clarifications above still don't turn my idea into a feasible method, an approximation like this would be totally cool. It would actually be more realistic really since even real world aerobrakes I don't think can 100% accurately predict their results, as my in-game method would for a given trajectory.

Can you link me to the post where the admit that? I need some context...

Here.

Another teaser. I added the ability to show the spacecraft defined in the Mission Architect "Other Spacecraft" dialog box. I think it looks pretty neat, and I'm sure you could do some interesting visual analysis with it, as well.

Yup, this was exactly what I was imagining in my Duna probe scenario, which I came up with after I noticed the "Other Spacecraft" box.