Snark

Not sure what you mean by "add custom text"? Can you elaborate? I mean, all the UI strings that the mod uses are defined in the localization file, so if you wanted to change "Max Elevation" to "Most Upness" or whatever, then yeah, you can do that. And if you wanted to change the format of the numbers displayed, then that's doable, too. Beyond that, though, I'm not sure what you mean? What did you have in mind? Out of curiosity, do you mean "using it for" in the sense of just installing it for your gameplay when you're running some planet pack or something? Or do you mean that you're authoring a mod and were thinking of somehow incorporating this?

Hi all, I'm pleased to announce the release of PlanetInfoPlus 1.3.1. This one has no new user-facing features in normal gameplay for most users, but it does add two new things: French localization. Merci beaucoup à @vinix for generously supplying this! Ability to dump planetary "max elevation" data to a file. As has been discussed in the preceding page or so of posts on this thread. Thanks to @flart for the suggestion. You can access the data-dump function via the Alt+F12 debug console. Open the console, and issue this command: /pip dump This will cause the mod to write a file, PlanetInfoPlusDump.cfg, into whatever folder the mod's installed in. Here's what it looks like, for example, when I run it with the New Horizons mod installed: Note that executing this command will force the mod to go ahead and (expensively) calculate the max elevation point of every single body in the system that isn't already pre-calculated. So, depending on how fast your machine is and what percentage of bodies have already been pre-calculated by the time you run the command, it might lock up the game for up to several seconds. (On my machine, fully calculating the entire New Horizons system with 32 solid planets takes around 10 seconds total, for example.) So, if you use that command, give it a few seconds and don't think your game is crashing. Enjoy!

Some content has been removed. A gentle reminder, please avoid political topics. Politics are not allowed in the KSP forums. Thank you for your understanding.

Just report them. It's the right thing to do, and is the best way to help them. Reporting them doesn't "get them in trouble". Remember, folks: Filing a report on a post is not pejorative. A report does not mean "this is bad" or "this person is doing evil". It simply means "hey moderators, take a look at this, please". A newbie who is clueless about the rules is an excellent example of someone who needs some help, and so reporting is absolutely the right thing to do. It's no different from calling 911 if you see a kid who's stuck up in a tree. "Clueless newbie colors outside the lines" is a thing that happens all the time. It always has, and it's no big deal. We moderators know this, and remember, we're here to help. It's why we signed up for the job. Users don't get in trouble for making an innocent mistake-- anyone can goof, we understand this. So in a case like this, typically what happens is: we see the report we go tidy up the problem in question we drop the person a friendly note along the lines of "hi, welcome to the forum, by the way we see that you did X over here, we understand you mean well but the rules say not to so please don't do that; please don't worry, you're not in any trouble, hope you have fun here" (Someone who repeatedly does the same out-of-bounds things despite being told not to would be a different matter, of course, but most of the time that doesn't come up.) Not really, no. There are only a small handful of us, we're part-time volunteers who have IRL stuff to deal with and do this only as a hobby. We simply don't have the bandwidth to monitor the forums-- we never have, and we don't even try, for the most part. We do notice stuff on our own from time to time, but only because we're forum users too, just like you. If I'm browsing the forums and I just happen to notice something amiss, I file a report (to share it with the team) and then we move from there, sure. But for the most part, we're heavily dependent on reports from users. You good folks have several orders of magnitude more eyeballs than we do, and there's simply no way we can compare to that. In short: if you don't report it, there's a pretty good chance we won't see it. Which means the person will probably keep repeating that behavior because they don't know any better. Which will annoy people, more and more, until people start angrily lashing out at the clueless person, and then everyone loses and the newbie feels bad. It becomes a whole sorry mess that could have been easily and amicably avoided if the newbie had gotten a friendly helping hand right at the start. So, yes, please report. It helps the person you're reporting, it helps the moderator team, and (indirectly) it helps everyone else in the forums.

Ah, I see what you're suggesting. Thank you for the suggestions, I'll think about it. I wouldn't consider it to be appropriate usability in the classic ModuleManager way, because the file wouldn't be generated until running the program, and even then there's no guarantee it would be complete (because not all planets may have had their calculations done yet, it's somewhat "on demand"). Which means a user who tried to set up usage of this config via a ModuleManager patch would have a situation in which stuff wouldn't work unless they ran KSP, mucked around in the UI until they're pretty sure everything's been covered, exited the game completely, and then restarted it, before the data would actually be usable by anything else. On the other hand, simply exporting a text file that's basically in config format, with the expectation that anyone who wants to use it would manually copy the file somewhere and then do stuff with it-- that has a considerably lower bar and makes more sense to me. I can imagine that a variety of different mods might conceivably want the data, so I'd be hesitant to over-specialize it specifically just for WaypointManager, but a file that would contain the requisite tuples of "celestial body, latitude, longitude, elevation" would at least have the necessary data in it, and wouldn't be difficult for someone to run through a script to wrangle it into whatever format they needed for some specific mod. I shall think on this.

I still own the mod, I'm still around. Fixing it would require time and energy, and it's not a super high priority for me, given that the mod basically works (I use it in my own gameplay, and find this problem only a minor annoyance). (This was one of the first mods I made for KSP, and it shows-- the code is a fairly complicated mess. Going in to track this sort of thing down would be quite time-consuming for me. That's not to say I'll never do it, just that I've got a lot of other higher-priority things going on.)

Quite a few posts have been removed. Let's try to remain at least in the general vicinity of the topic, folks. Thank you for your understanding.

Yah, that's a built-in function of KSP. I'm sure it would be possible to tinker with it, if one knew the correct sequence of actions... but that's getting into UX semantics and I'm fairly strongly disinclined to do that. In general I'm happy with the way the KSP UX hangs together, not least because I have several thousand hours of muscle memory telling me how things behave and where to find them. (Also, I wouldn't know how, anyway; I'm seriously not well-versed in tinkering with UI in this game. For example, I'd love to adjust the height and/or width of the planet info pane, and haven't been able to figure out how to do just that one simple thing. But in the specific case of what you're asking, I think I'd be disinclined to do that even if I knew how.) Thank you, good to know!

Update time once again! I've just released PlanetInfoPlus v1.3. This one adds a new section, "Gameplay", to the panel. It's below the "Physical Characteristics" and "Atmosphere" sections, so you'll probably have to scroll down to see it. This new panel shows the following stats: The height of the boundary between upper and lower atmospheres (if atmosphere is present) The height of the boundary between low and high space. The number of biomes present (not counting mini-biomes like the ones around KSC) The "exploration status" of the body. Like everything else, these new parameters have their own toggles in the settings dialog. (If you turn all of them off, the "Gameplay" section goes away completely.) Regarding the "Exploration" field: It shows the "most advanced" exploration yet done for the body, be it a simple flyby or planting a flag (or "none" if you've never been there). It uses different rules for what "most advanced" means for the homeworld versus everything else. For example, planting a flag on Eve is more impressive than just orbiting it... but the reverse is true for Kerbin. The rules for exactly which achievements count as "more advanced" than others are admittedly somewhat arbitrary-- e.g. should "crewed orbit" rank higher than "uncrewed landing", or not? Since it's arbitrary, I just decided, based on how I feel from playing KSP for a while. I realize that not everyone will necessarily agree with every one of my choices, but that knowledge is a burden I am prepared to live with. (No, I don't plan to add config settings to allow the user to tweak the order. Feels like overkill to me.) Anyway, enjoy! Shout-out to @Arrowmaster and @caipi, both of whom indicated interest in seeing some of these new parameters.

Hi all, I've just released PlanetInfoPlus v1.2. No major new UI-facing features, just various goodies including some bugfixes and improvements to performance, compatibility, and configurability. New with this release: Added some clever pre-calculation to reduce the momentary freezes when first going to the planetarium view. Add a Kopernicus compatibility patch to deal with certain edge conditions. Note, requires Kopernicus Release-83 or newer to work. (Thanks to @caipi for the bug report with JNSQ compatibility, and to @R-T-B for tracking down the problem and releasing a Kopernicus update.) Add config options for "approximately tidally locked", for Principia compatibility. (Thanks to @R-T-B for the suggestion.) Shorter "Atmospheric Characteristics:" label, to fit on one line. (Thanks to @flart for the suggestion.) Add config options for time precision for rotation & orbit periods. (Thanks to @flart for the suggestion.) Fixed a bug where bodies with no surface would show "NaN" for max elevation. (Thanks to @flart for reporting.) Regarding the time precision options: @flart, not sure if this gets you exactly what you need, but it's a step in the right direction. I notice that increasing the precision from the default 3 places to 4, still fits on one line (at least in English). Enjoy!

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

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? Already asked. My answer:

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.

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

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

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

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

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

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.

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

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

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

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

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