AndyMt

I experienced the staging problems with 2 different pure stock craft, without any other mods installed than GT. @NeuroticGamer: So you say with that craft file the problem is reproducible? That would be fantastic! Looking at the screenshots and the log files at first glance it doesn't seem to be a problem with the staging code as such, but rather something with GTs state event machine. Which means the additional logging and debug information I generated is in the wrong place... I'll try to use your craft file and hope to reproduce the problem.

In the meantime this strange "does not stage sometimes" effect happened to me, too. But only 2 times and I was never able to reproduce again. So I added some diagnose display and more log entries temporarily. Here is a pre-release of the next version someone affected by this please try: https://github.com/AndyMt/GravityTurn/releases/download/V1.7/GravityTurn_1.7.zip This actually should have been the 1.7 release, but I don't dare to release this officially. So - whoever conveniently put V1.6.1 on CKAN: please wait with this one! This version contains a lot of new stuff (see GitHub Milestone 1.7 for details): Storing default parameters for new crafts locking parameters so they are not overwritten. autostaging of top fairings and interstage fairings. option to speedup of launches via timewarp smother pitching maneuvers Some bugfixes (like the problem with detecting other mods). So now for those who want to help testing and diagnosing the staging problem: open the stats window during the launch and keep it open press the Alt-Key for a few moments The stats window will extend with additional information When the staging problem happens => make a screenshot => copy the log file And post it here somehow. I haven't updated the starting thread of this post. I'd like to first iron out this staging problem.

That's exactly the piece of code I had in mind, too. So I'll change it to the suggested alternative way of detecting a loaded assembly. I still cannot reproduce the problem on my machine. But I guess it depends on the order of how the mods were loaded. If GT finds MJ before it has to iterate CC then it won't fail. @nightingale: which also means - not only mods which use the toolbar mod are effected: it is all mods which have to detect a specific loaded assembly. Yes, I noticed that, too. The reason was that the calculation of TWR was broken because of 1.2, then always 100/10 is used as default. So - I fixed that for the next release and now there is always an initial guess if TWR is > 1.2. @Jovus: You can find the calcuation of angle and speed in GravityTurner.CalculateSettings(): if (TWR > 1.2) { TWR -= 1.2; TurnAngle = Mathf.Clamp((float)(10 + TWR * 5), 10, 80); StartSpeed = Mathf.Clamp((float)(100 - TWR * 30), 10, 100); }

hm - I have to try to install it myself via CKAN then, because obviously I've never done that... Of course a log file will help.

Thank you for pointing me at this. But actually GravityTurn doesn't use the Toolbar mod. So which part or how is the mod broken? I did some tests together with Contract Configurator and everything worked. The only code looking remotely similar in GT is the detection of MechJeb based on assembly name. But MechJeb detection worked as well. I still assume GT is affected by this bug, but I just can't reproduce it. So please help me out with some more information.

Ok, for now I've implemented a "save defaults" button which stores all parameters of the current craft to a default config file (locked and unlocked). When loading a new craft GT will load these parameters and will then apply the "First guess" calculation on all unlocked parameters. Where locked/unlocked consequently will be set to what they are in the default config. That's the easiest solution I can implement for the next release before I redesign and restructure the UI which will be up for the next-next release. Good point! So I'll keep it as is.

Fairings behave strange sometimes in 1.6.1. But I think I've figured this out and it will be fixed with the next release. Here is the project and issue tracker on GitHub for anyone who is interested: https://github.com/AndyMt/GravityTurn/projects/1 100 is pretty low. The default is 10000 which I think is still too high. As aerodynamics changed since GTs initial release I consider to lower it to 1000.

If that happens no configuration is loaded and no learned data during previous launches - even if this is the same vehicle. One occasion this happens (I think) is if you share vehicles across saves.

Now I have 3 ideas I'd like to discuss: Speedup: With GravityTurn a vehicle takes quite long to get into orbit: what about a "autowarp" feature? Especially after the apoapsis reaches the destination height, things could be speed up until the vehicle leaves the atmosphere. Then when MechJeb takes over it would warp to the circularisation burn. During critical phases like the initial pitch over and also when pitching orbital prograde higher up, time warp would be disabled. Pitch speed: currently GT tries to pitch over as fast as possible. The angle of attack can get quite high and it can result in wobble for structurally unstable vehicles. So I changed the pitch maneuvers so they take around 3 seconds now. Which of course changes the efficiency figures for a specific speed/angle/vehicle combination slightly. It's generally more efficient now because of reduced drag by a very small amount. Locking parameters: I'm almost done with that one. But what values should locked parameters have for a new vehicle you launch the first time? I've now implemented the following: every locked parameter is stored in a default config file. When GT finds a vehicle which doesn't have any stored config it will load the default config file (with the locked parameters of the last launch) and then run the "improve guess" feature once. Which is renamed "First Guess" now if it doesn't have previous data. Speedup I will certainly make an option, but what about pitch speed and default parameters ? What do guys you think? A general question: Launch parameters are stored by vehicle ID, which changes kind of "often". I think about changing this to using the vehicle name+celestial body instead.

I've identified some cases where staging doesn't work, for example when using parts with custom modules, like non-stock procedural fairings. And Rapier engines won't auto stage, too. But most of the time it works and sometimes it doesn't? I haven't observed that yet. I identified and fixed some bugs I must have built in during de-linq-ing the code. Maybe that will solve the issue.

I see . I was also in doubt if turn angle and height should be in the "Simple" tab. I'll consider the end staging in any case. Probably we will end up with a "Custom" tab in the end where everyone can combine the parameters they want...

I actually don't know exactly - bear with me, I haven't analysed all the code (yet). Looking into it briefly it looks like it takes the "Total Loss" values of each launch to calculate the next suggestions. Which means you can revert any time, but the earlier you revert, the more "guestimated" the total loss will be. I usually revert when the apoapsis reaches the destination height. This way I don't have to wait for the vehicle to reach orbit. The original development thread might contain the exact description. I'm thinking about a tabbed UI where the tabs would be "Simple", "Standard" and "Advanced". Simple: only the most basic parameters will be shown (turn height, turn speed, destination height, inclination). Standard: the UI we have right now with staging and stats as separate popups on request. Advanced: Same as we have now, plus staging parameters and the stats all in the same window again. But I'm not sure if this is the way to go.

No worries, the next release will have a "lock" feature for every parameter. Here's a sneak preview what that will look like: So you will be able lock the parameters (per vessel) which you want to have different from the defaults and won't be modified by the "Improve guess" or "Previous Best Settings" (not sure about the last one). Note: UI design and button labeling not finalized! I changed the AP times to 50 because they generally result in more efficient launches. I also changed sensitivity because throttling an engine down to 20% is just not realistic. But I noticed that in KSP scale this results in some issues for some launches. So I'll change the default to 30% with the next release. I'll follow that thread and thumbs are pressed!

New release V 1.6.1 >download< Changes: Bugfix: Circularization with MechJeb didn't work. Looks like GT used an old API for creating and updating maneuver nodes. Fixed now. MechJeb integration tested with MJ dev version 2.5.9.642. Now I will really try to implement the next features...

Thanks a lot. I kind of expected this as I didn't have a MJ version which worked with 1.2 before I released GT 1.6 - well I wasn't aware of it to be honest. I'll look into it soonTM. Until then - it'll be a known issue and you would have to circularize manually. Hm... actually you can't because MJ integration is automatic. If it turns out to be more complicated I'll just make MJ integration an option and do an intermediate release. And as stated in the 1st post: "The 1.2 release might brake this mod".

Yes, that was part of the whole "remove garbage" task . If I missed something please let me know. Looking into history it most probably will be tomorrow in my time zone ;).

I'm not sure if my phrasing was ambiguous: the calculations are only done as long as the stats window is open. If you close it, there's no impact. Furthermore you can only open the stats window if you have opened GT at least once for that vehicle. The calculations work exactly the same way as while GT is performing an automated launch, so threading and calculations are no different.

New release V 1.6 >download< Changes: Stats window shown in (optional) separate window. In GTs main window you can now toggle an option to show the launch statistics in a separate window (off by default). The stats window remains open even when you close the main window. Stats window updates during manual launches. Stats are always updated while the stats window is open and the vehicle is not landed. Also during manual launches without using GT. Using new KSP skin with smoother fonts. The skin is changed to the more modern skin using vector fonts. Still not scaleable (I think). Reduced memory usage and garbage. Removed Linq from all source files, replaced by Smooth.Slinq in some cases. Most foreach loops converted where they produced garbage. Garbage production reduced to roughly 1/10th. @okder: I'll incorporate your changes in one of the next releases in some form or the other. I just hope tomorrows 1.2 release won't break this plugin...

That's how I'm used to doing it for 20 years or more now... Except that the IDEs and designer tools for the "create once" part got much better during that time. So I think it will be easier for me to understand and I'll try the Unity editor and loading assets. If you could please point me to one of those discussions, I haven't spotted them yet. As soon as (if) you've updated MJ I want to think about an elegant way of sharing components or code between the 2 plugins. Yes, sure I'm interested in providing an API like MechJeb does (as an example). But first I have to refactor the whole thing.

Just an idea: you might look into what the StageRecovery mod is doing. Because I think this is exactly covering the "fall back into atmosphere and recover the thing" part. So as a start you could just implement thrusting retrograde and then let StageRecovery do the rest of the job.

So - I've de-linq-ed the plugin now - and by doing that introduced some new bugs I'd like to iron out first before the next release. I've noticed a considerable amount of GravityTurn's code is 1:1 copies from @sarbian's MechJeb. I'll update the thread before the next release to reflect that. But this fact helped me to de-linq these parts "easily". Garbage is now reduced to below 10% of the initial amount. Currently it's just the UI which seems to be causing all the rest of the garbage. The way the UI is shown seems a bit strange - it's drawn and layouted every frame... But maybe that's the way UIs work in Unity (WinForms and WPF is my world). I'll check some other Plugins to see how they do it - and learn how to make the UI scaleable in the process. I prepared the debug version of the dll to be used with @Kramer's Kramax Plugin Reload, so I don't have to restart KSP every time I change something . This helps enormously! Now I have to figure out how to actually use the debugger with it. Just cannot attach to the KSP process... Any ideas?

@hab136Thanks for that wiki entry, now I know more. Looks like foreach won't be an issue in this particular case - there aren't many and most are not affected. But I'll rewrite them anyway - just as second priority. I looked into de-linqing the plugin. Well - most files have the "using System.Linq" just in there but don't actually use it. Then there are 4 files left which actually make use of it. 2 of them should be easy to de-linq but FuelFlowSimulation.cs and StageController.cs look much more complicated. I've never used Linq in any "real" project - just because I find it hard to read. Too much of "syntactic suggar" if you ask me. So I might have one or the other question in certain cases. But I'll give it a go.

I will definitely look into the memory garbage issue. Using mainWindow.WindowVisible is not a good idea because GT can still do it's job and be hidden after launch. But if(Launching) looks like the best way to do it as a first fix. I was under the impression that de-Linq-ing is not necessary if you compile with Visual Studio? Because it compiles foreach differently? Regarding feature requests: @5thHorseman: I intended to make the statistics part a separate window anyway - so I'll think about this. ^^^^^^^^^^^^^^^ how do I "mention" someone and make the username formatted in this blue box?

I just tested this mod with 1.2pre - and it works! @Kramer: thank you so much.

That is definitely one of the next things I'll implement. I'm thinking about a "lock" toggle behind each parameter. Press it and it won't overwrite that parameter and use the last one - stored somewhere... Thanks for the input - I thought I've excluded the dll, but I'm using this Visual Studio Git plugin for the first time, I should have checked... And of course I'll move the license file. The "compilation script" is a post build step in the VS project configuration. That's an excellent idea! Should be reasonable easy to implement: deltaV calculation exists already. So some additional parameter on the UI and then staging when dV value is reached. So that will be number 2 on the list. Number 3 will be optional "physics time warp to apoapsis".