DStaal

Given that they have a CDN, a location you're checking from (or even better: the IP address spacedoc resolves to) is very likely to be helpful when reporting outages.

Define 'broken'. (Not that I'm aware of any issues with the water containers at the moment - but it's hard to troubleshoot without more info to go on.)

If there is one than it can be removed from this config - though I didn't see one when I looked through the config for the part. Given the way MM works, if there is one the above shouldn't affect it. (It's a blind add - which won't modify one that's already there.) AR does need there to be one though, from what I understand. (I'm not sure if it really needs one if you're only trying to add it to the network - AR basically does a 'store and forward at the antenna' for transmissions, and that's not the main purpose of having this antenna - but I'd expect sooner or later someone would cause issues if it wasn't there.)

Untested, but here's an AR config: (it makes the antenna exactly half as strong as the standard whip antenna.) @PART[SampleReturnCapsule_Parachute]:FOR[AntennaRange] { @MODULE[ModuleDataTransmitter] { @name = ModuleLimitedDataTransmitter nominalRange = 3182 simpleRange = 10250000 maxPowerFactor = 8 maxDataFactor = 4 } MODULE { name = ModuleScienceContainer dataIsCollectable = true dataIsStorable = false storageRange = 2 } }

The USI Survival Pack (SrvPack) has a lot of parts that go well with this: Monoprop engines and tanks that fit the 0.625 form factor, as well as solar panels and batteries that can extend your service life. I'd almost want to ask for more ablator as a tweekable - I just built a science return capsule that's under a ton total and can return unaided from the surface of Minmus or Mun, with dv to spare. A bit more ablator for areobraking, and it'd be able to return from Gilly or Ike...

On antennas: How about an AntennaRange patch? (For similar reasons as the RemoteTech - although it's not on by default in AntennaRange, it is possible that people will need an antenna to control the ship.) I'd just copy over the stats from the standard small antenna myself; no need to get fancy.

I haven't had a chance to load up KSP in a while, but someone should check how MOLE interacts with this mod. (It has a similar system to Station Science, where results are only available after a time period.) (In fact, I might suggest to put it on an exemption list preemptively - it's science experiments are designed to take time after all, and most/all aren't designed for running around the space center.)

So, assuming you have enough batteries to last ~20 minutes, and enough generation to refill those batteries while you're in the sun (or if you've got enough generation not need to rely on stored charge) you should be good. You don't need to have enough EC to last your entire mission. You only need to have enough to last until you can get more EC.

The one problem I see with that idea is that to do it correctly you really want to be able to stack more than two high on occasion - and multiple docking ports on a single part don't work well. Having another node on the other side might be nice in relation to that. I could even see making one side a 'Kontainer Dock' port and have a stand-alone addon dock that can be fitted to the other side. (Just a low profile frame, that fits the outside of the Kontainer.)

Yay!

Love the idea. My one request: Could we get an option to turn it on/off on a per-save basis?

Not yet. Several of us are working on an add-on mod that would add that. (My patch set doesn't have the workspace yet either, though I've been meaning to add it.)

Here probably isn't the place to ask that question... However, IIR (and understand) the configs correctly, if you add the 'ModuleLifeSupport' module on it's own (with nothing else) that should short-circuit adding the wear mechanic. (Because the wear mechanic and life support mechanic are added at the same time, and only keyed on ModuleLifeSupport.)

It's also worth noting that recent flap between CKAN and mod authors resulted in an agreement that means the process to get something onto CKAN is likely to be slower than it was. (But is also less likely to be wrong and cause issues.) If you want to use CKAN for convenience realize it is not and cannot be the the best way to get a completely up-to-the-minute version of all your mods. It takes time for the CKAN people to notice a mod has been updated, and then to update their info for it. (And in some cases *test* the new info to make sure it's correct.) If you want to get updates faster, you can always install them manually.

For reference: It's surface attached on that. In case it matters. I just took a pre-existing design and threw a fuel pack on top to see if it worked with the Wagon. I didn't really expect it to, and that rover was intended to work on solar power anyway. (Though if the flex fuel pack had worked on it I would have kept it as the updated design - solar's nice, but it's also nice to be able to work at night, even if I find driving in the dark to be hazardous.)

Ok, note to self: The new Flex Fuel Power Pack works 'oddly' with the inflatable Wagon:

On the other hand, a big retrograde planet would be a very unique event: Basically, by current theory, such a planet would need to be an interloper into the system, so it would need to have been captured by Kerbol. And if it was a big planet, this would have been a massive event in the system, destabilizing most of the orbits. Such a system would likely look very weird, or very empty. A more realistic retrograde orbiting body would be something like a comet - on a highly elliptical orbit, and of moderate mass. Much easier to capture, and less likely to cause massive disruptions when it was captured. (It could even have had assists from Jool or Urlum or others in it's capture.) It would be as hard or harder to reach, and would be a very interesting body scientifically, but it's something that might actually occur without destabilizing the entire system.

I've had a couple of low-TWR Mun landers where the ability to thrust to a more eccentric orbit at a low ISP would have been helpful... (Flight to Mun was more efficient than expected - I needed to dump fuel to get sufficient TWR to successfully land.)

Of course, what I was just thinking I needed on the Buffalo is a part that's an EL workshop... (And would mount the Spyglass, for a mobile base-building solution. Though I think I might be able to mount that to a crew segment.) (Looking good, and I'm looking forward to playing with the new parts.)

It's just the one file, and removing it doesn't remove any parts. If you remove it about the only thing that will change is that KSP will load.

I'm working on a big patch which should make maintenance of and extending this pack easier in the future (part of the inspiration is to allow other mod makers to add 'USU-compatable' containers to their mods easily without worrying about balance or that you'll need to change what is being carried in the future), and I'm wondering if anyone could spend a bit of time looking over it before I try a PR. (Because it will literally touch *every* Kontainer, and I want to make sure I get it right.) My dev fork is here: https://github.com/DanStaal/USI_Core/tree/DEVELOP/FOR_RELEASE/GameData/UmbraSpaceIndustries/Kontainers The main file to look at is here: https://github.com/DanStaal/USI_Core/blob/DEVELOP/FOR_RELEASE/GameData/UmbraSpaceIndustries/Kontainers/USI_Cargo_Switch.cfg It consolidates the Firespitter setup for the Kontainers into one place, calculating all sizes and costs in ModuleManager. An example of just how much simpler it can make things is the radial supply pack, which goes from: MODULE { name = FStextureSwitch2 textureNames = UmbraSpaceIndustries/UKS/Assets/MKV_Tex_04;UmbraSpaceIndustries/UKS/Assets/MKV_Tex_04;UmbraSpaceIndustries/UKS/Assets/MKV_Tex_04;UmbraSpaceIndustries/UKS/Assets/MKV_Tex_04;UmbraSpaceIndustries/UKS/Assets/MKV_Tex_04;UmbraSpaceIndustries/UKS/Assets/MKV_Tex_04;UmbraSpaceIndustries/UKS/Assets/MKV_Tex_04;UmbraSpaceIndustries/UKS/Assets/MKV_Tex_04;UmbraSpaceIndustries/UKS/Assets/MKV_Tex_04;UmbraSpaceIndustries/UKS/Assets/MKV_Tex_04;UmbraSpaceIndustries/UKS/Assets/MKV_Tex_04;UmbraSpaceIndustries/UKS/Assets/MKV_Tex_04;UmbraSpaceIndustries/UKS/Assets/MKV_Tex_04;UmbraSpaceIndustries/UKS/Assets/MKV_Tex_04;UmbraSpaceIndustries/UKS/Assets/MKV_Tex_04;UmbraSpaceIndustries/UKS/Assets/MKV_Tex_04;UmbraSpaceIndustries/UKS/Assets/MKV_Tex_04;UmbraSpaceIndustries/UKS/Assets/MKV_Tex_04 objectNames = Pack_002 textureDisplayNames = MetallicOre;Uraninite;Substrate;Minerals;Karbonite;Commodities;MaterialKits;Metals;Polymers;Supplies;Ore;Machinery;Recyclables;SpecializedParts;Fertilizer;Hydrates;Gypsum;Dirt useFuelSwitchModule = true fuelTankSetups = 0;1;2;3;4;5;6;7;8;9;10;11;12;13;14;15;16;17 repaintableEVA = true } MODULE { name = FSfuelSwitch resourceNames =MetallicOre;Uraninite;Substrate;Minerals;Karbonite;ExoticMinerals,RareMetals;MaterialKits;Metals;Polymers;Supplies;Ore;Machinery;Recyclables;SpecializedParts;Fertilizer;Hydrates;Gypsum;Dirt resourceAmounts = 1250;1250;1250;1250;1250;625,625;1250;1250;1250;1250;250;1250;1250;1250;1250;1250;1250;1250 initialResourceAmounts = 0;0;0;0;0;0,0;0;0;0;0;0;0;0;0;0;0;0;0 tankCost = 2200;875;375;1000;400;187500;2500;17800;10000;3125;5;19750;8750;40000;2500;625;12;375 basePartMass = 0.15625 tankMass = 0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0 hasGUI = false } into (and one of these lines is optional): MODULE { name = USI_Container_Solids objectNames = Pack_002 baseVolume = 1250 EVAConfigurable = true textureDefault = UmbraSpaceIndustries/UKS/Assets/MKV_Tex_04 } I've got the solids all fairly well done, but I'm having trouble figuring out some of the ratios between resourceAmounts on the liquid containers. (So, in the dev I linked to none of the liquid containers have the new module, although it's defined in USI_Cargo_Switch.cfg.) I could use someone to check my math and figure out what I'm missing in those - or if there are multiple variants of the liquid containers, which have different ratios between their various resources. I'll come up with a bit more docs on it before I'd do a PR, but the simple version is that you create a module of either 'USI_Container_Solids' or 'USI_Container_Liquids', with the baseVolume of the volume of the container, the objectNames of the object who's texture will change when you change the contents, and the different textures. (As well as a default texture that will be applied if one isn't specified for that material. Only the default is required.)

Looking at that ship... You might try putting in some fuel lines. I'm not sure the engine can get the fuel from those tanks.

Nils is working on official support. In the meantime:

As another option, you can also take a look at the Pathfinder mod, which has it's own colonization system. (It can also be dialed back to just a parts pack, in which case you could use it with UKS.) It works just fine with USI-LS as well. If you just want parts, take a look at Kerbal Planetary Base Systems; lots of good parts for building bases. (Currently they work with USI-LS, but don't integrate with either UKS or Pathfinder. The former integration is being worked on.) (Just wanted people to know there are options. I enjoy RoverDude's mods, but @Angel-125 makes some good mods as well. I run both, with the WildBlue Industries mods dialed partway back to give them some functionality, while not interfering with UKS's mechanics.)

Near Future Electrical currently collides with Umbra's reactors - they both have a compatibility patch for USI's reactors. (It historically has been in USI's mods, but it wasn't something RoverDude tested - it was just a PR he'd accepted. It's been agreed that Near Future is going to include it going forward - but at the moment we've got the old USI (which still has it) and the new Near Future (which also has it) and they conflict.) Delete the file in USI's reactor pack and you should be good.