DStaal

Ok, I've updated my patches to take into account UKS's recent updates. (Removed redundant code - UKS now adds resource consumers to nearly everything, so we don't need to do it.) Also, I've created a dev-branch for @ibanix, myself, and @tsaven to play around in. If you guys will send me a message on Github I can add you as collaborators to the repository. ( @Nils277 to, if you want it. ). I'd like to keep the 'main' branch as a stable branch at the moment, without adding much more. (I may add living/work space yet, and a set of tanks based on the new large fuel tank.)

Clicking to browse more doesn't help much - since they don't sort, I have to figure out manually which have been updated since I last looked. (And which ones have just updated their 'works with' tags...) 'Newest Mods' is a different list - they may not have been updated all that recently, they're just the latest that have been added. Even just having more on the screen isn't always enough of an answer - if you run enough mods, sooner or later the screen size isn't going hold them all. That said, it's a minor issue. Just a feature request for whenever someone has time. It's a bit of work for me as a user to deal with, but it can be done. (And there's always the nice emails you send out to help as well.) Thanks for all your work.

As a feature request, brought on by the latest update: Would it be possible to have an option to sort our own profiles? Perhaps by 'most recently updated'? The sort on the landing page is nice, but it only shows the six most recently updated mods in my profile. A KSP update comes and a lot more than six mods update - but not all of them.

That said, it doesn't specify that Minmus doesn't have water either - so it's up to random chance. @AdmiralTigerclaw, you have some good points, but this really isn't the place to me making them - make them in the CRP thread instead. I don't know if making a resource slope-dependent is possible (without a plugin) under KSP, but making it biome-dependent is, so they may be able to implement some of your suggestions. (Submitting patches to implement them would likely get them implemented even faster...)

27 days isn't 'running out of hab', at least if you're in Kerbin SOI (including the moons). It's 'plenty of hab'. I think a lot of the logistics stuff checks to see if you're landed, but I'm not sure which do and don't. Best just to dock. Another option, if you don't have the claw, is to send up an engineer with a small supply pack and some tools. Attach the supplies with KIS and he'll have them.

If people want - I'll admit it was on my mind as a possibility when I split these patches off. (Though the main impetus was mostly the fact that I had these and was advertising them, but using them was confusing to people since there wasn't a real 'download' link. Also, I tend to tinker with my personal patches, as well as having other patch projects, and I wanted these insulated from that.) If that's what we're doing, I'll create a branch so that people can consider the main set of patches (that work currently, but are very focused in effect) as 'stable' while the development is ongoing. Also, if this is going to be the repository for that I'm open to discussing licenses - I mostly picked MIT because I'm hoping these patches will be subsumed into the larger effort, and I wanted a license that would allow that easily. (Not that I don't like the MIT license - just that I'm aware that there are others out there.) Naming is also something that might need to get changed - I just wanted something that was unique and easy to distinguish/find in my GameData folder.

I'll look over the rest of your post later, but I wanted to mention that my patches take pretty much that approach. Also, to make it easier for everyone, I've moved them to a separate repository. This allows me to track them separately from the rest of my assorted patches, and it allows everyone here to download them as an actual release, instead of just 'download these files.' I've added a readme and a license (MIT) to round things out on them. Here's the new download link: https://github.com/DanStaal/DStaal_UKS_KPBS_Addons/releases

Actually, from what it sounds like, the code he needs to look at is Extraplanetary Launchpads - which can spawn parts connected to the current ship. (It then undocks them.)

Make sure you're UKS and USI-Core installs are up to date - that was a known issue a version or so back.

Filter Extensions doesn't hide the parts from the game - just it gives you more control over category tabs and such in the VAB/SPH. One of the tabs is 'Squad' - only Squad's parts, so you can see what parts are stock and which aren't.

Also, a better place to start is probably with Filter Extensions. (In fact, I think it has what you want - a category for stock parts only - built-in...)

Of note is that UKS already has code to implement this, which we could piggyback on - Here's the example from the Aeroponics module's config: MODULE { name = MKSModule workSpace = 1 livingSpace = 0 efficiencyPart = OKS_AgModule,5,USILS_Greenhouse_LG,4 } That means that the OKS Agricultural module would increase this module's production by 5 times, and the USI-LS large Greenhouse would increase it by 4 times. (500% and 400%.) The part in question is described as 'Requires at least one Agriculture Module to operate!'. No problem - I was more discussing the problems with having both split converters and a combined converter. I'm really fine without the combined or the smaller form factor ones; I just can see a large form-factor combined unit either displacing the split converters or vice-versa, unless a *lot* of thought was given to use-cases and balance. They would have to be very different beasts, designed for very different situations - and we'd want to think through what those situations were. In general I'd prefer to not try - The user can always pull in a MK-III part if they want the combined part, after all. I was more saying 'If we wanted to cover this use-case, I think the smaller size would be better than a larger size.' Which might well be a reason to *not* cover that use case. It is worth noting that with the split design we have, there is still a mass, part and Kerbal count advantage to building one base with all three - you'd only need one Process Coordinator module to get things working. Which might be enough for @ibanix 's use case.

I think because if you look at them you'll see they're all designed around a 'common core' - common interiors and form-factor, with various extras (thrusters, parachutes) attached on the outside in what's obviously a fairly modular fashion.

I could do it in an MM patch as well. But the model's the hard part. There's always different ways to use it - the way I tend to use it is to reduce the initial numbers of drills I need to land: You can land a Dirt drill and probably get all the resources you need for initial base building (via EL) or maintenance. (Depending on the planetary concentrations - on Mun in my current playthrough I needed one extra drill for Minerals to be able to produce MaterialKits, for instance.) You get more resources per time/EC out of a dedicated drill, so I'm building out mining operations now, and I use Planetary Logistics to tie the whole thing together. So yeah: It allows for lower-efficiency extraction of resources you can't get - one drill will get you most resources. But I tend to think of that as an early-colony strategy. We should think a little bit about use if we're talking about that - which parts to we see players using in what order, and what happens to them long-term. I tend to build out - start with a central base, and then build supply lines. In which case the 'single module' would get put at the central base as a starting part while I build out the rest - but then either it becomes redundant or I never use the individual modules. Personally, I think this would be a good place for the containers, if that's what you want to do: low-mass, low-efficiency (possibly still specialized to fit the theme, but still just color-swaps if so), low-production parts that you obviously want to replace. If we can think of a good use for them in a larger base good, otherwise they're then small enough (and modular enough) that they can be ignored or just pulled from the base and replaced with something else, whereas one that's full-sized would be hard to pull out of the base. (The other option would be if you could repurpose it somehow, but I'm not sure how to do that without custom code like in the MOLE mod.) (We're really sounding like we're building a better-than-UKS UKS at this point. ) I'm expecting it to be essentially an efficiency module for the refineries: It gives them a boost to production, and holds Engineers which give them a further boost to production. The refineries would have a 0% production on their own, so you'll need those boosts to get anything actually done. (Take a look at the MK-V Smelter+Crusher for similar examples of the latter mechanic, and the Areoponics+Kerbitat for the former IIRC.)

Yeah, from the chart as reference you only missed one long crossover line and got Machinery/MaterialKits flipped, so it was minor mistake from there. I thought about suggesting the garage formfactor for specilized parts production - it'd work, but I didn't want to lock that thought process in. If someone has another idea I'd be willing to hear it. (Especially since we're basically mimicking the MK-III for the rest - the Mobile Refinery is a MK-III as well, but we're splitting it up.) The 'Fabrication' module just needs to be more difficult to handle than the 'Factory Workshop' on your chart - so it depends a lot on what that part is like. If it was half-length or so then having a full-length fabrication module means it's more difficult to work with. Or whatever balance you want. (Heck, even having the Factory Workshop being a multi-use part of some sort with OSE and EL while the Fabrication module is dedicated might be enough to balance, if I'm throwing ideas...) Converters in the (large) container size wouldn't be very OP vs. UKS; it's about the same size and mass as a MK-V Smelter (I've even stashed MK-V parts on a container rack...) - which also has the requirement that an Engineer must be someplace else on the ship to run it, so if you keep it paired with the requirement of the Process Coordination we aren't gaining undue advantage. The question is whether we'd want to do that - it's a set of extra parts for not much extra benefit. Personally, I find landing a UKS part a lot easier than landing a KPBS part - so I tend to land an initial colony ship from that set, and then build out a KPBS base using EL. And again, it's that initial setup phase of the new colony that I find Dirt the most useful in, so I'm not sure about whether we'd need it here. If you did want it, a single recolored ISRU to handle it (as basically a presorter for the chemical plant/polymerizer/smelter) would likely be the easiest way - especially if we're going for a mid-size (Probably roughly equivalent to the the new parts RoverDude's working on and showing off glimpses of at the moment), and not trying to duplicate the 'exploration' MK-V parts. (Basically, I could see making a MK-V alike in the container system if you wanted - but I'm not convinced it's worth the work, or something you'd want to do, as they'll already have the MK-V parts.) The one useful part for the container system would be a version of the Microwave Power Transceiver - a part that will allow the power logistics to work on the base, meaning you can have the base power nearby ships, or have a power station that powers several nearby bases.

We do have a recycle part with 70% recycling without water - the Central Hub. It can *also* do water purification, but it's got the normal recycler as well. It's big, but it is the central hub of an advanced base. In general I like - I even really like the idea of splitting the Chemicals, Polymers and Metals converters - it makes conceptual 'mine and refine' bases an obvious choice, which I feel is a weak point in UKS. The only real issues I have are with SpecializedParts - UKS has it as the 'hard to produce' resource you need as well as MaterialKits to build/service your ships. You've got it with a simpler process, and being used to produce MaterialKits. (Was that just an oversight/misunderstading? UKS has them needed for Machinery, not MaterialKits.) You've also dropped a resource from them - in UKS they require both ExoticMinerals and RareMetals. Of course, most of the 'hard to produce' in UKS is that SpecializedParts require a MK-III piece, where MaterialKits can be done with a MK-V. So that depends quite a bit on the design of the 'Fabrication' module - high heat/mass/EC/etc. to do production could make my concern moot. The other thought is on Dirt - and I keep going back and forth on that. I tend to think of Dirt as an early-stage colonization resource - you can send up a dirt drill, a couple of MK-V parts, and get MaterialKits production up and running to build the rest of your base. I'm not sure if that's a niche we want to get into - though you could do it with basically container-sized low efficiency parts for the sifter and refiners. (Basically make the containers the MK-V of this mod, so you have a sifter, chemical plant, polyermerizer and smelter in that form factor as well. You could then upgrade your base by putting in the full form factor, taking advantage of your existing Process Coordination part.) But then that's even more parts. I haven't made much use of the MK-III sifter, so I'm not sure how useful that would be, or if we want one. My current leaning (as of this minute...) is to say 'Let this be the more built up mod - forget Dirt, they can use MK-V parts if they want to.'

I think we're pretty good on the USI-LS stuff, actually - unless we want to figure in wear, but that's not enabled in a default USI-LS install. (Even though it's a USI-LS mechanic.) I'll admit I haven't run the numbers on the greenhouse converters - but they don't lose or gain Supply mass, so they can't be to far off. Base USI-LS doesn't even have a way to produce fertilizer, and we add one in - which I like; a base-building project should look to be more sustainable. UKS would need to add wear, logistics, living/workspaces, and maybe some production parts to enable the supply chain for wear/EL/OSE. My patches cover most of that, but might be tweakable for better support coverage and I need to figure out the living/workspaces stuff. The production parts could either be included or in a separate mod - RoverDude's been known to tweak the supply chain on that a few times, so it's not exactly a fixed target.

I'll answer your question, so you have my view as well. There are several reasons, both in-game and out: Outside of the game, it makes sense from a balance perspective to not have the parts be high quality recyclers (and 70% is pretty high - 80% is max; anything beyond that is supposed to be a water purifier). You want to have a reason to have a more dedicated recycling part as well. In-game, the thought would be that the habitats have facilities for things like laundry and air purification that tie in and tuck mostly out of the way, and their 'designed' load is their normal crew capacity, but you build in a bit of headroom, so you can hot-bunk in an emergency or de-rate while you do maintenance. (Why I was thinking of 'space+2' - the +2 is the designed safety margin.) Basically, they aren't actually designed to run at 100% load, in my mind.

The rover in the most recent image is the Malmute. It's one of RoverDude's mods.

Make it depend on CRP, then it will only show up if the resource is installed. (Of course, we're talking about this in the context of USI stuff - which also depends on CRP.) The other issue I can think of is if we're adding it to the stock drill and another mod creates it's own drills for it - do we want to double it in that case? UKS adds drills for all of them, so again if we're doing a compatibility patch you might not need to add drills in that case. (Though USI-LS doesn't add drills for them - but it also doesn't have a way to produce fertilizer off-world, so do we want to add that capability for the USI-LS only patch?) Of course, the UKS drills aren't in the Planetary Base form factor - if we're doing in that form factor then that's enough of a difference that duplication isn't as much of an issue for me.

True. I know however that it didn't work until I wrote the patch in question, and it worked after. Still, knowing what the correct expected behavior is we can make sure the patch is correct.

RoverDude's suggestions are based on the mass of the part - many of his current parts are inflatable, and therefore very light. These parts are heavier, as solid pieces. If you run the numbers, you'll see you get a lot less recycling per mass unit with these suggestions than you do with UKS parts. That's what makes them underpowered - you can get more total recycling for less mass with other parts. (Though it gets distributed differently.) By mass, at the crew capacity of 3, the MK1 hab should be able to support a 60% recycler by RoverDude's guidelines. My suggestion is to keep the numbers a bit lower, so we increase the crew it supports. (Offsetting the mass in RoverDude's guidelines.) That gives us: MK1 habitat: 35-40% recycler at 5 crew capacity. (Exact guidelines would be 37%, but anywhere in that range would be 'close enough'.) MK2 Habitat: 50% recycler at 5-6 crew. (It's closer - I'd suggest 6 crew capacity, to be more inline with the idea of 'LS recycler for space+2' theme.)

clearing bad table I can't remove...

Looks good - though I don't have time to test at the moment. I'll try to remember to double-check it next time I can fire up KSP. And yes, the :NEEDS is a good idea - I can't believe I forgot that. (:HAS in this case is debatable - but it doesn't hurt. I mostly use that in my personal additions so that if a future update include official support my patch will get ignored. This is official support.)

Ok, Papa_Joe responded over in the CLS thread - We're not sure why it works on my box, but adding the passable would be the right thing to do. So, @RoverDude, feel free to merge in the pull request @Sherrif put up.