HebaruSan

[1.2.2] Astrogator v0.6.2

116 posts in this topic

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.

2 people like this

Share this post


Link to post
Share on other sites
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.

 

1 person likes this

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

Posted (edited)

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 by DMagic
2 people like this

Share this post


Link to post
Share on other sites

Posted (edited)

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 by meyerweb
Clarified the radial burn type

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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.

mainScreenshot.png settingsPanel.png

7 people like this

Share this post


Link to post
Share on other sites

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

:)

1 person likes this

Share this post


Link to post
Share on other sites

Posted (edited)

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 by Red Stapler

Share this post


Link to post
Share on other sites

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!

3 people like this

Share this post


Link to post
Share on other sites

Posted (edited)

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 by Red Stapler
1 person likes this

Share this post


Link to post
Share on other sites

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.

1 person likes this

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now