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

[Snark]

What it does

• Adds additional information to the "planet info" pane of the KSP planetarium.
• User can choose which parameters are displayed, via game settings.
• Config file allows customizing numeric formats.
• Works in modded solar systems.  (That's why I wrote it, actually.) 
• Localized in English and French.

   

Download from SpaceDock
License: CC-BY-NC-SA 4.0
Source code

 

How to install

Unzip the contents of "GameData" to your GameData folder, same as with most mods.

 

Why would anyone want this?

I've always liked the planet info display in the planetarium (in the tracking station, or in map view during flight). However, it's never felt quite right to me-- it's missing some bits of information that I find important, while "wasting" valuable screen real estate for some parameters that don't really have any practical in-game use.

This mod addresses that.

Here's what it does to the planet information displayed:

• Hides mass, area, and gravitational parameter (GM).
• Indicates whether the atmosphere contains oxygen.
• Indicates whether the rotation period is tidally locked.
• Indicates whether the rotation is retrograde.
• Shows the maximum surface elevation.
• Shows the orbital period.
• Shows the orbital semimajor axis.  (off by default, can turn on via options)
• Shows the altitude of a synchronous orbit (or "n/a" if not possible).
• Shows the height of the upper atmosphere boundary.
• Shows the height of the high / low space boundary.
• Shows the number of biomes present.
• Shows the number of biomes that have been explored.
• Shows the current exploration status overall (i.e. have you achieved orbit? landed? etc.)

 

In-game settings

The default behavior is tweaked to be the way that I, personally, like it, since it's my mod.

However, I realize that not everyone necessarily has the same preferences I do, so you can tweak it as you like via the game settings dialog.

Default settings are shown above.  Note that if you like showing the info I've removed (area, mass, gravitational parameter), you can turn them back on.

 

Configuration file

But wait, there's more!

You can also customize the colors used for the text, as well as the numeric formats used for showing the information and some other behavior as well.

You can do this via a configuration file, PlanetInfoPlus.cfg, which you will find in the mod's folder.

 

Debug console

From the Alt+F12 debug menu, type /pip to see a list of available console commands.

Currently, the most interesting/useful one is probably /pip dump, which will cause the program to dump its planetary "max elevation" data (altitude, latitude, longitude) to a text file, named PlanetInfoPlusDump.cfg, located in the same folder as the mod.

 

FAQ

• Q:  Does this work on modded solar systems?  What if I rescaled the solar system?
• A:  It "just works".  The mod dynamically calculates everything at runtime; nothing's hard-coded, it uses whatever you've got set up.
• Q:  Could you add <feature>?
• A:  Maybe!  If you've got an idea, let's hear it!  Please post in the thread, here.  No promises, but I'll certainly read and think about it. 
• Q:  Hey!  I noticed that your mod says the highest point on Kerbin is 6769 m, but I read somewhere that it's 6768 m instead!  Your mod is bad and you should feel bad.
• A:  Scanning for max elevation is imprecise, based on doing a bunch of samples of the surface. The only way to be perfectly accurate would be to take an infinite number of samples.  Since my mod isn't necessarily using the exact same number or arrangement of samples as whoever wrote the other number you read, it might differ by a meter or two.
• Q:  I'm playing a sandbox game, and I don't see the "biomes explored" field. What gives?
• A:  The mod defines a biome as "explored" if the player has retrieved science from the surface (or flying low, if it has an atmosphere).  Games where science isn't a thing (i.e. sandbox) therefore don't have this feature.

 

Acknowledgments

• Thanks to @Poodmund for pointing me at a handy algorithm for finding max elevation on a planet.
• Thanks to @flart for bug reports and feature suggestions.
• Thanks to @R-T-B for feature suggestions and Kopernicus compatibility work.
• Thanks to @vinix and @goldenpeach for graciously supplying French localization.

Edited December 21, 2022 by Snark
Update to v1.4.3 (Add SMA display, fix hanging bug in certain planet packs)

[KawaiiLucy]

Do the synchronous orbit numbers also work in rescaled systems, or are they hard coded?

[Snark]

5 minutes ago, KawaiiLucy said:

Do the synchronous orbit numbers also work in rescaled systems, or are they hard coded?

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

[Poodmund]

41 minutes ago, Snark said:

(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.)

Does this help at all? https://github.com/Sigma88/Sigma-Cartographer/blob/master/[Source]/SigmaCartographer/BodyInfo.cs

In any case, this is a great mod.  

[Snark]

18 minutes ago, Poodmund said:

Does this help at all? https://github.com/Sigma88/Sigma-Cartographer/blob/master/[Source]/SigmaCartographer/BodyInfo.cs

It does indeed! 

Thank you, I shall ponder on this.  I see that SigmaCartographer is licensed ARR, so your code shall have to be "algorithm inspiration only."

[HebaruSan]

Hi, will the plugin regenerate the cfg file if it's absent? I'd like to avoid losing users' settings when CKAN installs an upgrade.

EDIT: Looks like no, this will throw if there are no PlanetInfoPlus nodes:

https://github.com/KSPSnark/PlanetInfoPlus/blob/4f8c52ac6836d448401391c867d9b9fb5b08d398/src/Loader.cs#L21-L22

            UrlDir.UrlConfig[] configs = GameDatabase.Instance.GetConfigs(MASTER_NODE_NAME);
            ProcessMasterNode(configs[0].config);

 

Edited February 22, 2022 by HebaruSan

[Snark]

1 hour ago, HebaruSan said:

Hi, will the plugin regenerate the cfg file if it's absent?

It won't, but I'm having trouble seeing how such a scenario would likely happen?

This isn't anything to do with in-game settings; it's static config, that's included right next to the DLL and installed alongside it in the same folder.  It's necessary config that the mod expects to be there-- if it's missing, that's a damaged installation.  It's no different than, say, the solar-system config files for a planet pack.

The only way I could picture this file not being there would be if a user deliberately deleted it for some reason, but that's pretty much voiding the warranty, surely?  Why would a user do that?

1 hour ago, HebaruSan said:

I'd like to avoid losing users' settings when CKAN installs an upgrade.

Well, any actual user settings (in the sense of "choices that they make using the in-game UI") will be fine, because those aren't stored in the .cfg file; those are handled by KSP's built-in routines and persisted in the game savefile.

It's true that if a user has hand-edited this config file, and then an upgrade happens, the upgrade would overwrite the config file-- same as if a user had a planet pack and hand-edited the config for the planets.  If they don't want that to happen, then they've got a few options-- one would be to use ModuleManager to patch the config instead of hand-editing it, and that would be robust across upgrades.  Or, they could keep a copy of their hand-edited config and manually merge it in after the upgrade, or something.

This seems to me to be basically the same situation as any mod that has config (planet packs, part mods) that a user might want to tinker with; is there a reason for special concern here?

1 hour ago, HebaruSan said:

EDIT: Looks like no, this will throw if there are no PlanetInfoPlus nodes:

Well, that's a good point.  As I mention above, if someone deletes one of the game's necessary config files, as far as I've concerned they've voided the warranty on the mod-- I don't see any legitimate reason for doing that, it's no different than if they installed a part mod and deleted the part's config.  So I'm not especially inclined to expend a lot of effort on what I consider to be a fairly unlikely edge case.

That said, though, it would only take a couple of lines of code to handle this situation more gracefully if it did occur-- i.e. instead of throwing, detect the situation, log an error, and proceed.  The rest of the mod is written to function without throwing if the config is missing (it'll just use blah, C#-default values), so it would only take a line or two here to handle the situation.  Thank you for pointing this out!

 

Anyway.  Everything I've written above is based on a certain set of assumptions about how things work, how users are likely to interact with the mod, etc.  I don't use CKAN myself, so it's not out of the question that I might be making some incorrect assumptions about things.  I'd certainly prefer not to torpedo anyone just because they use CKAN, so if anything I've written above seems off base to you (due to my CKAN unfamiliarity), thank you for any advice that may enlighten me. 

[HebaruSan]

14 minutes ago, Snark said:

Well, any actual user settings (in the sense of "choices that they make using the in-game UI") will be fine, because those aren't stored in the .cfg file; those are handled by KSP's built-in routines and persisted in the game savefile.

It's true that if a user has hand-edited this config file, and then an upgrade happens, the upgrade would overwrite the config file-- same as if a user had a planet pack and hand-edited the config for the planets.  If they don't want that to happen, then they've got a few options-- one would be to use ModuleManager to patch the config instead of hand-editing it, and that would be robust across upgrades.  Or, they could keep a copy of their hand-edited config and manually merge it in after the upgrade, or something.

Ahh, OK. Never mind; I thought those were the settings the user could edit in the UI. Thanks for the clarification, we can just treat this as a normal file, then.

[R-T-B]

Ooh, I like.  Will download this today.

[modus]

I too will enrich my Gamedata folder with this.

[Arrowmaster]

I see you may add highest peak, what about space high/low transition and flying high/low transition altitudes?

Edited February 22, 2022 by Arrowmaster

[KeaKaka]

Download'd

[OrbitalManeuvers]

This KSRSS at 2.5x. All other bodies have either positive numbers or "locked."

UPDATE: welp - the stock one shows this too! Sorry, I thought this was one of the fields you had taken over, but it's wrong without the mod, too. All other fields looked GREAT! Thanks for this cool util

Edited February 22, 2022 by OrbitalManeuvers

[Snark]

50 minutes ago, OrbitalManeuvers said:

This KSRSS at 2.5x. All other bodies have either positive numbers or "locked."

UPDATE: welp - the stock one shows this too! Sorry, I thought this was one of the fields you had taken over, but it's wrong without the mod, too. All other fields looked GREAT! Thanks for this cool util

What you're observing is a planet that has retrograde rotation, thus the negative number.

And it's funny that you should mention this... because I actually was already working on a small enhancement for this very situation.  No, I'm not tellin' what it is, you'll see it in the next release, which will be Soon™. 

1 hour ago, Arrowmaster said:

I see you may add highest peak, what about space high/low transition and flying high/low transition altitudes?

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.

[Snark]

Hi everyone, I've released PlanetInfoPlus v1.1. 

This one adds maximum surface elevation as a feature, like this:

Many thanks to @Poodmund for pointing me at a useful algorithm for accomplishing this.  Some technical notes in spoiler.

Spoiler

Note that the planet-scanning algorithm for finding the number is computationally expensive.  You may notice a brief pause when you first enter the tracking station, or the first time you view a given planet or moon.  (Likely only a second or so, depending on your machine speed; on my own computer, it's around 800 ms.)  I'm sorry about that, but there's really no way around it; even with a reasonably smart algorithm, many thousands of points have to be sampled to zero in on the highest peak.

FWIW, I've done my best to take the sting out of it.  I've tweaked it to be as fast as I can while still being comfortable with the accuracy level, and I use caching to speed things up.  In any given game, it should only pause like that once for any given planet or moon, and thereafter it'll just use the cached value.  The caching persists across play sessions, so when I say once, I mean really only once. 

(caveat: it deliberately clears the cache any time you update the mod, to make sure it's not reading obsolete cached data)

Also, please note that the exact value of "maximum elevation" will differ based on how many points are sampled, the pattern they're arranged in, etc.  This means that different sources, e.g. my mod versus some other source, might give answers that differ by a meter or two.  Comes with the territory-- the only way to be perfectly precise would be to do a lot more point sampling, which would slow the feature down considerably.  I figured it was worth the tradeoff.

In addition, I've added a feature to handle retrograde rotation more intuitively (@OrbitalManeuvers, you may be interested in this).   If the planet rotates retrograde, then the "rotation period" label is changed to indicate that, and also the rotation period is rendered in an "alert color" to draw attention to it.

 

Enjoy! 

[StarCrusher96]

This is awesome! Thanks for making this!

[bobby72006]

Finally! I can know how low I can get my flyby missions without worrying that I'm going to finally kill Jeb. Thank you!

[linuxgurugamer]

13 hours ago, Snark said:

What it does

• Adds additional information to the "planet info" pane of the KSP planetarium.
• User can choose which parameters are displayed, via game settings.
• Config file allows customizing numeric formats.
• Works in modded solar systems.  (That's why I wrote it, actually.) 

Fantastic!!!!!

[JoeSheridan]

Fantastic mod  That´s a great addition to KSP, so: No more looking again and again into the forum-sites of all my planet mods to look up those stats (if they even exist there), now i can just use the planetarium / tracking station. Thank you

[JedTech]

Awesome! This seems really well thought out. I even love the default choices. Thanks!!

[Kerbart]

Does it come with blinking lights?

[alartor]

This mod seems really useful (mostly the max elevation feature), thanks!!

 

12 hours ago, Arrowmaster said:

[...] what about space high/low transition and flying high/low transition altitudes?

+1

 

[R-T-B]

Hey @Snark, lil code snippet you are free to use that you might find handy.

In Principia, you cannot rely on the tidal lock property to determine tidal locks.  You furthermore are supposed to use inclination, not period to determine retrograde orbits.  I'm using the following bit of code to determine if a body is losely "locked" or retrograde with it's parent in the CreateParam_RotationPeriod method:

		private static UIListItem CreateParam_RotationPeriod(KbApp_PlanetParameters app)
		{
			bool locked = false;
			bool retrograde = false;
			try
			{
				if (app.currentBody.orbit.inclination > 90)
				{
					retrograde = true;
				}
				else
				{
					double num = app.currentBody.rotationPeriod / app.currentBody.orbit.period;
					if (num > 1.0 || num < -1.0)
					{
						num = 1.0 / num;
					}
					if (Math.Abs(num) > 0.975)
					{
						locked = true;
					}
				}
			}
			catch
			{
				//Needed for preventing nullrefs on system root
			}
			if (PhysicalSettings.Instance.showOrbitalPeriod && locked)
			{
				return PlanetInfoPlus.CreateBody(app.cascadingList, Strings.ROTATION_PERIOD, Strings.LOCKED);
			}
			if (app.currentBody.rotationPeriod < 0.0 || retrograde)
			{
				return PlanetInfoPlus.CreateBody(app.cascadingList, InfoColors.Attention, Strings.RETROGRADE_ROTATION, KSPUtil.PrintTime(Math.Abs(app.currentBody.rotationPeriod), 3, false));
			}
			return PlanetInfoPlus.CreateBody(app.cascadingList, locked ? Strings.LOCKED_ROTATION : Strings.ROTATION_PERIOD, KSPUtil.PrintTime(app.currentBody.rotationPeriod, 3, false));
		}

Note that number 0.975:  It will consider a body locked if the rotation period and orbit period are within 97.5% of each other (obviously not if retrograde).  You can configure this, or make it an option, I just wanted it to tell me when a body is losely locked in "Principia" terms (where true 100% locking is rarer).

Edited February 23, 2022 by R-T-B

[flart]

23 hours ago, Snark said:

If you've got an idea, let's hear it! Please post in the thread, here.  No promises, but I'll certainly read and think about it.

• 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.
• make GUI longer
• put more precision on periods and synch. orbit (make GUI wider if necessary)
  (stock gives seconds for a vessel's period and meters for a vessel's orbit, KER gives milliseconds for a period)
  
• Making this string a little bit shorter probably will make it fit into one line
  
• NaN m for Jool and Sun
  

 

Edited February 23, 2022 by flart

[Snark]

4 hours ago, R-T-B said:

In Principia, you cannot rely on the tidal lock property to determine tidal locks.  You furthermore are supposed to use inclination, not period to determine retrograde orbits.  I'm using the following bit of code to determine if a body is losely "locked" or retrograde with it's parent in the CreateParam_RotationPeriod method:

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.

Spoiler

 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.