DMagic

That's because it's unlikely that anything else is creating a dictionary using biome names as a key without first checking if the key is already present in said dictionary. It's not something that's likely to come up very often.

That would be a side-effect of the odd decision to add three biomes to Tylo with the same name. It should be easy enough to filter out situations like that.

The science lab research module? ModuleScienceConverter is in the science lab config file. You can tweak the max amount of science the lab can hold, how much science is generated for each unit of data, how much EC is used, the scientist boost, and how long research takes. I guess one thing that would be nice to be able to tweak is the situation based multiplier for science gain. It's probably based on one of the celestial body science multipliers, I'm just not sure which one.

Were you reloading the Game Database? Either with the Alt+F12 menu or Module Manager.

I guess I forgot to add it to the space center scene. I also noticed that the SCANsat resource abundance readout module reads altitude above sea level, not above terrain when determining if the scanner is above its max altitude.

I've always figured that was a stock bug. I see it all the time too. I figure it must have something to do with the Science Data not destroyed in the right order when you board a vessel.

Version 13.1 is out; get it on GitHub. This version is really only for testing, commenting, suggesting, etc... at the moment. It features a replacement for the stock resource scanning mechanism. Settings are provided to disable to stock resource scanning and use SCANsat instead. Resource scanning functions mostly as before; the primary differences are: The M700 (clamshell) scanner functions as a low-resolution scanner for all resources All resource concentration values are rounded off to the nearest whole number for low resolutions scans [*] Narrow-band scanners are used for high resolution scans of each individual resource Module Manager configs are included to add such scanners to the required parts A new planetary overlay control window has been added to control the display of resource maps and biome maps. These maps are dependent upon SCANsat coverage and working mostly the same as stock resource overlays. A new resource settings window has also been added to control resource options and to adjust planetary overlay map quality. See the first post for more details and a complete change log.

It might screw up the toggle buttons while you're in the editor, but it shouldn't have any affect other than that. It's just tripping up when it tries to activate the resource scanners attached to those parts. It's an easy fix, too, I'll get to it whenever I update again.

FinePrint adds the waypoints for all offered and active contracts to the list when it loads in the tracking station, and only adds the waypoints for active contracts during the flight scene. The obvious solution might be to add the waypoints (if WaypointManager is loaded) in OnAccepted().

Activating waypoints when a contract is accepted is actually a tricky thing to do. When in the flight scene waypoints for inactive contracts aren't added to the WaypointManager (the FinePrint class, not this addon), so contracts with waypoints associated with them must be added manually (the spinning dots and orbit icons from specific orbit contracts are also waypoints, and must be handled in a similar manner). Before being activated waypoints are only stored along with their associated contract, not in WaypointManager.Instance.AllWaypoints(). So the only way for CapCom to get those objects is to search through the contract itself and find any stored waypoints; this is surprisingly difficult for stock contracts and very complicated for mod contracts. So technically this is something that would best be handled by stock KSP, but it would require separate waypoint lists, one for all waypoints and one for active waypoints.

Please try writing with less shorthand and more punctuation, it can be difficult to understand, but I think I get the gist of it. You still seem to be referring to Module Manager configs (searching for DMagicOrbitalScience and NEED; these are examples of MM syntax, and yes, they will always show up in the log files) and still don't seem to be understanding how those configs work. Those other addons are not needed, they aren't required. If they are installed, parts from Orbital Science can use some of the functions provided by those addons. Having or not having those addons (with some rare exceptions for crafts made with Universal Storage parts that still exist after deleting Universal Storage) does not produce errors or problems; not having those addons installed just means that Orbital Science parts won't have the related modules added to them. Whether or not Orbital Science is working at "100%" with or without these recommended addons is a subjective matter; I say that nothing else is required for it to work properly. You might say that the Universal Storage parts add unnecessary memory bloat if Universal Storage is not installed, but as I have noted repeatedly, the entire Universal Storage folder can be deleted to save space.

Well that continues to make little sense. It still seems like some underlying stock problem, but I'll try to look into it more this weekend. I'm not entirely sure what you're trying to say here. But the logs you showed are normal Module Manager behavior. If a [NEEDS] add-on is installed then MM will add the appropriate Modules to the part, otherwise it will skip it (and if you are still seeing the KAS references then you are either using an old version of Orbital Science or not following the universal installation instructions of deleting old copies first). Nothing else is required for Orbital Science to work, but as the first post suggests, there are several addons that it can interact with, or work well with. The closest thing to a requirement is Module Manager, as it's needed for generating stock contracts with Orbital Science parts, but it still works without it, so I don't include MM.

I tried it with your vessel. It exploded reliably after about 6.5 minutes (I timed it once, but every run seemed about the same) at max time warp. I also tried letting it run for 3 or 4 minutes, then saving and reloading, which seemed to reset the timer. The temperature remained pretty constant right up until the last frame, where it jumped to the value shown above.

The config file in GameData/Squad/Contracts allows you to specify the amount of contracts that can be offered and/or active for each contract type, I'm not sure if all of the stock contract types are there, but at least the FinePrint contracts are. There is also a field near the top, AverageAvailableContracts, that lets you specify the total number of contracts the system will allow you to have. Several contract addons also allow for customizing the number of contracts of each type available, and Contract Configurator has more complicated ways of handling it, too.

Not really. You can make it smaller, or get a better CPU, or rewrite SCANsat's map generating code. Otherwise there isn't much to be done about the map speed. Thanks for reminding me. I think technically this is a bug in how FinePrint and KSP handle coordinates; waypoints get stored with values like 100o S and 50o W, which gets turned into 80o S and 130o E. I've fixed this for the next version.

There are lots of errors when Contract Configurator tries to load agents, agent KKombat, or something like that. Maybe figure out where those agents are coming from and try to get rid of them.

Ok, I see it happening: But I have no idea why Orbital Science or SCANsat would cause this. Can anyone replicate this without either one?

There is something weird in the log file about CRM not finding a handful of contract types, I think the rescue missions were one of them. Maybe try deleting the config file and copying the default file from the download package. It should be able to automatically add contract types that aren't in the config file, but maybe something is going wrong there.

Hmm, how about the save file? Also, you should probably remove DDSLoader, I don't think there is any reason to keep that around anymore. Though I'm pretty sure that isn't causing this problem. When Contract Reward Modifier blocks a contract it generates a log file: Contract of type[*] over the limit; blocking contract, or something to that effect. That message doesn't show up anywhere in the log file, so CRM isn't actually blocking anything, at least not during the period covered by this log file. There is a contract completion message, new contracts are generally created whenever you complete a contract, so I would have expected to see that log message pop up there. Have you tried adding contract manually, through the Alt + F12 debug menu. CRM won't block contracts added that way, so you can check if there is some other problem by trying that.

KSP_Data/output_log.txt is the log file.

I've never had problems with CapCom and memory usage. KSP is full of memory leaks, so it could be something else or an interaction with something else, or there might be some specific contract type that has issues. But I would need more information to say more.

ModuleSCANresourceScanner inherits from the base SCANsat module, which has a public float power, which gives the amount of EC per second used by the scanner.

Do you log files? Or maybe just screenshots of what is going on? That's new, I've never had something like that happen. Can you post your log files?

Do you have the log files?

Version 12.1 is out; get it on Kerbal Stuff. This version is updated for MechJeb 2.5.1 (and should work for all subsequent dev versions until the main release is changed) and fixes a few minor bugs.