transfer calculator [1.12] Astrogator v1.0.1

[Rowen Wulfe]

21 hours ago, Murdox said:

Gotta love this mod. Easy to use but still so powerfull tool with nice UI. Very many thanks to Mr. HebaruSan!

I just installed latest v.0.6.0 and got under heavy NullRef spam which i hadn't with previous version. Also haven't yet had time try with clean install but i will and can provide full log if needed. Anyways spam im getting looks like this:

NullReferenceException: Object reference not set to an instance of an object
  at Astrogator.KerbalTools.Landed (ITargetable t) [0x00000] in <filename unknown>:0 
  at Astrogator.AstrogationModel.get_notOrbiting () [0x00000] in <filename unknown>:0 
  at Astrogator.Astrogator.Orpoodleanged () [0x00000] in <filename unknown>:0 
  at Astrogator.Astrogator.FixedUpdate () [0x00000] in <filename unknown>:0 
 
(Filename:  Line: -1)

Edit: Still spamming with clean install. Starts immediately after loading craft to launchpad. Full log just in case: https://mega.nz/#!vRBXxKaY!ZP23_ybX4-GGmImpdwEwl3IGoDtGlifHoHBZErkKlZc

I don't merit a gold star, as that was a version back and I didn't take the time to get the relevant bits of information to log a bug, it's late now so that'll have to wait till tomorrow.

It may be anecdotal, I noticed my log spam continued throughout launch until I opened the Astrogator main window, at which point the log spam stopped immediately.

[DMagic]

On 2/19/2017 at 0:06 AM, HebaruSan said:

Agreed; I've looked for ways to do this, but I'm not able to add things to the upper corners with the UI components I'm using, and I don't want to rewrite it to use another system. Would it be possible to meet this need with an option to auto-close the window after it creates maneuver nodes?

 

It's not something that the PopupDialog supports, but adding a small button anywhere in the window should be simple. You just have to manually create a UI button, the only sticking points would be figuring out the RectTransform properties to get it into the right position, and it might require a LayoutElement script, which you can just add and set IgnoreLayout to true.

 

I think the source for GC Monitor covers everything needed for creating a button entirely through code.

 

[HebaruSan]

2 hours ago, DMagic said:

It's not something that the PopupDialog supports, but adding a small button anywhere in the window should be simple. You just have to manually create a UI button, the only sticking points would be figuring out the RectTransform properties to get it into the right position, and it might require a LayoutElement script, which you can just add and set IgnoreLayout to true.

 

Thanks. And I hate to act like someone who expects to be spoon-fed, but I'm not following this at all. The main thing I like about the DialogGUI* classes is that they're used by constructing a tree of objects that represent UI elements and setting properties on them in a fairly straightforward (or at least discoverable) way. That makes sense to me, and I can figure out how to do most things I want in that kind of framework (the resemblance to DOM should not be lost on anyone).

 

But reading code like the below from GCMonitor raises more questions for me than it answers, presumably due to my inexperience with Unity:

            GameObject go = Instantiate(prefab);
            go.transform.SetParent(UIMasterController.Instance.appCanvas.transform, false);
            sizePlus = go.GetComponentInChild<UnityEngine.UI.Button>("CounterSizePlus");

It's similar to the problems I've had investigating TaxiService's suggestions for updating the UI without closing and re-opening it; the API calls do not map to anything I understand. (Please do not answer the following questions! They're non-exhaustive examples of why I struggle, not intended as being asked here and now.) Is this UIMasterController class part of GCMonitor, or built into Unity? Is GetComponentInChild finding an object or creating it? If finding, how do I create instead? Am I allowed to create my own GameObject without calling Instantiate on an object that I presume was created in Unity's GUI editor? And then there are the questions around how to integrate this kind of code with code based on DialogGUI* calls; I can't call DialogGUIBase.AddChild with anything that doesn't inherit from DialogGUIBase, so... what instead? If I can't decipher basic things like this about such code, that makes me reluctant to entangle my own code with this API.

 

To sum up, it doesn't look like I'll be implementing this, despite tips having been offered, for which I am more grateful than I may seem. If someone else wants to try, pull requests are always welcome, and the place to start is probably the main window code in src/AstrogationView.cs.

[DMagic]

I would say, if your going to be doing any modding for KSP, it's worth figuring out how the GameObject system works with Unity. Basically everything in Unity is a GameObject (MonoBehaviour inherits from it, and most complex scripts inherit from that), and all of that follows certain set of rules and conventions. That's part of the reason why the new UI is so nice to work with, the old version existed in its own little universe that was entirely different from how everything else worked. The only real difference between the UI and standard GameObjects is that standard GameObjects use a Transform to define their position in space (and it isn't always needed, as many GameObjects don't represent anything physical), while UI objects use the RectTransform, which allows for more nuanced positioning.

 

For a close button though, the simplest thing to do would be to add another button along the bottom row, next to the settings button. It would accomplish the same thing, even if it is in a slightly unorthodox position.

Edited March 3, 2017 by DMagic

[HebaruSan]

Astrogator v0.6.1 is now out. Thanks to a gracious code donation by our new best friend @DMagic, it features an X to close the window in the upper right corner. That log spam should also be gone.

 

 

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

[meyerweb]

Earlier today I tried using Astrogator to get four probes from Kerbin to Duna, with the plane-change maneuver node option enabled.  I used kOS to precisely execute the burns for the nodes Astrogator created, but none of the craft actually got Duna encounters.  I ran them out to their closest approach, but they never entered Duna’s SOI.  They reached Duna’s orbit late/slow, it seemed to me.  I reverted to a pre-departure save and ran the ejection burns again, then manually set up radial adjustment maneuvers once they’d left Kerbin’s SOI.  About 220m/s of radial-in burning achieved encounters.

I had the craft departing from an 80km Kerbin orbit.  Is that too low?  Anything I can provide to help diagnose?  My craft are somewhat mod-dependent—I use kOS and surfacelight parts, for example—so not sure if a save file will be of use, but let me know.

Edited March 5, 2017 by meyerweb
Clarified the radial burn type

[HebaruSan]

14 minutes ago, meyerweb said:

Earlier today I tried using Astrogator to get four probes from Kerbin to Duna, with the plane-change maneuver node option enabled.  I used kOS to precisely execute the burns for the nodes Astrogator created, but none of the craft actually got Duna encounters.  I ran them out to their closest approach, but they never entered Duna’s SOI.  They reached Duna’s orbit late/slow, it seemed to me.  I reverted to a pre-departure save and ran the ejection burns again, then manually set up radial adjustment maneuvers once they’d left Kerbin’s SOI.  About 220m/s of radial-in burning achieved encounters.

Yup, that's the "some adjustment needed" mentioned in the OP:

On 2/4/2017 at 2:56 PM, HebaruSan said:

These typically give immediate encounters for transfers to the Mun from low Kerbin orbit, and sometimes Minmus, Duna, and Jool, but some adjustment is usually needed for other destinations.

The idea is that it gives you maneuvers with approximately the right time and delta V, then you check the map view and fine tune it before burning to get the encounter. The only body that it reliably produces nice encounters for is Mun.

[meyerweb]

8 hours ago, HebaruSan said:

Yup, that's the "some adjustment needed" mentioned in the OP:

The idea is that it gives you maneuvers with approximately the right time and delta V, then you check the map view and fine tune it before burning to get the encounter. The only body that it reliably produces nice encounters for is Mun.

Oh, heh.  I read that as “the closest approach will be super close and you just need to tweak slightly on the way”.  But, fair enough!  I’ll play with it some more.  I may try comparing numbers with Transfer Window Planner, to see if TWP can be used as a guide for modifying what Astrogator generates.

[HebaruSan]

Now that I know how to put buttons wherever I want, 0.6.2 moves the settings icon to the top next to the close X for a slightly cleaner look. The window was getting unwieldy with so many settings shown together with the transfers, so this button swaps the whole window between transfers and settings. A non-disruptive crash on exiting KSP on Mac OS and potentially other platforms is also fixed.

 

[Red Stapler]

^ Looking better and better every week HebaruSan!  Thanks for the update.

Yeah, I was getting that non-critical crash on exiting KSP (Windows 10 64bit) and was wondering where it was coming from....glad you hammered out that gremlin as well.  

[Red Stapler]

Self LOL....I thought I was going to report a bug today but it was purely user error....just in case it happens to any of you other Astrogator users....  

I kept hitting the Astrogator icon but the window with all the transfer calculations was not showing up (I was in space at the time, dark side of the Mun).  I thought darn, something must have crashed so I quit and resarted, but still no luck getting the window to pop up.  Well, it was purely user error...the window was open the whole time but it was 'hidden' behind one of my MechJeb windows.  It was dark at the time so did not see the border of the Astrogator window behind the MechJeb one...but as soon as I got into a sunny/lighter spot I found it right away.  

Thus my 2 cents and lesson to self:  Don't loose track of your windows, especially if you are a statistical freak like me who needs a ton of windows open at all times.  

Edited March 14, 2017 by Red Stapler

[HebaruSan]

Pre-release announcement:

KSP 1.2.9 breaks this mod. A number of core API functions I use were removed (CelestialBody.theName) or changed (MultiOptionDialog's constructor), so the existing DLLs will not work as-is, and my current code doesn't even compile with the pre-release installed. Furthermore, the needed changes will break compatibility with 1.2.2, so I cannot release a version that's compatible with both.

If you wish to participate in pre-release testing, uninstall Astrogator first. If you wish to use Astrogator during the pre-release period, do not install the pre-release; stay on KSP 1.2.2.

My plans:

The next release of Astrogator will be compatible with KSP 1.3. It will be released after the pre-release period is over. There will be no versions of this mod compatible with the pre-release. If this triggers you, consider writing a strongly worded letter to SQUAD about the importance of backwards compatibility.

But why?

• The pre-release is a moving target; code that works today might break tomorrow.
• Not everyone will be using the pre-release, and I don't want to release a version that doesn't work for everyone.
• I don't want multiple versions floating around requiring users to keep careful track of a version mapping table.
• I need some time to fish around for suitable replacement API functions, without up to date online documentation.
• This will also be the localization update for Astrogator, and I need to write a wiki page about how to make a language pack.

What should I do?

Wait patiently, please. No bug reports are needed, and redundant requests for updates will be reported for moderator deletion. Thanks!

[Red Stapler]

13 hours ago, HebaruSan said:

Pre-release announcement:

KSP 1.2.9 breaks this mod. A number of core API functions I use were removed (CelestialBody.theName) or changed (MultiOptionDialog's constructor), so the existing DLLs will not work as-is, and my current code doesn't even compile with the pre-release installed. Furthermore, the needed changes will break compatibility with 1.2.2, so I cannot release a version that's compatible with both.

If you wish to participate in pre-release testing, uninstall Astrogator first. If you wish to use Astrogator during the pre-release period, do not install the pre-release; stay on KSP 1.2.2.

My plans:

The next release of Astrogator will be compatible with KSP 1.3. It will be released after the pre-release period is over. There will be no versions of this mod compatible with the pre-release. If this triggers you, consider writing a strongly worded letter to SQUAD about the importance of backwards compatibility.

But why?

• The pre-release is a moving target; code that works today might break tomorrow.
• Not everyone will be using the pre-release, and I don't want to release a version that doesn't work for everyone.
• I don't want multiple versions floating around requiring users to keep careful track of a version mapping table.
• I need some time to fish around for suitable replacement API functions, without up to date online documentation.
• This will also be the localization update for Astrogator, and I need to write a wiki page about how to make a language pack.

What should I do?

Wait patiently, please. No bug reports are needed, and redundant requests for updates will be reported for moderator deletion. Thanks!

Hey HebaruSan,

Sorry to hear the update will break your mod buddy, that is frustrating.  Just some commentary in support of your thought process and my plans for v1.29 - 1.3...other's might feel the same way (or not) so please chime in... 

I will be sticking with 1.2.2 and will not be touching 1.2.9...and will probably not move into 1.3 until a few months after release to let it and supporting mods 'mature'.  I finally have 1.2.2 humming along smoothly and have a great career game going and all my 80ish mods playing nice with each other (manual install).  I didn't see too much in the pre-release or 1.3 to get me excited to update at this time or near future. 

Specifically Re: 

"The next release of Astrogator will be compatible with KSP 1.3. It will be released after the pre-release period is over. There will be no versions of this mod compatible with the pre-release.  - totally understandable, I agree with your plan

But why?

• The pre-release is a moving target; code that works today might break tomorrow. - yup, these transition periods suck for modders and users alike
• Not everyone will be using the pre-release, and I don't want to release a version that doesn't work for everyone. - this, plus the bullet point below, it just becomes a chore to maintain multiple versions and may create confusion for some users for little gain.
• I don't want multiple versions floating around requiring users to keep careful track of a version mapping table."

So again thank you for your continued efforts on Astrogator, I wish you the best of luck...I'll be keeping an eye on things and will be happy to help test again in 1.3!

 

Edited March 17, 2017 by Red Stapler

[Darael]

Point of interest (but low-to-zero importance), prompted by a screenshot posted on the 7th: While the SI is a metric system, so it's pretty legit to put the latter parenthesised after the former, the US Customary and Imperial unit systems are different, though they (unhelpfully) use almost all the same unit names.  While this is mostly significant for volume, which rarely comes up in KSP and certainly not for Astrogator's purposes, there are two other units with different values between the systems: the hundredweight and (as a consequence) the ton.  Now, while I don't imagine weights (/masses; neither Imperial nor USC distinguishes entirely between the two, using weight-units with an implied under-Earth-standard-gravity for mass) will come up in Astrogator specifically, the difference between the US-Customary (or "short") ton of 20cwt of 100lbs (noticeably less than the metric tonne used by default in KSP) and Imperial (or "long") ton of 20cwt each of 112lbs (total: fractionally more than a tonne) would be significant to someone playing entirely in such units.

This has been a needlessly-pedantic post on measurement systems.  Now, a return to normal Astrogator programming.

[HebaruSan]

4 minutes ago, Darael said:

Point of interest (but low-to-zero importance), prompted by a screenshot posted on the 7th: While the SI is a metric system, so it's pretty legit to put the latter parenthesised after the former, the US Customary and Imperial unit systems are different, though they (unhelpfully) use almost all the same unit names.  While this is mostly significant for volume, which rarely comes up in KSP and certainly not for Astrogator's purposes, there are two other units with different values between the systems: the hundredweight and (as a consequence) the ton.  Now, while I don't imagine weights (/masses; neither Imperial nor USC distinguishes entirely between the two, using weight-units with an implied under-Earth-standard-gravity for mass) will come up in Astrogator specifically, the difference between the US-Customary (or "short") ton of 20cwt of 100lbs (noticeably less than the metric tonne used by default in KSP) and Imperial (or "long") ton of 20cwt each of 112lbs (total: fractionally more than a tonne) would be significant to someone playing entirely in such units.

Yeah, I added the parentheticals for users who may not know the official names, since the only units affected by this setting are mph and m/s. Most of the Youtube comment flame wars about feet versus meters or Fahrenheit versus Celsius are fought in terms of "metric" versus "imperial."  I'll be sure to revise it if volume or mass ever becomes relevant to this mod.

[Luovahulluus]

The optimal time for an interplanetary transfer burn can change many days depending on if you want to do a flyby or establish an orbit. As I usually want to do the latter, I still need to use the Transfer Window Planner and KAC to set them up. Would an option to include the orbit insertion burns be something you might want to include in your next version? Maybe a generic 100km above sea level would do? And maybe put a small icon to easily make a KAC alarm next to those "warp to burn time" icons.

[NISSKEPCSIM]

Does the planner calculate a free-return trajectory as well? (If you're just flying by)

Edited April 12, 2017 by NISSKEPCSIM

[Wadusher0]

8 hours ago, NISSKEPCSIM said:

Does the planner calculate a free-return trajectory as well? (If you're just flying by)

Doesn't look like it. But once you have a Mun encounter, setting up a free return is trivial.

[HebaruSan]

9 hours ago, NISSKEPCSIM said:

Does the planner calculate a free-return trajectory as well? (If you're just flying by)

1 hour ago, wadusher1 said:

Doesn't look like it. But once you have a Mun encounter, setting up a free return is trivial.

Right, it just gives you a simple Hohmann transfer. What happens inside the destination SOI is up to you.

[Probus]

Wow! This looks great! Can't wait to try it out.

[NotAgain]

This is a total godsend for me. My Dres probe thanks you.

[HebaruSan]

Pre-release update:

We have what will probably be the finalized version of the stock localization API, and my local copy of the code is updated to support it, so I should be able to ship an update on Day 1. However, I am a shamefully monolingual American, so I need your help to go beyond English in the next release!

Please contact me if you are willing to translate Astrogator's English strings into other languages; as a reminder, the languages supported in KSP 1.3 will be:

• Spanish (Spain dialect, not Latin American)
• Russian
• Japanese
• Chinese (simplified)

To give a sense of the scope of the help I'm asking for, the English version of the resource file weighs in thusly:

• Lines needing translation: 43
• Words: 256
• Bytes: 2627

I will be happy to provide full instructions and the English version of the file to be translated; the only requirement is that you are fluent in English and one of the languages listed above. GPLv3 licensing is presumed but negotiable. Compensation will be exclusively in the form of a thank-you acknowledgment in the README file and in this thread's OP. I may reach out to you later as my language expert if there are comments or questions about the translations.

Thanks in advance if you can help out! If not, I will have documentation in place for future volunteers after release.

(I have made an attempt with Google Translate:

... but I think it would be better to start from real translations rather than fielding dozens of complaints about poorly translated strings I don't understand.)

 

[Wolves_Hero]

This mod bugged always off screen. I click Astrogator icon not show up, I use Protractor mod much better never off screen but no time wrap.

[HebaruSan]

Just now, Wolves_Hero said:

This mod bugged always off screen. I click Astrogator icon not show up

Please include more information if you'd like to report a bug on this thread. Just complaining about an issue doesn't help.

[Cetera]

On 3/21/2017 at 2:03 AM, Luovahulluus said:

The optimal time for an interplanetary transfer burn can change many days depending on if you want to do a flyby or establish an orbit. As I usually want to do the latter, I still need to use the Transfer Window Planner and KAC to set them up. Would an option to include the orbit insertion burns be something you might want to include in your next version? Maybe a generic 100km above sea level would do? And maybe put a small icon to easily make a KAC alarm next to those "warp to burn time" icons.

Is this why there is a difference between the Astrogator output and the nodes and alarms I calculate with the Transfer Window Planner?  I really like both, and use both.  I LOVE the list of planets in order, and upcoming transfer windows in a neat list.  But I was curious why there were some discrepancies, and which I should trust more.  

In my dream world utopia, where everything works out just so, and all my wildest ideas can be implemented without effort or skill, it would be super duper awesome if Astrogator kept its look, but added a button for each planet/window with a button to generate a porkchop plot for more advanced planning, and maybe even adding to the display window.  As long as I'm dreaming, some kind of spreadsheet functionality to sort by departure date, planet order, etc, might also be very handy.  You know, if you wanted some extra work or designs to shoot for.  How's that for a feature request?