transfer calculator [1.12] Astrogator v1.0.1

[MechBFP]

7 hours ago, HebaruSan said:

That would be the ascending or descending node.

What did you expect it to do instead?

I was expecting the manevour node around Kerbin to be placed (in position and time) to do a direct Hohman transfer with only a slight adjustment in solar orbit to hit the target.

Edited July 23, 2019 by MechBFP

[HebaruSan]

20 minutes ago, MechBFP said:

I was expecting the manevour node around Kerbin to be placed (in position and time) to do a direct Hohman transfer with only a slight adjustment in solar orbit to hit the target.

Ahh, that's not how that works.

On 7/25/2017 at 5:06 PM, HebaruSan said:

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

(different emphasis than last time)

The things we do to handle differing planes (and eccentricity!) are outside the scope of Hohmann transfers, hacks tacked on later. Currently Astrogator does a simple plane change at the AN/DN, because that's what I could figure out how to program. I've wished for a better way, but not found one that actually works yet.

Is your suggestion possible mathematically? Burning only at Kerbin would always give you a solar transfer orbit that's co-planar with the Sun and Kerbin's starting location; effectively you can 'tilt' it along the major axis (since Kerbin will be your solar Pe or Ap). Since it's a Hohmann transfer, you arrive at the destination orbit at the opposite end of the major axis, at your solar Ap/Pe. But we just said we're only tilting around that axis, which means points on that axis don't move, so such a burn can't move your arrival point north or south.

That's why I went with ordinary plane changes. Let me know if you see a gap in that proof; it seems pretty air-tight to me. I guess there might be some wiggle room if you depart even further from a Hohmann transfer than usual, e.g. putting the Ap higher than the target orbit, or something like that...?

[Wyzard]

This may be out-of-scope for Astrogator, but to avoid the expensive plane changes, it'd be handy to have the option to do the transfer a different way.  Assuming for Ap/Pe terminology purposes that we're going to Moho:

• Do the Kerbin escape burn at the point where Kerbin passes through the target's plane.  Bring the solar Pe down to touch Moho's orbit.
• Wait for the spacecraft to reach that Pe, so the spacecraft is at a point on Moho's orbit.  It's not a rendezvous;  Moho will (probably) be somewhere else.
• Do another burn to lower Ap partway to Moho's, such that the spacecraft's orbital period around the sun will lead to a rendezvous in the future.

It's a much slower way to do the reach the target (potentially several years), but can be worth it to avoid the plane change.

[HebaruSan]

5 hours ago, Wyzard said:

• Do the Kerbin escape burn at the point where Kerbin passes through the target's plane.  Bring the solar Pe down to touch Moho's orbit.
• Wait for the spacecraft to reach that Pe, so the spacecraft is at a point on Moho's orbit.  It's not a rendezvous;  Moho will (probably) be somewhere else.
• Do another burn to lower Ap partway to Moho's, such that the spacecraft's orbital period around the sun will lead to a rendezvous in the future.

That's a really interesting idea. It's definitely not something that could be added to Astrogator without a major rewrite, but maybe someday.

Or as a stopgap, a toggle to limit transfers to when the target is a certain distance from the AN/DN. This would skip some windows, but the ones it did find could (maybe) get encounters without plane changes.

[Wyzard]

Searching for transfers where the target is near the AN/DN would work, but I suspect the transfer it finds will usually be far in the future, since it depends on both the target's proximity to AN/DN and Kerbin being correctly aligned with the target (in terms of phase angle) for a Hohmann transfer window.  Those two events don't usually coincide.  My intuition says that waiting for them to coincide will typically push the rendezvous further into the future than the handful of extra orbits in the transfer I suggested, though I can't substantiate that mathematically.

If you're looking for a stopgap, maybe you can implement just step 1 of the procedure I described: make a maneuver that departs next time Kerbin is at AN/DN, regardless of the target's phase angle at that time.  Once the spacecraft is on a trajectory that touches the target's orbit, the rendezvous is fairly easy to set up manually.  It's essentially a Hohmann transfer whose second burn has been split into two smaller burns executed at different times, so the dV is the same as what it would be if the target was properly aligned for a plain Hohmann.  Without computing the second maneuver, you won't be able to display exactly when the eventual rendezvous will occur, but "it gets there when it gets there" can be OK for some missions.

BTW, this is basically the same procedure  I use to rendezvous two spacecraft on the daylight side of a planet, when a plain Hohmann would have them meet in the dark.  I'm guessing others do the same.  Splitting off part of the rendezvous burn into a separate orbit-period-adjustment burn eliminates the need for an alignment window, so the rendezvous can occur anywhere you want, at the cost of taking longer (more orbits) to reach it.

(And on the topic of alternative transfers: there's also the bi-elliptic transfer.  I've never done one of those, though.)

[Friznit]

What you describe is pretty much a standard way of getting to places like Moho. Ignore the phase angle derived transfer window and instead depart Kerbin at the AN/DN.  As you state, it can take an additional orbit (or more) around the sun to capture Moho but it cuts down the overall trip dV requirements massively, and in particular the capture burn which can otherwise be prohibitively high.  This works well for Moho because opportunities come round often.

Astrogator could really help with planning by identifying when the local body coincides with the plane of the target, as an alternative to the regular transfer windows - perhaps as a switchable option?  As far as I know the only way to do this in stock is to lob a satellite into orbit and create a test manoeuvre node to see where the AN/DN, then take a note of the time and plan your actual launch around it.  Obviously that only works if you can get a satellite into orbit at the starting point.

[rmaine]

I appear to have the UI scaling bug. For some time, I thought the astrogator window just wasn't opening. Not til I perused prior posts here did it occur to me that my symptoms seemed consistent with the UI scaling bug. Reports imply that was fixed 2 years ago. My normal UI scale setting is 170% and I usually don't see the astrogator window at all. (It briefly came back right after a staging in a recent session, but when I came back later it was gone again). Indeed, if I drop the UI scaling to 100%, the astrogator window appears just fine. I pretty much can't read it or anything else on the screen, but I can see that it's there. At 150% UI scaling, the astrogator window is offset a bit low and left, but it is visible. At 170%, it disappears again. I tried manually editing the window position to a few different guesses in astrogator-settings.txt (I tried 0.0,0.0 and 0.25,.25 and 0.75,0.75) but none of them worked and after quitting I see that astrogator had automatically reset to the 0.5,0.35 that it seems to default to when UI scale is 170%. Other UI scales result in it auto-resetting to different values.

I suppose I could play at 150%, though it slightly strains my eyes. 100% is just plain out.

Relevant (possibly) data

  KSP 1.7.3.2594 win 64 en-us, Making history 1.7.1, breaking ground not installed (or purchased)

  resolution 2560x1600 full screen

UI scale 170% (usually; see above)

apps scale 100% (I've always been a bit confused about what this affects vs what the UI scale effects. Plus I don't know why it is only in the settings menu you get to after starting the game as opposed to the one on the main screen.)

  Mods (per CKAN)

  [x] science continued 5.22,

  Astrogator 0.9.2

  click through blocker 0.1.7.2

  KEI 1.2.9.10

  kerbal alarm clock 3.10.0.0

  kerbal engineer redux 1.1.6.0

  mechjeb 2 2.8.4.0

  module manager 4.0.3

  precise maneuver 2.4.2

  toolbar controller 0.1.8.2 (I don't have toolbar, just the controller, which several mods require)

  triggerAuFlags 2.9.3

 Link to a log file, though I don't see anything suspicious in it. Little about astrogator other than griping about the image files not being compressible, which seems innocuous. This log file was from just starting a saved game, which opens at the space center. No astrogator window appears. Then I quit. Doing the sam ething with UI scale 100% or 150% does show an astrogator window. I probably won't leave this log file up on dropbox forever, as it's of little long-term interest.

https://www.dropbox.com/s/qq24p0d06jb7yl2/output_log.txt?dl=0

 

Astrogator-settings.txt:

MainWindowPosition = 0.49999997,0.349999934
MainWindowVisible = True
ShowSettings = False
DeleteExistingManeuvers = False
GeneratePlaneChangeBurns = True
AddPlaneChangeDeltaV = False
AutoTargetDestination = True
AutoFocusDestination = True
AutoSetSAS = True
AutoEditEjectionNode = True
AutoEditPlaneChangeNode = False
TransferSort = Position
DescendingSort = False
DisplayUnits = Metric
ShowTrackedAsteroids = True
TranslationAdjust = True

[rmaine]

what? Um, let me rephrase that more politely as Hmmm. :-) So I pick up playing the same game as I posted the above data about. My usual 170% UI scale and no astrogator window visible. I'm not really needing it at this early stage of career anyway. I launch a mission to go rescue a Kerbal stranded in low orbit. As soon as I stage (dropping my SRBs), the astrogator window suddenly pops into view. I continue to a stable orbit so I can safely quit the game. The astrogator-settings.txt file has set the main window position to 0.85,0.85 (and rounding change). I restart the game, which of course puts me at the space center. No astrogator window. Use the tracking station to go to my rescue vehicle waiting in orbit. Still no window. Quit again to examine the astrogator-settings file. It's back at 0.5,0.35 (roughly).

[edit] Amused that the forum software bowdlerized my initial version of this post by changing my 3-letter common net abbreviation for an expression of surprise to the less controversial form "what". Probably made my comment about rephrasing it more politely a bit confusing.

Edited August 14, 2019 by rmaine
explain the forum's bowdlertization.

[HebaruSan]

3 hours ago, rmaine said:

 

I'm sorry you're having problems with UI scaling. For what it's worth, it was just as frustrating for me when I was trying to fix that. The window positions with UI scaling enabled just made no sense, and with an actual fix seemingly unattainable, I just tried to unscramble it with various workarounds. Apparently something changed and they're no longer helping. I probably won't bother investigating this fully since I'd expect it to still be just as incoherent and unfixable, but I may try disabling the old workarounds just to see if that makes it any better. Maybe it's improved, who knows.

(BTW, if you want me to remember to look into this between fixing things for CKAN and SpaceDock, make an issue:

https://github.com/HebaruSan/Astrogator/issues/new/choose )

Edited August 14, 2019 by HebaruSan

[rmaine]

11 hours ago, HebaruSan said:

I'm sorry you're having problems with UI scaling. For what it's worth, it was just as frustrating for me when I was trying to fix that. The window positions with UI scaling enabled just made no sense, and with an actual fix seemingly unattainable, I just tried to unscramble it with various workarounds. Apparently something changed and they're no longer helping. I probably won't bother investigating this fully since I'd expect it to still be just as incoherent and unfixable, but I may try disabling the old workarounds just to see if that makes it any better. Maybe it's improved, who knows.

(BTW, if you want me to remember to look into this between fixing things for CKAN and SpaceDock, make an issue:

https://github.com/HebaruSan/Astrogator/issues/new/choose )

Done (mostly just a cut&paste job from my description here). Thanks for your attention. And yes, I have a pretty good idea how much of your time I have a right to expect for support of a free mod (none). If I get desperate enough, I suppose I can play at 100% UI scale by cutting my resolution way back (assuming that doesn't just shrink everything to a fraction of my screen to maintain the same dot pitch). I used to do that before KSP supported a UI scale at all. Shame to go back there to low resolution, but I suppose it's an option.

[genbrien]

is this ok for 1.8?

[Kerbal101]

@genbrien Doesn't look like it. The plugin is working fine, but the created maneuvers are not very precise.

[HebaruSan]

On 10/21/2019 at 3:43 PM, genbrien said:

is this ok for 1.8?

On 10/31/2019 at 10:09 PM, Kerbal101 said:

@genbrien Doesn't look like it. The plugin is working fine, but the created maneuvers are not very precise.

I am planning a new release for KSP 1.8, since the Unity and .NET upgrades probably broke any number of things. As part of that I am looking into @rmaine's UI scaling bug report. The behavior of PopupDialog is still distressingly illogical (the left side of the screen is 0.33867 at 200% scaling??), but I have discovered a few things that may allow me to make some improvements. Fingers crossed!

[HebaruSan]

Astrogator v0.10.0 is released!

• References are updated to KSP 1.8 and .NET 4.7. This version is not compatible with KSP 1.7 or earlier.
• @Sooll3 contributed some much appreciated missing strings for the Russian translation. Sorry I sat on this for so long!
• UI scaling should hopefully work better now! The previous strategy was to quickly place a dummy window, immediately close it before the user saw it, and then open the real window at an offset based on the difference between the dummy window's requested and actual position. That's gone now.
  Instead, I dug in to how MultiOptionDialog's Rect param works at various UI scales (poorly!), made a spreadsheet and a graph, and used them to solve for a formula to calculate the apparent screen bounds at a given scale. Using this we can finally ensure a dialog will appear on-screen! There will be some gradual "drift" at some scales if you open and close the window repeatedly due to the numbers not matching up precisely, but it should be an improvement over not being able to see it at all.
  If you notice further problems with this, please reply at https://github.com/HebaruSan/Astrogator/issues/20 and include details about your screen resolution in case the formula relies on any bad assumptions about the display. Workarounds like this can be sensitive to things like that, and I've only got one system for dev and testing.
  

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

Edited May 9, 2020 by HebaruSan

[Stone Blue]

@HebaruSan Just an FYI, and to hopefully keep anyone asking about if it runs on 1.8.1: KSP AVC is reporting v0.10.0 only runs on KSP v1.8 ... on a 1.8.1 install

Edited December 20, 2019 by Stone Blue

[leatherneck6017]

-

Edited February 11, 2020 by leatherneck6017

[HebaruSan]

Astrogator v0.10.0 seems to be working fine on KSP 1.9.0, so I've updated the remote version file to mark it as supported. This will propagate through to CKAN soon.

[Misguided Kerbal]

Does this work with Principia? I've already tried it in stock and it works great.

[HebaruSan]

9 hours ago, Misguided_Kerbal said:

Does this work with Principia? I've already tried it in stock and it works great.

I haven't tried it, but I'd be surprised if it turned out to be useful, given how much it relies on the stock sphere of influence model.

[Krzeszny]

Could it show how much deltaV it saves by waiting for the transfer window compared to burning without waiting?

[Superfluous J]

1 hour ago, Krzeszny said:

Could it show how much deltaV it saves by waiting for the transfer window compared to burning without waiting?

You'd need to define how you were planning to do a burn outside a transfer window, as there are innumerable ways to do it "wrong" but only one way to do it "right"

[HebaruSan]

8 hours ago, Krzeszny said:

Could it show how much deltaV it saves by waiting for the transfer window compared to burning without waiting?

7 hours ago, Superfluous J said:

You'd need to define how you were planning to do a burn outside a transfer window, as there are innumerable ways to do it "wrong" but only one way to do it "right"

Yeah, if you're interested in exploring the space of all possible burns, check out Transfer Window Planner's pork chop plots. Each column in the heat map corresponds to a different launch date, each row is a different length transfer starting on that date, and the colors show how expensive the burn is. In the example in the thread OP, you can save 22357 m/s by burning at the best time as compared to the worst time:

https://forum.kerbalspaceprogram.com/index.php?/topic/84005-17x-transfer-window-planner-v1710-august-19/

Astrogator only deals in "good" burns.

[Krzeszny]

Transfer Window Planner isn't compatible with 1.9.1. I'll stick with your mod

[HebaruSan]

Astrogator v0.10.1 is released!

• Some untranslated strings in the Spanish translation have been translated, big thanks to @fitiales
• Fixed a crash on vessel switch, thanks to Git user joelmeaders for the report

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

[DY_ZBX]

Hi. Thank you for bringing this mod.
Emm... 

I have a problem, when I run the engine, the GUI will shift, as I described in the video below.

In some cases, if the GUI is not actively moved, it will also shift itself.

I would like to ask what caused this situation?