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.

Just knowing you are aware of it and plan on fixing it is good enough for me. This is an awesome mod

Great mod but something about it truly is bugging me. I am using the toolbar icon to close and open the timewarp window. For me the timewarp stuff is an occasional thing I don't often have to use. However /every/ time I switch ships or back to the station or to the tracking station it insists on showing me the timewarp window. Is there any way I can get it to stay closed until I tell it I need it? It even opens the window when I press escape to pause when I am flying a ship...

I (and others) have been running RemoteTech2 without issues with .24; you might want to post any issues you have with that on that thread as I doubt anyone is aware of any compatibility issues with that mod.

LOL better than my original solution, I had a ring of 11 ground based repeaters along the equator That was a pain to put into place, and I lost many of them to a tweakscale kraken issue.

Oh I just re-read this... it is definitely not DERP, as you can see from my previous craft I was able to get 17 of these on a ship, no issues. - - - Updated - - - Good point, I might add a hours worth of food in just so Jeb can have snacks

It is true with NEAR and FAR. They do not. (They still behave like they are in open air). NOTE: one useful thing to do (If you find yourself forgetting to deploy or like I do taking a way too horizontal orbital approach and sometimes just missing the window) is to use these: http://forum.kerbalspaceprogram.com/threads/64227-0-24-1-27-July-Smart-Parts-V2-0-New-API-and-new-KM-folder-structure What I do is place a smart altimiter part with a action group set to jettison the fairings and deploy my omni-directional. If I forget to deploy as long as my suborbital takes me above the programmed height, I regain control and can continue my ascent. I set it for 50k ascent.

Currently fairings do nothing for or against connectivity and vulnerability. You can connect through a fairing fine, but if you try to go fast in an atmosphere with a fragile antenna under a fairing it will still blow off.

Feedback from my tests the last few days, I have created two Karbonite based science landers (drills, tanks, karbonite thrusters and kerbils/science experiments) to explore the Mun and Minmus and utilized them to "bunny hop" from biome to biome. It would be nice if the drill deploy/undeploy animation was tied to the act of drilling for Karbonite. I have noticed areas where the amount of carbonite per second I get flickers between two values, is that normal / am I on a border? While I had a blast doing it, the Karbonite powered thrusters seem... too powerful, even the small ones. I am not sure how to quantify it apart from that but they just feel out of whack. On my Mun lander (used 4 of the smaller ones) I had to dial down the thrust on each of them to something like 10% to even make the lander flyable. Other than those feedback points, it is a lot of fun and definitely close to prime-time ready.

How about Karbonite RCS I.E. not monopropellant but RCS that uses liquefied Karbonite as its reaction medium.

http://forum.kerbalspaceprogram.com/threads/53961-0-23-5-HL-Mods-on-Curse Should be very doable with HL Airships