[1.12.x] PlanetInfoPlus v1.4.3: Better info in the planetarium, with configurable display.

[Snark]

  On 2/23/2022 at 10:21 AM, flart said:

don't waste a location of the computation-heavy Max Elevation and put it in the Waypoint Manager or as a contract for the ContractConfigurator.

Expand  

This one's a "no".  I like having the max elevation there, so it's gonna stay.  If someone doesn't want it there, it's easy to turn off via the settings dialog; and if someone wants it in other places (like the ones you mention), then some other modder is welcome to do so. 

  On 2/23/2022 at 10:21 AM, flart said:

• make GUI longer
• ... (make GUI wider if necessary)

Expand  

These are great suggestions, and actually, I already wanted to do that. 

Unfortunately, I haven't yet been able to figure out how to do that.  (Unity UI programming in general, and the foibles of KSP's UI setup in particular, are really not my forte.)  If some modder out there knows what the programming hooks are that would allow me to tinker with the size of this little window, I'd love to hear!  Until then (or unless I stumble onto the solution on my own), this will just have to be a wish-list.

  On 2/23/2022 at 10:21 AM, flart said:

put more precision on periods and synch. orbit

Expand  

What's the use case?  This feels like unnecessary levels of precision to me-- the current level seems plenty for all practical purposes, as far as I can tell.  Why do I care how many seconds the Mun's orbit is?

In any case, it's out of the question until and unless I can ever figure out how to make the window wider.  If I can figure that out, then probably what I'd do is add a setting to the config file that specifies the level of precision, so you could  override that if you want more precision than the default.

  On 2/23/2022 at 10:21 AM, flart said:

Making this string a little bit shorter probably will make it fit into one line

Expand  

Yeah, great suggestion-- I thought about that too.    Would really like to do it, but the reason "why not" has to do with localization.  Details in spoiler below.

(If I could figure out how to make the GUI a bit wider, that would solve the problem nicely right there.)

  Reveal hidden contents

KSP is localized into a wide variety of different languages.  All text that appears in all UI is translated accordingly.

Except for the few terms of my own that PlanetInfoPlus adds, every other piece of UI text that you see here is taken from the stock game.  That's pretty important, because it means that a player whose native language is not English will see everything in their own language.

Suppose there's a player whose native language is, say, German, is playing KSP with PlanetInfoPlus installed.  Almost all the UI will be in German.  The few terms I've added (like "Max Elevation") won't be, simply because I haven't included a German translation in my localization files... but everything else will be.  Including "Atmospheric Characteristics:".

If I were to replace that with a term of my own, it would only be in English (because that's the only language I've provided with the mod)... which means I would have taken a piece of UI that used to be in their own language, and removed the translation from them.

In short:  I'd kinda prefer not to do that, if possible.  Really, the way to solve this problem is to figure out how to make the GUI wider.  If I can solve that, it kills several birds with one stone.

 

  On 2/23/2022 at 10:21 AM, flart said:

NaN m for Jool and Sun

Expand  

D'oh!  Thank you, that's a good catch-- I missed a spot.  I remember meaning to put in a little check in the code that would not show "highest elevation" for bodies without a surface, but looks like I forgot to.  Thanks for calling my attention to it, I'll fix this in the next update.

[R-T-B]

  On 2/23/2022 at 11:57 AM, Snark said:

Thank you for the suggestions.  They're good suggestions, but my current thinking (I might change my mind at some point) is probably "no", to both.  Detailed discussion in spoiler, but they basically boil down to this:  I'm coding for the typical KSP user (including myself), i.e. someone who doesn't use Principia, and both of these suggestions run counter to what a non-Principia user (or, at least, myself) would want, and in general I tend to be resistant to coding logic paths that I myself won't use, due to maintainability concerns.

  Reveal hidden contents

 Two issues, one concerning "locked" and the other concerning "what is 'retrograde' rotation".

Regarding "locked":  As a non-Prinicipia user, to me, locked means locked, as in exactly locked.  This is important.  Either  I can count on the same face of a body always facing its primary, or I can't.  If I care about that-- for example, if I'm selecting a base location based on LOS for comms-- then I really care about that, and a planet that's a 98% match is not "locked" for that purpose.  Worse:  I almost certainly won't be able to tell by eyeballing it that it's not quite the same, I might think it's actually locked, and then some time in the future suddenly my stuff stops working and I'm left wondering what happened.

I understand that it's not quite as cut-and-dried in Principia land.  I suppose it would be possible to support Principia in this way without affecting players who don't use it-- for example, I could put various config settings in the config file, like "use strict locking check" or "minimum/maximum ratio to be considered locked", that sort of thing.  A Principia user could then use ModuleManager to override the default settings.

Doing something like that would not be a lot of code on my part... but on the other hand, it's not zero, and in my modding "career", one thing I generally try to be very wary of is ever inserting code that's on a code path that I, myself, will never exercise.  Because then I'm not likely to catch bugs, I'm not likely to have good visibility into the design, it's too easy for the code's behavior to end up being not quite sufficient for someone's purposes because the thing it was originally intended to support has changed its behavior, etc.  All of that stuff has the potential to result in a scenario where a year from now, someone comes back to me and says "hey, this feature doesn't work anymore because mod X has changed and you need to update to make it work again," sort of thing.  Code that I write is code that I need to maintain, and I'm unwilling to maintain a code path that I don't use myself.

That said, it is a fairly small code change, so this one's not a hard "no"; I may reconsider, it's just not super high on the priority list.

Regarding the other matter, the definition of "retrograde" (and why I even bother having that feature here in the first place):

You'll note that in KSP, there's not really any such thing as a "retrograde" orbit per se.  In game terms, an orbit that a human would describe as "retrograde" is simply one whose inclination is >90 degrees.

Similarly, if KSP hadn't made the curious development decision not to support axial tilt, then "retrograde" rotation would be in the same boat.  We'd say:  there's no such thing as "retrograde" rotation, there is only a rotation whose "axial tilt is over 90 degrees".

But that's not the case.  KSP really does only have one rotation axis, and a planet either rotates one way (in which case the game models it as a positive rotation period) or the other way (in which case the rotation period is negative).  There is a universal "up" direction (i.e. the direction that Kerbin's north pole points), and every planet's rotation is either prograde or retrograde relative to that.  And, for a KSP player who doesn't use Principia (meaning 99.9%+ of KSP users, including myself), if you say "that planet's rotation is retrograde", that's what they're thinking.  And therefore, that's the conceptual language that PlanetInfoPlus should speak.

This is not how an astronomer would talk.  To an astronomer, "retrograde rotation" means "in the opposite direction of a planet's orbit".  That may be how  a Principia user would think, too, I suppose.  But that's not how a KSP player thinks (at least, not me), in terms of this game, and so that's the way it's set up.

Again: this is something that I could always stick in chunks of code activated by config-file settings to try to support the Principia case, but my reluctance to do so is for the same reason as described above.

 

Expand  

I understand that and of course it's totally up to you, but two points for your consideration:

1.)  Would not simply making the percentage a config option and having it default to "100%" AKA total locking be enough?  I understand still it is extra coding, but just an idea.

2.)  I'll be maintaining a private fork for my use with Principia regardless.  I could simply make a pull request of a more user friendly facing version if you desire (with a config file option as described).  Or we could just leave it where the few Principia users can ask for my fork if they need it.  Or I could just make my patchset/fork public.  Or nothing at all.  Whatever works for you.

3.)  I'm not sure I understand your argument re the inclination logic.  Regardless of whether Principia is installed or not, I do believe I can make a body retrograde WITHOUT a negative orbital period by setting inclination above 90.  This happens with or without Principia, and will appear retrograde to the end user in both cases.  It's a weird property of KSP that I think your code should be aware of regardless of the other two points and whether or not you worry about them.

All up to you of course, just my thinking here.  And either way, execllent work!  I hope you don't mind my desire to tinker lol!

Edited February 23, 2022 by R-T-B

[Snark]

  On 2/23/2022 at 12:55 PM, R-T-B said:

1.)  Would not simply making the percentage a config option and having it default to "100%" AKA total locking be enough?  I understand still it is extra coding, but just an idea.

Expand  

Yes, it would be possible to have a config option.  (Would actually need to be two percentages-- a minimum and a maximum.  Specifying one number, like "within 2.5% either way", would be ambiguous-- for example, should the lower limit be 100% - N, or should it be the reciprocal of 100% + N, sort of thing.)

Like I said, doable.  Would have to keep it very, very simple to minimize the chance that I'd ever have to come back and do maintenance on it; I'm never going to want to be in a position where someone is asking for an update to the mod in order to "fix" (i.e. change behavior) of a code path that I never use myself.  I'll consider this, let me think about it.

  On 2/23/2022 at 12:55 PM, R-T-B said:

Regardless of whether Principia is installed or not, I do believe I can make a body retrograde WITHOUT a negative orbital period by setting inclination above 90.

Expand  

If your definition of "retrograde rotation" is an astronomer's (which I infer that it is), then you're correct, yes.

But if your definition of "retrograde rotation" is what KSP thinks it is, then no.

More details in spoiler.

  Reveal hidden contents

Let us define "galactic north" as "the direction that Kerbin's north pole points", i.e. the direction of "up" in the planetarium view.

In KSP terms (not an astronomer's),

• a planet's rotation is prograde (has a positive rotation period) if it appears to rotate counterclockwise when viewed from galactic north.
• a planet's rotation is retrograde (has a negative rotation period) if it appears to rotate clockwise when viewed from galactic north.

You'll note that both of the above definitions reference an absolute direction ("galactic north"), and not the plane of the orbit at all.

Kerbin's rotation, for example, is prograde.

If you took Kopernicus and used it to flip the inclination of its orbit to 180 degrees instead of 0 degrees, but didn't change anything else?  Then Kerbin would still be rotating counterclockwise as viewed from galactic north, and therefore by this definition would still be rotating "prograde", even though that's no longer the same direction as its orbit.

That's not what an astronomer would say, of course.  An astronomer would define "retrograde rotation" as "rotating in the opposite direction from the orbit", and by that definition, this situation would define Kerbin's rotation as retrograde.

But that's not what KSP does.  Its convention is that there is a universal preferred orientation (which there isn't IRL, which is why astronomers don't do this), and a planet's rotation is explicitly "prograde" or "retrograde" based on its rotation relative to that preferred orientation, regardless of what the inclination of the orbit is.

Again:  It wouldn't be too hard for me to add a config flag to, say, "define retrograde rotation as being relative to orbit" (it would default to false).  It's just a code path I never exercise and would be leery of maintenance requests from anyone who might say "could you make it work just a little differently please, it doesn't quite work with <thing I never use>".

 

[flart]

  On 2/23/2022 at 12:43 PM, Snark said:

Why do I care how many seconds the Mun's orbit is?

Expand  

for putting a relay before or after the Mun in, for example, 30°, without risk of shifting into Mun's SOI.
30 sec per Mun's period (6 days) is like 5.9 hours per 10 years, that is 60° shifting in 10 years

  On 2/23/2022 at 12:43 PM, Snark said:

KSP is localized

Expand  

  you could use one of the existing tags:
#autoLOC_501018 = Atmosphere Analysis
#autoLOC_6001674 = Atmosphere
#autoLOC_6004054 = Atmospheric
#autoLOC_7001059 = atmospheric
#autoLOC_8003223 = Atmosphere:

[R-T-B]

  On 2/23/2022 at 1:12 PM, Snark said:

More details in spoiler.

Expand  

I think I get what you are saying now...  Kerbin's (or the local bodies?) north pole is always "galactic up?"  If so, that does indeed complicate things in a silly way.  Understood.

EDIT:  Only this does not seem to be true.  I just set Kerbin's inclination in the stock game to 180, and it appears to be rotating retrograde to the end user.

Observe.  Kerbin normal orbit is the first, inclination 180 the second:

https://imgur.com/wBS47hB

https://imgur.com/TSQvJyk

Edited February 23, 2022 by R-T-B

[Snark]

  On 2/23/2022 at 1:27 PM, flart said:

for putting a relay before or after the Mun in, for example, 30°, without risk of shifting into Mun's SOI.
30 sec per Mun's period (6 days) is like 5.9 hours per 10 years, that is 60° shifting in 10 years

Expand  

Ah, okay.  Yes, that concern makes perfect sense, thanks.  The reason I didn't put 2 + 2 together, here, is that for me, this is the wrong place and the wrong way to solve that problem.  I have synchronous setups too-- for example, a satellite in sync with the Mun, or a family of satellites in sync with each other.  But when I'm setting up the synchronicity, what I want is not to have to toggle back and forth between looking at two different ten-digit numbers to see if they match.  I want to look at a single number that tells me the plus-or-minus error, with "zero" meaning "perfect sync".  And that's exactly what I do... but not with this mod.    For me, that's what the "synchrony tracker" feature of BetterBurnTime is for.  That's the right way to solve this problem (IMHO, of course.)

  Reveal hidden contents

  On 11/21/2015 at 11:28 PM, Snark said:

The synchrony tracker

If you're in orbit, and you're reasonably close to being in synchronous orbit around the current celestial body, the mod will display a "geosynchrony tracker" that shows how close you are to perfect geosync.

The tracker displays a time delta (positive or negative) showing how far off your current orbital period is from perfect geosynchrony. It shows hours/minutes/seconds until you get within 10 seconds, then switches to milliseconds display. (The transition point is configurable, see below.)

If you're in orbit and you have a target, then you get a "target synchrony" indicator, that works the same as the geosynchrony one, but shows time delta relative to target rather than relative to the celestial body's rotation period.

Expand  

That said, though, I do understand that not everyone wants to solve the problem the same way, and/or not everyone wants to install BBT.  I can look into adding some sort of config option (for the config file; won't be an in-game UI) to choose a precision value for the orbital time.  That would allow you to display increased precision if that's a requirement for your needs, without getting in the way of other players who don't need that.  (Though I imagine it might look kinda ugly if I can't figure out how to make the UI wider.)

 

  On 2/23/2022 at 1:27 PM, flart said:

you could use one of the existing tags:
#autoLOC_501018 = Atmosphere Analysis
#autoLOC_6001674 = Atmosphere
#autoLOC_6004054 = Atmospheric
#autoLOC_7001059 = atmospheric
#autoLOC_8003223 = Atmosphere:

Expand  

ah,  thank you!  That last one looks like a possibility.

I'm a little leery of making the substitution, mainly because I don't know in what context that tag gets used in the program.  It happens to be the case in English that substituting "Atmosphere:" for "Atmospheric Characteristics:" makes sense, but translation can be heavily context-dependent and there's a chance that it might come off sounding silly in that context in other languages.

That said, though, I don't think it's going too much out on a limb, and the word-wrap thing does bug me.    I think it's worth doing, thanks.  (If I ever figure out how to make the window wider, I can switch it back.)

[OrbitalManeuvers]

Thank you for the update on axial rotational period - Venus now says "Retro rotation 243d" in color, instead of the standard "Rotation Period" with a negative number. Awesome!

Is there any chance you could include a .version file? Idk if your workflow is just different, but that file is a big help for non-ckan users when looking at what they have installed. 

  On 2/23/2022 at 1:40 PM, R-T-B said:

I just set Kerbin's inclination in the stock game to 180

Expand  

Is it possible for a single planet to orbit in the opposite direction from all the other planets around a star? This seems odd. In our solar system, everything goes the same direction, with Venus being the sole outlier in axial rotation direction.

[Snark]

  On 2/23/2022 at 3:50 PM, OrbitalManeuvers said:

Is there any chance you could include a .version file? Idk if your workflow is just different, but that file is a big help for non-ckan users when looking at what they have installed.

Expand  

Check out the changelog.txt that's installed with the mod.  The most recent (i.e. topmost) entry is always the current installed version.  I'm conscientious about keeping that up to date whenever I release a new version.

  On 2/23/2022 at 3:50 PM, OrbitalManeuvers said:

Is it possible for a single planet to orbit in the opposite direction from all the other planets around a star?

Expand  

You mean cosmologically, IRL?  My understanding is that it would be practically impossible, given the way solar systems form.  About the only way it could happen would be if some interstellar visitor got captured or something, and in that case you'd expect it to have some funky eccentric, inclined orbit.

But that's IRL.  This is KSP, where people play with modded solar system, and planets can orbit any which way the mod author likes.  Even if it's highly unrealistic. 

I'd like the mod to work properly with any modded system the user has, without making any assumptions about realism.

[AtomicTech]

  On 2/22/2022 at 10:59 AM, Snark said:

It's automatically calculated from the planet's mass and rotation period, so it should work for anything.

(The motivation that prompted me to write this mod is that I like to play on modded solar systems that have new planets in them.  Since I don't have them all memorized the way I do from thousands of hours of playing in Kerbin system, I wanted something that would tell me the info I wanted to know.  So yeah, it works everywhere.) 

There's no hard-coded info anywhere in the mod; everything it displays is taken from the celestial body's stats at run time.

(Which was actually, in one case, a bit of a pain for me when writing the mod.  One stat I really wanted to add was "elevation of highest peak".  Unfortunately, I haven't yet been able to figure out any reliable programmatic way to determine that, so I didn't add it, alas.  Yes, it would have been easy for me to look up the values for all the bodies in Kerbin system and put that into a hard-coded config file... but I don't wanna.  If I can't get the info from the planet at run time, I'm not gonna put it in the mod.)

Expand  

I believe you mean, "automagically," right? 

[Snark]

  On 2/23/2022 at 4:02 PM, AtomicTech said:

I believe you mean, "automagically," right? 

Expand  

I guess it depends on whether you found high school physics to be fun, or a pain. 

[AtomicTech]

  On 2/23/2022 at 4:10 PM, Snark said:

I guess it depends on whether you found high school physics to be fun, or a pain. 

Expand  

  

  On 5/28/2015 at 5:01 PM, Dman979 said:

Disclaimer: Some questions may not be answerable, for various reasons.

The word of the thread is: Automagically.

THIS IS NOT A CHAT THREAD.

Mods-

How often are you called upon to examine the post of a Curious George, only to have it be a spambot?

Can you show us an example of what their messages look like?

Are the majority of the users on the forum humans? About how many unique users are active on the forum per month?

What do you do with a spambot?

About how many people join the forums per day?

Everyone else-

Have you ever wondered about this, or is it just me?

Expand  

 

To quote at @Dman979, "The word of the thread is: Automagically."

Perhaps you should name version 1.2, the Automagic Release!

[OrbitalManeuvers]

  On 2/23/2022 at 3:57 PM, Snark said:

Check out the changelog.txt that's installed with the mod.

Expand  

Alrighty. Well, if you ever get around to adding one it would really help with automated tools.

[alartor]

  On 2/23/2022 at 10:21 AM, flart said:

• don't waste a location of the computation-heavy Max Elevation and put it in the Waypoint Manager or as a contract for the ContractConfigurator.

Expand  

I might be wrong here, but maybe the idea was that not only Max Elevation is displayed, but maybe include the option to also display (configurable, maybe?) the location on the celestial body surface of said Max Elevation (so that you can try to plant a flag there? Heheh) instead of just discarding it after having done the computation-heavy effort that, even if just as a subproduct, finds it (well, I'm not really sure if the algorithm finds it or just computes the elevation, heh). I would find it interesting,  but might not be worth the effort of implementing it (or taking up some valuable display space in the GUI).

And again, thanks for this really useful mod!

[Snark]

  On 2/23/2022 at 6:17 PM, alartor said:

I might be wrong here, but maybe the idea was that not only Max Elevation is displayed, but maybe include the option to also display (configurable, maybe?) the location on the celestial body surface of said Max Elevation (so that you can try to plant a flag there? Heheh) instead of just discarding it after having done the computation-heavy effort that, even if just as a subproduct, finds it (well, I'm not really sure if the algorithm finds it or just computes the elevation, heh). I would find it interesting,  but might not be worth the effort of implementing it (or taking up some valuable display space in the GUI).

And again, thanks for this really useful mod!

Expand  

The algorithm does, indeed, produce the coordinates.     If you check the log file when it first does the calculation, it logs it.

Main reason I haven't surfaced it in the UI is that it's not a piece of information that I myself would find useful (for example, even if I knew the lat/long, I don't use any mods to make it easy to navigate to that specific place, etc.)  It wouldn't be all that hard to add, it's just my usual avoidance of "clutter" in UI.  I may add this at some point, but there are other higher-priority things to look at first.

[modus]

@Snark question regarding loading the game, in spoiler for those wanting to look at the messages during loading and guess my question:

  Reveal hidden contents

Is the 'thanking Poodmund' message your doing? If so: nice touch

 

[Poodmund]

  On 2/23/2022 at 6:39 PM, modus said:

@Snark question regarding loading the game, in spoiler for those wanting to look at the messages during loading and guess my question:

  Reveal hidden contents

Is the 'thanking Poodmund' message your doing? If so: nice touch

 

Expand  

If you're a heavy user of Snark's mods, you see a lot of thanks going to a lot of different community members.  

[Snark]

  On 2/23/2022 at 6:39 PM, modus said:

@Snark question regarding loading the game, in spoiler for those wanting to look at the messages during loading and guess my question:

Expand  

 

  Reveal hidden contents

https://github.com/KSPSnark/PlanetInfoPlus/blob/main/src/SplashScreen.cs

[modus]

And rightfully so!

Many thanks to the master himself!

[caipi]

Mhm, is it just me or does this not work properly (at all) with Kopernicus+JNSQ? I Just tried it on a clean install with KSP 1.12.3 + ModuleManager 4.2.1 + Kopernicus (latest stable release) + JNSQ (latest) + PIP (Planet Info Plus :D) 1.1 + DunaDirect (testing something else simultaneously, but it shouldn't be the cuplrit). It doesn't show (I can provide screens if requested, but you can probably guess what you'll see, the stock info). If I delete Kopernicus+JNSQ, it shows correctly.

Anybody else or is anybody using Kopernicus+JNSQ+PIP and seeing the intended information? If so, I'll have to do some more troubleshooting -.-'

@Snark, I actually have a suggestion as well. An information I frequently seek is the border between near space/orbit and high space/orbit. It would be awesome if it could be added here. I think it's a good addition to the atmosphere height.

[Snark]

  On 2/23/2022 at 7:54 PM, caipi said:

Mhm, is it just me or does this not work properly (at all) with Kopernicus+JNSQ? I Just tried it on a clean install with KSP 1.12.3 + ModuleManager 4.2.1 + Kopernicus (latest stable release) + JNSQ (latest) + PIP (Planet Info Plus :D) 1.1 + DunaDirect (testing something else simultaneously, but it shouldn't be the cuplrit). It doesn't show (I can provide screens if requested, but you can probably guess what you'll see, the stock info). If I delete Kopernicus+JNSQ, it shows correctly.

Expand  

Hmm, interesting.  I can say that PIP does work with Kopernicus-modded systems in general (I'm running it with New Horizons, for example, and it works just fine).

If it specifically doesn't work with JNSQ, I'm curious what could be causing that.  Does JNSQ have code that's also arm-wrestling for control of that window, or something?

  On 2/23/2022 at 7:54 PM, caipi said:

@Snark, I actually have a suggestion as well. An information I frequently seek is the border between near space/orbit and high space/orbit. It would be awesome if it could be added here. I think it's a good addition to the atmosphere height.

Expand  

Already asked.    My answer:

  On 2/22/2022 at 8:22 PM, Snark said:

I'll consider it.  Those, along with (for example) "how many biomes are there?", are what one might call "gameplay characteristics"-- they have nothing to do with the actual physics of the body involved.  I'll grant they may be of interest... but there's also a fairly limited amount of screen real estate available, and adding more stuff just means more scrolling to do.

One thing I've considered is adding a third section, "Gameplay:", which could go beneath the "Atmospheric Characteristics:" section.  Since it's below, then it won't be getting in the way of people who aren't interested.  But you'll have to scroll down to see it. 

Definitely on my radar, but probably not in the next update, as there are other things that are higher priority for me at the moment.

Expand  

[R-T-B]

  On 2/23/2022 at 8:08 PM, Snark said:

If it specifically doesn't work with JNSQ, I'm curious what could be causing that.  Does JNSQ have code that's also arm-wrestling for control of that window, or something?

Expand  

Does JNSQ even ship with plugins?  I don't remember it doing that.

I'll look at logs from a Kopernicus build and see if this isn't a bug on our end.  Maybe the two working together are just managing to express some deep otherwise hidden Kopernicus bug.

EDIT:  I really doubt it's SigmaLoadingScreens, that's one of the few dlls in JNSQ though...  Also SigmaTweakChutes.  Doubt that has any effect though.

EDIT EDIT: No it's none of those and Kopernicus is not reporting any errors either.  I can only guess it's because JNSQ destroys the stock system (ie is a system replacer?)

Edited February 23, 2022 by R-T-B

[OrbitalManeuvers]

  On 2/23/2022 at 8:08 PM, Snark said:

If it specifically doesn't work with JNSQ, I'm curious what could be causing that.

Expand  

Can confirm no workie.  However here's some excerpts, so it's alive, just doesn't show anything in the tracking station.

  Reveal hidden contents

[LOG 14:38:20.560] [PlanetInfoPlus] App activated for Kerbin^N
[LOG 14:38:21.257] [PlanetInfoPlus] Scanned highest elevation on Kerbin^N in 693 ms (86998 samples):  14249 m at latitude=-43.9625921602781, longitude=103.978478482206

[LOG 14:39:17.473] [PlanetInfoPlus] App activated for Krel^N
[LOG 14:39:17.882] [PlanetInfoPlus] Scanned highest elevation on Krel^N in 406 ms (86605 samples):  3031 m at latitude=1.58978109041825, longitude=105.861896208786
[LOG 14:39:17.891] [SpaceDust][ToolbarUI] Changed focus to Krel
[LOG 14:39:17.891] [SpaceDust][ToolbarPanel] Clearing all entries
[LOG 14:39:17.891] [SpaceDust][MapOverlay] Changed focus to Krel
[LOG 14:39:17.891] [SpaceDust][MapOverlay]: Removing body fields
[LOG 14:39:17.972] [OD] --> ScaledSpaceDemand.LoadTextures loading JNSQ/JNSQ_Textures/PluginData/Riga00.dds and JNSQ/JNSQ_Textures/PluginData/Riga01.dds
[LOG 14:39:26.325] [PlanetariumCamera]: Focus: Huygen
[LOG 14:39:26.330] [PlanetInfoPlus] App activated for Huygen^N
[LOG 14:39:26.698] [PlanetInfoPlus] Scanned highest elevation on Huygen^N in 367 ms (85865 samples):  7796 m at latitude=28.9107103702307, longitude=15.5748394488677

 

[R-T-B]

  On 2/23/2022 at 10:44 PM, OrbitalManeuvers said:

Can confirm no workie.  However here's some excerpts, so it's alive, just doesn't show anything in the tracking station.

  Reveal hidden contents

[LOG 14:38:20.560] [PlanetInfoPlus] App activated for Kerbin^N
[LOG 14:38:21.257] [PlanetInfoPlus] Scanned highest elevation on Kerbin^N in 693 ms (86998 samples):  14249 m at latitude=-43.9625921602781, longitude=103.978478482206

[LOG 14:39:17.473] [PlanetInfoPlus] App activated for Krel^N
[LOG 14:39:17.882] [PlanetInfoPlus] Scanned highest elevation on Krel^N in 406 ms (86605 samples):  3031 m at latitude=1.58978109041825, longitude=105.861896208786
[LOG 14:39:17.891] [SpaceDust][ToolbarUI] Changed focus to Krel
[LOG 14:39:17.891] [SpaceDust][ToolbarPanel] Clearing all entries
[LOG 14:39:17.891] [SpaceDust][MapOverlay] Changed focus to Krel
[LOG 14:39:17.891] [SpaceDust][MapOverlay]: Removing body fields
[LOG 14:39:17.972] [OD] --> ScaledSpaceDemand.LoadTextures loading JNSQ/JNSQ_Textures/PluginData/Riga00.dds and JNSQ/JNSQ_Textures/PluginData/Riga01.dds
[LOG 14:39:26.325] [PlanetariumCamera]: Focus: Huygen
[LOG 14:39:26.330] [PlanetInfoPlus] App activated for Huygen^N
[LOG 14:39:26.698] [PlanetInfoPlus] Scanned highest elevation on Huygen^N in 367 ms (85865 samples):  7796 m at latitude=28.9107103702307, longitude=15.5748394488677

 

Expand  

We figured it out.  Kopernicus was racing it (and winning) to modify the info box if Kerbin's atmosphere pressure ASL changed even the smallest bit (it does in JNSQ).  I added a parameter to stop this since we don't need to fix the stock info box if we are replacing it.  You can use this simple .cfg config to get it working.  He'll probably ship it soon.

@Kopernicus_config:NEEDS[Kopernicus]
{
	HandleHomeworldAtmosphericUnitDisplay = false
}

Requires new Kopernicus as of today, Release-83.

The technical details of this are Kopernicus recaluclates 1atm to equal whatever the home world pressure ASL is.  If the homeworld pressure changes, even a little, Kopernicus must update the info boxes to match this.  Obviously, when we do that, we are restoring the old stock ones...  right over PlanetInfoPlus. lol.

PlanetInfoPlus does all that and then some, so if it's installed we don't need to run that code.

Edited February 23, 2022 by R-T-B

[caipi]

Awesome and quick work!  Two thumbs and two toes up (I would give more if I had more  ). I can confirm that it works properly now.

@Snark Apologies for the redundant request. I missed it, my mistake. I didn't mean to be pushy about it! Your explanation makes perfect sense.

[Snark]

  On 2/23/2022 at 11:08 PM, caipi said:

Apologies for the redundant request. I missed it, my mistake. I didn't mean to be pushy about it! Your explanation makes perfect sense.

Expand  

Oh, no worries.  I wasn't chiding you, I was just explaining the context, otherwise my quoting myself would likely come across as either baffling or just passive-aggressive.  It's all good.

  On 2/23/2022 at 10:52 PM, R-T-B said:

We figured it out.

Expand  

^ To be clear, when @R-T-B says "we," here, he's being charitable.  He did all the heavy lifting tracking this down, I mostly just stood off to one side sort of pontificating.

Anyway, thanks to his work, we'll get this straightened out.  Will take a new Kopernicus update as he mentions above, and a new PlanetInfoPlus update (which is coming Soon™).

  On 2/23/2022 at 5:41 PM, OrbitalManeuvers said:

Alrighty. Well, if you ever get around to adding one it would really help with automated tools.

Expand  

Thank you, will bear it in mind.  I'm sorry, I know I'm kinda being a pain, here.  It's just that I didn't start off having version files, and now I own a couple dozen mods, and if I did it for one, I'd feel compelled to do it for all of them, and I don't feel like taking the time to do that right now.

I'll certainly bear it in mind for the future, if I ever feel the gumption.  Thank you for the suggestion, you're not the first.