DMagic

Aside from changing the waypoints to something from stock KSP (like flags, which doesn't seem like a good idea) this would require changes from SCANsat, not FinePrint.

That should fix it, it won't affect anything other than contract durations. I'm guessing that the problem has something to do with using Earth days/years. The magnetic field contracts use the length of the contract parameter to calculate the deadline. That amount of time is stored in seconds, but converted to days (using whichever time system you have chosen) to display the length of time required in orbit, and to calculate the deadline. I think I need to always convert them to Kerbin days for calculating the deadline, otherwise it ends up 1/4th the amount of time it is supposed to be. Other contracts aren't handled this way and won't have this problem.

This is a very brief outline of how to scan for resources using SCANsat. At some point I'll add something better here and to the first post. The first thing to check out is RoverDude's video from the Karbonite thread (at about the 8min mark), which goes over the process very well. Required Components SCANsat, obviously ORSX, included in USI addons *Note that standard ORS does not work ORSX Planetary Resource Definitions, included in USI addons in the [thread=91998]Community Resource Pack[/thread] Module Manager and MM configs to add the SCANsat module to the appropriate scanner parts, included in USI addons Resource Scanning With all of these components you will end up with SCANsat modules on the ORSX resource scanner parts (the Karbonite Detection Array, and the Planetary Survey Camera). These scanners are activated and used in the same manner as the standard SCANsat sensors. The primary difference is that there is no indicator on the small map for scanning altitude (the blinking orange/green lights). Instead, all SCANsat sensors display an altitude indicator in their right-click context menu. Scanning altitude is also indicated in the VAB for each part. Resource scanning data will be saved in the same way as standard SCANsat data is. Standard SCANsat scanners (RADAR, SAR, Multispec) are not used for resource scanning in any way, unless you've specifically modified them to do so. * Note that the "Display Karbonite Hotspots" button is a standard ORSX function, and has nothing to do with SCANsat scanning. Resource Display The first post has some examples of how to activate and select which resource to display. Resources are only displayed on the big map. For now all resource selection is handled through the settings menu. For a preview of a less-terrible method, check out the KSC map in the [thread=96859]dev version[/thread]. Kethane Resources The Kethane interface isn't functional right now. But the process will basically work the same way. Module Manager configs (MM isn't included with SCANsat or Kethane, so you'll need to have that) add SCANsat modules to the Kethane scanners. These can be used directly in the same manner as the ORSX scanners; they work in the background and save their scanning data. It is also possible to take scanning data already collected using standard Kethane scanners and incorporate those into SCANsat. This is done automatically every time you load or switch to Kethane resources. Data can also be transferred from SCANsat, back to Kethane using a button in the settings menu. It is a little finicky about updating the Kethane grid (it usually requires a reload, or changing scenes), but that obviously isn't a problem right now.

SCANsatRPM is integrated into the main SCANsat.dll. If you have any old copies of it lying around you should get rid of them. SCANsat doesn't interact with ORS or ORS resources in any way. That said, if you have the community resource pack and the [thread=94876]additional pack[/thread] for use with KSPI resources, you can still get maps for the planetary resources from Interstellar. Definitions and links to the KSPI maps are included in that, the required MM config to add SCANsat modules to the KSPI scanner part is also included in that.

The anomaly scanner is not a repeatable experiment, it must be reset at a science lab or you need an unused one. It also has a very short range (your current location is in range, indicated by the green lights) and gives two distinct results, landed and flying above (whether or not there is an atmosphere doesn't matter), so you may have collected results while still in flight and transmitted those, or maybe from another anomaly, though they generally aren't very close together. This is something that should probably be changed for the contracts, I have repeatedly forgotten about which result is needed while testing these contracts myself. Any results from the anomaly scanner should show up in the R&D archives for each planet, so you can check there to see if you have results returned.

Are you using this: [thread=80220]http://forum.kerbalspaceprogram.com/threads/80220[/thread], or did you change the deadline setting in the included config file? Other than that this shouldn't happen; contracts for the Mun should be at least around 3x the length of the parameter. It also shouldn't matter if you are using Kerbal or regular time.

I think using the name falls under a trademark issue, ie Firefox is released under some kind of GPL derivative, but the name itself can't be used unless certain conditions are met. While it seems unlikely that anyone is going to get a legally binding trademark for their addon, it would probably be a good idea for anyone releasing an alternate version of something that is still under active development to use a different name. If nothing else it would at least prevent confusion. That wouldn't be a bad idea for one of the forum addon rules.

It's there. If anyone ever wants to know the exact location of an anomaly just look it up on KerbalMaps.

For adding parts to the new nodes? Someone is going to have to assign Part A to Node X for everything that supports this, presumably that would be the addon owner, or someone making an MM config set for someone else's addon. I don't see any way to automate this process, nor would I think that was a good idea if it were possible.

Chapter 1: Radio and Plasma Wave Science Chapter 2: Magnetometer Chapter 3: Telescopes and Imaging Systems Chapter 4: Laser Ablation Chapter 5: Core Drill and Biological Experiments Chapter 6: Neutron Reflections and Subsurface Water Chapter 7: X-Ray Diffraction and Surface Composition Next up in the science instrument explainer series is laser ablation spectroscopy, technically known as laser induced breakdown spectroscopy (LIBS). The most well-known example of this type of instrument is Curiosity's ChemCam module, a laser ablation and remote imaging spectrometer mounted at the top of its upper mast. The principal component here is a high power, low duration laser that can be fired rapidly and repeatedly at a given target. The laser light strikes the surface of the target, vaporizing a small amount of it. This now-vaporized material is excited by the laser, and when it returns to its ground state it emits photons at frequencies characteristic of its chemical makeup. By matching the resulting signals to that of known samples the chemical composition of the target can be determined. The Laser To be effective a very high power laser is needed. Curiosity's has an output of over 10MW/mm2, which is incredibly high, but it only fires pulses of around 5 nanoseconds (five billionths of a second) to a target less than 1mm around, so the total energy delivered is more like 30mJ per pulse. This very focused approach means that anything outside of the target area will remain unaffected. The laser itself (a diode-pumped, rubidium titanium phosphate Pockels cell Q-switched, neodymium-doped potassium-gadolinium tungstate (Nd:KGW) linear oscillator, if you must know) is a solid state design, able to operate under a wide range of temperatures, withstand the trip to, and the hostile environment of, Mars, and to be very lightweight, about 500g. Because this instrument can be used repeatedly, and at relatively long ranges, many more samples can be analyzed than could be using the older techniques of other Mars rovers. These used physical drills to study samples, requiring close contact and sometimes multiple days to analyze one sample. The laser is also not susceptible to the same type of physical wear-and-tear of those instruments. Electron Excitation When the laser strikes the target a small amount of it is atomized in the process known as laser ablation. The initial portion of the blast is sufficient to ablate a small amount of the surface, usually only a few nanograms, or even picograms, making this essentially a non-destructive analytical technique (repeated blasts can cause more damage though). After a few nanoseconds the trailing end of the laser blast excites the resulting plasma, creating a kind of self-propagating reaction where electrons are stripped off of their atoms and react with other atoms, causing further electron excitation. This is a thermal image of the expanding plasma plume shortly after the laser blast. For a short period while the plasma plume cools a soup of photons are released as the electrons fall back to less energetic states, little useable signal can be collected during this period. After about 1 microsecond the electrons begin to fall back to their ground states, emitting discrete bands of photons. The frequency of these photons can be correlated with the composition of the atoms in the plasma. By matching up the emission lines produced by known samples the composition of the experimental sample can be determined. By recording these emissions with a spectrometer (see chapter 3), which is built into Curiosity's ChemCam module, a nearly complete analysis of the composition of any sample can be made. This is the spectrograph of Curiosity's first target. The photon counts are arranged by wavelength and labelled according to their corresponding source element. The ability to rapidly fire the laser allows for multiple samples to be recorded in a very short time. It also allows for interior samples to be collected by drilling down through the outer few mm of the surface (or more if it is merely loose dust covering the surface). LIBS Science The ability to quickly analyze the composition of most any sample (it can be used for liquids too) obviously makes for a very powerful tool. Rocks can be studied to determine their origin. Are they volcanic, what might they tell us about the interior of the planet, were they formed in the presence of water, do they contain any unexpected compounds, etc…? Meteorite fragments also make for excellent targets. Their composition could tell us about the source of the meteor, or whether it differs in some way from meteorites found on Earth. A LIBS instrument can also serve as a useful way to select interesting targets for further analysis. Curiosity's Sample Analysis at Mars (SAM) instrument (Curiosity's largest) can be used for a more accurate chemical analysis as well as for determining isotopic abundance. This can give clues about the age and possibly origin of a rock or meteorite. Or the exact mineral composition (rather than a list of chemical elements and their abundance provided by LIBS) of a sample can be determined through X-ray diffraction using Curiosity's CheMin instrument. In the next segment we'll look more closely at the biodrill and its inspirations.

I like this idea for earlier branches in the tree. Later branches could obviously be bigger and more complex since they would likely be designed with one or two specific addons in mind. But having some more variety early in the tree would be nice for some of the more optional type of parts (the resource scanners you mentioned, additional science parts, command pods, etc...); things that might not necessarily make sense at the end of the tree, but that might make the early nodes too crowded.

Release candidate 2 is up on GitHub. The primary change is the addition of a color/map management window. You can select from a number of color palettes (including the standard SCANsat colors) for your maps. There are also a number of options for the maps. You can adjust the minimum and maximum height range for each planet, this is used to for the terrain height-to-color algorithm. You can also clamp the first two colors of any palette to a given height, this is useful for ocean planets for making a clear distinction between the water and land. You can also reverse the color order for any palette and use a discrete stepping algorithm, rather than the smooth color scale used by default. Each planet has also been given default terrain height range and color palettes. This should prevent problems for planets like Bop or the Mun where the terrain is almost entirely in the highest ranges of the color scheme. There have been a number of back-end changes to the scenario module and data storage code. These should make SCANsat more tolerant of loading errors, as well as reduce log spam when something else interrupts the loading process. Let me know if anyone comes across any bugs.

Try v7rc5 with Kethane 0.9. I'm not sure about other versions.

Does this exception come up every time Science Library loads? It might be that Awake() is not the right place for it to be checking the FlightGlobals.Bodies list; it is probably too soon in the loading process, so the FlightGlobals instance hasn't finished, or maybe even started, loading yet. The Unity docs go over the MonoBehaviour load order. It might also be that this happens because the Bodies list isn't loaded in that particular scene, the VAB or SPH for instance.

Need more info; make sure US is installed in the right location, specifically the empty US science bay. You can always return it to complete the parameter. Otherwise there could be problems caused by Squad not using all of the celestial body science multipliers. For most planets the difference is small, but for the sun the multipliers are 11 for low orbit and 4 for high orbit. By not using the high orbit multipliers you get really high science from the sun; this difference might be confusing the parameter completion calculations. It's also possible that RemoteTech is the issue, but as long as the data is successfully being transmitted I don't think it should be a problem. It doesn't. See the recommended mod list on the first post; check for Custom Biomes.

Karbonite comes with Module Manager, which is necessary to add the SCANsat module to Kethane scanners. Kethane integration is not functional currently. There is no incompatibility, Tarsier simply doesn't work, and it fails in a catastrophic way. By interrupting the scenario module loading process it breaks every subsequent scenario module. This will destroy any saved SCANsat data (along with saved data from other addons, such as Kethane scans, life support data, or anything else that uses scenario modules). The only real solution is not to use Tarsier. For some reason MKS no longer comes with the requisite SCANsat resource scanners. You have to get Karbonite if you want to scan for MKS resources. Need more info.

I'm trying to get in touch with Sethnizzle to see about taking over these parts. I know that license is permissive, but I would rather get explicit permission to use and modify them. As it stands now, some of the textures for these parts are way too big, taking up quite a lot of RAM for such a small number of parts. Getting access to the source files would greatly facilitate fixing this, rather than relying on the .mu importer.

That would be Squad's poor handling of deleting addons with custom Agencies. See my instructions on handling this; alternatively you could just copy the Agencies folder from Tarsier's package and leave it in your GameData folder (it might need to be in the exact folder location it was before, just without the other Tarsier files) and it should work.

Do you have problems with other addons too? It looks like Tarsier is running into some errors when loading its scenario module, this seems to be preventing the SCANsat scenario module from being loaded (and presumably any other scenario module loaded after Tarsier) which breaks pretty much everything. I actually need to fix the SCANsat part modules so that they don't completely freak out when this happens. They should instead print out a single log error then shutdown, the same for the toolbar interface. This is what happens whenever a scene loads. [EXC 21:52:44.394] NullReferenceException: Object reference not set to an instance of an object TarsierSpaceTech.TSTProgressTracker.OnLoad (.ConfigNode node) ScenarioModule.Load (.ConfigNode node) ScenarioRunner.AddModule (.ConfigNode node) ProtoScenarioModule.Load (.ScenarioRunner host) ScenarioRunner+.MoveNext () Try getting rid of Tarsier and seeing what happens. Then make sure that is up-to-date and there aren't any known issues.

For ORSX resources you have to actually scan the surface with a SCANsat scanner. I was under the impression that MKS came with the Module Manager configs to allow for this, but I'm not sure that's true anymore. I think all of them got moved to the Karbonite scanner, though I think the plan is to change it back again. So the four standard MKS resources should be scanned with one part and Karbonite can be scanned with another. I guess you'll have to download Karbonite or wait until MKS updates. Otherwise I don't think there is any problem, everything seems to working fine according to the logs. I should make a more detailed tutorial about this at some point. For ORSX, as I said above, you must use special SCANsat resource scanners, most of which are provided by the addons that actually use them. For Kethane you can use SCANsat scanners (the MM configs are provided here), this allows for background scanning, but it isn't actually necessary. The Kethane scanning data is taken directly from Kethane's database, so you can scan something with a regular Kethane scanner and it will all show up on SCANsat maps. You can also do the process in reverse, scan everything with SCANsat scanners then update Kethane's database (though getting the Kethane grid to update usually requires reloading). There isn't technically anything wrong with SCANsat's Kethane integration, there is just something weird happening with the Geodesic Grid assembly that prevents SCANsat from accessing some of the methods it needs. I can build the GeodesicGrid.dll myself and it works fine, so we will just have to wait until Kethane updates before it works again. I think I see why the maps are getting saved to that location, but that's definitely not where they should be. I'll see about putting them back in the SCANsat/PluginData folder, or maybe making a better name for it like SCANsat/SavedMaps. Need more info; log files. Yep, it's about number 30 on the list of things to do, but I'll get there eventually.

Finally stickied after almost a year-and-a-half Thanks for the results xtoro. I should do a quick comparison to 0.24, but I don't think there is much difference in performance for this update.

All KSPFields are public and have methods for altering them, so you just need to access the Part that your PartModule is attached to or some other PartModule attached to the same Part. /* From within your part module */ //Set the cost field to 5000 part.Fields.SetValue("cost", 5000); //Set the other modules bar value to 10 PartModule pm = part.FindModulesImplementing<other_module>(); other_module.Fields.SetValue("bar", 10); I've never actually tried to do this before, but it seems like it should work. There are also GetValue and ReadValue methods, and overloads to specify the type the field is using. Accessing the other PartModule assumes that you actually have access to its Type, if it's from some other mod then you'll have to use some other method to assign the PartModule before you can get to its fields.

Resource overlays only appear on the big map, which I don't see in your picture. If there is an issue, this line from Interstellar is repeated endlessly, taking up roughly half of the log file: rd _Emissive: WarpPlugin/Parts/Electrical/RadialHeatRadiator/d_glow (UnityEngine.Texture2D) Need more info. Probably, I haven't tried it. Something for the BTDT sensor would be nice, I'll think about what it should be.

All of the orbit information (including the OrbitDriver) in the Vessel class is still available when a vessel is not loaded. I'm pretty sure it's all loaded through the ProtoVessel instance, not the Vessel load method, but you can grab the instance of the vessel you're looking for (FlightGlobals.Vessels returns all of them) and get most of the non-part-relevant information. All of that info updates regularly, just as it would if the vessel were in physics range. The vessel object does exist outside of physics range. ProtoVessel has a Vessel field (vesselRef) that handles everything I described above. I track orbital parameters for unloaded vessels in my contracts, and SCANsat tracks them for updating scanning coverage; I've never used ProtoVessel for any of those functions. I do use it when I need to get at Science Data stored in ProtoPartModules though.

Version 0.8.6.1 is released: Kerbal Stuff This primarily fixes a number of minor bugs and tweaks contract rewards and part costs. See the change log below. v0.8.6.1 - All textures replaced by .mbm files - .tga files available on GitHub repo for anyone interested - Numerous minor bug fixes - Update scale and rescaleFactor values for KSP 0.25 - Fix bugs in KAS modules - Storable KAS science parts can be recovered with Science Data intact - KSC biomes register properly - .version file should be pointed at the correct location now - Tweaks to contracts and parts - Primarily reduced reward amounts and duration - Reduced initial purchase price for all parts