DStaal

He built that around the Salamander Command Pod from MKS - which isn't really designed as a return pod, actually. It's designed as a command pod for bases and stations.

Which directly contradicts the portion of your post I quoted. Honestly if they just said 'Modpacks are not allowed.' with the implied 'What is a modpack will be decided by the moderators' I'd be fine with it...

Yep. NEEDS[] keys off of it, as one way it knows the mod is installed.

'USILifeSupport' should work. (It's the DLL. NEEDS[] keys off of folder, dll, or :FOR[])

That would actually manage to defeat the point of a couple of common mods... Going back to my example from above, USI's MKS is contains these mods that are or have been available separately: Module Manager USI Tools USI Core AT Utils Community Resource Pack Community Category Kit Firespitter Core Ground Construction Core Karibou Konstruction Two of these (Community Resource Pack, and Community Category Kit) were specifically designed to be included in other mods, and while they technically have a separate download location it's not easy to find. In two cases (USI Tools and USI Core) they were abstracted out, and are managed separately just for RoverDude's convenience. On the other hand, Karibou and Konsctruction were rolled in to MKS for RoverDude's convenience. (Based on what other mods he's creating - the first two are common tools many of his mods use, while the latter were at first released separately and then rolled in as they matured to reduce his total mod count.) AT Utils and Ground Construction Core are mods where he's working closely with the other mod author to integrate them tightly - to the point of making models for them. Is it really better to force users to download 11 mods for this? (And many would have trouble installing them - enough have trouble right now, when RoverDude can say 'it should look exactly like the zip file.') I see your point, but you're throwing the baby out with the bathwater - RoverDude isn't just saying 'the license allows it', he's actively working with or directly maintaining all of those but one. (Module Manager.) Saying 'no, you have to make your users jump though hoops to install it' is just going to make it harder for him to support his own work, for no benefit to you except for having a cleaner rule.

I've been paid upwards of $40 an hour to assemble Ikea furniture for people... Apparently some think it does.

Just as a point of discussion - and a couple of edge cases for people to debate on: It's worth thinking about how any proposed rule would handle things like USI's suite of mods. RoverDude packages them separately - including dependencies, which for MKS includes (portions of) Firespitter, Configurable Containers, and Ground Construction. (As well as the obvious Module Manager.) He then has been occasionally releasing a combined pack with all of the USI mods bundled together - as well as their dependencies. I get the issue with modpacks, just wanted to bring up what is likely the edge case any rule has to handle - People just slapping a bunch of mods together without much thought and without doing things like looking at the licenses definitely shouldn't be allowed. RoverDude's USI Constellation Pack probably should be. Exactly how to draw that line could be tricky, depending on where it's placed.

PDU won't work without an Engineer. I suggest nuclear, and a Kontainer for storage.

FOR will always run his cfg. It will also run configs that want his mod installed. If actually creating a mod, FOR is fine. If depending on a mod, use NEEDS. They are not synonyms: FOR is unconditional, with side effects. NEEDS is conditional, no side effects. Proper use of FOR won't break anything, true. Improper use breaks seemingly-random things in other mods. I have no problem with @kerbalism:FOR[HisModName] - but :FOR[Kerbalism] is dangerous. FOR should not be used for ordering. It has one intent: To create a mod.

Never use FOR unless you are writing a mod. Misuse of FOR is the most common way to break mods.

@Tex_NL:

Idea for full set: Ore->Fert (slow) (Could also be current Ore+Mulch->Fert) Ore+Water->Fert+Mulch (fast) Soylent Red Soylent Green Soylent another mod that does algae: Without Soylent, just have first two. May want SCWO in container format - any good models? (Could use same as liquid tanks...)

Another idea: Ore+Water -> Mulch+Fertilizer 500:100 -> 75:1 (Estimate off top of head.) Just idea, while throw around concepts.

Just wanted to mention that I didn't get to this before dislocating my shoulder. Trying to minimize typing now.

I like 3 and 4 - lean towards 4. I like the idea for Algae container. Maybe swappable between two, under MKS? (Not sure which dll provides swap.) I use water scanner fairly regularly... (May not need to, but I do.)

Do you have EL?

Just wanted to note that a dislocated shoulder is going to be delaying things a bit...

The OKS line of parts is dead - as are much of the corresponding MKS line. The new MKS line is designed to cover both situations. (Every single part was replaced when KSP 1.2 came out.)

Thanks. I need to circle back to the atmospheric lander, and the recent update to DSEV I think has provided me with the tools to build a rover-lander. After that, the plan is to get the Minmus base up and running a bit more, and to start test-building. Aims are to both test the construction processes (I've got both EL and GC - not sure which to use for the final ship), and to practice atmospheric landings by sending them back to Kerbin. (After that, the first stop is Mun - for a full systems test.) The recent MKS upgrade has also meant I'm tweaking some of the lander designs - Notably there's a new nuclear reactor that's a good fit for the Expedition Lander, reducing the length and partcount some.

I always figured the way to do that was to dock and let the normal processing do it.

I'm noting a couple of new resources in the list - in particular, FusionPellets, which I know @Angel-125 also uses in WildBlueIndustries. Just bringing up so you two can coordinate, if at all possible.

Not that silly - it is in a slightly different place than GitHub, and not as obvious, and I haven't put out an actual 'release' yet. (I'm waiting for some textures at this point - though I'm still having some issues applying the ones I have correctly.) Anyway, if you want to try out the current WIP, right under 'UKS Compatbability Patches and addons for Kerbal Planetary Base Systems.' is a row of buttons. Star, Fork, etc. If you want to use git with the ssh URL, go ahead. Otherwise the underlined down-arrow will give you the choice to download it in various different formats. Hopefully we'll have a beta-with-known-issues release in a day or two for 'Stage 1'. Then we can work on stage 2, and try to figure out why I can't seem to get the right background textures.

I can see them being used in bases and stations fairly often - much the same way shipping containers are today: Ad-hock, and without 'official' tools, in nearly all cases.

Working on it. We're working on a big patchset for full MKS compatibility - Thread below. We've got logistics and materials basically done (some texture issues remain) and then we want to get life support balanced out, but GC will be in there. Of course, Nils could do GC on his own, independently. The new workshop part could be good for it.

That's up to the CKAN people.