DMagic

That all sounds correct, and 9.3% is a pretty high concentration, around 15% is the max I think. There is a relatively simple method for doing this yourself. When I get a chance I'll post the instructions. Edit: Basically you just need to make sure SCANsat recognizes the resource then add a scanner module; this is something I should add to the SCANsat wiki. Open the SCANresource.cfg file in the SCANsat/Resources folder. Add a new SCANSAT_SENSOR node for the desired resource using the next available value. Resources are identified using an integer enum, so you just need to go up by powers of 2. I think 2^20 is the next available value that isn't used internally. After adding that you need to add a scanner module to whatever part you want to use. Look in the SCANsat_Resource_Scanner.cfg in the SCANsat/MM_Parts folder for reference. Just make sure to use the value you set in the other file. There are two SCANsat resource modules, one for the scanner itself, and the other for displaying the value in the right-click menu. You can customize the colors and cutoff values in-game using the color management window. Also note that you can alter an existing scanner module by changing the sensorType field. Just add all of the desired types together (the MKS scanner already does this), and the one module will work for all of those resources.

Ugg... This looks like it might be a serious compatibility problem with Kopernicus. I know that Kopernicus has some method of loading planets on demand, that may be interfering with how SCANsat draws maps at the KSC/Tracking Station and how it generates its terrain cache for the small maps and planetary overlay maps. I may have to just disable some of those features when Kopernicus is installed...

There is now: DropBox There is a new field: exclusiveExternalDeploy Set that to true and it should only allow for EVA deploy.

@AlbertKermin, I see the problem now, it's am issue with the new stock EVA deploy method. Try this version to see if it works properly: DropBox It also allows for custom failure messages when parts or modules are required. Use the fields: requiredPartsMessage = Requires such and such parts or requiredModulesMessage = Requires this and that part modules The customFailMessage field is used when you aren't in the right situation, like when you try to use the stock seismometer in orbit. Let me know if there is anything else before you release and I'll put out a proper release.

There isn't a dev build currently. I've used dev builds in the past when I've had some major project, something that has been spread across multiple versions. I don't have anything like that planned for now, so I've just been making regular releases. It's possible that this has something to do with Kopernicus. Does it happen with all planets? What about different map types?

Yeah, there are a few methods used to check if it's underwater. My understanding is that any area below sea level will have water on an ocean planet, but I've never really checked. I just need to get in-game and check which, if any, of the methods I'm using will work for in-land bodies of water.

I'll have to test it out to see where it's failing and maybe figure out why.

Does it work in the regular oceans? I can't think of why an inland water body would be any different, but I don't think I ever tested it.

Hmm. Try jumping and see what happens. Does it work if it's mounted on the plane while you're on the seafloor? It should. What happens if you drop it on ground and then try to use it? It's possible that either KIS or being an EVA Kerbal interferes with the underwater check.

That's odd. Both buttons produce science results? Does it only happen when connected to other parts? It may be possible that both this module and the base ModuleScienceExperiment module could be producing the button, though I've never seen that happen before. I'll try loading up a part with a similar config when I get a chance.

All of the maps make things slow? Or just the big map? The small map, the one that constantly updates, shouldn't really affect performance. But the big map has a major impact while the map is building. There are several ways to reduce the impact. First, you can make the map smaller, that will have the biggest impact. Once you pick a size, stick with it, changing the size makes the map and its cache rebuild. Next, when you keep the map on the same planet subsequent map builds will be much faster, this is because the data for that planet has been cached (caching all of the planets is not feasible). Otherwise there isn't much that can be done. A recent version had a major performance boost, but that was a one time fix, and the map build process is just inherently slow. Yes, the lo res altimetry scanner is grey scale and of limited resolution; the data looks blocky compared to the hi res maps (check the first part for some examples).

I was thinking more in terms of the license for tech tree definitions, Module Manger balancing changes, etc... that kind of thing. I agree that things should be easily configurable where possible, and that there should be some basic balancing guidelines, but it seems like deciding on one tech tree and building off of that would be a requirement. If someone is going to decide how much a part costs and where it comes in terms of career progression then you need to know how the tech tree is arranged. I like the ETT, at least in principle, I haven't looked at it too closely. But the idea of having different branches is good. I agree with this and the rest of the comment in general. Though it is just as easily possible to alter stock contract rewards. And I'm fairly sure that you can change the availability of parts for different part test situations. So if you want you can change which parts are available for launch pad tests, for instance. By families do you mean parts of related types, rover-part types, base-type parts, etc... Is the idea to have a several required mods, or just to provide guidelines for mods. If it's the former then nailing down the requirements would be a good idea.

Perform what physics? The part modelling physics? No. This is a system for syncing thread-safe operations (most commonly math heavy operations) to the Unity update cycles.

Whoops. It looks like I forgot to set those parts as rerunnable. For now you can just edit the two cfg files in the RoverScience/Seismic folder; set the line "Rerunnable" to True.

I'll make sure to fix these for the next release; most of my parts will suffer from this issue to some degree. Does anyone know how to access the part scale in code while using MODEL node scaling. When using rescaleFactor I can just use part.rescaleFactor, does anyone know if part.scaleFactor will work the same? Awesome, I added a link in the recommended mods section on the first post.

There shouldn't be. Are there two modules being assigned to that part somehow, maybe through a MM config? Does the part have an animation, and is the deploy event given the same name? You can post the config file if you are still having problems and I'll look through it.

Hmm, I haven't tested the BTDT for a while (nothing should have been changed since I think version 10), I'll look into it when I get a chance. That's odd. The planet names shouldn't matter, they are really just there for reference, it's the body index that counts, but neither seems to be causing the problem. It could be related to write privileges, but then it seems to have no problem loading the language file. I'll look into it. Thanks, it's one of the few times where something like it fits so seamlessly into the science system.

This doesn't use CC and that is expected behavior. Magnetic field survey contracts are given once per celestial body, per difficulty. So Kerbin system bodies will have three possible offers; one star contracts aren't offered outside of the Kerbin system, so the rest will only have two offers, and the sun only offer a three star contract (I think).

Version 14.5 is out; get it on Kerbal Stuff. This version is mostly minor bug fixes and tweaks. Changes: Version 14.5 - 2015-12-22 ------------------------ - Misc and Bug Fixes - Fix some .csv export related issues - Allow for disabling the stock resource scan threshold - Fix ocean depth indicator - Fix multi spectral sensor normal map - Fix some potential issues when using multiple different sensors of the same type - Add new survey waypoints as they are generated - Fix for repeat contracts *Requires Contract Configurator 1.9.1

This isn't designed for monitoring active contracts. Use Contract Window +.

It sounds like you're going for something like Realism Overhaul without the realism parts. That's a good idea, though I would skip any requirements for ground vehicles and boats for the progression. While I'm sure there is some small niche of players that just love tooling around in rovers and boats on Kerbin, I think I'm safe in assuming that most people play KSP to go into space, where there are plenty of more exciting possibilities for ground vehicles. If this is going to be a community effort then I would mandate that everything be released under open (and compatible) licenses. While there are legitimate reasons for choosing more restrictive licenses it seems like just asking for trouble to do so for a project like this. Since people tend to drop in and out of development all of the time this seems like the only way to make this feasible.

Also note that coroutines require that you be using a Unity MonoBehaviour, or something that inherits from it.

Sounds like a RemoteTech problem.

Well that's really the problem. This kind of thing requires a lot of time and "manager" is not something that is looked upon highly here when proposing a collaboration of this type (I do like the idea of it though). Other modders aren't really the best option for participating either, since (if they are anything like me) pretty much all of their KSP-related time is swallowed up by their own work.

This sounds like something that might be suited to FireSpitter. I'm not really sure how the configs for that module works, but I think it should let you handle multiple animations on a single part, and it's functions are much more generic, not tied up with science experiments like this module. But you aren't really leaving them blank. There are lots of sample entries, quotations and asterisks in there. I don't really know what KSP's config node parser will do with those, but I assume it's nothing good. If you don't have an animation then you should remove those fields entirely and set the experimentAnimation field to false. Any other field that you don't want to change should either be left at the default entry (which might not be what is in the reference config) or deleted (in which case the default entry, if any, will be filled in internally).