elfindreams

Hmm it also appears as any engines as of the latest update break mechjeb's delta-v calculations bad enough that it shows no data at all if there is a part on the ship that uses the plugin. (even an unrelated part like the Taurus HCV that uses the plugin but isn't in this pack)

Just thought I would share: This is why I love this pack:

I had both of these issues in the past. What it ended up being was a duplicate firespitter.dll somewhere. Go out to https://github.com/snjo/Firespitter/blob/master/For%20release/Firespitter/Plugins/Firespitter.dll?raw=true to download the latest Firespitter.dll, put that someplace sane. Do a find files & folders on your GameData directory (or dir firespitter.dll /b/s from the command line or find . -name firespitter.dll -print if unix or mac) to find any possible duplicate firespitter.dll files. That might just solve your issue, when I did this I found two random firespitter.dlls that had been installed at some point with some mod.

Ok I just spent the better part of the afternoon chasing this one down... very strange. The problem Woodstar is describing, I also got the issue. I removed mods, tried everything and was finally able to reproduce it in a "clean" environment. To reproduce: Install on a clean stock install this mod and the latest mechjeb. Create a new save game (or do it in your existing, this part doesn't matter) and create a new ship. On the ship put a pod (any pod or probe), a tank (any tank), mechjeb and a few TRR-1s. Launch. Stage and very carefully play with the throttle (you don't want to crash ) note that it works fine. Open Mechjeb, Options and enable "Prevent Overheat"... note that the throttle pegs to zero and nothing works. Worse from previous testing if you leave a ship like this and go to another ship even one without the TRR-1 parts, the throttle acts very very strangely (one ship I switched to had the throttle pegged to max, I could change it but it kept returning to max). Here is the output_log.txt https://gist.github.com/aelana/729f441c42cad5ddb18a

Non-specific observation about the phenomena... It seems to me it behaves the same as if you click too quickly before the scene has kicked in. In even a stock game if the screen loads and you click fast enough the right-click menu will contain only the tanks. This is also the period before everything "settles" onto the pad, so it feels like everything is on rails or in stasis for a split second before everything kicks in. This just feels like something interrupted that process (maybe something got in a bad way and is looping or returned badly/caused an exception/etc).

I am pretty sure that is by design.

Something very wrong has happened on the new release, I upgraded and lost the ability to launch vehicles or right click on newly launched vehicles. Other vehicles that were already launched were fine, but if I dropped a MK1 pod on the pad, none of the right-click functions worked. In addition physics seemed to be "off" I put out a probe body attached to a stability thingy, triggered the staging (which should drop the probe body) but the stability thingy disappeared and the probe body just hovered there like it was glued to the air. Thinking this might be a conflict with another mod, I did a cleanroom test (GameData with just Squad, NASAMission and Time Control brand new sandbox game, MK1 pod) and the same problem occurred. The link to the log is: https://gist.github.com/aelana/bc2229d9fcf94c1a7faf I am running 32bit if it matters. Just to be clear, right click itself works (and shows the tanks) but none of the functions exist ... i.e. no "Rename Vessel", "Control from Here", etc...

Certain ISRU processes utilize resources collected via atmospheric collection or oceanic collection. There is also a process on the science module that utilizes oceanic resources.

You should probably add: @PART[KA_DetectionArray_01]:NEEDS[OpenResourceSystem,SCANsat] { MODULE { name = SCANsat sensorType = 114816 fov = 4 min_alt = 5000 max_alt = 750000 best_alt = 100000 power = 0.5 scanName = Resource Scan animationName = Multi_Antenna } } To bring it in line with the stock config (the Karbonite scansat integration is on the part already, this just adds the ORS and other MKS resources).

Nice One other thing to consider is to close the loop and make the drills a functional alternative in MKS to a harvester node (so you can have unmanned harvesting probes) Basically add: MODULE { name = ORSModuleResourceExtraction powerConsumptionLand = 2.5 powerConsumptionOcean = 0.001 extractionRateLandPerTon = 1 extractionRateOceanPerTon = 0.1 resourceName = Water unitName = Water Extractor extractActionName = Extract Water stopActionName = Stop Water Extraction resourceManaged = False resourceToUse = ElectricCharge } MODULE { name = ORSModuleResourceExtraction powerConsumptionLand = 2.5 powerConsumptionOcean = 0.001 extractionRateLandPerTon = 1 extractionRateOceanPerTon = 0.1 resourceName = Substrate unitName = Substrate Extractor extractActionName = Extract Substrate stopActionName = Stop Substrate Extraction resourceManaged = False resourceToUse = ElectricCharge } MODULE { name = ORSModuleResourceExtraction powerConsumptionLand = 2.5 powerConsumptionOcean = 0.001 extractionRateLandPerTon = 1 extractionRateOceanPerTon = 0.1 resourceName = Minerals unitName = Minerals Extractor extractActionName = Extract Minerals stopActionName = Stop Minerals Extraction resourceManaged = False resourceToUse = ElectricCharge } To each of the drills.

Now these icons are also available on GitHub. Download from GitHub Can we get these folded into the main release from now on?

I doubt he can, I think he is using the ORS scoops as is and I am not sure they can have their default set. I think the engines are as designed, Karbonite is supposed to be heavy and highly volatile creating engines that are likewise heavy and over-powered. It is the tradeoff of using karbonite engines instead of just converting the LFO and using an LFO engine.

I could be wrong about KSP-I... I thought the ISRU converters were on rails. (not the extractors tho) What about using the MKS converters... it is not like the author is hard to reach

One request, can we get the: deactivateIfFull = true changed to false on the converter parts to bring it in line with the behavior of the KSP-I (ISRU) and MKS parts? The reason is so you can set up a production chain and leave it running just adding parts/fuel and taking away finished product as needed. So say I have a station I use for Karbonite refining, and I am using the MKS orbital logistics part. I set up the converters and set up a orbital delivery of Karbonite, the way it is now the converters will stop before the Karbonite arrives.

MapTraq is deprecated because you don't need a config any more to add maps to all pods/probes. The ScanSat button is now available without a part or a special MM config.