[1.4][1.7.7] GravityTurn continued - Automated Efficient Launches

[NeuroticGamer]

Quote

2 hours ago, volcanicshrimp said:

When I tried to use this mod in 1.2 to launch a rocket (meant to be SSTO and reusable but idk if it actually is yet), it insisted on detaching the second stage fairing on launch, even when I decreased the pressure to detach them at to 100.

 

Shouldn't that be 0, not 100?  Pressure is higher at ground level in an atmosphere.

[AndyMt]

6 hours ago, volcanicshrimp said:

When I tried to use this mod in 1.2 to launch a rocket (meant to be SSTO and reusable but idk if it actually is yet), it insisted on detaching the second stage fairing on launch, even when I decreased the pressure to detach them at to 100.

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

3 hours ago, NeuroticGamer said:

Shouldn't that be 0, not 100?  Pressure is higher at ground level in an atmosphere.

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.

[AndyMt]

On 21.10.2016 at 3:36 PM, plague006 said:

For locking and defaults I'd like to see the 2 separated. That is, if I want my default AP to be 75 but a particular launch is 120, I don't want the 120 carried to the next new craft. Similarly if for a given flight I had 6-7 parameters locked for any given reason, I don't want them locked on my next new craft. A "setup" specifically for defaults would be what I'd like to see where I can set whatever defaults I want *and* choose whether I want them locked or not. For example I might like a default start m/s of 50 but don't want it locked if "improve guess" has a better value. Similarly if I want everything in an 85km orbit I *do* want that locked on every new craft at launch.

Just my 2 cents, love the mod. Way more efficient launches than I've ever been able to achieve.

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.

On 21.10.2016 at 4:14 PM, JAFO said:

Mmm.. I could go two ways on that.. I can see the advantages, but on the other hand, I don't necessarily want the old learned data to go with the ship. And when I start a new game, I'll often re-use the same names for new craft, as in an older game, particularly in the early stages of the game.. "Mun Lander 1", "Orbiter 2", "Orbital Rescue 1", things like that. Having GT assume it's the same craft as before, even if the design is quite different, could be problematic.

Good point! So I'll keep it as is.

[islanit]

Can you make a look on the following topic?

With Contract Configurator installed this mod is broken

Edited October 24, 2016 by islanit

[AndyMt]

2 hours ago, islanit said:

Can you make a look on the following topic?

With Contract Configurator installed this mod is broken

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.

[islanit]

The gravity turr Icon in the right bar doesn't appear. I've run another test with no more addons. Only gravity turn installed is fine. But as soon as the contract configurator is active no icon appears  in the right toolbar and the windows isn't showing up when i go to the launchpad. And it seems that i'm not the only one with this problem:

How can i help further? Are there any logfiles which can help? ContractConfigurator and GravityTurn Installed via CKAN

Edited October 24, 2016 by islanit
typo

[AndyMt]

32 minutes ago, islanit said:

The gravity turr Icon in the right bar doesn't appear. I've run another test with no more addons. Only gravity turn installed is fine. But as soon as the contract configurator is active no icon appears  in the right toolbar and the windows isn't showing up when i go to the launchpad. And it seems that i'm not the only one with this problem:

How can i help further? Are there any logfiles which can help? ContractConfigurator and GravityTurn Installed via CKAN

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.

[islanit]

Which logfile do you need?

For me the following lines from the ksp.log logs suspicious:

[LOG 22:59:43.265] GravityTurn : Starting
[LOG 22:59:43.267] GravityTurn : System.NotSupportedException: The invoked member is not supported in a dynamic module.
  at System.Reflection.Emit.AssemblyBuilder.GetExportedTypes () [0x00000] in <filename unknown>:0 
  at GravityTurn.MechjebWrapper.FindMechJebModule (System.String module) [0x00000] in <filename unknown>:0 
  at GravityTurn.MechjebWrapper.init () [0x00000] in <filename unknown>:0 
  at GravityTurn.GravityTurner.Start () [0x00000] in <filename unknown>:0 

 

[Jovus]

Out of curiosity, is there any possibility (or clues that you have, since you've worked on this) for the gravity turn to be flown by varying the kick angle and start velocity rather than the throttle?

 

ETA: Badly formed question. I'm not asking you to change your mod; I'm writing my own autopilot and I want to use those parameters instead of throttle (since I'm using RO and throttle doesn't vary), and I was hoping that, as you've done all the work behind this, I might be able to borrow a bunch of your work, so I'm asking if, in your opinion, the mathematics might be relatively easily portable to different parameters.

Edited October 24, 2016 by Jovus

[NeuroticGamer]

1 hour ago, AndyMt said:

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.

I have the same issue as @islanit.  My .NET experience says the problem (and the solution) are the same.

Here is my KSP.LOG for the same issue: https://drive.google.com/open?id=0BxCPohKyyq63X0NDM2NFajhoRWM

FindMechJebModule(string module) is the source of the failure and you should be able to use @nightingale's example code that is linked with a change to look for MechJeb instead of Toolbar.

[JAFO]

18 minutes ago, Jovus said:

ETA: Badly formed question. I'm not asking you to change your mod; I'm writing my own autopilot and I want to use those parameters instead of throttle (since I'm using RO and throttle doesn't vary), and I was hoping that, as you've done all the work behind this, I might be able to borrow a bunch of your work, so I'm asking if, in your opinion, the mathematics might be relatively easily portable to different parameters.

The pre-AndyMt versions of GT used to do an initial guess as to suitable angle and velocity, which, about 75% of the time, turned out to be very close to the final figures. So far as I know, AndyMt has removed that function from the code.. at least, it doesn't seem to do a guess prior to first launch anymore.

The code to make that initial pre-launch guess might point you in the right direction.

[NeuroticGamer]

43 minutes ago, Jovus said:

Out of curiosity, is there any possibility (or clues that you have, since you've worked on this) for the gravity turn to be flown by varying the kick angle and start velocity rather than the throttle?

 

ETA: Badly formed question. I'm not asking you to change your mod; I'm writing my own autopilot and I want to use those parameters instead of throttle (since I'm using RO and throttle doesn't vary), and I was hoping that, as you've done all the work behind this, I might be able to borrow a bunch of your work, so I'm asking if, in your opinion, the mathematics might be relatively easily portable to different parameters.

I think you might want to also look at Throttle Controlled Avionics mod.  Despite the name, it has some advanced ToOrbit, DeOrbit, Rendevous functionality.  My experience with the current release is a bit wonky; I think KSP 1.2 may still be causing it fits from time to time.

[fourfa]

57 minutes ago, JAFO said:

The pre-AndyMt versions of GT used to do an initial guess as to suitable angle and velocity, which, about 75% of the time, turned out to be very close to the final figures. So far as I know, AndyMt has removed that function from the code.. at least, it doesn't seem to do a guess prior to first launch anymore.

That is kinda what I came to ask...  I would agree, previously about 75% of the time it would just be perfect to orbit, and the rest would usually be within my safety factor.  Currently, at least half the time this version of GT goes directly to space and turns right with 1-2000m/s circularization burns.  Once I start tweaking the fields by hand it's better, but do that a couple times (combined with the lack of memory of configs, thrilled to see work on this starting) and it's faster to just pilot by hand.  I could never match old GT's delta-V to orbit flying by hand - never - but currently I seem to beat it most of the time.  

I hope I'm not being overly critical - I just want to deliver 100% honest feedback.  It is still very hands-off convenient, but it just seems like only a couple small tweaks from working really well

[JAFO]

11 minutes ago, fourfa said:

I hope I'm not being overly critical - I just want to deliver 100% honest feedback.  It is still very hands-off convenient, but it just seems like only a couple small tweaks from working really well

Since we're on the subject of constructive feedback, the "Improve Guess" function seems a lot more... (not sure what the word I'm looking for is) umm... "mechanical" than early versions. In the early versions, you got the distinct feeling the mod was actually crunching numbers and taking a stab at what might work better.. now, it's like "ok, let's just step things up/down a notch, and see what happens.. then rinse and repeat".

I was left with the impression that a lot of the code handling the calculations/guesses had fallen by the wayside.

[AndyMt]

7 hours ago, NeuroticGamer said:

I have the same issue as @islanit.  My .NET experience says the problem (and the solution) are the same.

Here is my KSP.LOG for the same issue: https://drive.google.com/open?id=0BxCPohKyyq63X0NDM2NFajhoRWM

FindMechJebModule(string module) is the source of the failure and you should be able to use @nightingale's example code that is linked with a change to look for MechJeb instead of Toolbar.

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.

6 hours ago, JAFO said:

Since we're on the subject of constructive feedback, the "Improve Guess" function seems a lot more... (not sure what the word I'm looking for is) umm... "mechanical" than early versions. In the early versions, you got the distinct feeling the mod was actually crunching numbers and taking a stab at what might work better.. now, it's like "ok, let's just step things up/down a notch, and see what happens.. then rinse and repeat".

I was left with the impression that a lot of the code handling the calculations/guesses had fallen by the wayside.

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);
}

 

[JAFO]

7 hours ago, AndyMt said:

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.

Ahh.. that would explain the 'simplistic' (better word for what I was trying to say than 'mechanical') approach GT was taking towards improving its guesses.. good to hear you've found the cause!

[nightingale]

 

10 hours ago, AndyMt said:

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

More accurate is to say any mod that uses the Assembly.GetExportedTypes() method (there's many ways to do the same thing, and that's the only one that fails in this instance).

[AndyMt]

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.

[NeuroticGamer]

1 hour ago, AndyMt said:

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:

 

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.

I was having staging issues (and the mod incompatiblity).  Thanks for the update.  I'll see if I can reproduce the staging problem.

Edit: Even before I debug this, I think the staging issue is related to non-stock parts like SpaceY or MRS.

Edited October 26, 2016 by NeuroticGamer

[NeuroticGamer]

Ok, I've got it to fail in a relatively new career game.  Early staging goes well.  When the asparagus stages are fully complete, GTC is firing the decoupler for the upper stage but not igniting the engine for a long time.  By the time it reacts, the craft is falling deep into atmosphere and GTC never recovers. 

Screenshots as requested.  First screenshot is when it didn't fire engine.  Second screenshot is after it fired upper stage engine.

http://imgur.com/gallery/GG31e

And here are KSP.log, output_log.txt, and hopefully a sanitized craft file (should be free of mod parts):

https://drive.google.com/open?id=0BxCPohKyyq63Ny1aS0EyMGtNMU0

I verified that the sanitized craft failed but I haven't tested it in a unmodded sandbox game yet.

I'm still working on recreating the booster stage failures I've had where it failed to jettison empty boosters.  I'm 99% sure that was always a failure if the coupler was a mod (SpaceY or MRS iirc) rather than stock.

 

Edit: I just confirmed that if I turned off warp option, and manually staged where it should have done the upper stage. I got a good 90 km / 72 km orbit without me doing anything else (90 km being the target I had given GTC).  Ugh, I used GTE in a bunch of places.  Too many other mods with "Extended"

Edited October 27, 2016 by NeuroticGamer
GTE to GTC

[DStaal]

2 hours ago, NeuroticGamer said:

I'm still working on recreating the booster stage failures I've had where it failed to jettison empty boosters.  I'm 99% sure that was always a failure if the coupler was a mod (SpaceY or MRS iirc) rather than stock.

Hmm.  Was it one of the couplers that's also a seperatron?  (Just because I can see that being a weird case for this mod to handle - my older version handles them fine.)

[StevieC]

I only have problems with stage-separation on two occasions: One, when the decoupler has sepratrons built into it, and two, when there are sepratrons staged to activate at the same time as a decoupler.

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

[Superfluous J]

I wonder if it's because the sepratrons have fuel, and so GT is not staging them away because that fuel could (in theory) be used to propel the craft.

[NeuroticGamer]

10 hours ago, DStaal said:

Hmm.  Was it one of the couplers that's also a seperatron?  (Just because I can see that being a weird case for this mod to handle - my older version handles them fine.)

Yes, I'm pretty sure they were the combo sepratrons and that would make sense that it could freak out GT.