PhoenixBvo

I meant the overall effect is less pronounced, mainly due to the frequency of stutters. But it is indeed hard to tell whether the stalls are also shorter. I'll have to look at it again. I forgot to mention, but I observed the same behavior on two different machines: a Core i7 860 and a Xeon X5647 both on Win64. I'm running KSP from an external USB3 HDD. The stutters with 1.4.2 were similar on both machines. I might be able to do some testing over the weekend. Perhaps I'll record some short videos with Fraps for you to look at.

OK, so I tried with 1.5.0 and although the issue is still there ( new log entry: ) [WRN 19:21:33.172] ContractConfigurator.ContractPreLoader: Contract attribute took too long (0.1516724 seconds) to generate: FS_HardScience[scienceSubjectsTemp1] the stutters have become less pronounced. With 1.4.2 I got a short freeze every second or so and now it is every 3 to 4 seconds. OK, so an improvement is there , but for now I'll just remove that contract and if another one should produce stutters, I'll let you know. Thanks for your work btw, I really like those contract packs.

Hmm, I'm running 1.4.2. OK, i'll update and let you know tomorrow.

Concerning lag, I have a report that might help: After I activated the "Field Research: Temperature scan experiments on the Mun" contract, I got stutters with any spacecraft I flew. By removing contracts from the sfs-file I narrowed the cause down to the mentioned contract. I then checked the KSP.log and found [WRN 17:21:33.342] ContractConfigurator.ContractPreLoader: Contract attribute took too long (0.1782837 seconds) to generate: FS_HardScience[scienceSubjectsTemp1] and similar messages written at the time of stutters occuring. I have 7 other contracts active among which one other Field Research contract: "Field Research: Help a scientist perform experiments at the Mun's Midlands." But removing that one did not remove the stutters. Hope this helps and let me know if you'd like more info. Cheers

Those console screenshots look pretty in-depth. I take from it that you can basically get any info you need from KSP and possibly send stuff back for remote control? Looks awesome! Thanks for your work on this. The possibilities you opened up with KSPTOT are endless. PS: I sent you a PM with some code...

So in "Real Life" astrodynamics we don't really even do this. All of our maneuvers are based off the spacecraft separation time and then, to compute a launch window, we just assume "x minutes" to orbit. In fact, my primary mission planning software for "real life missions" has no knowledge of spacecraft launch time at all. It relies on the user to do the subtraction if needed. I feel there is an under-appreciated relevance to this question. Referring to the planetary transfer tutorial, you are using a perfectly circular "dummy" parking orbit for the departure burn in the pre-planning phase. This results in an ideal orbital position for the burn. Now we launch at the proper departure time "minus a bit so we have time to get to orbit and set up the burn". This gets you into an orbit which may have the shape of the dummy orbit entered while planning, but you will be in a random phase, i.e. position for a given time in this orbit (true anomaly at epoch is undefined). This results in situations where you're nearing the ideal departure burn time, but you're on the opposite side of the planet... Although you explain that "You can enter in this new departure time into KSP TOT, get a new set of delta-v values, and re-enter those into MechJeb", this may be quite sub-optimal. But getting the most bang for your propellant is what KSP_TOT is all about, right? So, I propose a procedure which takes two launch parameters: lambda, the angle from the launch pad to the circular orbit insertion point and DeltaT_L, the time elapsed from launch to circular orbit insertion. (You may obtain these empirically, e.g. by test launching) The goal would be to resolve the phase of the parking orbit, so you arrive at the correct true anomaly at the ideal departure burn time, or at least close to it.... I hope this makes sense. I could at least not replicate the "about 13 seconds early arrival" for the tutorial example. For me, it was more like 15 minutes and that seems to matter in terms of delta V. Just some thoughts.

Yes please! I'll see if I can adapt the ESA solver to work with your bodies.ini, this might be useful for comparison and validation of complex trajectories.

This looks very good indeed Arrowstar. The recent progress with the plugin looks promising. I'd like to try it out. I wanted to run TOT from source under Matlab, but ran into some trouble with undefined functions (like optimoptions and createOptimProblem). It seems these are part of the Global Optimization Toolbox. Can I substitute some optimization routine from the "normal" Optimization Toolbox? On another note, I'm interested in multiple gravity assist trajectories and found this project from ESA: http://www.esa.int/gsp/ACT/inf/projects/gtop/gtop.html They also have a working solver available for Matlab. Perhaps you can use some of it? Anyway, I have to try out the flyby maneuver sequencer, but some global optimization of a given flyby sequence might be nice to play with in KSP TOT... Keep up the good work!