drunkeNNN

crazy stuff...

Wow, this is a fantastic mod for KSP and a worthy successor to KOS. As an engineer, getting really into the math and physics of the game as a player makes the game so much valuable for me. I thought I had to wait a long while for a KOS alternative to appear, now its even one of the first mods out there! I really love the telemetry feature, especially the json-export. Fantastic work! Just three remarks. Would be useful to have the colors of the buttons tickmarks in the telemetry screen and the colors of the graphs the same. Currently, its difficult to keep up with whats plotted where in the graph if one uses multiple graphs at the same time. Would that be possible? Is it possible to change the font size of the mod? Together with MicroEngineer, my screen gets clogged really quickly (still playing on a 24 inch 1080p monitor :-/) Some of the scroll bar buttons disappear for me. Regarding the perspective ot this one: I can envision this mod integrated with a mech-jeb-like gui, where a default configuration is provided, however the user can modify the commands and add new ones. Would be kind of cool to have MechJeb on top of this mod. Your architecture seems sufficiently scaleable to do something like this.

Hey there. Thank you for your great work. I wanted to test the beta since I also end up with the access violation in mono.dll with the version from ckan. However, the link above seems to be dead for me...

Those were on default I believe. I suspected that the error is somewhat difficult to reproduce.

@Arrowstar Those are earth days. The error seems to appear statistically though. I set it to 200 runs and the error appeared in during iteration 20 or so.

The fix for Kerbin-To-Kerbin-transfers mostly works great. The weird results I got there are really fixed now with the new release. In the MFMS, a new graphics glitch arised. The plot in the main window is somehow messed up after running a Kerbin-Kerbin-Eve-Kerbin-Sarnus transfer. Another error that I got was the following: This happened also after evaluating a Kerbin(460d-500d, 0Rev)->Kerbin(70d-300d, 0Rev)->Eve(5-500, 1Rev)->Kerbin(100,600, 0Rev)->Sarnus transfer for a couple of times.

@Arrowstar: Are you interested in some code that improves the ga convergence towards the global minimum? I was playing around with some things yesterday and got some promising first results. It significantly reduced premature convergence towards local minima. This would reduce the need to run the solver 10-30 times to get what you want. First, I need to fix some stuff first however. In particular, there is a good amount of room for runtime improvements ;-) My implementation is quite hacky at the moment. The matlab interface is really restrictive in terms of data access there. I'll also test the third prerelease this evening and give you some feedback on it.

Thank you for the quick update to allow multiple revs in the MFMS in version 1.5.8. You're awesome. I have been trying to find a good Kerbin-Kerbin-Moho-transfer but did not have any success with it yet. There seems to be something odd with the solver. Try the following: Do a Kerbin-Kerbin transfer with a flight time of 430 to 450 days (so about one Kerbin year) and set the number of max revs to 1.0. Then do a standard transfer to Duna within 60 to 100 days. Very often I end up with a solution that has an orbit far larger than Kerbins orbit but the Kerbin arrival time shows about 1 Kerbin year (but I would say its rather 2 years). Are you sure the flight time is correct for multiple revs? The idea of this set-up would be to find a burn that changes the orbits radial component at departure but to keep the orbital time constant at the same time. That way, one would arrive at Kerbin after one revolution at an angle which gives the possibility to get a decent amount of energy.

That sounds great. Maybe I just had bad RNG luck with the optimizer there. I do agree that including the inclination component is computationally not feasible. But I dont think that a good estimate of the injection and ejection dv requires a lot of computation time if you already optimize the hyperbolic excess velocity. The dv needed is fairly straightforward to compute using energy conservation if you neglect inclination changes. After simplification you end up with: dv_inject=sqrt(v_inf^2+2*mu/R)-sqrt(mu/R) All this requires are two additional user parameters (the radii of the circular orbits R). According to the formula the circularization burn dv is not that different when the excess velocity is below the escape velocity of the associated circular orbit. For example, departing from a 100km orbit around Kerbin with an excess velocity of 500m/s costs 969m/s, departing with 1500m/s only costs 1267m/s, so you get additional 1000m/s for burning only 300m/s more. In contrast, leaving with 5000m/s costs 3678m/s while leaving with 6000m/s costs 3543m/s so you have to pay an additional ~900m/s. This means that the hyperbolic excess velocity generally isn't a good parameter to optimize for ejection and injection if that makes sense to you. Neglecting the inclination would not be a big deal here. A vessel can always be launched into the correct orbital plane and the arrival orbital plane can be easily changed with only a couple of m/s. If I understood you correctly, the current solution is good if one would always circularize at the edge of the SOI (where the associated escape velocity is basically 0) and for very small planets (where typical transfer excess velocities exceed the low orbit escape velocities). This was the reason why I was interested in the feature.

I've just started to get into KSP TOT and have to say its a really great tool overall. I also ran into the fact that multiple revolutions are not considered in the MFMS. Especially for the inner planets, that would be useful. In particular, that should make it possible to use a Kerbin as the first bouncing point (just like ESA did at the beginning of Rosetta). Another thing that I wonder is whether the MFMS also optimizes the excess vel at the final destination. Very often I do end up with extremely high velocities which basically makes the solution impractical (typically, you would not want to fly by the body but rather enter orbit at least I do :-) ) Related to that: is there a way to also minimize the injection burn in the MFMS? I think that would greatly improve the usability of the tool.