DMagic

@Horus @Tabris Does the zoom map/instruments window problem happen all of the time, or just with certain planets. I'm fairly certain gas giants or the sun are going to break it, since I missed a null check in there at some point. @OhioBob Those labels are the defaults for the UI in Unity, which would suggest that the UI is not getting properly initialized for some reason. But it's hard to say why without more information. @madindehead With those settings the SCANsat resource maps would function similar to the stock resource map. The M700 would provide a full, instant scan, which would show up on the big SCANsat map or the SCANsat planetary overlay map at a low detail level (rounded to the nearest whole percentage number, I think). The "Require Narrow Band Scanner" option means that the resources won't show up on the zoom map unless you have a narrow band scanner in orbit. So I think those settings will get you what you want. The wiki on GitHub has a little bit more detailed explanation of the resource scan settings than you'll find in the KSPedia entry: https://github.com/S-C-A-N/SCANsat/wiki/SCANsat-Resource-Settings#top-requires-narrow-band-scanner For biome scanning nothing has changed since version 1 or 2 of SCANsat, so any old video showing how that works would still apply.

SCANsat version 18.11 is out; get it on Space Dock. This version is updated for the Breaking Ground DLC and adds new features related to the Breaking Ground surface features. This update requires KSP 1.7.1 or higher, but does not require the Breaking Ground DLC. The BTDT scanner can now be used to detect these surface features (known as "ROCs" internally) and display them on both the Zoom Map and the Instruments Window anomaly viewer camera. Any area on the surface that has been scanned with the BTDT (which only works up to 2000m above the surface) will display all nearby "large" surface features (the kind that can't be picked up by EVA Kerbals). Note that this only works for a relatively small area surrounding the current active vessel, as KSP does not load surface features further away (the limit seems to be about 6-7km) or store their location. If you have an active BTDT scanner on the current vessel you also be able to view the nearby surface features in the anomaly viewer camera. There is also a new auto-refresh feature on the zoom map (the cycle icon in the top-right). It has three settings: no refresh, 4 second refresh, 8 second refresh. (Note that at low map generation speeds with a large size zoom map the auto-refresh may trigger before the map is finished drawing, you can adjust the map generation speed in the settings menu). Also, French translations are now available courtesy of don-vip. And some errors in the Chinese localization tags were fixed. Let me know if you run into any problems. @zeant93 Did you scan using the stock M700 scan function, where it scans instantly, requires a polar orbit and then transmits the science data? Or with the SCANsat function, where it progressively scans the planet? The SCANsat scanning method is required for contracts (the stock scanning function might work for contracts if the "Instant Scan" option is on in the settings menu and stock scanning is not disabled, but it also might not behave as expected).

The smaller, "zoom" map in SCANsat has undergone a lot of changes from its original version as just a popout from the regular map: It also uses a similar map projection as KerbNet does now, it helps to reduce distortion and looks nicer, if you zoom out far enough you can see it: Some day I'll look into the new DLC surface sites and how they should be displayed.

@dylsh SCANsat takes all of its values directly from the game. It pulls the terrain elevation data directly from KSP's planetary generation system (which can be a little computationally expensive and makes generating the big map slow in some cases), and its biome data comes from KSP's final output of the biome map, the slope map is basically the terrain data displayed in a different way. So it will work with any planet pack or any changes made to the biomes of stock planets.

That's what happens when you don't look at your own mods for probably years. There should be an option called "Scale" in the stock difficulty settings screen under "DMagic Mods". Unless something has changed, though, this panel might still be bugged to where it is difficult to use in some cases. If it works then it just changes the scale of the entire window; not just the map but labels, buttons, controls, etc... I meant cause problems if you try to use the moving parts while the struts are still active, though I'm guessing it would just make them not move.

@Jognt Does the error in the VAB happen only when placing and removing the first part for a new vessel, or when placing and removing any part? @AlexO I generally try (or tried, since so much has been added) to avoid showing duplicate information. Since the orbital velocity can already be shown on the nav ball I didn't add it, but I can see where you might want the nav ball to show something else and still see orbital velocity. And you can show orbital altitude, which is also shown on the main UI, so I guess it doesn't make much sense to exclude velocity displays, too. The other two I specifically avoid since that is telling you information that stock KSP generally makes you work to find. The only way to show that information in stock is to run an experiment or use KerbNet with a biome scanning part, so I didn't like the idea of just showing that information right away. And I think SCANsat has a better system for biome anyway, that information is available once you've scanned the planet's biomes, which is what makes the most sense.

@Jognt I should have the toolbar disabling function working properly and more clearly explained in the next update. That self-promotion is not allowed on the forums. But I leave the link in protest. @5thHorseman Kerbnet Controller never had a resize option, it just simplifies its usage and has some options make it remember some of your last-used settings. But if you want a map (and mapping system) that isn't garbage, you'll have to use SCANsat. I would imagine that EVA struts across robotics parts would cause problems. It would be the same as if you strutted across movable parts with regular struts in the VAB (unless something about struts has changed that I don't know about). But with EVA struts you can always just remove and replace them when needed.

They are stock waypoints. Just go to the map view, right-click on the waypoint, then delete it.

@Alexology Any time there is a source folder you can probably safely leave it out, though, in some cases it might be an indication that you downloaded the wrong thing. The CapCom-Master that you have listed above is likely such a case. That sounds like the GitHub repo, not the GitHub download package. CapCom in particular has several dependencies (ContractParser and ProgressParser, which are included in all of the regular download packages, but probably not the GitHub repo) and requires being installed in a specific location (GameData/DMagicUtilities/CapCom), any deviation from that would cause it not to work right.

@Jognt I think those settings functions may have migrated to the stock difficulty settings menu at some point. They should be under DMagic Mods, or something like that.

Regarding the stock Universal Storage science parts, refer to what @Jognt, those are not included for US2. For problems with the US2 science parts (the ones distributed by US2), I have yet to see an problems that don't involve one or the other science helper mod, so you'll have to direct your problems to there.

The multi-spectral scanner does not scan for terrain, only the RADAR and the SAR altimetry scanners reveal terrain. Unless the multi-spectral scanner's description has changed at some point, it only indicates that it scans for biomes and to "differentiate between terrain types", which is admittedly a little bit of a confusing term, but basically is being used to mean biomes.

It's in the settings menu, just turn off the toolbars.

@Kerbart Just delete the .version file. Or don't use AVC at all, as it seems to be not so useful anymore.

Probably. I'm guessing the version compatibility listed in the title has more to do with when the last versions were released than with any significant changes that were made. Also, this is almost ready, but I'm in the middle of moving so don't expect anything soon: https://i.imgur.com/dp5bC8f.mp4

It seems self-explanatory. What else would a "lock doors" function do but prevent them from being opened?

I really can't overemphasize how much I hate that line "this scanner requires a polar orbit" (or whatever the message is when you try to use the M700); NO! It does not require a polar orbit! In a game that is all about showing you how things like orbit, launch profiles, landings, etc... work this is the worst case of telling and not showing.

It's not just that it takes time to scan something with SCANsat. I think it's more important that it allows for something other than a polar orbit (which doesn't really ensure coverage anyway, but why would we need to know about orbits...). Maybe you only care about the equatorial region, so you can just scan from a low inclination, or maybe you can scan strips of the surface in successive flybys. My biggest problem with the stock mechanic isn't the time required, it's that it teaches by telling you what to do, instead of letting the player try different techniques to scan the planet and see what happens. The science part of scanning is sort of just an afterthought, as it follows naturally from the idea of a progressive scanning mechanism; scan half the planet get half the science, and so on.

Yep, the button to open/close the shroud won't be there in flight.

I think this is where XScience is running the standard experiments, you can notice above a bunch of code about checking to see if it's an Orbital Science experiment and doing things differently if so: https://github.com/Flupster/KSP-X-Science/blob/master/X-Science/StatusWindow.cs#L567-L572

@scottadges Thanks for looking into that. I'm fairly certain the problem is XScience (I think Automated Science something something and For Science would also have the same problem). It's also telling that I've never heard any reports of issues with the other US science parts, the thermometer, barometer, etc... Those also use a custom science module, but not one that would have this particular problem when used in conjunction with science management mods. You'll notice those "Running DMScienceAnimate" lines in the log, referring to DMagic Orbital Science experiments, both XScience and Automated whatever have explicit support for running DMagic Orbital Science and DMScienceAnimateGeneric (which is used by a lot of other mods) experiments (For Science does not have this support, which is why it is marked as incompatible with DMOS). But they don't have that kind of support for any random experiment that changes the science behavior like these do (they mostly have custom behavior in managing multiple samples for the same part). I'm pretty sure that Science Alert would handle this correctly, as it does this the right way: https://github.com/linuxgurugamer/ScienceAlert/blob/master/Source/ScienceAlert.Experiments/ExperimentObserver.cs#L284-L288 So the simplest solution would be do these experiments manually and bug whoever is maintaining XScience to change its behavior when it deploys the experiment. It should, theoretically, be a simple thing to change, and I think it's something I've brought up before, but all of those science mods tend to pass through multiple different maintainers and developers.

@scottadges Are you, or anyone else with this problem, using any of the science helper mods, like XScience, For Science, etc...? Or Kerbalism? All of these functions work fine for me, so it's a little hard to figure out what's going on.

That's sort of how it has to work, at least without really changing how KSP's code base works. All of the code for Making History is in the base game, at least as far as I know (there are a whole bunch of Expansions.something namespaces that you can check out it VS's Object Browser, or whatever program you use, or the API docs). I guess they could lock out some functions by testing to see if the expansion is installed, but generally I would expect all API features to be the same.

This doesn't make too much sense to me. If someone really cares about more terrain scatters and things to do with them, then they will probably buy the DLC. If they really want such a feature to be in the stock game, but aren't planning on buying the DLC then it doesn't much matter, they weren't going to buy it anyway. I imagine there is a very small number of players that care so much about this aspect that they would not buy a DLC that they were already planning to buy, just because of that one feature. I'm guessing there will be a small number of players that quietly think that way, and 3 or 4 that loudly think that way, and not much more.

So... you mean read all sorts of wild implications regarding inventories, storage, "put them on the ground", etc...