DMagic

It looks like it came in with a lot of horizontal velocity.

@vardicd I see the problem now, it seems to be an odd effect of how the map textures are removed from memory when turning off or switching the overlay. I'll see about getting a fix out sometime soon.

@vardicd Did you try it while attached to a vessel? I'm not really sure if behaves the same while attached to a Kerbal.

@vardicd Can you try it with the latest version? There are a couple of bugs in 17.6, they probably don't affect this, but they really clog up the log files, and may have other strange effects. I've seen the same odd effects occur in the past, but that was due to some very specific problems with how overlay maps were removed when changing scenes.

@Fzzt In sandbox the tooltips don't show at all. The only way to get them on is to enable Kerbal gee force limits. I think the same applies in science mode, but you can also enable experience to make it show up. Since Portrait Stats piggy backs off of the stock tooltip there isn't much that can be done if it isn't shown. @Kerbart That's an interesting idea. I'm not sure how complicated it is to essentially delete one part and replace it with another. I can try to look into it.

This:

@Sigma88 Yes, all components of the science id's (experiment title, body name, situation, and biome) remain in english. The display names are just used for the title that actually shows up in the experiment results window. Biome names are in lots of places, though. Stock modules might have better handling of the situation, so that they use the regular name if the display name field is empty, I haven't looked into it. But I'm also using the display name extensively for SCANsat, I can add a check for an empty field, but it's probably best for Kopernicus to also set it.

@DocRockwell It looks like Kopernicus is the culprit and will need to be updated to handle the way that biomes are displayed now. @wile1411 That contract pack is somewhat redundant, but if you prefer that type you can either use it together with the included contracts, or just delete the included contracts found in the SCANsat/Resources folder.

Yes, specifically, the CBAttributeMapSO.MapAttribute has a displayName (and localizationTag, which I'm not sure what the purpose of is), which, at least in some cases appears to be the unformatted localization string (#autoLOC...) so that you have to call Localizer.Format on it. Science results and some other things need to be able to read both the standard and the display name for the biome. ScienceUtil.GetExperimentBiomeLocalized and GetBiomeDisplayName are used quite a bit and both return only the displayName. The last section of the modders notes goes over it a little, with further complications if anyone is trying to set "mini-biomes" - KSC biomes:

@Thomas P. Does Kopernicus support using localized biome names? I don't see anything about setting the displayName field in the BiomeLoader class.

@DocRockwell That's because someone either hasn't updated their Kopernicus planets for KSP 1.3, or hasn't done it properly (or possibly Kopernicus hasn't been updated properly). All biomes need a localized name now (regardless of whether any translations are actually available), and SCANsat reads that value.

I don't think the RAM usage due to parts is as bad as most people think it is: It's all of the stuff that you can't touch that uses up the most RAM. And that is even taking into account how inefficient older stock part textures are; my guess is that you could make the same parts (the old ones, not the space plane parts), or parts with higher quality, with around half of the texture assets that are now in use. Parts mods are a different story because they can be as high quality as someone wants, and they may or may not be optimized at all. Something like BDB has over 300 parts, but only uses about 150MB, whereas something with individual textures per part could quickly take up more space. So I don't think memory usage is really a relevant justification for procedural parts.

@V8jester, @Ziw The Surface Sampler plugin is updated and should be working now: https://github.com/MagicSmokeIndustries/IR-Surface-Sampler/tree/master/GameData/MagicSmokeIndustries/Parts/Rework_Utility/Plugins

Fixed; on GitHub now.

A minor update has been release on GitHub. It fixes a bug allowing scientists to reset an experiment on EVA. Thanks @Aelfhe1m

Version 17.8 is out; get it on GitHub. It fixes a but that was allowing more than one big map window to be opened at the same time. It also adds a few more localization strings (16 words, total) for UI labels, specifically, the labels on the big map and zoom map drop down menus (projection, map type, etc...) and the labels on the settings tabs (general settings, resource settings, etc...), these will all need to be translated. Final translations (expect for the above) for Chinese have been added by Summerfirefly.

Version 1.3.10 is out; get it on Space Dock. It fixes some bugs with ground detection for the XRay and Seismic Hammer experiments. It also adds an option to disable the science or antenna (to completely remove the antenna functions you will need to delete the ModuelDataTransmitter) functions for the SIGINT and Soil Moisture parts. This can be used, for instance, with @Dunrana's Buzzard Collector to get around having any science events and action groups.

Have you tried it? There were changes made in the latest version (both updates) that should have fixed at least some of the RT problems.

@Alshain That's new. Has that ever happened before? Did you try deleting the BTDT part to see if it finished loading? I don't think there's anything different about that part in particular (except maybe that "®" in the title), so I don't know why it would fail there. It's failing with an access violation error (code: 0xC0000005), which I've never seen happen before with SCANsat.

In possibly related news (and late news, due to Squad's apparently contractually obligated lack of communication skills ), KSP doesn't seem to be available from the Squad store anymore. https://kerbalspaceprogram.com/kspstore/index.php?p=22 https://www.reddit.com/r/KerbalSpaceProgram/comments/6gmwfa/ksp_no_longer_available_for_purchase_in_squad/

It turns out there is another problem with closing the big map. If you open it from the toolbar menu button, this thing: It won't set the state of the toolbar button correctly, so the button thinks the window is still closed. This means that if you push the button again, without closing the toolbar menu, it will open another big map window, orphaning the old one. It should be an easy fix.

Or better yet, just delete the .version file, since I'm not sure if changing only the local .version file will be enough. You can also use the dev version for 1.2.2; it works fine except for a few minor bugs:

@OhioBob I would need to be able to use whatever dev build of GPP you have to be able to help diagnose any problems.

@Alshain There are a few problems with that idea. One is that, given the situations the mod is designed for, slightly mismatched vessels on the surface, pulling the two together would likely end up with wonky results that may end up causing problems. Such as, one part of the vessel holding the other up in the air, or part of the vessel being forced into the ground. Another is that this sort of thing gets into the territory of moving parts like IR. When you do that you have to deal with moving joints around on an existing vessel, trying to account for struts, or autostruts, which are things that I gather are really nasty to deal with. The animation of the docking port extending and retracting doesn't have anything to do with the physical connection between the two vessels, so you could technically retract the port, but you would just end up with a gap between the vessels. And, also, Flexible Docking ports is extremely finicky, and delicate. I'm always hesitant to try to change things because it will probably break something else. For instance, I have a method for making the ends of the ports able to rotate significantly more than they do, something like ~40o instead of 10-12o like it is now. But when I do it, the math for positioning the flexible docking ports get screwed up and things don't end up in the right place anymore.

@clown_baby This is how I've always done it and it works for me: https://github.com/DMagic1/KSP_Better_Maneuvering/blob/master/Source/BetterManeuvering/ManeuverPersistence.cs#L91 I'm no sure if all of that Path.Combine, Path.DirectoryName stuff is actually needed (or converting the \ to /), but it works, so I've just used the same method every time.