DMagic

Same story. No email, spam folder or otherwise.

It is used by other mods, @CobaltWolf's Bluedog Design Bureau is the only other active mod that I'm aware of. And I'm not sure of this mod's license but mine is the simplified, 2-clause BSD. Its download link is at GitHub.

The big map width can be found in the save folder by searching for SCANcontroller then looking for map_width below. I'm not sure why any specific map size would cause the problem, but odd-numbered widths aren't aloowed and may cause problems. There are several methods in place to prevent odd-numbered widths, but I may have missed something. You can also manually set the map width in the settings menu (that will round odd-numbered values up by one). Also keep in mind that the map window is much larger than the map itself, there are large margins to fit all of the buttons and labels. That's because the MKS_Antenna doesn't have stock resource scanning modules for the new resources. If and when they are added the zoom map and mouse-over readout numbers will work as before. If they aren't added then it will be a problem. You can get around the restriction for now by turning off the Narrow-Band Scanner requirement in the resource settings window. That looks like a RemoteTech error. Nothing. It has been deprecated for a very long time. The part is kept in the folder on the off chance that someone still has an old vessel with one present.

Depending on your resource scanning settings, yes. See the Wiki for more.

Pictures would help.

Version 14.8 is out; get it on Kerbal Stuff. It includes fixes for RPM and Kopernicus compatibility and support for the new CRP resources (Gypsum, Hydrates, ExoticMinerals, RareMetals, and Dirt).

That depends on what exactly is going on. The fuel lines have a maximum length, which can be changed in the part's config file found in this mod's folder. To connect to a vessel within range (I think the default is 200m) you don't have to click on the part again. Once you have picked up the fuel line from its origin point just walk over to the target vessel and point the mouse at it. As long as the vessel is within rage it should show a preview of where the fuel line will attach; click on the vessel to attach the fuel line at that point. To open the transfer window you will have to click on the origin point of the fuel line again (but you can do so from far away while on EVA).

You can sort contracts by type and planet. Then you can arrange them into missions however you want. There are some inherent limitations though. Contracts have no universal method for designating a target planet, and some have multiple targets, or none at all, so there will always be situations where a contract can't be properly assigned to a certain planet. And Contract Configurator contracts are all sub-types of one parent type. So they will all get lumped together. Getting around this can be a bit of a pain. I always recommend staying away from any type of quick start or load mod. Malah's Quick Start takes some measures to make sure things are initialized properly when skipping the Space Center, but in general I think those are a bad idea (outside of mod development, where you might want to load into a specific file as quickly as possible).

What about Dirt and RareMetals? Those both seem to be planetary resources, too.

Thanks, I'll add these and ExoticMinerals for the next update. There is a help function in all of the settings windows; from that: "Adjust the scanning frequency during TimeWarp. Higher settings result in fewer gaps in the maps but may have a performance impact at high TimeWarp." The performance impact is generally a little hiccup once every second when running at the highest timewarp. Putting the Time Warp Resolution at medium is usually enough to alleviate that problem and will only result in gaps when you are wither scanning from a very bad orbit, or when scanning a body with a very slow rotation. That's what I was thinking, but I'm not sure how it would happen, or really even why it would cause a problem, maybe it got forced into an odd-numbered map texture width somehow. Can you get it back to where it breaks? I'll try to find out what's going on. Not sure. I know that Pathfinder does something with resource scanning, but I've never really been sure exactly what that is. There are several SCANsat resource scanning settings, and standard SCANsat scanners shouldn't interfere with anything.

Does it only happen with the SAR, or does it happen also with the low resolution RADAR scan too? Does the map start building, then start spamming the error? Or does it start spamming the error as soon as the map opens? Can you re-size the map and see if the error persists? I put in place some measures to prevent the type of error you are seeing, but it's possible something slipped through.

That shouldn't happen. Is there a delay from when the scene loads to when the contracts appear in the window? Usually this happens when there is some error while loading contracts, or, maybe, if there are so many contracts that KSP takes too long to load them, though I don't think this is possible. Hmm. Something like that might be feasible. Though for now you could just make another mission called "Unassigned" and put them there.

SCANsat Wiki. Does anyone have a complete list of all the CRP planetary resources and which parts are used to scan for them? I don't particularly want to search through it all myself.

I'm not sure why there is still so much confusion. CurseForge is the official mod hosting site, when you click on the link at the top of the forums, and the majority of links in individual mod threads, it takes you to the CurseForge site, not Curse. There are no adds on CurseForge, and there is a big, obvious, download button that immediately grabs the latest version. And, no, there was no already developed mod site for Squad to chose, KerbalStuff came after Curse and they had been trying to replace SpacePort for a long time (which was truly awful). Also, CurseForge pays you money for your mod if you want. It's not a huge amount (but way more than I ever get from donations), but if you have decent download numbers it's more than enough to help with something like software subscriptions. The main downside at this time seems to be the lack of any CKAN support. I'm not sure if that is something that will change anytime soon, but it can be a problem for mods exclusively hosted there.

So do I, but I wouldn't take those numbers too seriously. Kerbal Stuff frequently shows download numbers for long out of date versions that can sometimes surpass the current version (and sometimes still has mysterious download spikes for no reason; Portrait Stats had one a few weeks ago). If you want to get Github download numbers without too much fiddling you can just grab all of the data in a big blob of text online, just replace your username and repo name. Why they can't just provide a simple download number is a mystery, but you can find the value by looking down about 30 lines to the "download_count" value.

CKAN should be working now. For the next update I'll probably change the folder structure around for this and CapCom so that it's more clear that they share resources; the current solution with two separate folders is not ideal.

The science archive might make sense, but some of us become quietly enraged by the constant need to go back and forth from the space center to access things that we should be able to access anywhere. So this works well enough for me (I plan on adding it to CapCom at some point too): It's also nice to be able to view recent progress completions without having to use the stock message box (which can't be moved, or re-sized, and disappears when you click anything else).

Version 6.0 is out; get it on Kerbal Stuff. This version has a new progress node tracker (which is present in a separate folder from ContractsWindow - GameData/ProgressParser - as it is intended to be used with other addons), it stores data about each progress node's rewards and completion information. Completed Progress Nodes can be viewed by clicking on the contract mission title bar at the top of the window. There is also a third window size option, and custom notes added for certain stock contracts that specify which available parts will satisfy certain contract requirements; these notes are only displayed in the Space Center and Editor scenes. Progress Tracking:

Not for Contracts Window +, but they would work great for another mod (). I try to keep this focused on contracts, though I do have one addition coming that's not strictly related to contracts - a progress reward tracker - something to improve upon the current method of keeping track of progress rewards (not deleting the blue icon message...). But that actually fits in very nicely with the current setup.

Pictures? It won't work when you are hovering because you have to be landed. Put it on a vessel, activate it, find some anomalies, get close and collect science. You can find anomalies however you choose; there are several contract packs (including this one) that will guide you to them, SCANsat will show you where they are, you can look them up online, or, if you really want to punish yourself you can use the magnetometer from this and watch for magnetic field spikes.

The current version of SCANsat, 14.7 (and 14.6) should support Kopernicus 0.5x and later, though I've only tested with 0.63. If planet packs don't support the latest version of Kopernicus ask in those threads about getting them updated. I can't say why SCANsat would be having problems without full logs.

All of the SCANsat RPM stuff was moved into SCANsat a long time ago. But this is actually a SCANsat + RMP + Kopernicus problem. I know what the cause is, just a dumb mistake in how RPM maps are created.

Those are attributes. I don't have a good understanding of them either, but the basic idea seems to be that they further define or categorize the method or field following each attribute. So the [KSPField] attribute is used for all Part Modules and Scenario Modules to collect each value into their respective Fields lists (BaseFieldList, I think; [KSPEvents] and [KSPActions] work the same way, with a BaseEventList and a BaseActionList). It makes for a convenient tag for saving and loading data, displaying information in a part's right-click menu, or telling a Part Module what values to look for in the config file. [KSPAddon] just tells KSP to start a Unity MonoBehaviour that the attribute is attached to. It's useful for mods that don't have a part or scenario module (you need something to tell your code to actually start doing something). I'm not really sure what the MonoBehaviour is attached to, there's probably some KSP controller class that is the parent of all KSPAddon classes. [KSPScenario] is, as far as I know, only used once, the first time you start a game with an addon using that Scenario Module (and it only seems to be read in the Space Center scene, which is why you can't skip that scene when loading new mods with Scenario Modules). After that KSP's Scenario Module controller loads all of the data from the save file, and as long as there is a matching class that inherits from Scenario Module it will be handled properly. It isn't actually necessary to use [KSPScenario] to add your Scenario Module, it's just much simpler than the other options. The only other KSP-specific attribute that I'm aware of is [Persistent], which gets used when manually saving and loading data.

If the hammer is too close it can kind-of push through the surface which messes up the distance check calculation (it it checks the distance to the other side of the planet it that case). I was aware of this problem, but for some reason didn't think of the very simple way to fix it (move the point from which the distance is checked up a bit...). Then there is also the case where the hammer is judged to be too close to the surface and won't deploy because it risks flipping the vessel over (this will display a message about being too close onscreen). I might just drop that check and remove the collider from the hammer itself, thus removing any issues caused by the hammer striking the surface too hard. If the hammer is simply too far away it will also fail (and also display a message onscreen, the same as in the image above). It should otherwise work. I'm not aware of anything in RSS or Kopernicus that would affect it. All of the distance checks are dependent upon the size and position of the hammer itself. I'll check it out to see what's going on.

16GB? It might be unlikely to actually fill up 16GB just from having a game run, but there are situations where you can easily run into problems with less (OK, less than 12GB, but that is a somewhat odd number and it's much more likely that people will either run 2X8, or 4X4 GB). I played Cities Skylines (another Unity game with a x64 build) and constantly ran into problems when mods pushed me over 4GB. I found myself, for the first time in probably more than a decade, having to make sure all other programs were shut down before starting CS. After moving to 16GB I never had problems. With a handful of big parts packs, planet packs, and high resolution visual mod packs you could easily go through 5-6GB of RAM for KSP. That would be a problem with only 8GB of system RAM.