ExavierMacbeth

Its not instant. USI LS has a 15 day "grace period" before the kerbals completely lose their minds lol. So temporary power loss isn't a big issue, just make sure you don't timewarp with closed panels

Using both is a bad idea. Whichever patch gets applied first will be the one that shows up (which might leave Nertea's engines without a fuel source). Both patches target the LF & O resources on the ship and then remove them after the patch is applied, so when the next patch runs there is no LF & O Resources for it to find. So it really depends on if you want the LH2 fuel options (and Nertea's engines) or not.

Yea its not really something I pay much attention to half the time. I generally over compensate so my timers always report almost double digit years... just for trips to the Mun. Depends on how much I expect to leave them there while I do other things EDIT: Also keep in mind that they also consume a tiny ammount of electric charge per day too. If you fail to provide it they may loose your stockpile of NOMS out the airlock while fumbling with the container in the dark... and I do mean ALL of it. Safeguard I think Rover built in to keep ppl from cheating the system

You'd have to search this thread. There is a decimal loss in there somewhere. I think Rover said it was like 1.08 per day usage or something "because math" was his reason. But its close enough ball park until we get a prediction timer for the VAB/SPH

Yes 1 supply = 1 kerbal day. No to the 2 Nom O Matics... A single Nom O Matic can keep up with a single kerbal's supply usage. What happens though is that your only getting a 50% return. Two of them will do the conversion faster but you will still end up with only half the supplies you started with after the mulch has all been reprocessed. Basically they extend the time needed between resupply but it is not a closed system. EDIT: For a full closed system you would want to add the Aeroponics/Kerbitat setups from MKS into the mix. As they let you get better conversion rates or InSitu supplies fabrication (from mined water & substrate).

You can target the MM patch to ignore the tanks with monoprop easily enough. Thats how Nertea's Cryo Engine & Interstellar Fuel Switch patch works. @Porkjet : You may want to put an advisory in your post that this will not play well with Nertea's Cryo Engine Pack. It also applies a global patch to all tanks that contain an LFO mix, though dynamically instead of by part so it catches mod parts, but you both are targetting the same conditions. So whichever one gets applied first causes the other to be ignored.

Think its deliberate. Most LS mods are set to dump waste products if there is no storage for them. After all why store the waste if you have no way to recycle it anyway? Its just extra mass on the rocket. And I agree with the 99% complete. I think the only thing that is really needed is more UI components for VAB/SPH and other screens for planning & monitoring. But that has already been mentioned a few times

Take a look at Nertea's Cryo Engines mod. He already has a global patch that converts all stock tanks to switchable LFO, LH2/O, LF, O, LH2... The LH2 options are the ones used for the engines in the pack but it also solves your request

There is a problem with your test. Try it in orbit Kerbins atmosphere is pretty good with dissipating heat. One of the problems ppl where having (still are to a lesser extent) is that they test their Nervas on the ground and don't realize that once its in orbit the heat buildup is much much faster.

WOOHOO! 5hrs of driving myself nuts digging through the ModuleManager thread and I finally cracked it The trick was figuring out a variable I could check for that didn't have alot of extra punctuation in it to throw it off. After I realized variables your math creates still existed on the part I had MM search for it to narrow the filter down. @PART [*]:HAS[@MODULE[InterstellarFuelSwitch],#mixLFCost[>0]]:AFTER[CryoEngines] { %ExBaseRN = #$MODULE[InterstellarFuelSwitch]/resourceNames$ %ExBaseRA = #$MODULE[InterstellarFuelSwitch]/resourceAmounts$ %ExBaseTC = #$MODULE[InterstellarFuelSwitch]/tankCost$ %ExBaseTM = #$MODULE[InterstellarFuelSwitch]/tankMass$ %ExTotalCap = #$totalCap$ @ExTotalCap *= 1 %ExCost = #$mixLFCost$ @ExCost *= 1 @MODULE[InterstellarFuelSwitch] { @resourceNames = #$../ExBaseRN$;Karbonite @resourceAmounts = #$../ExBaseRA$;$../ExTotalCap$ @tankCost = #$../ExBaseTC$;$../ExCost$ @tankMass = #$../ExBaseTM$;0 } } Thats as compact as I could get it. Even Better... It stacks. I could specificity a single resource like above as individual MM patches specific to different mods. Or add multiple new types in a single patch. If someone else creates one it doesn't matter what order they run in, it will pull the most current values each time and just keep adding tanks. No idea how one would go about removing tank options but I don't need to open that can of worms since that would probably be a parsing nightmare if MM even allowed it. Ok problem solved... now maybe i can get my brain to stop ticking long enough to go to bed or work is really going to stuck tomorrow lol EDIT: As an after thought Nertea you may want to consider adding "resourceGui" and "initialResourceAmounts" values to your config. The first one is arguably not very important unless you like Labels on thing. The latter one however would be helpful even if you just duplicate the "resourceAmounts" field into it. Some resources like Rover's Karborundum arn't tweak-able in the VAB and I have found that if I use the above to add it to your configs I get a free full tank on launch, which sorta defeats the point. I can't just add it in my own to start the tank off with 0 because there is no base value in yours to build off of for stacking. Just a suggestion

Could try using a heat shield as an insulator and running a fuel pipe between it and the engine for fuel flow. Thats what I have been doing to keep mine isolated and from blowing up whatever they are attached to. Even after the Ablator is gone the max thermal on the Heat Shield is something like 3400k (bout 600 higher than the Nerva I think) so by then your already throttling down anyway to keep the Nerva from exploding.

It was stated by one of the Devs in the release day Q&A on reditt (don't have link handy) that the Drestroids don't actually start spawning until you get a ship into the SOI.

Invader, Check the part stats. The two Mk1 tanks not only contain less combined fuel than just removing the oxy from the T800 but also weigh 1.8t combined (dry weight) compared to 0.5t of the T800. Add in the weight difference between the engine masses (Nervas are heavy) and you find your discrepancy. Nervas become much more useful when your rocket size hits a point where the extra weight from the Oxidizer (which is 55% of the fuel weight for normal engines) starts costing you more than the difference between tank & engine weights. Squad sorta overlooked that there wern't any really good LF only tanks for use with the Nerva since all the fuselage parts are balanced for aircraft/jet use. There are a few mods, if your not opposed to them, that add the ability to switch what fuels are available in stock tanks. I would recommend Nertea's Cryo Engines mod as being one of the most straight forward. It applies a patch that lets you switch stock fuel tanks between LFO, LH2/O (Used by Cryo Engines), LF, O, & LH2. So you could have your T800 with a full 800 units of LF

Nertea, Is there a good way to MM hook additional fuel types into your tanks without having to remove & reapply the entire patch? Want to make a patch that adds other fuels/storage i put on the tanks but make it so I don't have to rewrite it if you decide to adjust the ratios of your fuel types in the future. Not quite that good with MM patches yet lol Much as I like MFT I honestly find the fuel switch system easier to work with most of the time.

Probobly the side effect of a stock bug. I've reverted rockets (and planes) back to launch/VAB where i was doing burnup mach speeds and had them spawn on the pad still hanging onto the mach speed/heat values (and burn effects) for a few seconds after physics stabilized. Depending on how hot things where before I hit revert this generally caused something to explode lol. Pretty hit and miss when it happens but maybe thats what you saw

Ok went back several pages and didn't see this question so I will ask (Haven't decided if i want to reinstall this yet or not). If you choose to use the Default style Resource mapping (instascan), Does that also affect the terrain mapping for science function? I am hoping they are separated so that you don't get instant map & anomaly reveal just for being impatience about trying to find a good ISRU location

Ravien, Could I request support for another mod? Well not really support but an exclusion list cfg we can use MM to assign parts to. Basically Nertea is finishing up Near Future Electrical, Propulsion, & his new Heat Control system soon. Overall its going to be based on stock heat so compatibility is negligible. But I think his radiator system is going to be self regulating so they can handle the temps his reactors run at without outright exploding. Would be nice to add them to an exclusion list since we already know they are running hot and don't want the part highlighter & temp gauge to constantly focus on them

Theoretically yes, technically no Yes you could though the amount of work involved would be rather massive especially if you where to invest the effort to provide combinations needed to account for mods that skip nodes (since you would have to do 3 configs... 1 with both on, 1 with one off and the other one, and one reversed one off and one on). No for 2 reasons. 1) You would have to monitor every mod for part changes and update accordingly. Leaving it to individual mods to make their own config for theirs only would just mess with your combinations.. 2) Not every mod provides a DLL for MM to target. So mods that are pure parts packs with no actual non-stock code to them couldn't be used in MM "NEEDS" statements to filter them. In reality the only way to truly account for all the combinations would be to rewrite the entire tree (Like ADIOS and a few others have done) to make a specific set of "Core" nodes and then keep all the mod added nodes to they own offshoots that could be disabled as needed. Problem with that route is that your basically skewing away from the "Stock" style that alot of people like and what CTT was designed to keep closely to. EDIT: Lmao ninjaed by Rover

Works just fine

No. Last update for this mod was before DRE released a v1.0 compatible version of the mod. Maybe we can suggest support for it be added as an option

Then you will probobly want to post here: http://forum.kerbalspaceprogram.com/threads/111159-WIP-0-90-KSP-Interstellar-Extended And see if FreeThinker will update his CTT configuration file. It looks like that package is still configured for 0.90. The tree (both stock & CTT) have changed with the 1.0+ game versions.

lmao only 1km long? Are you finally catching up with everything lol

Would probobly depend on the efficiencies your getting out of the MKS/OKS modules. Staffed properly I think those are designed to run pretty close to self sufficiency, in which case you'd be running at a loss with the greenhouse sorta like you do with the MKS Pioneer module's converter. They are designed for early game LS extension rather than late game sufficiency.

From original post:

I get the alert like you would expect if I drag the part from Part Menu > Container. If I select the part & place it on the scene, then drag it from the scene to the container it will let me put it in there, even if the part was 3 times the size of the containers max volume EDIT: NVM its an MKS bug lol. Sorry