RoverDude

Kerbals have issues with braking and steering on minmus. For minmus I use this:

I guess the difference is that I'd assume a civvie becomes a scientist or engineer, and then goes into the workforce (at least from the MKS standpoint) or, you kinda have to rebuild the entire efficiency model (at least as far as MKS modules go).

Correct. Xenon was actually removed from the Karbonite distillers, despite much sadness. You have a few ways to get it other than shipping. First, reactors (but the amount is tiny, and it requires the reactor to be used, plus you need a source for all of that uranium). Second, if you are REALLY lucky, atmospheric or oceanic harvesting.

Engines require something with mass in order to work.

Yeah I vaguely recall that there were KSPI plans for RTGs back in the day but it was never used. Really, it's easier for us to add stuff in than take it out FYI here's where I got my CO2 density: http://encyclopedia.airliquide.com/encyclopedia.asp?GasID=26

All fine by me, as long as the stuff is consistent and we don't have two names for the same thing, there's little harm in having some variety. Did we decide that nobody is using that plutonium resource?

That's pretty much it - Xenon Gas is a distance limiter. Recharging is free, fuel is not. And to make it meaningful you'd end up nerfing your non-warp engines.

That's a CRP thing not a Regolith thing. Not sure off the top of my head, I expect it's just Karbonite but could be wrong

Excellent! FTT needs some love, but at this point it will probably all come out with 1.0 as everything is getting it's series of breaking changes right now, and I need to wait till 1.0 to release all of that.

Sounds nice. So basically they can manage their civvie population, and periodically 'recruit' for a new Kerbonaut

Actually I think they have the Alcubierre power requirements down now with some changes to the shape of a drive But for 90,000 science it's a nice capstone.

You might be a bit misinformed RE resources, etc. - generally if you have a resource starvation issue you are probably having issues with intermediary resources - I've had zero issue doing unattended background mining and processing, including very long resource chains, over massive time differences (I usually test a harvesting and four-process resource chain over a decade or so when testing). EC is handled separately, and due to battery storage limitations operates on a different max-delta than other converters. RE the earlier post for efficiency, you would have to either subclass or rebuild the efficiency code to include non-kerbonaughts, though I'd think it would make more sense to leave the actual base operations to the existing kerbonaughts. RE getting ore slow... Resource harvesting works in the background, no problemo

Oh - and Uraninite is listed as a fictitious resource - it's not

I have had no issue with the PackRat wheels you are describing - are you using attach or store? Because you should store them in place and they will snap in correctly. The symmetry bit is a FireSpitter issue and is already logged. The base module EVA range is a KAS issue because it is not respecting it's own parameters. Insufficient detail is being provided RE your EC problem with AMT.

Ahh.. yeah, the KA engines have built in intakes for operating in this mode - so assuming KSPI has intakes as separate bits, I can see that being an issue. Guess we can leave it in then since you folks might have that use case. - - - Updated - - - Also RE LqdCO2 - would need Nertea to see if it ties out, i.e. it's relative density should be on the same yardstick as all of the other liquid gasses for consistency. I'll have to do a scrollback and see how he's baselining. Assuming all densities are consistent and based on the same assumptions, the final number should be irrelevant if it is inline with that. [Edit] I'm seeing 1256.74 kg/m3 for LqdCO2 (which ties in pretty close to the 1200) and 1142.2 for LqdOxygen (which is what it already is in CRP). So I'd propose for consistency plugging LqdCO2 in at ther 1256.74 number.

Oh... if your issue was with survey stakes then those were most definitely not my parts But yeah I would not be surprised with TweakScale causing surprises, it has become one of my leading sources of bees recently.

There is an amazing amount of witchery that goes into making a PackRat assembleable with KAS, as the nodes have some pretty hellish relationships. That is why they are set up the way they are - to make the whole thing work assembled. Until such time as it gets a complete rework (which will not happen for a very long time - definitely not for 1.0) I would no anticipate any of the nodes or it's operational characteristics (to include operating manned) to change.

Totally insufficient information here to even remotely troubleshoot this. (Edit) How much RAM is KSP using? Are you using the 64 or 32 bit client? etc. Also - usual question. Did you try a clean KSP install and use process of elimination?

Log a Github issue Side note. Going to request this thread be locked so folks wind up on the release one, as I miss a lot of the replies here.

As noted... I gave you the code that makes this completely obsolete. The stock ModuleResourceIntake already includes precisely the override you are looking for. I already deprecated using IntakeAtm in all of the Karbonite parts and was happily flying around Jool last night. So either that flag did not exist when Fractal_UK made KSPI, or he simply did not know it existed (in fairness, someone pointed it out to me and after a test we all realized it worked a treat)... but in any case, the module is there, and has a flag already that renders the need for IntakeAtm completely obsolete. - - - Updated - - - Sorry, missed this earlier. Tank storage is a matter of volume not density. i.e. a cubic meter of lead has a higher density than a cubic meter of aluminum. But both would fit in the same 1m x 1m box.

Also - can we deprecate IntakeAtm? It's basically IntakeAir with checkForOxygen= false MODULE { name = ModuleResourceIntake resourceName = IntakeAir checkForOxygen = False area = 0.0131 intakeTransformName = Intake } What does KSPI use this for other than air intakes?

Which MKS/OKS part? That would be helpful.

It would be LqdCO2 for consistency, with the expectation that folks would adjust their mods accordingly (again, this whole bit is for 1.0 so we all have time to deal with our respective changes). Sorry, given that we're giving up LiquidHydrogen for consistency the same is going to need to apply to LiquidCO2. Nertea - go ahead and deprecate any Biomass resources that are not being used by USI/KSPI-E/NFT. Obviously we have Oxygen, CarbonDioxide, and Water tied to TAC-LS, and I'll plug in the updated Biomass number for... well... Biomass, since there's no reason not to use their number for the rest. As to the others, if they decide to come to the party, then they can adjust/conform to the rest of CRP. (edit) For LqdCO2 density, that's up to FreeThinker to sort, or a combination of him and NathanKell if they use it in RealFuels (which I have no idea on)

In fairness, all of us are changing things that are critical to our mods. Like.. hardcover breaking changes. As such this pass is for 1.0 where everything will break to hell anyway. I'd rather suck it up and have all of us adapt to the final form and not leave outliers for backwards compatability, given just how much we're sacrificing to get on the same page.

Yep, I can do that but it would require draining them first and that patch is now in FireSpitter, but I need to test this.