transfer calculator [1.12] Astrogator v1.0.0

[Jebs_SY]

21 hours ago, HebaruSan said:

I'm not 100% sure of that... http://ksp.cybutek.net/kspavc/Documents/README.htm

• KSP_VERSION - Optional, Required for MIN/MAX
  Version of KSP that the add-on was made to support.

That phrasing isn't very clear, but I took it to mean you either need KSP_VERSION by itself, or KSP_VERSION_MIN and KSP_VERSION_MAX. I'm not sure what the advantage of providing all three would be; if anything, it could cause confusion by giving conflicting impressions of the scope of compatibility. Looking at the registry.json file, that does seem to be how existing mods use these fields, and my data seems to be in line with others':

 

Oh, you're right. KSP_VERSION is optional, but as soon one uses KSP_VERION_MIN and/or KSP_VERSION_MAX then KSP_VERSION is mandatory. In the end it's required indirectly for CKAN.
You could always update the .version file and release it as 0.2.1. I think.

The point is, I am observing another mod (part angle display) that doesnt get his update recognized by CKAN and that mod also only has KSP_VERSION_MIN and KSP_VERSION_MAX defined and it seems that CKAN ignores that release even if the netkan settings seem right for me. So I think CKAN takes the AVC specification seriously and does want a KSP_VERSION.
On the other hand, you/we will find thatout on your next release.  

Edited February 10, 2017 by Jebs_SY

[Jebs_SY]

If you're interested, you could take a look at the part angle display netkan and the last 3 releases and check the version files in it.
0.3.2.2 had a KSP_VERSION only and got indexed. 0.3.2.3 had 2x KSP_VERSION_MIN and got not indexed. However, 0.3.2.4 has a KSP_VERSION_MIN and KSP_VERSION_MAX and does also not got indexed.
That is, why I assume, CKAN want's a KSP_VERSION. But I could be wrong.

Edited February 10, 2017 by Jebs_SY

[HebaruSan]

4 minutes ago, Jebs_SY said:

If you're interested, you could take a look at the part angle display netkan and the last 3 releases and check the version files in it.

0.3.2.2 had a KSP_VERSION only and got indexed. 0.3.2.3 had 2x KSP_VERSION_MIN and got not indexed. However, 0.3.2.4 has a KSP_VERSION_MIN and KSP_VERSION_MAX and does also not got indexed.

I think that's actually caused by an unrelated syntax error in his .version file. There should be a comma between these two objects (JSON is mindbogglingly strict sometimes).

https://github.com/Gerry1135/PartAngleDisplay/blob/master/Output/PartAngleDisplay/PartAngleDisplay.version

	"KSP_VERSION_MIN":{
		"MAJOR":1,
		"MINOR":2,
		"PATCH":0
	}      //<--- COMMA IS MISSING HERE
	"KSP_VERSION_MAX":{
		"MAJOR":1,
		"MINOR":2,
		"PATCH":2
	}

I'll submit a pull request in case it helps.

[Jebs_SY]

17 hours ago, HebaruSan said:

I think that's actually caused by an unrelated syntax error in his .version file. There should be a comma between these two objects (JSON is mindbogglingly strict sometimes).

Wow! Indeed! Thx for figuring that out / explaining that. I've missed that. Something learned again and a false assumption on my side corrected!  o/

EDIT: @HebaruSan

You're totally right regarding version and min/max. Iv'e found this: "It is an error to mix version (which specifies an exact version) with either min_version or max_version in the same object. "

 

Edited February 10, 2017 by Jebs_SY

[HebaruSan]

Do you find establishing encounters with the stock maneuver editor frustrating? Do you like to set up your arrival trajectory along a precise path, but struggle with finding the maneuver, clicking the handle you want, or dragging the mouse the right amount (or all three)? Have you ever experienced the torment of editing different components of multiple nodes simultaneously? If you use Astrogator, the 0.3.0 release has a new option for you!

With this new setting enabled (it's on by default), maneuver nodes created via Astrogator's node creation buttons will respond to the RCS translation keys (and the joystick/controller translation axes), as long as RCS is turned off:

• h/n: Adjust the prograde component of the ejection burn
• i/k: Adjust the normal component of the plane change burn
• j/l: Adjust the radial component of the plane change burn

Holding the modifier key (alt on Windows, right shift on Linux) will make smaller changes for greater precision. Now it's easier to fine tune your maneuvers without fumbling with the mouse. (Yes, this functionality is similar to PreciseNode and other mods; I feel that Astrogator is responsible for easing the pain of tweaking any nodes it creates that aren't quite perfect.)

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

NOTE: Only nodes created by Astrogator will respond to these keys, and only if you haven't saved/loaded or switched scenes since clicking the node button. Otherwise you'll have to edit them in the usual ways.

[diomedea]

Would be possible to add tracked asteroids to the list of bodies for which a transfer is selectable? I plan maneuvers manually all the time, asteroids can get a bit tricky to do right (as do bodies with a small SoI), believe this tool could come handy with roids even more than it is with planets.

[sarbian]

Nice to see some clean code  I should make the effort...

[Jebs_SY]

Thx for the update. H and N key working well, but when pressing IJKL I am getting a NRE. But I have to say, it's a highly modded install. So it could be a mod conflict. 

Spoiler

170210T115329.438 [EXCEPTION] [ManeuverNode.OnGizmoUpdated] NullReferenceException: Object reference not set to an instance of an object
   at ManeuverNode.OnGizmoUpdated (Vector3d dV, Double ut)
   at Astrogator.Astrogator.AdjustManeuver (Astrogator.BurnModel burn, Vector3d direction, Double fraction)
   at Astrogator.Astrogator.<keys>m__4 (Astrogator.AstrogationModel m)
   at Astrogator.Astrogator.Update ()
 

The NREs get spammed in the log while the keys are pressed. Only difference is m__2, m__3, m__4 and m__5.

EDIT: Also have Precise Maneuver and Maneuver Node Evolved installed. Doing a test without them, now.
EDIT2: Removed both, no change, still the NREs. Hmm

Edited February 10, 2017 by Jebs_SY

[Samapico]

On 10/02/2017 at 5:17 AM, diomedea said:

Would be possible to add tracked asteroids to the list of bodies for which a transfer is selectable? I plan maneuvers manually all the time, asteroids can get a bit tricky to do right (as do bodies with a small SoI), believe this tool could come handy with roids even more than it is with planets.

If possible, a more generic "target" could also work, and might work for various intercept courses. Would it only work if the target is orbiting a different body? Or does this mod work out the math even if the target is in the same system? Getting a rendez-vous with a single click would be awesome!

[HebaruSan]

On 2/10/2017 at 4:17 AM, diomedea said:

Would be possible to add tracked asteroids to the list of bodies for which a transfer is selectable? I plan maneuvers manually all the time, asteroids can get a bit tricky to do right (as do bodies with a small SoI), believe this tool could come handy with roids even more than it is with planets.

9 hours ago, Samapico said:

If possible, a more generic "target" could also work, and might work for various intercept courses. Would it only work if the target is orbiting a different body? Or does this mod work out the math even if the target is in the same system? Getting a rendez-vous with a single click would be awesome!

I've got good news and bad news on the asteroid front. Yes, I can add tracked asteroids to the list of transfers. However, this mod currently is all about Hohmann transfers, the timing of which depends on the relative angular velocity of bodies compared to their phase angle (so bodies with closer / more similar orbits will tend to have longer delays between their transfers). Since freshly spawned asteroids orbit the Sun close to Kerbin, their relative solar angular velocity is very low; consequently, if I treat asteroids the same way I treat planets, all four of my test asteroids have Hohmann transfers 7+ years into the future. Since they all have Kerbin encounters long before that, they'll also be experiencing gravity-slingshotted changes to their orbits, so I doubt those transfers would be of very much use even if you're willing to wait that long. (This is why you almost always want a less delta-V optimized route to an asteroid than a Hohmann transfer would give you. It's also worth noting that almost all of the transfers we auto-generate do require some manual tweaking to turn them into encounters or good rendezvous, so your "single click" is really just the first click.)

On the other hand, if you pilot your own non-Hohmann transfer to an asteroid and then maneuver it into, say, a high circular orbit over Kerbin that doesn't encounter Mun or Minmus, then the transfers to that asteroid would become more useful. Since that makes it useful in a minority of use cases, I'll plan to add tracked asteroids as a toggleable option. Similarly, the active vessel's target should already be included in the list of transfers in the last few released versions, so you should be able to target an asteroid yourself to see it in the list (though it's possible that a visual glitch might prevent it from updating as it's supposed to).

I'll add a future to-do item regarding rendezvous with bodies that will encounter Kerbin at some future date (i.e., try to intersect them near the Pe of the hyperbolic trajectory of their Kerbin encounters), but I have a feeling that may be a difficult task.

Edited February 12, 2017 by HebaruSan

[HebaruSan]

On 2/10/2017 at 5:05 AM, Jebs_SY said:

Thx for the update. H and N key working well, but when pressing IJKL I am getting a NRE. But I have to say, it's a highly modded install. So it could be a mod conflict. 

  Hide contents

170210T115329.438 [EXCEPTION] [ManeuverNode.OnGizmoUpdated] NullReferenceException: Object reference not set to an instance of an object
   at ManeuverNode.OnGizmoUpdated (Vector3d dV, Double ut)
   at Astrogator.Astrogator.AdjustManeuver (Astrogator.BurnModel burn, Vector3d direction, Double fraction)
   at Astrogator.Astrogator.<keys>m__4 (Astrogator.AstrogationModel m)
   at Astrogator.Astrogator.Update ()

The NREs get spammed in the log while the keys are pressed. Only difference is m__2, m__3, m__4 and m__5.

EDIT: Also have Precise Maneuver and Maneuver Node Evolved installed. Doing a test without them, now.
EDIT2: Removed both, no change, still the NREs. Hmm

I'm not seeing these exceptions on a stock+Astrogator install. Please let me know if you are able to further narrow down the mod conflict; I'd be willing to install an additional mod or two to track it down. In the meantime I'll add some additional error handling around maneuver adjustment, but I may not be able to make them go away completely since they're being raised in stock code.

[diomedea]

57 minutes ago, HebaruSan said:

I've got good news and bad news on the asteroid front. ....

Had a suspect asteroids wouldn't be easy to tame. They are all generated so to cross the SoI of another body within a rather short time, so there's not much of their Sun orbit before that, while a Hohmann transfer requires a large arc (180° along the transfer orbit). Almost all roid encounters are actually conducted within the minor body SoI, therefore while the roid is on a hyperbolic orbit (my procedure is to maneuver the vessel so to get an early encounter, as close as possible to the SoI limit, but that requires the vessel to be already past its AP and descending while the roid arrives from above; certainly not Hohmann). It is slightly less efficient than the early encounter to go meeting the roid before it even enters the minor SoI (though, the farthest from the minor, the less DV required to redirect the roid); but definitely such a maneuver requires a different approach.

So, I'm really glad to see there is interest in the idea. Delighted about the possibility to plan encounters with other vessels in the same SoI. 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.

[Jebs_SY]

1 hour ago, HebaruSan said:

I'm not seeing these exceptions on a stock+Astrogator install. Please let me know if you are able to further narrow down the mod conflict; I'd be willing to install an additional mod or two to track it down. In the meantime I'll add some additional error handling around maneuver adjustment, but I may not be able to make them go away completely since they're being raised in stock code.

I stripped down my 190 mod install step by step with CKAN until I only had Astrogator left. The error was still there. I transfered the save and the remaining files in gamedata into my vanilla folder and still had the NRE. I deleted all remaining files and it was still there. In the end it is reproducible with a Vanilla KSP + Astogator + the ship in this save.

Edited February 11, 2017 by Jebs_SY

[HebaruSan]

24 minutes ago, Jebs_SY said:

I stripped down my 190 mod install step by step with CKAN until I only had Astrogator left. The error was still there. I transfered the save and the remaining files in gamedata into my vanilla folder and still had the NRE. I deleted all remaining files and it was still there. In the end it is reproducible with a Vanilla KSP + Astogator + the ship in this save.

Thanks, I think that save file gave what I needed to fix it!

[HebaruSan]

Astrogator 0.4.0 has been released, featuring an option to generate solar Hohmann transfers to tracked asteroids (which isn't what you want most of the time, as per the above discussion, but could still be useful once in a while and may be improved in the future)...

... plus calculation of perfect-circle capture burns on inbound escape trajectories (I think this is the first burn I've seen with the projected post-burn Ap and Pe exactly the same down to the meter):

Note that once you pass periapsis, you're on your own again:

Finally, those pesky translation-key null reference exceptions should be gone from the log. I think some of the assumptions in the original PreciseNode code don't apply here because we have two active nodes instead of just one.

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

[DMagic]

On 2/10/2017 at 0:48 AM, HebaruSan said:

NOTE: Only nodes created by Astrogator will respond to these keys, and only if you haven't saved/loaded or switched scenes since clicking the node button. Otherwise you'll have to edit them in the usual ways.

Is the problem here that you don't have any reference to maneuver node gizmos not directly created by you? Because there is any easy solution to tracking any maneuver gizmo.

You can take advantage of the fact that the gizmo is a Unity MonoBehaviour that is instantiated from a prefab. The prefab is stored in MapView, so you can just wait for it to become available and attach a small script to it that gives a reference whenever the gizmo is started: 

https://github.com/DMagic1/KSP_Better_Maneuvering/blob/master/Source/BetterManeuvering/ManeuverController.cs#L305-L314

https://github.com/DMagic1/KSP_Better_Maneuvering/blob/master/Source/BetterManeuvering/ManeuverGizmoListener.cs

[HebaruSan]

Just now, DMagic said:

Is the problem here that you don't have any reference to maneuver node gizmos not directly created by you?

No, it's more about what I think should be in scope for this mod. If you've clicked one of my buttons to create maneuvers, then we know exactly what the RCS keys should do and how to do it. But if you've placed your own maneuvers somewhere for some unknown purpose (maybe you're leaving Minmus to burn at LKO to gravity assist past Eve, who knows), then messing with those is probably best left to a singularly focused mod like Precise Node (or, apparently, your Better Maneuvering ), which I'm not attempting to replace.

Thanks for the Unity tutorial, though. I'm still getting the hang of how it works, and it helps a lot when someone actually explains part of it.

[HebaruSan]

New in the 0.5.0 version of Astrogator, if you're orbiting a satellite of a body with a solid surface (Eve, Kerbin, Duna), the parent body will appear as a transfer destination corresponding to a burn to return to low orbit. It aims at just above the atmosphere, but there's still a margin of error; from Mun:

From Minmus:

And since I didn't like having an undiscoverable feature, there's now a notification line that informs the user about the translation control bindings when it's active:

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

[Jebs_SY]

What do you think about a possibility to create a circularisation maneuver at current AP/PE? 

[HebaruSan]

FYI, I caught a visual bug a few minutes too late to fix in 0.5.0: That notification message appears even if you disable the translation controls feature in the settings. That'll be fixed in whatever the next release turns out to be; I don't think it merits a fix release all by itself, though leaving it unfixed will weigh on my conscience.

A question for our resident mod fiends: Do you know of any planet pack that contains a landable body with a satellite that has its own sub-moon? Stock doesn't have this (since the Sun doesn't have a solid surface, and no moon has a moon of its own), but in principle it should be possible, and I'd like to test the return-to-parent routes feature in such a context.

2 minutes ago, Jebs_SY said:

What do you think about a possibility to create a circularisation maneuver at current AP/PE? 

I can think of three ways this could come up:

1. Go from a hyperbolic trajectory to a circular orbit at Pe (added this in 0.4.0)
2. Make an existing stable elliptical orbit more circular
3. Finish a launch (i.e., raise periapsis out of a suborbital trajectory)

For #2, I don't anticipate adding that. Being in a perfectly circular orbit doesn't come up as a game goal often enough to be worth taking up UI space, and I don't know if there would be a clear way to indicate what those two burns would do in the listing. But I'd be open to counterarguments on this.

For #3, I expect this to be superseded by other another long-term goal: Providing precise times for launching directly to ejection, like they do IRL (I think). If I want to go to Duna, I should be able to put my craft on the pad, click the >> icon for Duna, and then just launch till I have an encounter (and likewise for coming home). This has potential benefits in that you'd run at full throttle longer lower (Oberth), and you could leave your Pe in the atmosphere behind you, both of which should provide fuel savings.

[Errol]

Will that long term goal for number 3 include being able to account for launches off of the equator (with some inclination) and from bodies that have inclined orbits?

[HebaruSan]

1 hour ago, Errol said:

Will that long term goal for number 3 include being able to account for launches off of the equator (with some inclination) and from bodies that have inclined orbits?

Ideally yes, but at this point even the equatorial, KSC-only case is an unsolved problem, so I don't know what difficulties might arise and can't make any promises. If I gave the impression that I have a worked-out roadmap, I should admit that I only have a general vision and some notes about what would be cool. When I say "long-term," that just means I'd like to do it but don't know how yet.

But if anyone else does know how, pull requests are very welcome!

[Hesp]

7 hours ago, HebaruSan said:

like they do IRL (I think). If I want to go to Duna, I should be able to put my craft on the pad, click the >> icon for Duna, and then just launch till I have an encounter (and likewise for coming home). This has potential benefits in that you'd run at full throttle longer lower (Oberth), and you could leave your Pe in the atmosphere behind you, both of which should provide fuel savings.

Actually, this is the most efficient way to launch if you don't have to perform operations in low orbit. Just look at the latest Soyuz launch profile to GTO

https://spaceflight101.com/soyuz-vs16-launch-success/

It could be harder than it looks for the software, since a variation in TWR will lead to different gravity turns and ejection trajectories...

[Jebs_SY]

My intention for the circularize thing was (3) for example. I played around a little bit with Gravity Turn Continued and to compare the ascends, I have to (at least) create a node at AP=80km and cicularize that. I just thought, it would be cool to have a "1 click" for that. When you do it often after another. On the other hand, one can do it with 3 clicks with Precise Maneuver, too. So that's nor a problem if you don't want to wast UI space here.

[Jebs_SY]

Just a short question. I am tracking a problem, that I sometimes in the game lose the ability to create a maneuver node. This is unrelated to Astrogator, cause I had this problem also before installing astrogator.

However, I have much log entries like this:

Spoiler

170214T173446.724 [INFO] [Astrogator.DebugTools.DbgFmt] [Astrogator 2593.601] Differences: sma
170214T173446.730 [INFO] [Astrogator.DebugTools.DbgFmt] [Astrogator 2593.606] Differences: sma
170214T173446.758 [INFO] [Astrogator.DebugTools.DbgFmt] [Astrogator 2593.635] Differences: sma
170214T173446.791 [INFO] [Astrogator.DebugTools.DbgFmt] [Astrogator 2593.668] Differences: sma
170214T173446.796 [INFO] [Astrogator.DebugTools.DbgFmt] [Astrogator 2593.673] Differences: sma
170214T173446.824 [INFO] [Astrogator.DebugTools.DbgFmt] [Astrogator 2593.701] Differences: sma

Does that mean something? Would it maybe be possible to add a "debug mode" toggle in the settings, that could disable these messages? (only if it's not much work)  

Edited February 14, 2017 by Jebs_SY