DStaal

Ok, so a bit more on the short-term... Here's a list of parts and specs that are interesting from a USI-LS perspective: Part PartName Mass Seats Months Multiplier EC/s Recycler % Airfilter KKAOSS_LS_container_airfilter 0.7 0 n/a n/a n/a n/a Algae Container KKAOSS_LS_container_algae 0.5 0 n/a n/a n/a n/a Carbon Extractor KKAOSS_LS_container_carbon_extractor 0.7 0 n/a n/a n/a n/a Elektron Container KKAOSS_LS_container_elektron 0.7 0 n/a n/a n/a n/a Greenhouse Container KKAOSS_LS_container_greenhouse 0.5 0 n/a n/a n/a n/a Sabatier Container KKAOSS_LS_container_sabatier 0.7 0 n/a n/a n/a n/a Water Purifier Container KKAOSS_LS_container_waterpurifier 0.7 0 n/a n/a n/a n/a Recycler Container KKAOSS_USI_Recicler_g 3.5 0 n/a n/a 6 70/6 Greenhouse KKAOSS_Greenhouse_g 3.0 2 0 1.3/2 0.525:1 35/4 Central Hub KKAOSS_Central_Hub 7.5 6 60/6 0 0.925:(5/15) 70/8(90/8) MK2 Habitat KKAOSS_Habitat_MK2_g 2.6 4 30/4 1/4 0.7 n/a MK1 Habitat KKAOSS_Habitat_MK1_g 1.7 3 20/3 0 0.45 n/a Cupola KKAOSS_Cupola_g 1.75 1 0 2/2 0.09 n/a Science Lab KKAOSS_Science_g 3.55 2 0 1.25 :1.2 50/5 Not all of these parts are currently in effect with USI-LS, but they exist and are used for other LS mods if so. In the Months, Multiplier, and Recycler coloumns the format is 'quantity/crew affected'. EC/s is Habitiation on the left side, recycler on the right. The Central Hub is 0.925 ec/s for the habitation, 5 ec/s for the recycler, and 15 ec/s for the purifier. Not in this chart are other effects: The Algae Container converts Ore+Mulch into Fertilizer, and the Greenhouses obviously convert Mulch+Fertilizer into Supplies. So: What needs to change? What should the 'correct' values be? Suggestions? My thought would be to actually give a decent multiplier for the Central Hub (you're taking all your paperwork and stuff out of your bunks and moving it to an actual office, which means a lot), remove the habitation months, drop the recycler entirely, and keep the purifier at 90 - but only for one Kerbal. It then gets things like Planetary Logistics and efficiency bonuses for other parts to make up for it. The rest I haven't thought about much. Mostly, they should just be brought into line with the current MKS, in my opinion - whatever that means. I do like the habitation multiplier on the large Greenhouse, at least in theory - I haven't looked at the numbers. As for the science lab on the Central Hub: We'd be removing that from base part - I'm not sure I want to do that. That's one I'd want to discuss with Nils277 before doing. Agreed on duping the KPBS SEP wedge for short-range power distributor. We might want another for the long-range. And on machinery: It's probable. They might even handle Enriched Uranium transfers. We need to take a look to be sure.

That looks very KPBS-alike.

Question - somewhat relevant to the recently added 'Rovers' category - What's the feeling on putting stock parts in CCK categories? I can see arguments either way, but I wanted to bring it up because stock *does* have a few dedicated rover parts. Should they be in the Rovers category? Or should that just be modded parts?

Out of curiosity: Did they start out as one ship, or did they get launched separately? I've noticed that if you un-dock you have to move a certain distance away before bringing docks back together and have them dock.

Just out of curiosity - and to make sure it's documented - what's the intended behavior when both NotGroundWorkshop and GroundWorkshop are on the same part? (You know it will happen eventually...)

For the life support, I agree it's the best option. I'm not so sure about it being the best option for the rest - see my discussion on options for KPBS+Pathfinder+MKS for one reason why. Also, I'm pretty sure we're going to need more parts at some point, and if it's 'officially' part of KPBS, that means Nils277 has to create parts for it - whereas if it's a community parts pack, he doesn't have headache. Or the headache for keeping it up to date in respect to MKS. Basically, I see USI-LS as a sideline to what I want to do here - but it's an important sideline, and one that needed to be dealt with soon, and needs to be thought about as the rest of this is handled. So, integrate the discussion (as it needed a place, and we needed to talk about many of the same things), but then spin that off as a patch to KPBS while the rest continues on. I definitely don't want to have a 'make everything a Duna/Tundra duplicate, and then change everything later' on the roadmap. That's just confusing to users and potentially save-breaking. That's why my first goal has been to get necessary functionality in place so that you can build a combined KPBS+MKS base without issues (including LS), and only once we've got that working to work on the more long-term goal of replicating the production chains. That's the stage where I don't want to just duplicate MKS parts. The reasoning is to give some interest: If all the parts are is the same thing in different form factors then the difference is purely aesthetic, and choices start to become either an art game (what's the prettiest base) or a numbers game (where can I abuse the balance). I'd rather continue the thought process of MKS that colonization is a hard task, and that there are many ways to do things. To that end, K&K Advanced Orbit and Surface Structures is a different company than Umbra Space Industries, and they've made different choices. A quick example so far being the Central Hub: The obvious 1:1 equivalent in MKS is a Pioneer - designed to be the first part down, and needs very little to be a mini-base on it's own. However, the Central Hub is larger form factor than the rest of the parts (unlike the Pioneer, which is the same size or *smaller*), and we're talking about it being more of the capstone of colony. In fact, the Pioneer is a good Ground Construction Workshop - a feature you're arguing against for the Central Hub. This is not immediate, it's just me trying to put out what I'm thinking long-term, so that if people want to help we won't be going in different directions. (And so that people can decide if they want to help, or if they want to try to talk me out of something.) That was actually my thought on those workshops. Wear is no longer a thing, and we should be using the actual workshop part, not the airlock. I actually don't either, really - but KPBS has three drills. So, what do we do: Ignore two? Make them all exactly the same, in that you can just switch them to be interchangeable? Neither really sits well with me, so the idea of having each one dedicated to a different 'class' of resource was a way to use all of them without making them into color-swap clones of each other. If you've got a better idea (or think you can argue for color-swap clones ) I'm open. I think we can justify it, but at the moment it really feels like the 'best of the bad options'. This mostly matches what I was thinking. And yes, not having Supplies or Mulch should be possible, I think. (Or at least, not having more than a few seconds worth.) Definitely Resource Distributor - that goes along with access to PL. I'm not entirely convinced it should be a Power Distributor - but then I think we should have a Power Distributor in the small container form factor (or two, like the two stand-alone parts for it in MKS), and the thought then is that by the time you get to putting in a Central Hub you probably already *have* a power network, so that putting on in the 'central office' is redundant.

Technically, there is one in the 1.25m size, though it still fits fairly well in the 0.625m size. And then there's the easy-to-overlook 'HT16 'Noon' Gridded Ion Engine Cluster'. In the 2.5m size - one of my favorite parts in the mod.

Fairly close, might do what you need to do:

I find the small Kontainers fit amazingly well on the Akita - three Akita beds, and the Kontainer laying on them. Almost perfect. Add a (small) docking port in the front and the back, and have a little four-wheel Akita with a seat in the front, and you've got a nice little set of runabouts. (The WBI Buckboards fit even better than Kontainers, actually...) There's an example in this screen shot:

(Or your Kerbals are such bad engineers that there's a lot of stuff to recycle near the space center... )

You made a commit - but you didn't make a Pull Request. That's where you submit it back to my repo. At the moment, you just have a fork. (And you don't need to create branches for every change you make - I'm being a bit complicated in my setup, but the idea is that *groups of related changes* are on a single branch. Basically - don't bother to create branches, I'll do that.) And you don't have to put the PRs on both. In fact, it's probably better you *don't*: Then I can just merge in on one, and I can push those changes around, instead of trying to make sure both merges are the same. Pick whichever feels comfortable for you to work with - I have a slight preference for GitLab, but I suspect I'll probably end up dropping that for this as everyone just uses GitHub. Thanks. At the moment, the only 'for sure we need' are the Kontainers - which you're already working on. I would not mind having the discussion in this thread - especially as from my roadmap that's really the next stage, to put all those in. I can see having RoverDude's advice would be nice, but he's busy already and it would keep the discussion separate from the problem/support discussions that normally happen in that thread. (And it's always possible he could pop in here.) That would mean that for users who have both this and Pathfinder, then yes the parts would no longer have any integration with the Pathfinder system. Part of the idea there being that then you have a choice: If you play with Pathfinder and MKS without this patch, you get Pathfinder/KPBS integration. If you play with Pathfinder, MKS, and this patch you get MKS integration. As there's a lot of overlap, trying to have both at the same time will just make things wonky. (And once Angel-125 refines his patch a bit, you can use the parts with USI-LS just fine either way.) I'm going by what's released at the moment, especially as it's not directly related to this patch set. If you do want a starter Unity/Blender project, a height adapter would probably be a good choice: Even just an angled tube would work. My thought is actually to distribute this at the end as a separate support mod, though if Nils277 wants to I'd be willing to help put parts or the whole thing into KPBS. (The life support rebalance especially - this is a good place to work on it, but it's probably best to merge those back into KPBS.) I haven't looked over all the parts very closely at the moment, but I do want to avoid just duplicating the MKS modules in a different form factor. On the other hand, my thoughts for the end goal is that you should be able to build a fully functional MKS base using just KPBS parts. (Though there should be cases where a mix is definitely a better choice.) As a quick question: I was planning on removing at least some of the functionality of the workbenches, and even thinking of retiring them, given that KPBS has real Workshops now. So, what are your mostly using them for? I want to make sure I don't break whatever it is that's keeping them useful. --- Hopefully I'll be able to start working on writing and testing some configs later today or tomorrow. A couple of thoughts I'm having: Splitting the drillable MKS resources up between the three drills currently in KPBS. My thought is to make one drill 'various metals', one 'various solids/minerals', one 'various liquids'. (I'll admit I haven't checked to make sure that this is possible using MKS's drillhead swap system.) Nerfing the central hub; I get the feeling that in some ways it's a bit of a do-everything part at the moment. I'd like to re-envision it as a command/control center, that doesn't do as much itself. I'm thinking it's main effects should be: Access to PL (where it's the only KPBS part for that), EL/Ground Construction setup, and a habitation multiplier - it frees up using *other* parts so they can be habitation. *Maybe* a small purifier, just to raise the top end of the recycling. (The goal being that you should be perfectly fine building a base without it - but adding it is a major boost to any base you build, and it's not a base on it's own. Last part you add, instead of the first.)

I'm thinking of doing several stages: First stage is to get storage and the basic mechanics (logistics, tethering, Kolonization bonuses) in place. Next stage is to do a good USI-LS balance pass, make sure everything's in good order. After that start working on integrating the MKS production chains, etc, to try to make it so you can build a full colony with KBPS parts - with the intent being the part set would be equivalent but not identical; have it fall somewhere between Duna and Tundra (probably), and split things up differently. The first stage will dupe a couple of parts to make things like Kontainers. The second works entirely with the KPBS parts, while the third is probably all duped parts - though likely some things will be added/changed in the new EL parts that KPBS added. Anyway: I got a chance to load in and do some experimenting. Angel-125's patch... Needs work. I think he didn't realize that KPBS already had USI-LS patches, and his conflict or ignore them, meaning some things just plain don't work, and some things work altogether to well. I'm definitely leaning towards having this patchset remove that integration entirely - though likely the best way to do that is in a single patch file, which the user could remove if they wanted. Also: Exactly how picky are we with adaptors? Here's the current joint between KBPS and a multi-hub (sorry for the lighting, this is my career save and I didn't want to wait until next morning): That's with the KPBS legs extended, obviously. There will be more difference if they are retracted. For myself, I'd be tempted to just use either the MKS or the KPBS flexotubes and make the connection - it won't be off more than two vessels would normally be on uneven ground. Otherwise, I think I still have the Garage Adapter I added a couple of nodes to around...

Minor issue with the MK4-1: We didn't know NFT had perfected invisible aluminum. (Note there is also a node at the correct location - this feels like a missing fairing of some sort.)

The point being that with this pack, everything's agreed on - whatever it is.

To expand on that: This mod is an *interoperablity* mod. It defines resources that a variety of other mods have found useful and want to use, in a way that they all can access them and agree on the properties of the resources. This way you don't have one mod defining that Kerbin's oceans are made out of Water and another defining that they are made out of IntakeLqd, or arguing over the mass per unit, or something like that.

Nice. (I assume the 'MTO' is what's being planned to have change for specific conents?)

My actual guess is that RoverDude spent a lot of time balancing the MKS parts - and then threw numbers at the stock parts.

I'd start with less boundaries, if that's possible. You're getting *very* precise in where you want to place the vessel, so EL doesn't have much choice. Usually I place a few origin stakes around an area (just so the vessel doesn't spawn directly on top of a stake), and maybe one boundary. In your case, I'd change all the X and Y stakes to origin, and move the -Z boundary uphill, if there's any slope.

The latest revision (not version at this point - but major revision) of USI-LS added EC usage - and I think that's included in the balance calculations somehow.

My plan is to have our own tanks regardless. But yes, you have the concept about right. Pathfinder loosely supports some MKS concepts - it's logistics attempts to tie in to MKS logistics, for instance - but the support isn't really full support and isn't always balanced. The issue to keep aware of is that it applies these templates to *other* parts as besides just tanks: For instance, I mentioned that it applied templates to the MK-II habitat - meaning that when I got to my pre-deployed base, it was configured to be a 'Pigpen', which is a *recycler*. It could be reconfigured to be a habitat, but it wasn't by default. (But note below for an issue.) Mostly I want it known and thought about, so we don't step on each other's toes. An example again from my own game: The MK-II was configured as a recycler - but I think it still had the habitation converter from the KPBS patch. So, definitely overpowered at that point. The question then is really do we want to defer to Pathfinder when it's present - make our patches conditional on it - or do we want to try to override it's integration? (There is a third option - which I consider the worst of both worlds - which is to dupe all the parts and provide an MKS-version alongside the Pathfinder version.) Making our patches - where they might conflict - conditional on there not being Pathfinder would be the easiest route, but it would mean less integrated MKS support at that point - and presumably if someone is installing this patch set they *want* MKS support. (On the other hand, Pathfinder's stuff is nice too, as it allows for a more flexible base setup.)

I don't believe you can, actually. It should be available in blizzy's, and I don't believe RoverDude ever put in an option to switch between the two. (Other than installing Blizzy's.)

It would depend slightly on what templates he has in use, but in general I think what we should do if both are present is to leave Pathfinder alone, and fill in some of the gaps. I doubt he wants to try to defer to our stuff, as he's got a system where you can switch between multiple production templates for various parts (and even things like wet workshops: Send up a tank full of fuel, empty it, and turn it into habitation, or a science lab) - and those templates can be shared among parts, so disabling one of those templates means *none* of the WBI stuff would have access to it. On the other hand, since all he's doing is adding the template switching to current parts and I was mostly thinking of cloning parts (except for the USI-LS stuff), we should be able to work around each other. Of course, if we're looking at it and think the Pathfinder USI-LS values are unbalanced, we should probably bring that to Angel-125's attention - as that will affect more than just the KPBS parts.

I still think it fits better on your cupola.

Ok, I was doing some base-building in my current game and stumbled (it was a bit of nasty surprise, as things weren't as I expected - though planning for it will be nice) across something we may need to decide how to handle: the current version of WBI Pathfinder includes support for applying templates to KPBS. Pathfinder includes USI-LS support. So, if someone has both KPBS systems and Pathfinder installed, they already have support for USI-LS, including habitation, recyclers, etc. (I haven't checked what all templates are available to all the parts - my MK-II habitats were configured as Pigpens, I know that.) So we're going to need to balance against that as well, for the USI-LS sections. However, Pathfinder doesn't really have full support for MKS - it's storage units can hold MaterialKits or Supplies for example, but not SpecilzedParts or ColonySuppies. So there's still a need here, especially for those who *don't* play with both Pathfinder and MKS.