transfer calculator [1.12] Astrogator v1.0.1

[trbaron]

I've just started trying to use this mod, but the main window of the astrogator so far is only there the first time I go to use it, if I cancel the nodes it goes away and I can't seem to get it back except for deleting and reinstalling the mod.

Clicking the icon in-game doesn't seem to do anything.

Then once you close the game the astrogator.settings file contains 

MainWindowVisible = False

Changing that to true seems to have no effect as it returns to false again when KSP is reopened.

However deleting the file and then restarting sees the return of the astrogator window.

 

EG: I asked it to set nodes to intercept minmus but the second node would have resulted in a collision so I cancelled it, now the astrogator window is still gone and I can't see to make it reappear.

Edited February 19, 2017 by trbaron

[Wadusher0]

On 2/17/2017 at 10:05 PM, HebaruSan said:

Turning off calculations when the window is closed is another of my plans to deal with this. Right now I don't think there's any such check.

Could you also make the mod check if you are currently burning before it does calculations? There might be some people who have this problem who forget to turn off the window when they do a transfer burn and don't realize this mod is tanking their framerate. Not to mention, you probably won't be planning any transfers right in the middle of a maneuver node.  

[Cetera]

After the most recent update, Astrogator is absolutely killing KSP.  At any point during a craft launch, once you are out of the atmosphere, Astrogator tries to start doing something.  It is running constantly, and I think forcing garbage collection every couple of seconds, which is what is killing the framerate and making the game unplayable.

The error from the log is this:

[Astrogator 575.321] Somebody tried to load with a null origin
(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 42)

Here is the log file:

https://dl.dropboxusercontent.com/u/62531235/output_log - Astrogator.txt

 

That error occurs 30-40 times per second.  

Please let us know when you get this fixed.  I love the functionality of Astrogator, but can't use it as it stands right now.

[HebaruSan]

4 hours ago, trbaron said:

However deleting the file and then restarting sees the return of the astrogator window.

What does the rest of the settings file look like when it's in the non-working state? This kind of sounds like the window position somehow gets set to "off screen", and then you can't see it when it toggles on and off, but who knows. If you can also upload a copy of your KSP.log file somewhere, that could provide some insight.

Remember, there is a bug tracker! https://github.com/HebaruSan/Astrogator/issues

1 hour ago, wadusher1 said:

Could you also make the mod check if you are currently burning before it does calculations? There might be some people who have this problem who forget to turn off the window when they do a transfer burn and don't realize this mod is tanking their framerate. Not to mention, you probably won't be planning any transfers right in the middle of a maneuver node.  

I expect the "every five seconds" check and the background thread to address the problem for that case.

58 minutes ago, Cetera said:

After the most recent update, Astrogator is absolutely killing KSP.  At any point during a craft launch, once you are out of the atmosphere, Astrogator tries to start doing something.  It is running constantly, and I think forcing garbage collection every couple of seconds, which is what is killing the framerate and making the game unplayable.

The error from the log is this:

[Astrogator 575.321] Somebody tried to load with a null origin
(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 42)

 

That's a message it logs when it's not calculating. I notice there's an exception in your log right before that starts up:

Quote

NullReferenceException: Object reference not set to an instance of an object
  at Keramzit.ProceduralFairingBase.DestroyAllLineRenderers () [0x00000] in <filename unknown>:0 
  at Keramzit.ProceduralFairingBase.OnDestroy () [0x00000] in <filename unknown>:0 

Do you see this problem without Procedural Fairings (either on the craft, or installed)?

Edited February 19, 2017 by HebaruSan

[Stratickus]

I am having on odd issue with Astrogator. I have the mod installed via CKAN. I get this error when when trying to update it to the latest version:

Spoiler

I subsequently get this error when trying to manually delete Astrogator:

Spoiler

It appears that my computer thinks the folder Astrogator is in use or something. It is not. KSP is not running and I have no idea why it would think that it is. This has happened 3 times now when I try to update the mod via CKAN. The first time it happened, I dismissed it as an anomaly, restarted my computer and had no issues. However, it continues to happen. I of course have no idea why, but it is curious, especially since people have reported lag/FPS issues. Let me know if you need anything else that can be of use. 

Cheers,

Edited February 20, 2017 by Stratickus

[trbaron]

13 hours ago, HebaruSan said:

What does the rest of the settings file look like when it's in the non-working state? This kind of sounds like the window position somehow gets set to "off screen", and then you can't see it when it toggles on and off, but who knows. If you can also upload a copy of your KSP.log file somewhere, that could provide some insight.

This is all thats there;

MainWindowVisible = False
MainWindowPosition = 159405360,-159405344

The numbers aren't always the same.

If it helps, I play in 4k resolution.

[Cetera]

16 hours ago, HebaruSan said:

That's a message it logs when it's not calculating. I notice there's an exception in your log right before that starts up:

Do you see this problem without Procedural Fairings (either on the craft, or installed)?

Woah, great catch!  I missed that before.  I was watching the debug screen, and just noticed all the Astrogator spam, and confirmed that in the log.  I will test with the procedural fairings, and let you know.

[HebaruSan]

3 hours ago, trbaron said:

MainWindowPosition = 159405360,-159405344

Yeah, that position is over 10 Earth radii to the lower right of your screen. I can stop it from saving and loading off-screen positions, but we may have to settle for logging some window dimension data to the debug log at open and close to get closer to identifying where those values come from in the first place.

32 minutes ago, Cetera said:

Woah, great catch!  I missed that before.  I was watching the debug screen, and just noticed all the Astrogator spam, and confirmed that in the log.  I will test with the procedural fairings, and let you know.

I should note that Procedural Fairings isn't necessarily causing the problem---it could just be the first mod affected by it. But having that exception raised probably isn't helping matters.

[Cetera]

11 hours ago, HebaruSan said:

I should note that Procedural Fairings isn't necessarily causing the problem---it could just be the first mod affected by it. But having that exception raised probably isn't helping matters.

You are correct, it isn't Procedural Fairings, and it isn't Astrogator.  It isn't tweakscale either.  I have no idea what it might be.  

After a bunch of testing, I couldn't isolate it, so I just did a fresh, clean install, and huzzah, fixed!  For a while.  After a couple of hours over a few sessions, the issue has now returned.  Once it seems to happen, it doesn't seem to stop happening.  

It seems to start immediately upon vessel load, and there will be roughly three pauses before the game settles down and a vessel can be launched.  As you climb, the issue gets worse and worse, until you're out of the atmosphere, and things are unresponsive and uncontrollable.  It is extremely frustrating and irritating.

[HebaruSan]

On 2/11/2017 at 5:03 PM, diomedea said:

Fantastic if this tool could also compute hyperbolic encounters, I get it's a very different task than with closed orbits. The ability to plan the kind of encounters I described above is probably something for a far, far future.

I've looked into asteroids a bit more. Unfortunately, it looks like what I want to do isn't possible. The game by default only loads the current orbit for each asteroid, not any future SOI changes or patches, so the encounter isn't there to check. It stays that way until you go into the tracking station and click on the asteroid, at which time the future encounter is calculated and the in-SOI and post-SOI patches are added, just for the one asteroid you clicked. Attempting to do that same thing in code fails with exceptions. It seems that others before me have had the same findings.

Long story short, no asteroid transfer improvements planned anymore.

[diomedea]

3 hours ago, HebaruSan said:

I've looked into asteroids a bit more. Unfortunately, it looks like what I want to do isn't possible. ...

Thanks for the effort. Should say my interest is mainly about a tool to automate what I do manually to get early intercept of asteroids out in solar orbit (example picture), but those are definitely not Hohmann transfers and you were already clear in your previous post this tool will only be computing such transfer trajectories. Indeed a R/V at periapsis is Hohmann-compliant, but that comes too late for most purposes.

Also, as you correctly pointed out, KSP only computes and displays patched conics for selected vessels (asteroids included); definitely I need to have the asteroid targeted while manually tweaking the maneuvers, so KSP shows its future conics in different SoI (which is very relevant to allow matching inclination and LAN in my maneuvers while still within a planet SoI). I'm sure it is possible to compute maneuvers for a R/V out in solar orbit without need to have KSP compute the patched conics (there are tools already doing by using Lambert solvers, but none within KSP yet. Such solvers take time to find solutions, which probably makes them unfit for your tool).

[wrobel-cwirek]

Is it possible that the calculations can be done less frequently (maybe you can set it in configuration how often) and also a button to calculate it on demand?

[HebaruSan]

2 hours ago, wrobel-cwirek said:

Is it possible that the calculations can be done less frequently (maybe you can set it in configuration how often) and also a button to calculate it on demand?

No, I have no plans to do either of those things. I want it to work well out of the box without manual tweaking.

[trbaron]

On 21/02/2017 at 3:38 AM, HebaruSan said:

Yeah, that position is over 10 Earth radii to the lower right of your screen. I can stop it from saving and loading off-screen positions, but we may have to settle for logging some window dimension data to the debug log at open and close to get closer to identifying where those values come from in the first place.

I don't know what causes it now, last time I deleted the settings and open KSP the astrogator window disappeared before I even selected a manoeuvre to make.

Setting the file to read only after entering a position of 0, -0 doesn't seem to help, but I don't know how the screen coords work so maybe thats off the screen too.

[HebaruSan]

1 hour ago, trbaron said:

I don't know what causes it now, last time I deleted the settings and open KSP the astrogator window disappeared before I even selected a manoeuvre to make.

Setting the file to read only after entering a position of 0, -0 doesn't seem to help, but I don't know how the screen coords work so maybe thats off the screen too.

There might be an informative exception logged to your KSP.log file.

[trbaron]

9 hours ago, HebaruSan said:

There might be an informative exception logged to your KSP.log file.

https://www.dropbox.com/s/bpn5q9utartws3q/KSP.log?dl=0

Should be there.

[HebaruSan]

Astrogator v0.6.0 has been released. The major focus of this release is the ability to calculate transfers from the surfaces of bodies, accounting for both the time it takes the body to rotate into position and the extra delta V required to launch. When piloting a vessel, launches are plotted from the vessel's landed position; without a vessel, launches from Kerbin are assumed to be from KSC, while vessel-less launches from other bodies are treated as having an indeterminate time. It is assumed that you will launch at the 0-second mark and follow a typical gravity turn without throttling down, which I successfully used to get encounters with Mun and Jool.

Note: The launch delta V values are currently (very) approximate! The physically correct calculations involve solving integrals, which I don't expect to be able to do on the fly, so I created a simplistic linear model based on gravitational force and atmospheric pressure and tuned it for Kerbin, Eve, Duna, Laythe, Mun, Tylo, and Gilly (but mainly Kerbin). The values for Duna will be off by about 30%, but they should be within 20% for other bodies. Since these errors could cause mission problems, the estimated launch delta V value is shown in the subtitle so you can compare it to your favorite subway map and make corrections as needed. If you know of a way to get accurate real-time numbers for these estimates, I would be very happy to learn, but please do not report "launch estimate for body X is off by 15%," because I already know that.

(Note that the version number in the title, also added in this release, is out of date in these screenshots and should say v0.6.0. Another wrench thrown into my release process.)

A much easier but very visible change for those affected is the switch from hard-coded 6-hour days and 426-day years to the calendar of the solar system's home body. For RealSolarSystem users, this means 24-hour days and 365.25-day years:

In addition, the RasterPropMonitor display is now more or less completed; it will look and feel more like the normal window, and can scroll through multiple pages of transfers in case you have a very crowded solar system.

Finally, I spent some time investigating the problems reported in this thread since the previous release. While I was not able to pin down specific causes, I did add new sanity checks and debugging output to the areas that appeared to be related. If those issues still occur, we should be able to get more information about them from the logs.

https://github.com/HebaruSan/Astrogator/releases/tag/v0.6.0

[EmberTech]

Holy crap, this is great. I'm terrible at transfers, so this is a godsend.

[Red Stapler]

Just wanted to send out a huge thank you to Hebarusan for this mod...I am now using this instead of Transfer Window Planner (another great mod).  I just prefer the way Astrogator presents you with the data and it's ease of use.

Jeb will be installing the latest update tonight!  

[diomedea]

1 hour ago, HebaruSan said:

... The major focus of this release is the ability to calculate transfers from the surfaces of bodies, ....

Impressive! This is a very useful feature, thanks for implementing it .

1 hour ago, HebaruSan said:

Note: The launch delta V values are currently (very) approximate! The physically correct calculations involve solving integrals, which I don't expect to be able to do on the fly, so I created a simplistic linear model based on gravitational force and atmospheric pressure and tuned it for Kerbin, Eve, Duna, Laythe, Mun, Tylo, and Gilly (but mainly Kerbin). The values for Duna will be off by about 30%, but they should be within 20% for other bodies. Since these errors could cause mission problems, the estimated launch delta V value is shown in the subtitle so you can compare it to your favorite subway map and make corrections as needed. If you know of a way to get accurate real-time numbers for these estimates, I would be very happy to learn, but please do not report "launch estimate for body X is off by 15%," because I already know that.

Spoiler

 

Determination of exact DV required could be possible launching from an airless body. After all, it would  just require to compute 1) the vectorial difference from what the vessel orbital speed is when still landed (e.g. 174 m/s eastwards on Kerbin) and when on the ascent elliptic trajectory at the same altitude of the launch; 2) the circularization speed required at apoapsis. 1) is at its root a problem of ballistics, the equation is v² = [k/p](1+e²-2 cos(θ)) (from here), could be noted it allows a whole family of solutions with different values of true anomaly (θ) at launch; 2) isn't even worth showing as you certainly know it too well.

Trouble with this approach, it is valid for impulsive thrust, DV being immediately applied to the vessel (thrust = infinite); vessels we use have limited TWR so need time before the required DV is applied; during this time gravity keeps "pushing down" and needs be compensated; this is generally known as "gravity loss" at launch: the less TWR, the larger the loss. Have yet to find an equation able to tie TWR (variable during ascent) with the amount of gravity loss, but certainly it involves using integrals.

Launching from a body with atmosphere requires to account for "aerodynamic loss" too. This loss is best computed by integration over time, as it requires to determine the vessel speed and altitude at each time sample, compute drag force (Fd = ½ ρ v² Cd A) (please note Cd and A are tied to a specific vessel), and sum all the amounts of Fd x time interval.

Conclusion, there are too many factors involved in the exact determination of required launch DV, and using integrals can't be skipped. Seems to me this would be too large a burden for Astrogator.

 

What I would like to see is, if a best estimate at DV is needed, if Astrogator could take advantage from other add-ons specialized in this. Probably MechJeb launch autopilot is fitting, but I'd suggest to verify the possibility to exchange data with Gravity Turn Continued (proceedings with GTC are very different and require some optimization steps, so values would be valid for only the specific ascent profile required and vessel used).

[HebaruSan]

6 hours ago, EmberTech said:

Holy crap, this is great. I'm terrible at transfers, so this is a godsend.

Thanks! I hope it serves you well.

5 hours ago, Red Stapler said:

Just wanted to send out a huge thank you to Hebarusan for this mod...I am now using this instead of Transfer Window Planner (another great mod).  I just prefer the way Astrogator presents you with the data and it's ease of use.

Jeb will be installing the latest update tonight!  

You're welcome! Ease of use is definitely an ongoing priority.

4 hours ago, diomedea said:

Conclusion, there are too many factors involved in the exact determination of required launch DV, and using integrals can't be skipped. Seems to me this would be too large a burden for Astrogator.

It is indeed a very daunting prospect; credit to this post by @OhioBob for laying out the details with crystal clarity. However, I suspect that there is a way to get close enough without going to those lengths. After all, most of these parameters don't truly vary across the whole range that can be handled by those integrals. TWR will be between 1 and about 3; pitch will follow a similar curve every time for a decent gravity turn; speed over time should look pretty similar, and therefore so should drag for a given atmosphere. And so on; even gravity and the atmospheres are essentially limited by what's found in stock, OPM, and RSS. If enough of the important factors are effectively constant, there should be a simple enough polynomial approximation out there waiting to be discovered. I just wish this was only a 2-dimensional relationship so I could plug some data into a spreadsheet and try various solvers.

4 hours ago, diomedea said:

What I would like to see is, if a best estimate at DV is needed, if Astrogator could take advantage from other add-ons specialized in this. Probably MechJeb launch autopilot is fitting, but I'd suggest to verify the possibility to exchange data with Gravity Turn Continued (proceedings with GTC are very different and require some optimization steps, so values would be valid for only the specific ascent profile required and vessel used).

Does Gravity Turn do delta V estimates? I'll take it for a test drive later, but the thread looks like it mainly manages your pitch while keeping you close to prograde during launch. I could conceivably interface with other mods, but I'm not sure any are trying to do this.

[Murdox]

Gotta love this mod. Easy to use but still so powerfull tool with nice UI. Very many thanks to Mr. HebaruSan!

I just installed latest v.0.6.0 and got under heavy NullRef spam which i hadn't with previous version. Also haven't yet had time try with clean install but i will and can provide full log if needed. Anyways spam im getting looks like this:

NullReferenceException: Object reference not set to an instance of an object
  at Astrogator.KerbalTools.Landed (ITargetable t) [0x00000] in <filename unknown>:0 
  at Astrogator.AstrogationModel.get_notOrbiting () [0x00000] in <filename unknown>:0 
  at Astrogator.Astrogator.Orpoodleanged () [0x00000] in <filename unknown>:0 
  at Astrogator.Astrogator.FixedUpdate () [0x00000] in <filename unknown>:0 
 
(Filename:  Line: -1)

Edit: Still spamming with clean install. Starts immediately after loading craft to launchpad. Full log just in case: https://mega.nz/#!vRBXxKaY!ZP23_ybX4-GGmImpdwEwl3IGoDtGlifHoHBZErkKlZc

Edited March 2, 2017 by Murdox

[diomedea]

2 hours ago, HebaruSan said:

It is indeed a very daunting prospect; credit to this post by @OhioBob for laying out the details with crystal clarity. However, I suspect that there is a way to get close enough without going to those lengths. After all, most of these parameters don't truly vary across the whole range that can be handled by those integrals. TWR will be between 1 and about 3; pitch will follow a similar curve every time for a decent gravity turn; speed over time should look pretty similar, and therefore so should drag for a given atmosphere. And so on; even gravity and the atmospheres are essentially limited by what's found in stock, OPM, and RSS. If enough of the important factors are effectively constant, there should be a simple enough polynomial approximation out there waiting to be discovered. I just wish this was only a 2-dimensional relationship so I could plug some data into a spreadsheet and try various solvers.

As shown by that post you linked, gravity loss integral is a function in 2 variables (g, flight path angle); aerodynamic (drag) loss has 5 variables (speed, air density, drag coefficient, cross-section area to make Drag Force + mass). I'm not considering steering loss as a optimized launch profile would bring that down to 0.

With a project I worked on, did polynomial regression on functions with 3 variables. It was mainly a question of method to get the correct poly factors, though a bit time consuming. In my project the functions were precisely known (I could compute the output from a large expression involving integrals and hyperbolic trigonometry), therefore sample data very accurate; yet the R squared from the approximating polynomials (4 terms with each single variable) wasn't always high enough (0.91 to 0.988) and the complete resulting polynomial in three variables (27 terms - 6th degree) could achieve R2 = 0.816 (enough for my needs but still way less precise than  the original functions). I hope you can find a way to link some of those variables with drag to be mutually dependent (e.g. cross-section area and mass) so to reduce the terms and degree to something manageable. However the main difficulty I see is with sampling data, to find DV loss in a large enough set to be representative of different vessels, bodies, launch profiles used in practice. With enough accuracy in the measurement of each variable and DV loss to make each sample worth.

2 hours ago, HebaruSan said:

Does Gravity Turn do delta V estimates? I'll take it for a test drive later, but the thread looks like it mainly manages your pitch while keeping you close to prograde during launch. I could conceivably interface with other mods, but I'm not sure any are trying to do this.

GTC provides a measure of Total DV and loss of DV (for gravity, drag, steering) in the stats window. It is integrated over time during a whole launch, of course what required is the final result once in orbit. GTC mainly manages thrust to keep time to apoapsis at a precise value, while pitch isn't (currently) commanded other than for initial angle and when reference switches from surface to orbital, it otherwise stays as close to purely prograde as possible at all times.

[HebaruSan]

8 hours ago, Murdox said:

Gotta love this mod. Easy to use but still so powerfull tool with nice UI. Very many thanks to Mr. HebaruSan!

Aww shucks!

8 hours ago, Murdox said:

I just installed latest v.0.6.0 and got under heavy NullRef spam which i hadn't with previous version. Also haven't yet had time try with clean install but i will and can provide full log if needed. Anyways spam im getting looks like this:

NullReferenceException: Object reference not set to an instance of an object
  at Astrogator.KerbalTools.Landed (ITargetable t) [0x00000] in <filename unknown>:0 
  at Astrogator.AstrogationModel.get_notOrbiting () [0x00000] in <filename unknown>:0 
  at Astrogator.Astrogator.Orpoodleanged () [0x00000] in <filename unknown>:0 
  at Astrogator.Astrogator.FixedUpdate () [0x00000] in <filename unknown>:0 
 
(Filename:  Line: -1)

Edit: Still spamming with clean install. Starts immediately after loading craft to launchpad. Full log just in case: https://mega.nz/#!vRBXxKaY!ZP23_ybX4-GGmImpdwEwl3IGoDtGlifHoHBZErkKlZc

Explains the user action that triggers the problem... check
Text of exception pinpointing problem code... check
Tried with clean install... check

If I could give you a gold star for a good bug report, I would. Thanks!

I do see this when I try it, but it stops after 2 seconds and the mod is usable after that. Is that the case for you as well? I need to decide whether to do a quick fix release just for this or hold it for later.

[Murdox]

12 hours ago, HebaruSan said:

If I could give you a gold star for a good bug report, I would. Thanks!

Have a golden star also! 

Now when i had time to test it little bit more it's actually doing it just like you said. Couple of seconds spams and then it's gone. i was getting some constant spams before but it was with my modded install so it was maybe this mod + some another doing it all the time. No need for separate quick fix release since i can handle this spam and if i dont then i just use older version temporarily 

Thanks for taking look of this issue and have a nice day!

Edit: Also one improvement came in to my mind before and already mentioned in page3 from Luovahulluus who said that "It would be nice if the window had a button for closing it in the upper corner." I definitely second this if its not big task to do. Would be awesome small feature

Edited March 3, 2017 by Murdox