DMagic

Do you mean you accepted the contract through CapCom and it disappeared immediately, or that you accepted it, completed it later, and it disappeared? There is nothing special that CapCom does to contracts, it has the same effect as accepting a contract from the debug menu. As soon as a contract is accepted it is handled by the stock contract system. It wouldn't delete something unless you tell it to.

I thought I had fixed the problem causing that Tylo map bug, but apparently not. Does it happen all of the time, or just the once? The others should be simple fixes, I'll look into it.

I'm not sure why that would happen. Do you mean that you can't access these experiments while on EVA, or that they don't work at all? And are you using the stock barometer/thermometer or the Universal Storage version? All of my parts should be compatible with KIS. I've never actually tried to attach those instruments directly to an asteroid, but it should work, and they should function properly, it's technically no different from having them attached to vessels which are attached to the asteroid with a claw.

Missions are already assigned to craft, though there is no explicit interface or manual selection possible. You just have to add whichever contracts you want to that mission and Contracts Window + will handle it for you. Each time you save while in flight or change from flight to the another scene it saves whichever mission is currently active. Then the next time you load that vessel it will automatically switch to that mission, or the default if the mission has been deleted or there is some problem.

That looks great. The next version will allow for changing the color of each icon in the settings file. Currently the icons are all white with the color hard-coded in the plugin.

I should probably add a check to that system so it doesn't carry on trying to calculate the planet's height map if something weird like this happens. But if the error persists it's likely to cause problems beyond SCANsat. Scanning for liquid resources? I've never really bothered with it because there isn't as much complexity as there is with planetary resources, and Ore doesn't use it, so there isn't as much need for more accurate ocean scans. And there's really only two stock planets where it matters anyway, so I don't want to create another resource handling system just for that. I'll look into it though. As for custom resource scanning instruments. I don't see much need for it. Resource scanners are already provided, either by stock for Ore, or by other mods when they are actually used. Creating my own would just a be a duplication of efforts. That's been a suggestion for a very long time. I might get to it eventually, but it's not something that I've ever considered a priority.

SCANsat doesn't do liquid resources. If you want to setup liquid methane to be found on the surface, like the CRP has water setup, then you'll need to add it as a planetary resource (ResourceType = 0, in the resource config), and add the appropriate stock scanning module (ScannerType = 0). You can limit planetary resources to ocean biomes using a BIOME_RESOURCE config, the same way that stock ore is excluded from oceans.

Do you have a scanner on a vessel in orbit? Check the SCANsat instructions for more on how resource scanning and display works.

The surface scanner will give the accurate resource concentration for your current location as long as you are below 1000m. If you haven't scanned that biome it will say (x% avg.), but the value it shows is accurate, whereas the narrow band scanner will truly show the average value for that biome until you do the surface scan. It's kind of confusing because of the way it still says avg., but you can test it by putting both on the same vessel. There is no minimum altitude, if you are landed the resource scanners will always work. The maximum altitude might be shown in the VAB info panel, or you might have to look at the config file. I think the narrow band scanner's max altitude is 500km, the surface scanner's is 1km. Some resource scanners from other mods have a max value of 1m, which basically means it only works while landed. The narrow band scanner's map also works on the surface, it can be helpful if you have a rover and want to find the absolute best location.

There are a handful of tutorials that cover stock scanning, I made one here as part of SCANsat's documentation. It basically works as you've described, the M700 gives a sort of gross overview of resource distribution on a planet, but it's not very accurate. The narrow band scanner gives an accurate picture of the resource distribution, but only over a very limited area, and only for your current location. The only point to add is about the surface scanner; it is meant to improve the accuracy of the other scans. Before scanning a biome from the surface the other resource displays will only show you the average resource concentration for that biome. After surface scanning it will show you the real value, which can differ by quite a bit. You don't really have to scan every biome to find the best space to drill, the initial scan from the M700 should give a decent idea of where the highest concentrations are. But really, if you want more accurate resource scanning you should use SCANsat. There are several options to control how resource scanning works. At the default settings there is no need for any additional scanning for resources, it just provides better tools for how to see what you have already scanned.

This is only for offered contracts, not active contracts? You can use Decline regardless of what the CanBeDeclined flag says, CapCom has a somewhat hidden option to allow this (and the same for cancelling contracts), and I'm pretty sure that it works fine. You can always go for the brute force method, though, and just remove the contract from the list entirely. All you have to do is make sure to unregister the contract (this should stop it from doing anything), and remove it from the ContractSystem.Instance.Contracts list.

Those are more-or-less just stock contracts that ask for results from my parts. They randomly assign locations, so you juts have to be careful about which contracts you accept. You can see where the waypoints for offered contracts are in the tracking station (and you can use CapCom to accept those contracts without having to go back and forth from the mission control center to the tracking station so much), that should give you an idea of easy it is to get to multiple locations. I've never really had any desire to add Kerbal experiments. I always intended this to be a probe science pack. As in science results text? I'm pretty sure KillAshley already added those for all of the new planets.

I've noticed the same: here, here, and here are some examples. Usually the current version's downloads remain relatively consistent, but an older, usually the oldest, version starts getting a huge number of downloads every day. Of course, it might not have anything to do with Kerbal Stuff, maybe some bot is just downloading lots of copies of old versions of KSP mods for some reason. I don't really care so much about the absolute download numbers, but I do like to check the general trends from time to time.

Yes, and what's really frustrating is that KSP has lots of events that can be triggered whenever anything about the vessel changes (docking, staging, parts breaking off, ect...) so it's not at all difficult to keep an up-to-date dictionary of all the relevant parts. I've done this with [thread=120731]EVA Transfer[/thread] to avoid just that problem of constantly cycling through every part and it seems to work fine.

Because KSP is awesome, there are two values that indicate asteroid size and only one of them is always reliable, but isn't always available. When an asteroid is untracked, or hasn't been actually visited (as in, you haven't traveled to within 2.5km of it) you can reliably get the asteroid size based on its Vessel.DiscoveryInfo.Size value. This value is, I think, just an integer from 0-4, 0 is class A, 1 is class B, etc... The problem is, once a vessel docks to that asteroid it becomes Size = 2, regardless of the original asteroid size class (all regular vessels that you launch are Size = 2). To get the asteroid size at this point you have to look at the asteroid's ModuleAsteroid PartModule, then look at the last character of the prefabBaseURL field; the last character is A, B, C, etc... It's just a string, and it's persistent, so you should be able to access it while the asteroid isn't loaded. The only problem is that the asteroid doesn't have a ModuleAsteroid instance (or it isn't actually loaded) until you visit the asteroid.

It sounds like there are some duplicate experiment definitions. More than one experiment with the same name will interrupt the experiment loading process and break all subsequent experiments.

The narrow band scanner does show terrain height, it's just usually hidden behind the resource map.

And now there is one. The wiki has some basic info on how to scan and how to find a decent orbit using the orbit overlay. It also includes a fairly in-depth guide on how stock resource scanning works, how SCANsat resource scanning works, and how they differ. There is always a log file. In the main KSP folder there is the KSP.log file, and in the KSP_Data folder there is the more verbos output_log.txt file. Both are updated every time KSP starts, so make sure to get a log file from a session in which you see the problem. I keep meaning to add KIS and EVA support. You wouldn't be able to use the scanner while attached on EVA, it requires power, but I could at least add proper KIS support and the ability to toggle scanners while on EVA.

It isn't supported, but if it were I would need to see log files. They can, but it shouldn't be in the way you are describing. The actual parts themselves don't have much to do, so loading up a vessel with scanners, active or not, shouldn't make much of a difference. The part models themselves also shouldn't be much of a problem, the animations aren't terribly efficient, and some of the parts are made of way more objects than they should be, but unless you start adding 50 scanners per vessel that shouldn't really be an issue. The actual scanning mechanism is separate from the parts themselves, even for the active vessel. It only updates once per second though, so the performance impact you see from having too many scanners active at once (that is, all active scanners, on any vessel, loaded or not) manifests as a slight hiccup once every second. Except for some worst case scenarios (very low-end CPU, with hundreds of active scanners) the only time you should see this is at the highest, or next-to-highest, time warp level. If that becomes a problem you can always lower the scanning resolution in the settings menu, I usually leave it at medium, since minor gaps in scanning coverage rarely matter at max time warp.

I have two things that I think will help with some of the confusion for this, eventually. One is to put a help function into the menus, just the standard question mark button that provides description tooltips for each button. The other is a proper GitHub wiki for scanning. I really have plans for two main sections, one on scanning and the feedback that SCANsat gives (orbit lines, altitude indicators, etc...) and one on resource scanning. The resource scanning will probably have to cover stock scanning as well.

It should only be a problem if the default parameters result in two overloads using the same set of non-default parameters. Something like this: void funcOne (bool b, string s, bool c = false) { } void funcOne (bool b, string s) { } Even then I think it should compile, but the default parameter will just be pointless since it will only go to that function if you actually specify it. I'm also using VS, so maybe it's something specific to Monodevelop.

See the post above yours.

The exception from me means that something strange happened while loading some of the definitions used for my contracts. The warning itself is harmless and just means that it is skipping that particular config definition. I'm still not entirely sure why this happens, it is similar to an error that occurs when duplicate science experiment definitions are present, but I think something else is causing it. The actual problem seems to come from this line: [EXC 10:41:03.548] NullReferenceException: Object reference not set to an instance of an object QuickRevert.QuickRevert.OnGameStateLoad (.ConfigNode node) EventData`1[ConfigNode].Fire (.ConfigNode data) Game.Load () SpaceTracking.Start () It appears soon after loading the tracking station and is followed eventually by: [EXC 10:41:07.243] NullReferenceException: Object reference not set to an instance of an object SpaceTracking.DrawGUI () RenderingManager.OnGUI () Something in QuickRevert might be interrupting the Tracking Station start method (a similar error is seen while loading the space center scene too) which can cause all sorts of problems.

Both of the stock scanners can be used for resources. The M700 gives a low resolution scan for all loaded resources and the Narrow-Band scanner gives high resolution data for ore. Scanners from other mods can be used for other resources. All you really need in the Community Resource Pack. By itself it doesn't do anything, but mods like Karbonite and MKS use several of the resources provided by that. They have no function for stock KSP though.

I'm not sure that I've seen anyone use it, but you can setup the stock system to deplete resource deposits. That said, what taniwha is proposing doesn't sound at all like the stock system of infinite deposits, but a slowly regenerating deposit, which, depending on how long it takes, could be a very different thing.