DMagic

Thanks, I'll add these, and probably the other KASModuleGrabs for the regular parts in the next update.

I think it might show up in the list of resources in the settings menu, but you'll never be able to actually scan for it without explicit support, which isn't included, so nothing will show up on the map. But yes, there is probably a better way of handling this; a few additions to the planetary resource configs might be a good idea. I'm thinking empty and full color fields for overlays (SCANsat or the ORSOverlay) and maybe a field to specify that it not be shown.

I've submitted another pull request for this. Primarily this is to simplify accessing resource values through reflection, allowing SCANsat to drop the ORS dependency. I suspect Cyrik's map overlay could use these methods too. Not needing to distribute another ORS dll with SCANsat should alleviate some of the version problems that ORS has.

Is this what your log actually looks like (the line repeated 10 or so times), or does it continually print this? If it repeats a certain number of times that's probably because you are registering the callback every time the scene changes, but never removing it. Put this in your OnDestroy() method. GameEvents.onCrewKilled.Remove(onCrewKilled);

That's the wrong location for the Minmus anomaly (the stated values are intentionally off by as much as 5 or 6o, but that's very far off). Previous versions have had some problems with the anomaly locations, so this isn't entirely unexpected. If your quoted text really is a quote then you're using an older version. The latest version should be better for correctly assigning the location, so you'll probably have to update to get accurate anomaly contracts. [thread=75129]Universal Storage[/thread] is installed? The latest version does have some changes that could affect my parts, but as long as you have the US_Core.cfg located in the primary US_Core folder, and everything is installed in the correct location my parts should load. Otherwise those parts are intentionally disabled, they are not designed to work without US; they won't function correctly, they will probably give errors when using them, and they will look ridiculous, kind-of floating around not attached to anything.

yourScenarioType scm = (yourScenarioType)psm.moduleRef;

There are all sorts of things going wrong here. It's giving an anomaly contract parameter in an asteroid contract, it's not returning the title correctly, and it should have failed if only two parameters were generated. Are any of the other contracts broken like this? Were you using v.0.8.4 before this? I can only guess that the contracts didn't get reset like they were supposed to (there is a problem with the contract reset function, so this isn't unexpected) and it's confusing old contracts for new ones. You can regenerate the contracts in the Alt+F12 menu under the Contracts tab, but that will also reset all stock and mod contracts. You could also just decline all of the currently offered contracts from my mod and cancel any currently active ones (cancelling contracts will make you pay the failure cost, but declining them won't).

Does this mean someone finally looked up benzoylmethylecgonine? But really this was all confirmed by first-hand analysis a long time ago (scroll down to the gif near the end of the post). Yeah, KAS should work fine for moving parts around without affecting any stored science data. There is a link in the first post that adds the KAS grabbable module to most of my parts, though I probably should just be adding this myself to everything. It's possible, sometimes the Crowd-Sourced science logs gets screwed up and causes conflicts that break science experiments. It's hard to say without knowing more.

ProtoVessel => ProtoPartSnapshot => ProtoPartModuleSnapshot => ConfigNode = ProtoPartModuleSnapshot.moduleValues => ConfigNode.GetValue("nameOfYourField")

OnVesselRecoveryRequested happens during the flight scene when you push the green recovery button. OnVesselRecovered happens after the R&D center does all of its processing on the vessel's science and part values. OnVesselRecoveryProcessing is what you want. The problem is that this is also when the R&D center does its thing (the crew stuff might happen elsewhere, but I'm pretty sure the MissionRecoveryDialog must pass through the R&D center at some point); I'm not sure that there is any way to force your code to run before the R&D center's code, so it will be tricky to get your stuff to be counted in the mission recovery dialog. You can, of course, reset the frozen Kerbals' status manually so that they will be available for the next mission, but they probably won't show up in the dialog, and you would have to manually add in rep for successfully recovering them (you might also need to watch out for losing rep when you set your Kerbals to "dead"). Edit: The crew recovery stuff probably happens in the Reputation scenario module, which is also where you can manually add in more rep.

So that would be a 3600*1800 map? You can store the values as single precision floats to cut that number in half; there's no real need for doubles since the range of values isn't really that big. But even still, this is for one map, 25MB or 50MB? And there are 15 planets with terrain, so that's 375MB or 750MB of disk space, just to speed up the slope map a little (I'm still not convinced that a slope map at this detail is all that much more useful than a height map). It wouldn't, presumably, take up that much space in RAM, you would only have to load in one at a time and you could just reuse the same array, but still, that's kind-of crazy.

Well, you can calculate the height again for the slope, but reusing the existing height map removes the need for doing those slow pqsController calculations over again. This whole, slow-terrain-height-calculation problem is SCANsat's biggest issue, I think, so I'm very open to ideas about how to get around it. You can calculate the data offline, but then you're right back to ISAMapSat's problem of storing big texture files that take up huge amounts of RAM. Maybe there's a better way than using textures to handle it though.

Any ideas on how to actually calculate slope? This is a tough one, since there is no "slope" field for a given location, all you can do is look at a location and look at the surrounding area. So your slope map is only as good as your height map. And to get a good, granular slope map means having a very high resolution height map, which kills performance (at least if you're trying to do it for the entire planet). This is why I think SCANsat's slope map is fairly useless, you have to zoom in very far to get any realistic idea of how flat an area is. I was thinking that adding the slope to the tooltips might be easier, just look at the terrain elevation for the exact point where the mouse cursor is and compare it to several points very close by, then you're only dealing with a dozen or so terrain elevation calculations.

It seems like the mod contract glut is a problem that's not likely to go away. There are a number of ways to generate fewer contracts of each type. One is to limit the number of each type as has been discussed before. Another is limiting the acceptable prestige rating as shown above (it would also be nice if the stock "explore" contracts didn't permanently take up a 3 star slot...). I've also been trying to delay the point when my contracts are given. Anyone playing a long career game will surely have plenty of opportunities to use any given contract type, so there's no reason to spam them with 5 or 6 DMagic contracts as soon as they complete the first launch. The base Contract class has a some methods to determine which planets you've been to, but they aren't very granular. GetBodies_Reached just returns all of the CelestialBodies you've visited; entering their SOI is enough to mark them as "reached". If you want to get more specific you can use something like: public override bool MeetRequirements() { return ProgressTracking.Instance.NodeComplete(new string[] { "Minmus", "ReturnFromOrbit" }); } This example is in the MeetRequirements() method, but I've also been using them in Generate() too. This is the example from my asteroid contracts, you have to enter orbit around Minmus and return to Kerbin's surface before they will be generated (I figure this is a good demonstration of the ability to rendezvous with a relatively small target in a different orbit). You can get really specific about the requirements for any contract type using these progressTracking nodes. You can use something like "Jool", "FlyBy" if you want to give contracts for Jool's moons. I'm not sure what happens when other addons change the planet names, there might be a better way of specifying that (maybe use the flightglobals index to find the planet), but I think this is a good way to slow down contract generation, or just be more specific about what requirements you want before you start offering a contract.

Yeah, comments can be put on separate lines or at the end of lines in config nodes. The config node system ignores all of that stuff when using HasValue or GetValue.

I think this is at least partly a construction problem. I don't know why it seems to happen more with the big SRBs, but changing you setup just a little seems to fix it. I've seen this happen before, if I fire the sepratrons before the SRBs run out of fuel they will separate fine, but if I wait until they are out of fuel disaster follows. I think this is because the rockets get pushed up and away while the SRBs are still firing, but if they aren't the sepratrons damage each other and break off. Pushing the sepratrons closer together and rotating them down a little seemed to fix it.

Any persistent KSPFields handle saving and loading on their own, and they run before OnSave and OnLoad.

I'm not sure that you can use doubles in a KSPField, try it with a float.

I updated this to version 1.2. There were a few bugs with how parameter rewards were shown after they were completed. For some reason the reward amounts are set to zero upon completion, maybe so they can't be rewarded more than once, so I made sure to store those values so they can continue to be shown in the fully expanded mode. I also fixed a bug introduced in the last update that prevented the altitude range contracts from being sorted correctly. The root contract notes can now be displayed. These aren't used as much as the parameter notes, except by DMagic Orbital Science. Previously they were only able to be viewed in the mission control center, the stock contract window didn't show them either. I also made new note display and hide icons, they match the note text a bit better. Support for more part-specific contracts is included. It should work with Fine Print after its next update, and it works with all DMagic Orbital Science contracts using the latest version of that addon.

Update to version 0.8.5: [Defunct link removed by a moderator] There are many updates to the contracts. Any active contracts from the last version will be removed (without any contract penalties), stock contracts and contracts from other mods will not be affected. The basic collect a specific science result contract has been removed, it's function is essentially filled by the survey contracts. The three survey type contracts (orbital, surface, biological) have been consolidated into one that can give any of the three types. These have been altered too. The orbital surveys never ask for specific biomes, but they do require that the science returned be worth something. Ground surveys ask for biomes if applicable and all experiments will be for the same biome. So you might get a contract to study the Mun's surface with all of the parameters asking for results from the canyons, or some other biome; if the experiment isn't biome sensitive then it will work anywhere. These also require that the science returned be worth something. The biological surveys are a mix of the two; any surface experiments will ask for the same biome, but orbital experiments won't, and the science returned doesn't have to be worth anything. The asteroid surveys are largely unchanged, but the method used to detect successful collection of data is improved, and will display an on-screen message. There are also contract notes making it explicit that only DMagic parts can be used for these contracts, i.e. only the Universal Storage versions of the mystery goo or the accelerometer can be used to collect asteroid science. Anomaly contracts also have an improved method for detection of data collection and their distance constraints have been significantly loosened. It should be much easier to collect data from orbit for these contracts. The magnetic survey contracts have a much improved method for tracking suitable vessels around the target planet. Multiple vessels can be used to carry out the contract, and as long as the both of the orbital parameters are satisfied at all times you can switch out old vessels with new ones, dock, undock, use decouplers, etc... There has also been a total overhaul of how the asteroid science collection works (independent of the asteroid contracts), most of which was discussed way back here. Some new GameEvents added in 0.24 have made this much more feasible. There are two basic aspects to these changes. One is that asteroids are assigned a spectral type randomly when they are first loaded (if anyone comes up with a better method of doing this, that could be read easily by other mods it would be great). Science results are now given based on these spectral types, there are nine, rather than the asteroid size class. This makes much more sense for most of the science experiments I have, and the science defs have been updated to reflect this change. The other change is that there is now a much more robust method for tracking asteroid science results and allowing for repeated experiments from different asteroids of the same spectral type. Now you can collect multiple results from different asteroids of the same type and their worth will gradually diminish. Everything is updated whenever science results are transmitted or recovered so it is mostly transparent to the user. There have been a few other changes, mostly non-user end stuff. The anomaly code has all been consolidated to remove lots of duplicate methods. Check the first post for the full change log.

I'm not sure you should be using a constructor for a scenario module. KSP will create a list of all the protoscenariomodules in Game. If you need an instance of your scenario module you can just pull it out of that. Edit: Actually you shouldn't use constructors with any monobehaviour: http://docs.unity3d.com/ScriptReference/MonoBehaviour.Awake.html. They should only started with KSP attributes or by manually adding with gameObject.AddComponent.

These are from the vessel.landedAt string. If that isn't empty they will override any standard biome. I don't know if you can change, add, or remove these, though the string is public, so maybe you can just change it and see what happens.

It would appear that you are running out of memory. I don't know why the SCANsatKethane entries are showing up at the end of the logs, you don't have Kethane installed so SCANsatKethane is behaving as it should and is simply not being loaded. The same entries are present about TweakScale, so I'm not sure that they mean anything. Just above that though, this shows up: KSP(22420,0xa03ac1a8) malloc: *** mach_vm_map(size=25694208) failed (error code=3) *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug DynamicHeapAllocator out of memory - Could not get memory for large allocationCould not allocate memory: System out of memory! Trying to allocate: 25165888B with 32 alignment. MemoryLabel: Texture Allocation happend at: Line:411 in With this version of SCANsat, v6.1, you have to be using a vessel with an activated SCANsat part for background scanning to work. It doesn't work while in the Space center / tracking station. That's been fixed in the dev version though and will be updated here soon. Make sure you are using the latest version of Karbonite and that your ORS/Plugins folder has ORS v1.2 and nothing else. Reasons... Ideal altitude is anything above what's labeled "ideal" up to the max altitude. Many of the scanners could probably use some rethinking. Unfortunately, no, but it's a good idea and has been suggested before.

You seem to be taking a far more literal and legalistic approach to the use of licenses in KSP mods than most people here do. I haven't once seen anyone actually claim that they will take legal action against someone violating the terms of their license. The most that ever happens is that a mod will be taken off of the forums for license violations. And is this really so hard to understand? That people might have a variety of reasons for choosing less-restrictive licenses, none of which necessarily have to do with allowing anyone to alter or distribute their creation, with or without their permission or approval. I for one, am glad that very few people take your approach to licensing. If everyone chose closed licenses and refused all requests to alter their addons this would be a far sadder place.

If ORS v1.1 is left in the SCANsat directory it should work ok. If it doesn't you'll have to wait for the update.