transfer calculator [1.12] Astrogator v1.0.1

[HebaruSan]

11 hours ago, DY_ZBX said:

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?

Hi, and thanks for your comment!

I think you're experiencing a version of this:

On 11/11/2019 at 11:36 PM, HebaruSan said:

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

As you perform a burn, the transfers that are available change, and that means we need to update the display. You may notice that the rows sort in a different order after each shift:

 →   → 

Due to the way the DialogGUI stuff works, this requires us to close the dialog and re-create it, so that's the "if you open and close the window" part. I hope that's not too disruptive (because there's not a lot I can do about it).

[DY_ZBX]

4 hours ago, HebaruSan said:

Hi, and thanks for your comment!

I think you're experiencing a version of this:

As you perform a burn, the transfers that are available change, and that means we need to update the display. You may notice that the rows sort in a different order after each shift:

 →   → 

Due to the way the DialogGUI stuff works, this requires us to close the dialog and re-create it, so that's the "if you open and close the window" part. I hope that's not too disruptive (because there's not a lot I can do about it).

It turned out to be because of this reason, I thought it was not enough for my configuration.

[Misguided Kerbal]

@HebaruSan, this might be a stupid question, but does Astrogator work with JNSQ? I know it works with Kerbal Komets.

[vossiewulf]

2 minutes ago, Misguided_Kerbal said:

@HebaruSan, this might be a stupid question, but does Astrogator work with JNSQ? I know it works with Kerbal Komets.

Yes, it works fine.

Question, when fast-forwarding using Astrogator to a launch window, sometimes the time warp stops 3 minutes or so before the window. Other times it stops 10 seconds or less from the launch time, and other times it fast-forwards all the way to zero so you end up missing the launch time by a few seconds. I've yet to be able to see what the pattern is, can anyone explain?

[HebaruSan]

49 minutes ago, vossiewulf said:

Question, when fast-forwarding using Astrogator to a launch window, sometimes the time warp stops 3 minutes or so before the window. Other times it stops 10 seconds or less from the launch time, and other times it fast-forwards all the way to zero so you end up missing the launch time by a few seconds. I've yet to be able to see what the pattern is, can anyone explain?

It's supposed to be half the burn time plus 1 minute. If you're already inside of that 1 minute, then it warps to half the burn time. If you're inside of half the burn time, then it warps to the burn itself.

https://github.com/HebaruSan/Astrogator/blob/2d0f58483e215e62b6ddccfd6bb70eebb0c2229f/src/TransferModel.cs#L789-L824

[vossiewulf]

3 hours ago, HebaruSan said:

It's supposed to be half the burn time plus 1 minute. If you're already inside of that 1 minute, then it warps to half the burn time. If you're inside of half the burn time, then it warps to the burn itself.

https://github.com/HebaruSan/Astrogator/blob/2d0f58483e215e62b6ddccfd6bb70eebb0c2229f/src/TransferModel.cs#L789-L824

Thanks Hebarusan. I'm not quite sure it's doing that, but I will check now that I know what it's supposed to do.

[vossiewulf]

Hebarusan, is that behavior you're describing from the Space Center, or the launch pad? I tend to use it on the launch pad, i.e., launch and then warp to window then take off. In the latter case of using it on the launchpad, the vast majority of the time it warps right to zero on the launch window, and in a small percentage of cases you'll see it go to zero then suddenly there are a few more seconds back on the clock (up to 5 max) that then tick down again. I've just done a whole series of these warps from 9 hours ahead of time down to 30 minutes and I see the same thing every time, it doesn't leave you time to nail the takeoff window. 

Keep in mind though that I also use Astrogator constantly and it's one of my required mods, so just trying to make it better here (at least if what I'm seeing is not intended), and thanks for making it and supporting it.

[HebaruSan]

8 hours ago, vossiewulf said:

Hebarusan,

Hi @vossiewulf,

8 hours ago, vossiewulf said:

is that behavior you're describing from the Space Center, or the launch pad?

No, it's for orbit (whenever the Duration column is visible). At the space center and launch pad, there's no known burn time, because we don't know how long it will take you to launch. So "half the burn time" is not a meaningful quantity, and I think it would default that part to 0.

8 hours ago, vossiewulf said:

I tend to use it on the launch pad, i.e., launch and then warp to window then take off. In the latter case of using it on the launchpad, the vast majority of the time it warps right to zero on the launch window,

Yeah, that's what I'd expect based on the current logic; it would warp either to the exact window or one minute before (treating "half the burn time" as 0).

8 hours ago, vossiewulf said:

and in a small percentage of cases you'll see it go to zero then suddenly there are a few more seconds back on the clock (up to 5 max) that then tick down again. I've just done a whole series of these warps from 9 hours ahead of time down to 30 minutes and I see the same thing every time, it doesn't leave you time to nail the takeoff window. 

Clearly that's not ideal for your play style, but I wonder what it should do instead. Would you want one full homeworld-day of padding? More? How many launches would you typically do for a given window?

8 hours ago, vossiewulf said:

Keep in mind though that I also use Astrogator constantly and it's one of my required mods, so just trying to make it better here (at least if what I'm seeing is not intended), and thanks for making it and supporting it.

You're welcome, and thanks for the feedback!

[vossiewulf]

3 hours ago, HebaruSan said:

Clearly that's not ideal for your play style, but I wonder what it should do instead. Would you want one full homeworld-day of padding? More? How many launches would you typically do for a given window?

For local launches (Mun/Minmus), I think the windows are much too small for multiple launches, so I launch, warp forward to next window, then do the next launch and anything non-local gets launched to the target from orbit with reasonable separations (hours apart, I don't want to be madly switching back and forth between vehicles as they all hit the target SOI close together).

If you're willing to make a change, for simplicity's sake just add one minute padding to launchpad warps. That's plenty to do one last scan before launch, and if you're warping from the launchpad you're saying you're ready to launch so you shouldn't need much padding. I think the padding for Space Center warps should be a bit more since you may want to hit the tracking station or mission control first. In orbit, where you know the window, I think your current logic works fine.

[Sarxis]

Circularization on approach option?! Woah, awesome! Oh, and I finally got around to trying out adjusting the nodes using the translate keys - so good!  lol  

[gilflo]

Hello thank you for this mod

Is it possible to use it on KSRSS in the solar system, or is there a special database to write to use it in this case?

 

Edited September 16, 2020 by gilflo

[HebaruSan]

24 minutes ago, gilflo said:

Hello thank you for this mod

You're welcome, glad you like it.

24 minutes ago, gilflo said:

Is it possible to use it on KSRSS in the solar system

Yes.

24 minutes ago, gilflo said:

or is there a special database to write to use it in this case?

No special database, the planet data is loaded from the game on the fly, using whatever planet packs you have installed.

[gilflo]

Great!!

[gilflo]

I have a question about the nodes that are generated

I am trying to burn for Mars and Astrogator generates 2 nodes, the first one at the departure time, but there is no encounter with Mars et the second one is 348 days later (236DV)?

What's the meaning of these 2 nodes?  It does not seem to be the lowest DV window

How am I suppose to use this?

[HebaruSan]

4 hours ago, gilflo said:

but there is no encounter with Mars et the second one is 348 days later (236DV)?

What's the meaning of these 2 nodes?

The second node is the plane change. Astrogator generates one maneuver to adjust your solar apoapsis, then another to align your orbit with your target's orbit.

[HebaruSan]

Astrogator v0.10.2 is released! Just a few minor fixes:

• Changed how we search for encounters to avoid missing them in certain cases when they're in the near future (based on an old PM from @strider3)
• Then I noticed I was getting wrong plane changes, and that code is all borrowed from MechJeb, so I checked the current MJ and found some changes related to degrees vs radians (that seemed to have been made before I borrowed it? Either way, pulling them forward fixed my plane changes).
• Made transfers from retrograde orbits work more like their prograde counterparts as part of the first fix above

I also tried warping to a transfer on the lauch pad. To my surprise, it stopped at T-minus 3 minutes! I think that it's feeding the estimated launch delta V into the stock delta V simulator to figure out how long it would take the craft to burn that much, then pretending that's the burn duration and therefore dividing it by 2 and adding 1 minute (so presumably my test craft reaches ~3400 m/s sometime around the 4 minute mark). For now I'm going to leave it like that, as it seems mostly reasonable.

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

Edited October 28, 2020 by HebaruSan

[NateDaBeast]

On 10/28/2020 at 1:49 AM, HebaruSan said:

Astrogator v0.10.2 is released! Just a few minor fixes:

• Changed how we search for encounters to avoid missing them in certain cases when they're in the near future (based on an old PM from @strider3)
• Then I noticed I was getting wrong plane changes, and that code is all borrowed from MechJeb, so I checked the current MJ and found some changes related to degrees vs radians (that seemed to have been made before I borrowed it? Either way, pulling them forward fixed my plane changes).
• Made transfers from retrograde orbits work more like their prograde counterparts as part of the first fix above

I also tried warping to a transfer on the lauch pad. To my surprise, it stopped at T-minus 3 minutes! I think that it's feeding the estimated launch delta V into the stock delta V simulator to figure out how long it would take the craft to burn that much, then pretending that's the burn duration and therefore dividing it by 2 and adding 1 minute (so presumably my test craft reaches ~3400 m/s sometime around the 4 minute mark). For now I'm going to leave it like that, as it seems mostly reasonable.

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

Any chance you could add in a button that would allow us to add transfer window times to our Kerbal Alarm Clock lists? Is a bit tedious manually entering the time.

[HebaruSan]

13 minutes ago, NateDaBeast said:

Any chance you could add in a button that would allow us to add transfer window times to our Kerbal Alarm Clock lists? Is a bit tedious manually entering the time.

Standard KAC-question response:

On 3/7/2019 at 1:17 PM, HebaruSan said:

No, but KAC makes it pretty easy to add an alarm for a maneuver node (created by Astrogator or not), if you want to do that. And KAC already has its own transfer window features.

[strider3]

On 10/27/2020 at 11:49 PM, HebaruSan said:

Astrogator v0.10.2 is released! Just a few minor fixes:

• Changed how we search for encounters to avoid missing them in certain cases when they're in the near future (based on an old PM from @strider3)
• Then I noticed I was getting wrong plane changes, and that code is all borrowed from MechJeb, so I checked the current MJ and found some changes related to degrees vs radians (that seemed to have been made before I borrowed it? Either way, pulling them forward fixed my plane changes).
• Made transfers from retrograde orbits work more like their prograde counterparts as part of the first fix above

I also tried warping to a transfer on the lauch pad. To my surprise, it stopped at T-minus 3 minutes! I think that it's feeding the estimated launch delta V into the stock delta V simulator to figure out how long it would take the craft to burn that much, then pretending that's the burn duration and therefore dividing it by 2 and adding 1 minute (so presumably my test craft reaches ~3400 m/s sometime around the 4 minute mark). For now I'm going to leave it like that, as it seems mostly reasonable.

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

Thanks for the update!

[strider3]

On 11/2/2020 at 10:23 AM, strider3 said:

Thanks for the update!

@HebaruSan

Does 10.2 not work in KSP 1.73? I updated to the 0.10.2 release, to eliminate the issue I originally posted, and double checked the install...but I get no Icon for Astrogator on the sidebar?

Edited November 6, 2020 by strider3

[HebaruSan]

10 minutes ago, strider3 said:

Does 10.2 not work in KSP 1.73? I updated to the 0.10.2 release, to eliminate the issue I originally posted, and double checked the install...but I get no Icon for Astrogator on the sidebar?

I follow the modding sub-forum convention of indicating the game version compatibility in brackets at the start of the thread title.

[strider3]

1 hour ago, HebaruSan said:

I follow the modding sub-forum convention of indicating the game version compatibility in brackets at the start of the thread title.

OK...I see that...now. Thanks!

The problem I have is that I am always 2-3 versions behind on KSP...due to waiting on the 20+ mods I use to be updated to newer versions. I'm not complaining by any means...just stating facts. Usually it's not an issue...I just wait for all my mods to be updated and then update KSP and everything. The rare problem is when a mod gets a "fix", as in this case, with Astrogator. The other thing I run into is I have 3 or 4 mods that aren't readily available on the Community/Mods site...and have to go searching for them. PreciseManeuver is one. I do wish there was a better way to make it all a little less painful but I guess I'll have to do the Mods review and see what is available for KSP 1.8 and up.

Thanks again!

[HebaruSan]

18 minutes ago, strider3 said:

The problem I have is that I am always 2-3 versions behind on KSP...due to waiting on the 20+ mods I use to be updated to newer versions.

Yeah, I know plenty of folks do that. For what it's worth, the jump from 1.7 to 1.8 broke most plugins quite a while back, and most actively maintained mods were updated shortly thereafter; if a mod still hasn't been updated past 1.7, it probably won't be.

18 minutes ago, strider3 said:

The other thing I run into is I have 3 or 4 mods that aren't readily available on the Community/Mods site...and have to go searching for them. PreciseManeuver is one. I do wish there was a better way to make it all a little less painful but I guess I'll have to do the Mods review and see what is available for KSP 1.8 and up.

PreciseManeuver is listed in CKAN (for KSP 1.8), maybe that would work for you?

[strider3]

@HebaruSanRight know I'm trying to download a clean and full install of KSP 1.8.1...all I see are patches. 1.9 mods I need aren't in existence. I will ask about this in the proper forum. Thank you, Sir!

Update: Looks like I will be sticking with 1.7.3 for now. Do you know how many days in advance of a given transfer window that Astrogator 0.9.2 will go to the next transfer window (the issue I originally asked about in my PM)? I ask because I would like to know how late I can put 4 ships in Kerbin orbit and still have Astrogator choose the next available Dres transfer window...not the one after that? 30 days, 50 days? I hope I'm explaining this correctly.

Thanks for your time and efforts, by the way...it is very appreciated.

Edited November 7, 2020 by strider3

[HebaruSan]

23 hours ago, strider3 said:

Do you know how many days in advance of a given transfer window that Astrogator 0.9.2 will go to the next transfer window (the issue I originally asked about in my PM)? I ask because I would like to know how late I can put 4 ships in Kerbin orbit and still have Astrogator choose the next available Dres transfer window...not the one after that? 30 days, 50 days?

Hmm, not sure, but maybe we can figure out an upper bound...

The old logic looked for an optimal transfer solution within a 90 degree arc around an initial guess based on the relative phase angles (KAC's transfers use essentially the same logic as that initial guess). The problem occurred when the solution was in the future but the corresponding initial guess was in the past. In the worst case, we can assume that they're 45 degrees apart (initial guess at the center of the search interval and the solution at the future edge) and that the initial guess is in the very recent past (say, 1 second). So about ⅛ of the starting body's orbit, or 53 Kerbin days if you start from Kerbin? But that's only the absolute worst case; 50% of the time, the solution is before the initial guess, and the problem wouldn't happen at all, and in the remaining 50% the number of days probably ranges from 0 to 53 with some distribution unknown to me.

(For those curious, the fix just got rid of the initial guesses entirely. The first 90 degree search arc now starts at the immediate present in all cases, because our method for discarding bad guesses is efficient.)

Edited November 7, 2020 by HebaruSan