transfer calculator [1.12] Astrogator v1.0.1

[HebaruSan]

20 minutes ago, Probus said:

@HebaruSan,  I am having the same problem with the mod working for a little while and then putting itself off the screen.  I have a feeling it may be a conflict between mods.  Would you like me to give you a list of the mods I have installed?

The goal of any bug report, at least for me, is to allow me to make the problem happen myself so I can investigate and fix it. I'm skeptical that a mod conflict could cause this, but there's no harm in sharing your mod list if you have it easily to hand.

Other things that might yield clues based on the description:

• Your GameData/Astrogator/Astrogator.settings file when it's been happening to you
• Full screen or windowed
• Screen resolution if full screen
• Window size if windowed
• UI scale settings
• Which operating system you have
• Version numbers for Astrogator and KSP
• Anything else I've forgotten that relates to the size of the display or UI

The game uses a coordinate system to control where popup windows appear, but the details aren't specified anywhere that I've been able to find, so I've had to infer how it works by using it and trying to observe what the rules are. So far it seems that the x and y coordinates can range from -1 to 1, corresponding to the lower left and upper right corners of the screen respectively. E.g., right now my local settings file has this:

MainWindowPosition = 0.910937488,0.54957509

... which as far as I have been able to figure out so far means to put the window most of the way toward the right edge of the screen, roughly vertically centered (since I've set the point being specified to the top middle of the mod window). There are checks in place to prevent these numbers from getting outside of what seems to be the on-screen range, but what I can't rule out is the possibility that the game might apply a different interpretation that turns the above into off-screen values, unbeknownst to me. If your settings file looks weird, then I can look into how it got that way, or if it looks normal, I can try to figure out why it still isn't working.

Thanks for offering to help!

[HebaruSan]

8 hours ago, QAQdong said:

Hello!I finished translation just now.I uploaded on Github

I found one thing that I'd like to have taken care of before using your translation. Please take a look at your convenience. Thanks again!

https://github.com/HebaruSan/Astrogator/pull/13#issuecomment-304951451

[Probus]

4 hours ago, HebaruSan said:

The goal of any bug report, at least for me, is to allow me to make the problem happen myself so I can investigate and fix it. I'm skeptical that a mod conflict could cause this, but there's no harm in sharing your mod list if you have it easily to hand.

Other things that might yield clues based on the description:

•  

The game uses a coordinate system to control where popup windows appear, but the details aren't specified anywhere that I've been able to find, so I've had to infer how it works by using it and trying to observe what the rules are. So far it seems that the x and y coordinates can range from -1 to 1, corresponding to the lower left and upper right corners of the screen respectively. E.g., right now my local settings file has this:

MainWindowPosition = 0.910937488,0.54957509

... which as far as I have been able to figure out so far means to put the window most of the way toward the right edge of the screen, roughly vertically centered (since I've set the point being specified to the top middle of the mod window). There are checks in place to prevent these numbers from getting outside of what seems to be the on-screen range, but what I can't rule out is the possibility that the game might apply a different interpretation that turns the above into off-screen values, unbeknownst to me. If your settings file looks weird, then I can look into how it got that way, or if it looks normal, I can try to figure out why it still isn't working.

Thanks for offering to help!

•  
• Your GameData/Astrogator/Astrogator.settings file when it's been happening to you - Ah, I think you may be on to something...
• MainWindowVisible = False
  MainWindowPosition = 0.597851932,-0.653124988
  ShowSettings = False
• Full screen or windowed - BORDERLESS WINDOW
• Screen resolution if full screen - 4K, 3840 x 2160
• Window size if windowed - FULL SCREEN SIZE
• UI scale settings - 150%  (WINDOWS 10 SETTING IS 125%)
• Which operating system you have - WINDOWS 10
• Version numbers for Astrogator and KSP - V0.6.2 & 1.2.2

If nothing stands out there, I will send you my mod list next.

BTW, I changed the MainWindowPosition to 0,0 and it changed it back to -0.25,-0.5.  Still no visible window.

Edited May 30, 2017 by Probus

[HebaruSan]

42 minutes ago, Probus said:

• MainWindowVisible = False
• UI scale settings - 150%  (WINDOWS 10 SETTING IS 125%)

Hmm, I will have to play around with UI scaling.

Clicking the toolbar button is supposed to toggle MainWindowVisible. If you open the game, click it once, and exit, does it still say False?

Another thing to check is whether there are any errors in KSP.log. I've seen a number of helpful exceptions for previous issues. It's possible that something might be failing when it tries to show the window. A search for "EXC" should find them if there are any.

[QAQdong]

Thank for your attention！I did not do well in checking this translation。Anyway，I must thank you for giving me this opportunity。

[Probus]

14 hours ago, HebaruSan said:

Hmm, I will have to play around with UI scaling.

Clicking the toolbar button is supposed to toggle MainWindowVisible. If you open the game, click it once, and exit, does it still say False?

Another thing to check is whether there are any errors in KSP.log. I've seen a number of helpful exceptions for previous issues. It's possible that something might be failing when it tries to show the window. A search for "EXC" should find them if there are any.

Its the UI Scale Slider that is causing the problem.  I have it set to 150%, when I switch it back to 100% in settings, Astrogator shows back up.  The higher I raise it moves the Astrogator window to the left until it is off screen.

[HebaruSan]

3 hours ago, Probus said:

Its the UI Scale Slider that is causing the problem.  I have it set to 150%, when I switch it back to 100% in settings, Astrogator shows back up.  The higher I raise it moves the Astrogator window to the left until it is off screen.

Thanks, good catch! I have confirmed this in testing and am looking for a fix. It ought to be a simple matter of multiplying and dividing by GameSettings.UI_SCALE in the right places, but the window keeps jumping around when I expect it to stay still. I may just need a nap.

[Craig D]

Hello HebaruSan,

 

Thank you for the welcome to the forums and the game.  I must say, I am impressed with both the game and the active community.  There are a lot of great forums and contributors to this game.  I am very impressed.  And thank you for responding to my post so quickly, I really appreciate it.

On 5/30/2017 at 0:06 PM, HebaruSan said:

Hmm, I don't think I would know how to calculate that. I'm honestly surprised that you made it to Minmus off-schedule; depending on exactly what you did, there's a risk that you'd de-orbit and crash to Kerbin instead, or end up on a trajectory that never got near Minmus. The stock maneuver node editor may help with this sort of planning, though; you can drag the center circle around to move the time of the burn back and forth and see what would happen.

I read this just before I went to a meeting and this was all I could think about, which later cracked me up.  I thought maybe this is why I have to do final tweaks so much for my final approach and orbiting.  But after some more playing around I realized when I say I would just go, I was meaning using the MecJeb tool, I would hit the button to go and it would automate the travel.  After some closer looking, I see the next maneuver was always the same timing as the window you have.  So I did not have the ah ha moment I thought I was having.  So I am still learning.  I am not sure but I believe it is probably user error why some approaches are so clean and others take so much more Delta V to get a good orbit.

I now have the updated Kerbal Alarm Clock and I see now what you mean.  Yeah it would be just duplicating someone else's work if you did what I was suggesting.  Thank you for the input.

Keep up the good work, as a new person to this I appreciate your efforts!

Thank you,

-Craig

Edited June 2, 2017 by Craig D

[HebaruSan]

Astrogator 0.7.3 is now available, featuring Chinese and Russian translations!

   

A big thanks to @QAQdong for the former and Niev on Github for the latter. The only remaining stock language not supported is now Japanese. (I just noticed the section headers are missing in the Chinese settings; I'll look into what's going on there, but hopefully it won't be too confusing in the meantime.)

Next up, the year has gotten one day shorter, but fortunately each day has been lengthened just enough to compensate. That's right, we've switched from sidereal to solar day lengths! This should be mostly imperceptible unless you watch the times count down very carefully; each day in the stock solar system is now exactly 6 hours long, whereas I think it would have been a few minutes shorter previously. Yes, it works for modded solar systems as well.

Regarding the issue where the UI Scale setting makes this mod unusable, I unfortunately have been unable to solve that problem yet, and meanwhile these translations were gathering dust while I'm sure their creators were eager to see them put to good use. I didn't want to leave this problem completely unaddressed, so I looked for ways to 1) detect the problem, 2) alert users, and 3) provide a workaround if desired. Toward that end I added a warning message when the setting has a value that will cause problems; if you try to open Astrogator with UI Scale set to 150%, you'll see this:

Clicking Reset UI Scale will set UI Scale to 100% and open the Astrogator window, after which it will work normally. Clicking Cancel will dismiss the popup and prevent Astrogator from opening. Now anyone who previously would have been affected by this problem unexpectedly will at least have a warning and an indication of what the problem is and how to avoid it. Note that this is just a temporary workaround, which I hope to replace with a true solution soon.

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

[HebaruSan]

On 5/31/2017 at 9:17 AM, Probus said:

Its the UI Scale Slider that is causing the problem.  I have it set to 150%, when I switch it back to 100% in settings, Astrogator shows back up.  The higher I raise it moves the Astrogator window to the left until it is off screen.

Would you be interested in testing a possible fix for this issue? I've been making slow progress and just reached a point where all the problematic cases I knew about are working (though not always as nicely as I'd like). However, I am not fully confident in it and would like to have somebody else try to break it before I do a new release.

• https://github.com/HebaruSan/Astrogator/files/1050160/Astrogator.zip

Things I want to know:

1. Are you able to get the window to disappear off-screen again with this version?
2. Are you able to get the window to jump around when opening/closing it or toggling to/from the settings?
3. If the answer to either of the above is Yes, then the precise steps to make it happen

Anyone else is welcome to try it and send feedback as well, but be aware that this is not a real release! It may be more buggy than usual, possibly far more. If testing goes well, there will be an official release of these changes plus any needed fixes, so do not download this if you just want UI Scale compatibility.

Thanks in advance for any help!

[HebaruSan]

Astrogator v0.7.4 is released!

  

• UI Scale setting now supported; the popup error message is gone, and the window should stay on screen without jumping around
• Missing headers in the Chinese translation of the settings now visible
• Delta V column was empty in Chinese, now fixed
• Spanish header for the leftmost column updated based on translator feedback
• Translation instructions' link to the Lingoona documentation updated to show the verbose help by default

But even if you use English at 100% scale, there's something in this release for you: plane change maneuvers are now more accurate!

When I first implemented plane change burns, I didn't understand why MechJeb's plane change burn calculator returned a Vector3d instead of a double (my eyes glaze over at dot products and cross products), so I stuffed the magnitude of that vector into the normal component of the maneuver node. This worked well enough most of the time, but it introduced errors for larger burns, resulting in a higher apoapsis and slight mismatches of inclination. In the process of investigating why this happened, I realized that you need to "tilt backwards" for an accurate plane change; this is easiest to understand if you imagine a 90 degree plane change, where you have to zero out your entire initial velocity to start going another direction, but the effect is there even for smaller plane changes. Sure enough, that's what that Vector3d was for! Now the inclination and the apoapsis will be correct after the calculated burns, which gave me immediate Minmus encounters a greater proportion of the time in testing (example above), and should help across the board for any transfer that involves a plane change.

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

[HebaruSan]

Astrogator v0.7.5 is released.

This is primarily a code clean-up release; I learned a few ways to do things better while working on SmartTank, which are now copied back to improve Astrogator. Most of these changes have no visual or functional impact; if you're happily using Astrogator v0.7.4, there's not much new for you here. However...

• If you want to use the RasterPropMonitor display (which just updated for 1.3), you'll want to upgrade, as I fixed a localization-related issue in the previous v0.7.* releases where all the planets were listed as "astrog".
• If you install @JPLRepo's LoadingTipsPlus alongside Astrogator, the loading tips will include three new Astrogator-related entries.

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

[Chaumas]

@HebaruSan I just discovered your beautiful mod thanks to your post on the RPM thread. I love the integration with RPM -- thank you!  

I think I might have discovered a minor issue. The mod works perfectly well except when using it with RPM while on an escape trajectory.

I understand that the mod cannot be used while on an escape trajectory and we get the relevant message when we press the Astrogator button. However, if by accident or out of curiosity  we click the RPM monitor Astrogator button while on an escape trajectory, the game freezes and I have to do a force-quit.  I am on Mac running KSP 1.3 and using the latest RPM (0.29.0) and Astrogator (0.7.5) releases. I have tested this twice on 2 different ships and got similar results.

 

Edited July 22, 2017 by Chaumas
Additional details and screenshot

[HebaruSan]

4 hours ago, Chaumas said:

I think I might have discovered a minor issue. The mod works perfectly well except when using it with RPM while on an escape trajectory.

I understand that the mod cannot be used while on an escape trajectory and we get the relevant message when we press the Astrogator button. However, if by accident or out of curiosity  we click the RPM monitor Astrogator button while on an escape trajectory, the game freezes and I have to do a force-quit.  I am on Mac running KSP 1.3 and using the latest RPM (0.29.0) and Astrogator (0.7.5) releases. I have tested this twice on 2 different ships and got similar results.

Thanks for the report! I've tried this and confirmed the bug, and I have a guess as to the cause. This fix will be my main priority for a new release.

[Chaumas]

1 hour ago, HebaruSan said:

Thanks for the report! I've tried this and confirmed the bug, and I have a guess as to the cause. This fix will be my main priority for a new release.

@HebaruSan Awesome and thank you. Meanwhile I will just have to be more careful and resist pushing that tantalizing RPM button! 

[HebaruSan]

Astrogator v0.7.6 is released.

The RasterPropMonitor display no longer freezes the game when there are no transfers to show. Ways that could happen:

• Outbound escape trajectory
• Inclination > 30°
• Your craft is the Sun (impossible, of course, but the code path exists)

Instead, an error message is shown as in the popup window:

I didn't want to leave this known issue out there after advertising on the RPM thread. Thanks again to @Chaumas for catching this.

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

[KerbMav]

@HebaruSan

Some encounters are a bit kerbed - Moho is nowhere near where this node will place me?

[Chaumas]

1 hour ago, HebaruSan said:

Astrogator v0.7.6 is released.

I didn't want to leave this known issue out there after advertising on the RPM thread.

@HebaruSan Thank you for such a quick update to Astrogator! I am glad to see that you are now on RPM's OP. I am looking forward to test the update. The RPM monitor error message looks good and I like the red colored font.  Thanks again!

[HebaruSan]

11 minutes ago, KerbMav said:

@HebaruSan

Some encounters are a bit kerbed - Moho is nowhere near where this node will place me?

Can you share that save file, so I can try the exact timestamp you have there?

[KerbMav]

17 minutes ago, HebaruSan said:

Can you share that save file, so I can try the exact timestamp you have there?

Uuh, heavily modded, but be my guest. ^^

Speaking of modded - how good does Astrogator handle modded planets?

https://www.dropbox.com/sh/7561x9jeso4w8ky/AAClaBr-pvOfxhlm2Ip9IoqZa?dl=0

[HebaruSan]

7 minutes ago, KerbMav said:

Uuh, heavily modded, but be my guest. ^^

Yeah, I saw that , but all I need is the alignment of the planets. It doesn't matter much if a bunch of modded craft get deleted on load in this case. Thanks!

7 minutes ago, KerbMav said:

Speaking of modded - how good does Astrogator handle modded planets?

It uses the standard APIs to get info about the planets rather than assuming anything about them, so planet packs are no obstacle.

So far, users have reported compatibility with RSS, OPM, Other Worlds, and Cercani:

 

[HebaruSan]

3 hours ago, KerbMav said:

Uuh, heavily modded, but be my guest. ^^

Are you using a solar system scaling mod? My times and delta V don't match up with your screenshot. (I can still more or less reproduce the problem with normal scale Moho, but I'd like to know for sure that it works in your case as well.)

[KerbMav]

43 minutes ago, HebaruSan said:

Are you using a solar system scaling mod? My times and delta V don't match up with your screenshot. (I can still more or less reproduce the problem with normal scale Moho, but I'd like to know for sure that it works in your case as well.)

Sigma Dimension - but I only doubled Kerbin in size, 5x Jool and increased its moons' orbits - mass of Kerbin might be higher, I think SD increases it to keep surface gravity the same.

[The Destroyer]

I haven't played KSP in quite a long time, but this mod sounds fantastic. Easy to use and works (mostly) well it seems!

[HebaruSan]

On 7/23/2017 at 6:48 PM, KerbMav said:

Sigma Dimension - but I only doubled Kerbin in size, 5x Jool and increased its moons' orbits - mass of Kerbin might be higher, I think SD increases it to keep surface gravity the same.

I tried changing Moho's eccentricity from 0.2 to 0.001 for testing purposes (Kopernicus is quite handy for this!). The maneuver that Astrogator generates for that Moho orbit is within 1 m/s of a direct impact encounter (although the close approach marker misleadingly shows an increase in distance as you get closer to the encounter). After that discovery, I tried changing Eeloo's eccentricity from 0.26 to 0.0001, and Astrogator gave me a maneuver that was within 2 m/s of an impact encounter. So the problem you observed is essentially the same problem Astrogator has with Eeloo: eccentric orbits are tricky.

Wikipedia describes a Hohmann transfer as: "an elliptical orbit used to transfer between two circular orbits of different radii in the same plane" (emphasis added). So the standard math for this may assume an eccentricity of 0, and I'll need to give some more consideration to how a transfer to an eccentric orbit should work. But I've at least found some discussion of non-circular orbits:

https://space.stackexchange.com/questions/13632/transfer-between-elliptical-orbits