Astrogator icon indicating copy to clipboard operation
Astrogator copied to clipboard

Interrupted transfers

Open markjfisher opened this issue 1 year ago • 2 comments

I was trying to create a transfer to Minmus, but as the Mun was in the way, it didn't make a sensible transfer.

Is this expected, or should Astrogator try another orbit when there isn't a body in the way?

Here's an image of the result:

image

The deltaV of the 2 nodes created when there isn't an intercept are the same as when there is an intercept, so it looks like it calculated the transfer as if nothing would get in the way. Can the calculations take into consideration that the eventual target isn't the one specified?

markjfisher avatar Sep 28 '22 23:09 markjfisher

Yes, that's expected. As far as I know, none of the automated tools try to detect when another body gets in the way like that. It could be a fun problem to work on, though.

HebaruSan avatar Sep 29 '22 00:09 HebaruSan

In my kos scripted transfers I originally wrote I recognised (through testing orbits) that if the phase angle of Mun was between 220 and 280 degrees from my ship at its ejection point (considering Mun at "North" or 0 degrees, and a CCW angle around Kerbin to the ship), then you would always get a Mun intercept, and I had to look further in the orbit for when this wasn't true. It isn't a sustainable solution though for the general case of X to Y, as you'd have to know every phase window that would interrupt the transfer, but was good enough for my very early game play (the furthest I've ever got is Minmus in the game, as I've only really started playing recently)

It felt a bit dirty though, and I think I can get kos-astrogator to check the SOI of the orbit does eventually meet the target, and if not, shoot the ship around until it does. It's a bit of a combination of approaches, but would be nicer if this was taken care of automatically, as there's way more power in the c# than kerbal script!

markjfisher avatar Sep 29 '22 07:09 markjfisher