DMagic

That's a fairly common problem and KSP doesn't handle duplicated experiment definitions very well. Usually you end up not being able to use most experiments at all, it's very irritating and it's a simple thing for Squad to fix... I also went ahead and made sure every contract checks for valid experiments for the next update.

Do you have the crowd-sourced sciencedefs? I see this when it's loading science experiments. Duplicate experiment definitions will break things. Config(EXPERIMENT_DEFINITION) Squad/Resources/ScienceDefs/EXPERIMENT_DEFINITION Config(EXPERIMENT_DEFINITION) Squad/Resources/ScienceDefs_orig/EXPERIMENT_DEFINITION I'll see about verifying that the experiment exists first before generating the contract, most already do this, I suspect that's why you were only seeing a few contracts generated.

The included config file uses all of the original values.

Thanks. The Minmus problem could be related to where the anomaly is (is it still floating?), but if the on-screen message shows up it should work. Either way, anomaly contracts are getting an overhaul and should have much better detection of science collection and looser distance constraints for orbital collections. For now you can open the debug log (Alt + F2) and it will tell you how far away the anomaly is when you collect the requested science data. It should at least give you an idea of how close you are and whether or not something is going wrong. It is known. Log files will probably be needed for this issue. It sounds like it is going through the process of transmitting without actually sending anything. There are a few stock bugs with transmission, and there is no reason why one experiment would break like this while the others work fine. I'll look into it though. Log files will be needed here too (KSP/KSP_Data/Output_log.txt). The contracts problem sounds like something more serious is going wrong. Are you using the latest version? All I can say is to re-install or wait for the next version (which will break all current contracts anyway), it should be released in a few days.

What you might want to do is build a cache of the current map. If it has already been scanned then store that info and only check the remaining un-scanned regions when you update. And since ORS maps are pretty small you can just scan something like one row of pixels each update, then it will only take a few seconds to re-check the entire map.

Looks like someone didn't change their \'s and /'s when assigning path names. You always need to append ".Replace("\\", "/")" to the end of the string when assigning a path to account for differences in Unix and Windows \ / usage; Windows can use either, but I think Unix screws up when you use \. var dir = System.IO.Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location); var radii = System.IO.File.ReadAllLines(dir+"\\Assets\\Radii.cfg"); https://github.com/Cyrik/MapResourceOverlay/blob/master/Source/MapResourceOverlay/MapOverlay.cs#L75-L76

Not really, the dictionary where they are stored is private. But you can also just search for all of the ORS planetary resources loaded into the gamedatabase, that's what SCANsat does. Of course, if ORS has errors loading in these resources then you will have problems, but you would have problems anyway in that case. There's no real reason for that dictionary to be private or internal though, you can just make it public in this pull request and it might get implemented.

Do you mean to figure out if scanner A has covered lat X and long Y? Yes, if you are hard linking it is trivial to setup: https://github.com/S-C-A-N/SCANsat/blob/release/SCANsat/SCANutil.cs#L26-L56. Just plugin in the location and the scanner type (the integer values of which can be found here) and it will return true or false. If you don't want to hard-link, and it's easiest not to, it's also pretty easy. Science Alert does exactly this, those methods were actually added specifically for Science Alert and they seem to work fine. There is no SCANsat.dll in the RPM folder. If you are referring to the SCANsatRPM.dll then you have an old version of RPM. There should be no copies of SCANsatRPM.dll anywhere in your GameData folder.

I updated this with a minor bug fix. Contracts with multiple primary parameters and sub-parameters were showing the sub-parameters under every primary parameter. I'm not sure how much this affected stock contracts, but I only caught during testing of the next DMagic Orbital Science update.

Thanks for these. I believe we have a new winner in the performance department. This thing is basically running in real-time the entire test.

I think I've come up with a way to drastically simplify how the magnetic field survey contracts are monitored. My current method requires passing information back and forth between several parameters and constantly tracking their states. It will be much easier to make the two orbital parameter children of the main long-orbit parameter. The main parameter will then only have to wait until the two orbital parameters are met before starting its timer; it won't need to track any vessels. The two orbital parameters can also be improved to make it so they won't lock one vessel into being tracked. Any vessel that meets the requirements should mark the parameter as complete, you could even have one vessel meet the inclination and one meet the eccentricity requirement. I've also realized that contract overcrowding is a real problem, and one that we probably can't do anything about. So I'm going to consolidate the three regular survey contracts (orbital, ground, biological) into one contract with three different types. Then maybe allow just two of those at a time. I might also get rid of the basic collect science contracts all together, the survey contracts basically fill the same role anyway. There is a whole host of other changes that I'm working on to make the anomaly scanner and anomaly contracts use less redundant code. And I might finally get around to overhauling how the asteroid science collection works, Squad added some new GameEvents in 0.24 which make these changes much simpler. So I'm not sure when I'll actually be able to update, but it shouldn't be too long.

Do you know what your inclination is? I thought I took care of it, but it's possible that an inclination of over 90 could cause problems. Do you have other vessels in flight with that name? maybe around other planets? There is a bug where it's supposed to reset the parameter if the vessel is orbiting the wrong body, but it won't necessarily trigger the way it's written now. It should be able to handle renaming of a vessel, but if there are more than one with the same name it will probably get them mixed up.

I'm not sure if I ever posted it here, but I've mentioned it elsewhere. The GameVariable.GetContractDestinationWeight() method returns the CelestialBodyScienceParams RecoveryValue amount, the thing that determines how much science a vessel returned from a given planet is worth. The default values of which, along with all of the other ScienceParam values, can be found here: https://github.com/DMagic1/Science-Param-Loader/blob/master/ScienceParamLoader/ScienceParams.cfg

Yeah, that's a bit of a combo bug between my parts and Squad's not-so-great transmitter modules (which I think RemoteTech builds off of). If you transmit at the wrong time, like when the transmitter is closing, it will remove the data, but won't fully send it through, but it does seem to get added to the transmitter's queue, so you just have to transmit something else and it should push it through. I can probably fix this so that the data doesn't disappear from my part when this happens, but the transmitter problems are another matter.

I think you want a single transform, not an array. Transform detectorTransform = part.FindModelTransform(detector); //FindModelTransform without the s float height = mainBody.getAltitude(detectorTransform.position);

There isn't any good way to get at the existing SCANsat map, you would have to generate your own. SCANsatRPM generates a modified form of the zoom map, which is why it is has that edge-overlap and isn't necessarily centered correctly. The standard big map is generated here: https://github.com/S-C-A-N/SCANsat/blob/release/SCANsat/SCANui.cs#L1730-L1744. That's not sufficient by itself to generate a map, but something along those lines will do it. There's no particular reason why the map is not accessible, changing this, and changing the way it is generated is planned, but for now you would have to generate a new map and use that.

Just be careful not to change the "RecoveredDataValue" field too much, it's used to calculate rewards and other parameters for contracts; changing it can really screw things up. You have no idea how often I make that typo, every third time I type scientific it comes out scienctific... The Class A contract is from Fine Print, but it shouldn't affect anything here. You have to transmit the science results before the Class C contract parameters will complete. Unfortunately there isn't any good indication that the data has been collected correctly before you transmit (the anomaly contracts do a better job of this), so that's something I will have to improve.

Oh wow, I just realized what's causing this. If the window isn't open during in the spacecenter it won't catch newly added contracts. That's dumb. I can fix that pretty easily. Edit: or wait, scratch that; I still don't know why this would happen, maybe on the very first time running it won't save properly, but after that it should save everything after adding new contracts.

They should be added as soon as you accept them, you can't see this happen, because the Mission Control Center locks out any outside UI windows, but they should be there when you go back to the space center. The only thing that might prevent you from seeing them is if you are viewing the hidden contracts list (the eyeball icon toggle in the upper left). There is a standard list and a hidden list; hiding contracts with the little eye icon to the right of their title moves them into the hidden list, but all new contracts are added to the standard list, regardless of which you are looking at. Each list of contracts is saved every time you change scenes, so unless something is somehow circumventing the saving procedure, new contracts should always be view-able in the standard list. The two contract lists are persistent across all scenes, but all of the other contracts window options are saved per-scene, so it's possible to be looking at one list in the space center and another in the VAB. Thanks, the stock window bugs be to no end.

It works for the solar particle collector, but that's just a side-effect of the arbitrary data.labBoost value that I've given to all of my results. I used 0.5, but anything below 1 would have the same end-result (at least for science not moved out of my containers). The increased level of science lab boost comes from a separate value that I've hard-coded into the particle collector module (the drill is intended to have a similar, but smaller increase, but I guess I left it out), the same goes for the anomaly scanner. Everything else though, including the Universal Storage parts, uses the stock behavior for science lab boosts; an increase of 50% of the transmission rate. So by setting the lab research boost level to the data.labBoost level, all of my experiments will get a huge, unintended boost in science return by processing them in the lab. This could really throw things off for the stock replacement parts in my Universal Storage collection. There are really only two data.labBoost levels that matter; anything less than 1, and 1.5, which is the standard, after-lab-processing level.

I don't think this will actually work. Having spent an absurd amount of time trying to get my experiments working properly with science labs I've discovered that the ScienceData.labBoost field doesn't actually do what it sounds like it does. This field stores the current research level of the science data, not how much it will be increased by the science lab. The value returned by GetBoostForVesselData isn't the same thing as the labBoost value, though I think they are related. Any labBoost value less than 1 is standard data. A labBoost of 1.5 is the regular "Detailed Analysis" level. There are, however, four other levels of research that aren't implemented, you can find them in ScienceUtil.LabBoostLevels. What I think is going on here, is that there was once a much more complicated system of science lab gameplay. With different levels of research available, probably linked to how many science labs you have on your vessel, or maybe different types of science labs.

That's intentional, and if I could I would make that persist, but I don't know of any way to store lab boost amounts in the data itself, so it's only when you process data while it's still inside of the solar particle collector, or bio drill or anomaly scanner that it gets boosted this way.

Science lab interaction is one of the biggest problems with custom experiments. The most complicated part is resetting experiments, which shouldn't be an issue here, but you also need to make sure your experiment results dialog code is checking everything correctly when it decides whether or not to add the science boost option. I use this line in the dialog page setup: data.labBoost < 1 && checkLabOps() && xmitDataScalar < 1 where checkLabOps() is private bool checkLabOps() { List<ModuleScienceLab> labList = vessel.FindPartModulesImplementing<ModuleScienceLab>(); for (int i = 0; i < labList.Count; i++) { if (labList[i].IsOperational()) return true; } return false; }

You assumed [thread=64972]wrong[/thread]. The directions are intentionally vague, as pointing out exactly where an anomaly is wouldn't be appreciated by most people.

Those VAB icons aren't simple textures. As far as I know they use the actual part and make it rotate when you select it. It's easy to trigger this while in the VAB, but the readily accessible methods to do so don't work outside of the editor. There is an EditorPartIcon class, which seems to get its info from an AvailablePart instance, and a PartListTooltips, but I'm not sure how usable any of those are outside of the editor.