undercoveryankee

That's the plan. 7rc5 is the prerelease of the ORSX version of SCANsat (the old GNU "odd numbers are prerelease, even numbers stable" convention), so what I'm testing will work with the stable series when it's ready.

When I get my Interstellar/CRP integration pack updated for ORSX, I plan to include SCANsat support for all of Interstellar's ground resources. This info will be a good start.

Found the prereleases last night. I should have Interstellar 0.12, SCANsat 7rc5, and CRP 0.2 looking like one big happy family by the end of the weekend.

I vaguely recall that FAR uses ModuleManager to zero out the stock drag on stock parts with winglet or control surface modules. If SRB's patches to those parts were allowed to run after FAR's patches, unpleasantness would happen. Fortunately, all of those patches are protected by a :NEEDS[!FerramAerospaceResearch], so they don't conflict with FAR. Looks like a separate test for NEAR will have to be added.

Currently LqdWater, but it's an easy conversion. My Community Resource Pack integration thread currently has the code to convert engines, tanks, refineries, and ground extraction to CRP 0.1.3 Water. The next update, which will synchronize atmospheric and oceanic resources as well, will be targeted to the CRP 0.2 pre-release. Until I can get that out, it should be simple enough to hand-edit the atmospheric and oceanic resource configs.

There's no code to remove the intake module in rapier.cfg. If you made that change, it might just not have made it from your local copy to Github. Or are you trying to dynamically remove the intake module in the plugin?

If you would rather not replace the SCANsat dll for whatever reason, it also works to overwrite GameData/SCANsat/Plugins/OpenResourceSystem_1_1_0.dll with WaveFunctionP's build from his Interstellar 0.11 release.

The MKS parts' built-in probe cores even have the RT2 modules applied out of the box.

I've been able to switch fuel modes on fusion reactors in flight. Fissions with their EVA shutdown/fuel swap process are trickier. There's no fuel mode that directly burns lithium. You can use Li as reaction mass or breed tritium from it. To run a reactor, you'll need a supply of tritium or helium-3 somewhere.

The math operators don't work on a value that can't be parsed as a single number. A multi-number value like a FloatCurve entry can be either completely replaced or edited as a string with regular expressions, but that's it.

As long as that general rule runs in a pass where it can be overridden if you want to do something special. I deliberately set up the NRAP test weight to have local control so I don't have to copy my entire comms network from my career save into my testing sandbox. There are also a few oddities like the Interstellar AI core that you might want to be smart enough to count as local control.

Sharing maps for any resources that overlap is still a goal. Interstellar doesn't have its own scanner for groundwater yet, so making Interstellar look at the same Water map that the MKS scanner scans is especially convenient. I've been thinking of NearFuture EnrichedUranium as being in the form of uranium dioxide. Common form in power-plant fission reactors, but not in the types that are in Interstellar. I don't really have a preference on how uranium mining works; going straight to the usable resource is probably better than having a series of steps when most people won't have a choice of end product. If I have to interoperate an Interstellar release that expects uranium to be mined as UF4 with one of your releases that wants to mine uranium as something else, I'll share a map (for scanner agreement and so I can delete the unused one) between an ORS definition that goes to UF4 and an ORSX definition that goes to your supply chain.

I'll explain in a little more detail: All of the plugins in the K+ package are shared with other USI projects. Their sources can be found in their home repositories. All that's unique to K+ is the art and part config files, which don't really have source separate from what's packaged. There's the no-op KarbPlus.dll, but that's just a name to use in a ModuleManager :NEEDS clause. It doesn't contain any code.

I've started a thread for some work I've been doing on Interstellar/Community Resource Pack integration. I think I can get the current releases of Interstellar and MKS to play nicely together. I'm a day or two from having everything I want configured and tested, but I wanted to get what I have out there in case it helps anyone else who's working on the same issues.

I've started working on getting KSPI 0.12 to play nicely with Community Resource Pack and RoverDude's mods. Here's what I have so far: To install, I deleted KSPI Lite and WaveFunctionP's OpenResourceSystem and installed WarpPlugin/ and both ORS folders from the Interstellar 0.12 package in an install of KSP 0.24.2 that formerly had KSPI Lite and had all of RoverDude's mods working with KSPI Lite. I kept a copy of WaveFunctionP's OpenResourceSystem_1_2_0.dll in the UmbraSpaceIndustries folder as was required for the last release of KSPI Lite. Changes made in my ModuleManager config: Configured KSPI to use CRP Water and ArgonGas instead of its own LqdWater and Argon. Renamed or deleted PLANETARY_RESOURCE_DEFINITION nodes (ground-extractable resources) in Interstellar that duplicate CRP's keys. Since only KSPI Lite is currently mining CRP EnrichedUranium, patched CRP's Uranium maps to extract as traditional KSPI UF4. Future goals: Check whether the two Argon resources have different densities, and if so adjust the Argon capacities of KSPI parts. Unify atmospheric and oceanic resources. What's been tested: Extracting and electrolyzing Water on the KSC runway. Works. Displaying water hotspots with the MKS mapping camera and thorium hotspots with the KSPI spectrometer. Works. SCANsat 7rc4: Could not open any SCANsat windows, even the settings window. If I find a solution, I'll update. Need to test: RoverDude's resource extraction parts. Should work if I have a copy of their required ORS dll around and unique, usable resource definitions. Oceanic and atmospheric resources once I have the definitions sorted. // Rename Water and Argon. @WARP_PLUGIN_SETTINGS:AFTER[WarpPlugin] { @WaterResourceName = Water @ArgonResourceName = ArgonGas } @PART[*]:HAS[@RESOURCE[LqdWater]]:AFTER[WarpPlugin] { @RESOURCE[LqdWater] { @name = Water } } @PART[*]:HAS[@RESOURCE[LqdWater]]:AFTER[WarpPlugin] { @RESOURCE[Argon] { @name = ArgonGas } } @BASIC_NTR_PROPELLANT[Water] { @PROPELLANT[LqdWater] { @name = Water } } @ELECTRIC_PROPELLANT[Argon] { @PROPELLANT[Argon] { @name = ArgonGas } } @PART[*]:HAS[@MODULE[FNModuleResourceExtraction]] { @MODULE[FNModuleResourceExtraction]:HAS[#resourceName[LqdWater]] { @resourceName = Water } } // Fix planetary resource keys @PLANETARY_RESOURCE_DEFINITION[Uranium]:HAS[#resourceName[UF4]] { @name = Uranium_KSPI } @PLANETARY_RESOURCE_DEFINITION[Uranium]:HAS[#resourceName[EnrichedUranium]] { @resourceName = UF4 } !PLANETARY_RESOURCE_DEFINITION[Water]:HAS[#resourceName[LqdWater]] { } !PLANETARY_RESOURCE_DEFINITION[Alumina]:HAS[#mapUrl[*WarpPlugin*]] { }

ModuleScienceLab requires you to set "containerModuleIndex" to tell it where in the module list to find ModuleScienceContainer. If the module at that index isn't ModuleScienceContainer (because the number wasn't updated when copying the module to a different part, or because of trying to add science lab functionality with ModuleManager and not knowing how many patches might run ahead of yours), I've heard that it leads to exceptions and general sadness. There's no reason you couldn't put ModuleScienceContainer and ModuleScienceLab on the Interstellar part if you get containerModuleIndex right (I need to check whether ModuleManager 2.4's new expression feature can automate this). Putting the Interstellar function on the Squad part would save you from having to be responsible for that little wrinkle, as long as the Interstellar lab module doesn't depend on the part having animations.

I answered basically this question a few weeks ago on Reddit: http://www.reddit.com/r/KerbalSpaceProgram/comments/2egwil/does_having_a_lot_of_flights_cause_a_lot_of_lag/cjznk4n

Asteroids are a part called "PotatoRoid" located somewhere under GameData/NASAmission. Planets don't have a part file. Their stock characteristics are in non-user-serviceable bundle files, and any mod that adds or changes them has its own config file.

Without changing the plugin, you might be able to give a part two copies of the pump module, each set to pump a different set of resources. It's an extra module added to the parts with ModuleManager. Ships will normally load all right if the parts in the save file mention a module that no longer exists. Still doesn't hurt to make a backup copy of your save before you try, in case something else you have installed decides that it doesn't like to have its module moved to a different index.

Every planet has a magnetic field based on its rotation rate. Some bodies have multipliers in the plugin (weakening the field around small moons and increasing it around Moho, Jool, and Eve), but custom planets should already get the default magnetic field.

Sounds like nothing in the Interstellar plugin is loading. First thing to try: Remove GameData/OpenResourceSystem and any other copies of ORS that a particular mod hasn't instructed you to keep, and install the ORS that's packaged with the version of KSPI you're trying to run. If you have both GameData/Interstellar and GameData/WarpPlugin, you're mixing versions of Interstellar. Remove whichever one you're not trying to use. If that doesn't fix it, post an output log so we can see why the plugin isn't loading.

Once a map is made, it's available to anything that views maps unless you manually discard it from SCANsat settings. No need to keep the sensor in orbit after the map is complete. The image files generated by exporting are useful if you want to view them or import them into a tool outside the game, or if you want to refer to them while playing a save where you haven't scanned that body yet.

Probably need to do a depth-first walk of the part tree and explode() all of the descendants before you explode() the ancestor, or at least explode() all parts other than the root and the Dyn-O-Mite part before explode()ing either of them.

From the changelog for version 6.0: + [NEW] [OPTIONAL] Toolbar support. Strongly suggested, because the experience is better and more consistent with the Toolbar. [thanks DMagic!] - [REMOVED] Removed the old expanding/contracting floating SCANsat button. Replaced instead with either a Toolbar toolbar or with nothing, but maps become visible upon starting a scan. [Thanks Dmagic!] If you aren't using 000_Toolbar, the maps simply appear when you start a scanner. If you are using Toolbar, do a "configure visible buttons" in the flight scene, and SCANsat buttons should be available if you have a SCANsat part on the ship. (If you're on the development branch, 7.0rc4 or later, you no longer need a part to have access to the buttons and maps.)

I had a nasty slowdown the last time I used the science bay too. Wasn't sure at the time what triggered it. Might be that the version of Firespitter that ships with MKS isn't as current as I thought it was.