Overengineer1

[1.0.5] GravityTurn version 1.3.1 - Automated Efficient Launches (1.1 pre-release available)

Recommended Posts

5 hours ago, Sir_Robert said:

It just warps to the node and then stops, leaving me to do the actual burn.

This is the part that you did not make clear before.  Based on what you said before, the only objection you seemed to have was the time warp not staying turned off, which is a normal function of MJ.  Since that seemed to be your only issue, and since you never said MJ did not execute to maneuver node it was logically incorgusious to object to receiving early access to a feature of MJ that you would receive earlier in the tech tree than auto assent since you were ok ignoring that part of MJ and using a different auto assent.  I don't care how you play the game.  I was only pointing out that your explanation did not make any sense.  Had you said the above statement earlier I would in all probability have said nothing.

Edited by mcirish3

Share this post


Link to post
Share on other sites

I'm using KSPI-E with a spaceplane and gravity turn in throwing exceptions if the craft uses nuclear turboengines (no fuel other than intake air).  The exception is:

GravityTurn : Exception in StageStats.RunSimulation(): System.Exception: FuelFlowSimulation.SimulateStage reached max step count of 100
  at GravityTurn.FuelFlowSimulation.SimulateStage (Single throttle, Double staticPressure, Double atmDensity, Double machNumber) [0x00000] in <filename unknown>:0 
  at GravityTurn.FuelFlowSimulation.SimulateAllStages (Single throttle, Double staticPressureKpa, Double atmDensity, Double machNumber) [0x00000] in <filename unknown>:0 
  at GravityTurn.StageStats.RunSimulation (System.Object o) [0x00000] in <filename unknown>:0 

 

FULL LOG

Share this post


Link to post
Share on other sites

I'm confused how Hold AP Time works. I set both to 40 (the default values). I launch. We're full throttle until Ap time goes to 40... and then we remain at full throttle while the Hold AP Time setting zooms up. I was expecting the mod to control the throttle to avoid doing that. Am I understanding something wrong?

This is the rocket (by maccollo): https://dl.dropboxusercontent.com/u/22015656/KSP%202016-02-06%2017-50-56-54.png

Edited by numerobis

Share this post


Link to post
Share on other sites

@numerobis That's why.  GravityTurn can't throttle down a SRB any more than you can.  Your actual Time To AP is going to go where it's going to go, so GravityTurn just accepts it.  A recent change made the APTimeStart increase when the SRB pushes the actual HoldAPTime out beyond the original setting.  This is to avoid going to the next stage and staying at zero throttle until the AP time comes down, which actually just loses speed and is pretty much never a good idea.  This way the AP Time fades down to the original desired setting as the rocket ascends, so the rocket will continue to use a reasonable amount of thrust throughout the launch.

Share this post


Link to post
Share on other sites

I don't expect it to throttle back the SRBs, but I was expecting it would throttle back the main engine. Instead, what I see is 100% throttle when the SRBs are on (no, bad!) and 20% throttle after they turn off (no, bad!) which ends up in fiery death.

Granted, MechJeb is only slightly better by keeping the throttle at 100% the whole way.

Share this post


Link to post
Share on other sites

I can see that if the rocket is a little overbuilt with SRBs and the main engine together, it does seem to leave the throttle a little higher than it should.  This is an oversight, since I'm calculating the AP TIme Start to make the Hold AP Time exactly what it currently is, the throttle calculations work out that it thinks it should be holding what it has.  I'll fix that.  But really, if you don't want your main engines running with your SRBs at all, you shouldn't stage them together.

Share this post


Link to post
Share on other sites

Looking at the code, looks like a bug. We increase the APTimeStart immediately when it's exceeded and there's an SRB on board, so in the next frame we'll see that the time to the apoapsis isn't too large, so we shouldn't throttle back. Maybe it should increase a little less quickly -- say increase it only if it's more than 10s more than the target (10s being half the 20s magic figure for taking drastic action).

Share this post


Link to post
Share on other sites

Yes I already said that.  I've just changed it to set APTimeStart as 99% of the calculated value, which seems to work, and this would react instantly instead of waiting an additional 10 seconds.  This works well in my tests.  I'm looking at another issue reported by someone else, and I'll do a minor version release tonight.

Share this post


Link to post
Share on other sites

@armegeddon It looks like a problem with that engine.  Either it doesn't activate properly or because it doesn't burn fuel, either way it breaks the staging calculations in a way that I don't think I can fix.  Logically this doesn't seem like something to be fixed here, since every engine should consume some resource, whether it's ElectricalCharge or EnrichedUranium or whatever.  Instead this part actually seems to generate power and thrust for free from nothing, which isn't really compatible with reality.

Share this post


Link to post
Share on other sites

@Overengineer1

just playing around with the learning system. 

Each launch for the same ship I'm having to change the stage delay times. For my current rocket I'm setting it to .2 post and .3 pre (little terrier looses time to AP between staging)

Any chance this can be recorded with the best guess times ?

Share this post


Link to post
Share on other sites
2 hours ago, Overengineer1 said:

@armegeddon It looks like a problem with that engine.  Either it doesn't activate properly or because it doesn't burn fuel, either way it breaks the staging calculations in a way that I don't think I can fix.  Logically this doesn't seem like something to be fixed here, since every engine should consume some resource, whether it's ElectricalCharge or EnrichedUranium or whatever.  Instead this part actually seems to generate power and thrust for free from nothing, which isn't really compatible with reality.

You should watch Scott Manley's 100+ videos career mode with KSPi then I think you would understand.  It is beamed power and all power is comes in via a receiver.  But yes this is weird stuff though theoretically possible is certainly outside the realm current tech.

Share this post


Link to post
Share on other sites

 

16 hours ago, Overengineer1 said:

@Sir_Robert GravityTurn isn't timewarping to Apoapsis.  MechJeb is.  GravityTurn stopped all operations as soon as you left the atmosphere and handed it over to MechJeb.

You call MJ with reflection and when stuff don't work well for your users you tell them to seek support with me ? Classy. 

Share this post


Link to post
Share on other sites

@sarbian I didn't tell them to seek support from you.  But it's true, MechJeb is the one doing that, since all I did at that point was call "ExecuteOneNode" from your assembly.  The user can't do anything to GravityTurn at this point to stop the execution, he has to do it in MechJeb since MechJeb is driving.

Share this post


Link to post
Share on other sites
5 hours ago, sarbian said:

 

You call MJ with reflection and when stuff don't work well for your users you tell them to seek support with me ? Classy. 

@sarbian  Sir_Robert has been told that this mod is not integrated into career mode yet, which is why it causing an issue.  As a result GT tries to access a function of MJ has not unlocked yet by this user. The thing is MJ behaves exactly as it should.  The maneuver node is created but it does not execute it. I do not understand why Sir_Robert thinks it should auto execute since he has not unlocked that function of MJ in career mode. There really is no malfunction in either mod the user is trying to use both mods in an unintended way.  IF he is coming to ask for help I would just tell him what he is trying to do is unsupported.  
 

2 hours ago, Overengineer1 said:

@sarbian I didn't tell them to seek support from you.  But it's true, MechJeb is the one doing that, since all I did at that point was call "ExecuteOneNode" from your assembly.  The user can't do anything to GravityTurn at this point to stop the execution, he has to do it in MechJeb since MechJeb is driving.

@Overengineer1  Placing a bold statement in the OP that this mod is not integrated into career mod and will cause unexpected issues with MJ (not really a problem but people are dense)  if used in early career mod. For future update; setting GT to not access MJ untill auto assent is avalalbe in career mode would also solve this, or to be unavailable until that time in career mode (at least until you are truly ready to deal with that part of the game) may also make sense.

Edited by mcirish3

Share this post


Link to post
Share on other sites

@mcirish3 I'm not clear that there's actually a problem to solve here.  My understanding is that the MJ hand-off works as intended, but the user was confused about how it works.  Did I miss something?

I do intend to run a check to see if the node executor has been unlocked in the tech tree to keep consistent with the MJ unlock path.  The ascent module isn't involved, though.

Share this post


Link to post
Share on other sites
48 minutes ago, Overengineer1 said:

@mcirish3 I'm not clear that there's actually a problem to solve here.  My understanding is that the MJ hand-off works as intended, but the user was confused about how it works.  Did I miss something?

I do intend to run a check to see if the node executor has been unlocked in the tech tree to keep consistent with the MJ unlock path.  The ascent module isn't involved, though.

No you are spot on there really isn't a problem, more like miscommunication and a misunderstanding about how things work, and your solution to the non-problem is exactly what I was suggesting, other than temporarily editing the OP for clarity until you can release an update.

Share this post


Link to post
Share on other sites

My understanding of the user's problem is that he wanted to ABORT the node execution and because he didn't have access to the Mechjeb window yet he couldn't? 

I think it could be fixed by either adding an "Abort Mechjeb Node Execution" button to your window that called the .Abort on the  MechJebModuleNodeExecutor as long as the computer module was .enabled  , or testing the .unlockchecked property before making the circularization node would fix his issue?

Share this post


Link to post
Share on other sites
14 hours ago, artwhaley said:

My understanding of the user's problem is that he wanted to ABORT the node execution and because he didn't have access to the Mechjeb window yet he couldn't? 

I think it could be fixed by either adding an "Abort Mechjeb Node Execution" button to your window that called the .Abort on the  MechJebModuleNodeExecutor as long as the computer module was .enabled  , or testing the .unlockchecked property before making the circularization node would fix his issue?

EXACTLY this yes. Couldn't have said it any better.

The system is great, and now that I know the problem it won't be a problem. What happened was: GT does it's thing, hands off to MJ (and makes a manouver node. Not sure which mod does that). MJ attempts to auto-execute the manouver node (but can't because that module isn't unlocked yet). So it autowarps to the node as normal, but at the node stops working. This causes problems for manually executing the node

 

18 hours ago, mcirish3 said:

Sir_Robert has been told that this mod is not integrated into career mode yet, which is why it causing an issue.  As a result GT tries to access a function of MJ has not unlocked yet by this user. The thing is MJ behaves exactly as it should.  The maneuver node is created but it does not execute it. I do not understand why Sir_Robert thinks it should auto execute since he has not unlocked that function of MJ in career mode. There really is no malfunction in either mod the user is trying to use both mods in an unintended way.  IF he is coming to ask for help I would just tell him what he is trying to do is unsupported.

Please stop putting words in my mouth. I never said anything about expecting an auto execute. In fact, my confusion came from the mod FORCING an auto execute where non was possible.

 

18 hours ago, Overengineer1 said:

I'm not clear that there's actually a problem to solve here.  My understanding is that the MJ hand-off works as intended, but the user was confused about how it works.  Did I miss something?

I do intend to run a check to see if the node executor has been unlocked in the tech tree to keep consistent with the MJ unlock path.  The ascent module isn't involved, though.

In normal situations, it works great. However, what I stumbled upon is a fringe case where GT attempts to hand off the execution of the manouver node to MJ, but MJ manouver planner not being unlocked (early in career). This causes problems with MJ warping to the node as normal, but than not doing the burn.

 

 

For now, the problem can easily be worked around by deleting the manouver node

Because MJ manouver planner wasn't unlocked yet, my assumption was that GT was just warping me to the node so that I could do the burn myself. Than mcirish3 starts putting words in my mouth about how I apparently assumed certain functions. I never even mentioned the ascent module

Edited by Sir_Robert

Share this post


Link to post
Share on other sites

Hi @Overengineer1, I like this mod very much. After a few days testing, I found a few bugs. One is the sorting function will put a failed launch in front of a successful launch. I believe it's because in the LaunchDB.betterthan function, You should add

if (other.LaunchSuccess && !LaunchSuccess)
                return 1;

after Line 46, and add the reverse version of line 43 and 44 too. This bug is causing the previous best settings button not functioning correctly.

The second bug is when saving the launch results to the file, if the StartSpeed and TurnAngle are the same with one of the previous launches, it overwrites that entry. This can cause problems. For example, If I use previous best settings to launch to a different orbit, and the new launch has more total loss, in future launches the use previous best settings button to launch to the original orbit will not give the true best settings because it's overwritten.

Also, the initial guess for 1.25m rockets seems to have too large TurnAngle. It causes a lot of wobbling. Decrease the TurnAngle and StartSpeed together will make the launch a lot better.

The improve guess button sometimes gives weird results. I once get a negative TurnAngle. Set upper and lower limits for these parameters may be a good idea.

Finally, there is some rooms to improve the improve guess. Currently if the improve guessed launch is worse than the second best launch, the next time you hit the button it still give the same guess, which has been proved to be worse.

Hope these will make your mod better

Share this post


Link to post
Share on other sites

Why does the Gravityturn window say I'm experiencing souposphere levels of drag?  I'm running FAR, and the drag calculation is off by over a factor of 4.

Edited by Thorbane

Share this post


Link to post
Share on other sites
This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.