DMagic

One or two more window sizes should be possible. I've already tested a third window size (each increase in window size increases the font by 2) and it seems to work OK without any other changes. Simply making the window resize button cycle through each size works well enough. I've also been experimenting with adding additional information to the contract notes: These notes specify which parts are acceptable for certain contract parameters. If anyone has suggestions for other parameters that could use some more clarification I can see about adding support for those. It only really works for stock contracts, anything from another mod can be very complicated to handle.

Some pictures of the situation would help here. Is this only happening with asteroids? Those can be a little tricky because the hammer is trying to point toward the center of the asteroid, not the surface, so bigger asteroids might allow for situations where what is visually "down" doesn't match what the hammer thinks is down. The same is not true of the surface of planets. Also make sure that you aren't running into problems with the hammer not being reusable. There is a bug in the seismic hammer and sensor pod config pods that makes them require a lab reset, change the line "rerunnable" to true in those files. And, also, there is a bit of a built in exploit where you can run the experiment from the sensor pod and it will collect data from the hammer without doing any of the actual surface contact checking. You will need to have the sensor pod on a vessel (it can't be on the same vessel as the hammer) to do something with it, or use a Kerbal to get the data, so it won't always help. The same doesn't apply for asteroids though. The sensor pod and hammer will always be on the same vessel and the experiment will always activate the hammer, regardless of which part you activate it from.

It looks like MechJeb has some changes in how it draws the landing targets on the surface. They were made 2 days ago, so any MJ version after that won't be compatible with SCANsat until I update it. To fix it for now you should be able to go into your SCANsat settings menu and deactivate MechJeb landing guidance mode, if that fails you can always just delete the SCANmechjeb.dll file from the GameData/SCANsat/Plugins folder

If it's too close then it won't work, once it starts to sink into the surface then it's too close. What did the setup look like before? Whenever I had problems with asteroids I could usually just unlock the grappling arm joint and bend in one direction or another to get to a better angle. Yes.

Go to a vessel with a SCANsat part and start a scan, or install Toolbar and add the buttons to that.

Your inclination should be from 55° to 125°, since a 180° is a retrograde equatorial orbit. An inclination of at least 55° means at least that far away from equatorial.

Have you tried any other scanners? What are your SCANsat resource settings? Some pictures of the situation and log files would help?

The 750 Ti will definitely handle KSP, I've been using for quite a while and never really encountered any significant GPU related performance problems (sometimes aero-effects on large vessels can slow things down a bit, but that's not very common); it can also handle most other games at 1080p fairly well. It is positioned a bit weird in terms of price though (or at least it was when I bought it for around $150) because it gives by far the best performance you can find for a board powered GPU. So if you want to go a step down you'll probably still get good performance in KSP at a cheaper price, but I wouldn't go down much further.

The sensor pods (and the hammer) need to be activated for the system to register them. But they are activated automatically when you use the decoupler, so no, you don't need to do anything with the pods after firing them. And if a seismic hammer is in range of a sensor pod you can use the pod to trigger the hammer to collect data. You will still get the higher science amount, the experiment will take place where the hammer is (if the pod is in a different biome, for instance), and the data will be stored in the hammer.

Yep. The update should allow for new contracts to be generated, but it won't do anything about cancelled or deleted contracts if you have already installed 14.6. For anyone coming from 14.5 there shouldn't be any problems with contracts.

Yes, but deciding through code which contract is ambiguous doesn't really work. The ISRU parameter isn't really a case where the contract needs to be made clearer, the contract just needs to be fixed. There is nothing preventing that contract from accepting either part, the differences between the size and weight between the two shouldn't really be enough to prevent that. There is no simple way of deciding when a contract might not be clear, so the simplest method is just to list everything.

Those are only unlocked parts. If you have everything unlocked, and you have a few mods that list could get very long. If nothing else, it shows you why listing the acceptable parts in the actual contract parameter name isn't feasible.

Version 14.7 is out; get it on Kerbal Stuff. It fixes the contract issue.

How about this? It's actually fairly complex. Each part request parameter (the one asking for a thermometer above) can actually request any one of multiple parts, or, any part with one of potentially several part modules. For instance, there is a station/base part request parameter that asks for a lab using the stock lab part name (Large_Crewed_Lab), but also the lab part module name (ModuleScienceLab). So if it doesn't find the part it will instead look for a part using that module; most part requests don't seem to do this (you can check the requirements in the Contracts.cfg file). Then there are the Vessel Systems Parameters, those give requests for specific Part Modules. But what you find in the config file or the save file is not the actual modules, but a type of module. FinePrint keeps a list of acceptable Part Modules for each type (which, again, can be found in the config file). So you have to grab all of the acceptable Part Modules for each type, then run through all of the loaded parts (I'm limiting the list to parts that have been purchased in the R&D center) and check if they have one of those Part Modules. It's not something I would want to run repeatedly, but I don't see any need for this to be run more than once per scene. The resulting list can be quite big, but they are contract notes, so that isn't much of an issue. The important takeaway here is that if a contract asks for a power source you just need to attach a launch clamp and drag it along to wherever you are going.

That would be great. SCANsat parts would fit in great with this pack.

The next update will have decreased ejection force and increased crash tolerance. You can change that now in the configs if you want, or just decrease the ejection force in the editor. Do you mean they have a command module? Or just that they aren't debris? There shouldn't be any need for antennas to connect them. All of the connections between the seismic pods and hammers are handled internally (the little antennas on the hammer are meant to represent the connection method between them). They should be already. There are supposed to be two methods that prevent repeat anomaly contracts, though I think both might have problems that allow for at least some repeats. There should be some amount of science to be gained from the anomaly scanner experiment (but then there are two types of scans, from the ground and above). Then there is supposed to be the internal contract hashing system that prevents repeat contracts, but I think that will still allow repeats of the same anomaly as long as there is a different number of parameters requested (so one contract with two extra science requests, and another with three extra requests). In any event, anomaly contracts are getting another overhaul in the next update and will be tied to a new contract type requiring some new experiments. I've also done a complete overhaul of contract config options, using a format similar to the stock contract config file. This will allow for much finer control over contract amounts, rewards, various modifiers, etc...

Not really, I think a lot of people just start putting both sensors on probes once they have them unlocked. If you aren't concerned with getting into an ideal scanning orbit for the hi res sensor that works, but otherwise there isn't much point in doing a lo res scan after the hi res scan. Any others bugs popping up in the new version? I'll probably update again later today to fix the contract issues if nothing comes up. If you want to fix it yourself for now just delete the :ScanSatOfficial line at the top of each contract config (it should read CONTRACT_TYPE instead of CONTRACT_TYPE:ScanSatOfficial).

Well it would probably be best for CCF support, too. Having clear delineations between contract packs seems to me like the best way to go.

I released version 0.11 of DMModuleScienceAnimateGeneric; it fixes the EVA scientist problem and another bug triggered when collecting data or resetting an experiment on EVA. Also note that in your configs you should be using the requiredPartsMessage field to tell people which parts are required. The customFailMessage (probably not the most descriptive name) is really only for telling people they are in the wrong situation, trying to run a surface experiment while in orbit, for instance.

Version 0.11 is out. It fixes the problem with detecting EVA scientists and fixes a bug with EVA data collection and experiment reset.

Version 14.6 is out; get it on Kerbal Stuff. It includes fixes for Kopernicus compatibility, a change to how the mouse-over and tooltip info for resources is displayed, some issues with power consumption and the scanning altitude indicator, and the addition of MetalOre from EPL. ChangeLog: Version 14.6 - 2016-1-15 ------------------------ - Fix Kopernicus compatibility (Thanks ThomasKerman) - Allow mouse-over info and overlay tooltips to fall back to low resolution resource data in some cases - Add a warning when stock resource scanning is disabled without having Module Manager installed - Fixed some issues affecting scanner power usage and scanning altitude indicators - Allow for included contracts to be disabled through the ScanSatOfficial Contract Type (Thanks DBT85) - Fix a bug that was preventing loading of the color config file when additional planets are installed - Add MetalOre as a SCANsat resource and MetalOre scanner modules to EPL scanner parts

There are good reasons why the internal part name is used by the contract, not the title. The internal name is unique, there is no confusion there; the title can be anything. Also, if you look at the part = ... line in the PART_REQUEST node, you can just add more part = whatever lines and the contract will then accept any of those parts.

That's true, but also nonsense in this case. If they add a part that should logically fill the same purpose as an existing part asked for by a contract, they should include the new part too. The contract in question is specifically designed to handle such cases. Also, how do you split quotes in replies? And how do you copy a quote to an existing post rather than making a new one?

Stock contracts do both. There are specific module parameters (those are the Include an Antenna, or a Docking Port requests), and there are specific part parameters, two actually. The Part Test parameters really do ask for a specific part, and those should use the title (do they?) and have a button like 5thHorseman says (Contracts Window + used to have something like this, but that got dropped when they remade the editor). The other specific part parameter, the one causing the problem, asks for a specific part, but not necessarily just one. In the Contracts.cfg file you can add whatever parts you want to the parameter (I use this to add my parts for satisfying those Include a Science Jr., or Goo Pod requests). One solution, the one that I've started using, is to take the first part in that list of acceptable parts and give its in-game title. I think that's better than a generic description (especially when parts covered by that description aren't accepted), but it's still problematic. It could lead people to think that is the only acceptable part. I guess you could list all of the acceptable parts in the contract notes.

Yeah, it makes sense that something about staging could cause an issue like this. Using FixedUpdate rather than OnFixedUpdate is something that should be done anyway, most parts don't have any need to require activation through staging. I've also updated the Wiki on how to create new language packs for the localization file (for adding translations to SCANsat's help tooltips). And for how to add new resources for SCANsat to recognize and the scanner modules to scan for them.