DStaal

[1.2.2] [0.9.5] KPBS/MKS Integration Pack

Recommended Posts

6 minutes ago, Urses said:

Hi Chummer's, @DStaal@Merkov and @dboi88.

I Really appreciate your try to integrate the both bigguns at colonisatuon.

I See hove you are struggling with Integration of MaterialKits and i have a idea.

Nill's modules are mostly selfsustaining but they have a Common Ressource the EC. And MaterialKits world be only needed if MKS is present in all other Combinations you don't need them.

Would it not be easier to provide a small module like "Maintance Module", the smallest Container. That will be only activated füll if you have MKS there and that give the ability to deploy other modules. It hold all hydraliks and so on Inside and need a Engineer and EC to be used. And if no MKS is there you never Need this part and can prevent it from loading?

Yep, all of the above discussion only applies if MKS is installed.  :wink:  And if you have this mod (and MKS) you have both the Workbench - a part with a seat and MaterialKits storage, among other things - and several sizes of Kontainers that can hold all of the MKS resources, just like USI's Kontainers - except in KPBS form.  That includes both sizes of rack-mount container, as well as two larger sizes in the full KPBS form factor.

All of the above is dependent on having MKS and this mod installed.  So we've got that covered.  :wink:

Share this post


Link to post
Share on other sites

Why the strugle than?:wink:

If you will deploy without MKS, so as you wish. If you will deploy with MKS the Workbench is a Must-Have to deploy.

You only have to clarify it in the VAB/SPH "Attention! Deployment is not Inflation. For deployment a Engineer needs spezialisied Equipment. And this is provided by the Workbench. The part must be on the deployment-side and will be used automaticaly by any present Engineer". 

I Think it will clarify it for all Users. And the Process need than more Maschinerie or SpezialisedParts and not MaterialKits. You don't build something new you only use the ability of a part.

God Speed with Good work

Funny Kabooms 

Urses 

Edited by Urses

Share this post


Link to post
Share on other sites
2 minutes ago, Urses said:

Why the strugle than?:wink:

Because there's a big difference between 'I can fit the screws we'll need in my pocket' and 'we need to be able to refit the entire interior when we get there'.  :wink:  The main question is: How *many* resources do you need?   A Workbench can hold ~200.  Is that enough for one module's deployment?  Two?  Twenty?  Or do you need more than that?

Share this post


Link to post
Share on other sites

Hmm RD have somewhere a Spreadsheet with a qoutation of mass to Volume to Productivity.

And he use it for all Upgrades, inflates, efficience and so on. 

If i understand this right and  will be strikt on MKS if your mass Doubles you need MaterialKits in the same mass.

Deployables don't get mass up but Volume. And you don't get a Productivity Bonus because you only use the Item deployed. 

Thereafter you need to provide a Volumegain. If you provide a Volumegain of 10% of the objekt you need MaterialKits for 10% of Originalmass?

What about this?

200 MK's are 200kilo this means for my example you have Material to deploy up to 2tons on modules?

Edited by Urses

Share this post


Link to post
Share on other sites
26 minutes ago, Urses said:

Hmm RD have somewhere a Spreadsheet with a qoutation of mass to Volume to Productivity.

Yep.  Linked earlier in the thread, and I have a downloaded version.

27 minutes ago, Urses said:

If i understand this right and  will be strikt on MKS if your mass Doubles you need MaterialKits in the same mass.

Deployables don't get mass up but Volume. And you don't get a Productivity Bonus because you only use the Item deployed.

Note quite: Inflatables mass up by using MaterialKits.  So to double your mass you need your mass in MaterialKits.

We don't want to do that, because we're pretty set on our mass already.  :wink:

The productivity bonus is a separate mechanic.

29 minutes ago, Urses said:

Thereafter you need to provide a Volumegain. If you provide a Volumegain of 10% of the objekt you need MaterialKits for 10% of Originalmass?

Nope.  RD's calculations don't link mass to volume directly.  (There are often linked indirectly by what you are setting up, but you don't spend mass to get volume.)

31 minutes ago, Urses said:

What about this?

200 MK's are 200kilo this means for my example you have Material to deploy up to 2tons on modules?

200 MK's are 0.2 tons.  How many kilograms that is depends on which 'ton' you're using.  :wink: It's also 200 liters of storage space, which is how we're tending to think of things.  Current thought is to use ~100 MK's to deploy one module - which seems reasonable for materials to secure and seal the deployment.

Share this post


Link to post
Share on other sites
33 minutes ago, DStaal said:

Yep.  Linked earlier in the thread, and I have a downloaded version.

Note quite: Inflatables mass up by using MaterialKits.  So to double your mass you need your mass in MaterialKits.

We don't want to do that, because we're pretty set on our mass already.  :wink:

The productivity bonus is a separate mechanic.

Nope.  RD's calculations don't link mass to volume directly.  (There are often linked indirectly by what you are setting up, but you don't spend mass to get volume.)

200 MK's are 0.2 tons.  How many kilograms that is depends on which 'ton' you're using.  :wink: It's also 200 liters of storage space, which is how we're tending to think of things.  Current thought is to use ~100 MK's to deploy one module - which seems reasonable for materials to secure and seal the deployment.

Im Not Good at english. But i try.

1. Yes found your tread

2. Yep like i mean , you need MaterialKits in the mass like you gain on whight. If your Module whight 2tons (2000kg) and goes for 4 (doubles) you need 2tons on MK's (same mass as original)

3. Yes he don't but you have mass as a constant.

If (Volume to RD's Mechanik to mass = Productivity)

For you is only (Volume to RD's Mechanik = Productivity) something to bother because mass does not Change.

Simplifing? Makes it easier because you have more numbers to juggle.

And if 0.2tons = 200 Liter  (200kg if it is water:wink:) you have a way to simplify.

If your production go from 0 (undeployed) to x (deployed) you need only to look how Many MK's you need to gain this Upgrade and bring your Volumegain in there?

Let Speculate. You have the right numbers.

If for the Produktion Upgrade for 1ton/hour on Ressources you need 200 kilo MK's. And your Module produce deployed 1.2 tons/hour.

Than you need

1.2*200/1 = 240 kg on MK's for deployment.

Will this be a Way around?

Because RD'S Mechanik is constant and the mass?

Funny Kabooms

Urses 

Share this post


Link to post
Share on other sites

I think you're misunderstanding 'deployment' - it's not a noun, it's a verb.  You don't produce it, it's something you do.  The parts don't produce *anything* unless they are deployed, because they're in a stowed state.  And the volume of a part doesn't have any direct relation to it's mass, so you can't say 'I need this much mass to gain this much volume' - some parts are denser than others.

Share this post


Link to post
Share on other sites

I Think we have a Communication problem :-)

Let me sleep over maybe i find a Way to clarify my point:wink:

And One for Sure. No offense i realy try to help.

Funny Kabooms 

Urses

Share this post


Link to post
Share on other sites
14 hours ago, DStaal said:

Which is part of why I'm all over the place on how much it needs to be: Is it stowed in the part itself?  Part of it?  Would it be secure?  Etc.  (I'm not sure I trust the IVA of the undeployed pod though.)  Even if it there's space, I'm not sure it's *appropriate* space - in that it may not be secure enough to handle the stresses of launch, etc.

You can actually go down to IKEA and buy all their installation/assembly parts separately.  :wink:  I've even had some items from them where they're in a separate box.  But note that IKEA is obviously an over-simplification, and the question is how IKEA-like this actually is.  Also note that there are several parts in this pack that make shipping them easier: Both the Kontainers and the Workbench will hold MaterialKits, meaning an integrated packaging is quite possible - but I'm not sold on it being the *default.*

(Actually, my mental model has you needing to deploy these from Workbenches - which conveniently allow you to EVA and hold MaterialKits.)

Let's take your early Mun landers for an example: If they have several thousand for dark side transits, would 400-500 of it meant that you couldn't deploy until you were in the sun?  And would not being able to access the hab or greenhouse until sunrise have been an issue?  That's enough to have to think about, without over-doing it, I think.  Yes, if you have generation it's pretty trivial - but then it should be.  (And of course note that you can well have two/three of these in a base...)

For a Biologist - not without writing our own plugin.  Basically, if an ability doesn't exist in Stock, KPBS, or USI, we don't have it.  Which is also partly on the EVA issue - We can make it deploy without cost and without EVA, but that also means it doesn't need a Kerbal.  I *do* think it should take a Kerbal to deploy.  So to require a Kerbal, that Kerbal needs to be EVA, because that's what the tools we have support.  (And really, even a Ranger inflatable should be deployed from the inside.  I mean the Biglow module on the ISS was inflated by astronauts checking connections and opening valves, and that's basically a first prototype.)

Oh: And on the 'form over function' comment: We've just spent quite a bit of effort to make sure these parts aren't form over function, and are in fact just as functional as USI parts.  :wink:

This is possible - but could well be annoying, and remember that there are *three different* parts we're talking about here, not just the greenhouse(s).  If the Greenhouses require Water, that should be in *addition* to whatever the 'standard' costs are to deploy a KPBS part - which is shared by the MK2 Hab and the Science Lab.  And note that that then means you need to have a container for that resource as well - which if you *only* need to deploy can be annoying.

 
 
 
 
9

How do you split up quotes to reply piece by piece? I've tried normal forum commands like (/quote) with square brackets, and it just gets all screwed up in the preview. :/

Anyway, the workbench deployment is a -very- interesting idea, but... are you sure that's possible? I really like it if it is.

For the Mun landers, note that that's for -orbital- dark side transit. Landed dark side transit pretty much precludes the use of batteries and solar panels, as it takes huge amounts of time. AmpYear actually estimates the EC requirement for a landed dark side transit as infinite. So pretty much any ground base (which is what KPBS is designed for) is going to have generation and sufficient storage. There's probably enough EC simply built into the modules to make it a trivial matter; there certainly is in MKS parts. I haven't actually included even a single EC storage part in my Minmus base, and it still has six figures of EC storage.

Re: Biologist... Well, how about a biologist on EVA then? That would just be a matter of changing the skill required for deployment, right?

Also, MKS modules require a certain skill to be present for other buttons to function, as does stock for that matter; a science lab won't perform research without a Scientist present, no matter how many times you click the button. How is this any different? It just ties a different class to a different module, just like MKS does.

Re: form over function... Of course, I didn't mean to imply that you're not making them functional. But someone who is satisfied with function alone would just use MKS and be done with it, was my logic. If they're going to go to the trouble of downloading two extra mods to get "prettier" high-end ground bases, they obviously care about appearance quite a bit.

Re: three different parts... Is there a coding reason why there needs to be a 'standard cost'? There isn't in MKS. I'm not sure I agree that it needs to be the same. The greenhouse is an inherently space-filled part, because the plants need room and light to grow. Until they -do- grow, that's all just empty space, making it easy to collapse to half size, and still have room to spare for the equipment needed to deploy it.

On the other hand, I could totally see a habitation module requiring Material Kits, as there might not be enough room in the collapsed state for all of the furniture and equipment. So if the beds and life support are built into the wall sections, for example, they'd have to ship up food prep equipment, exercise equipment, tables and chairs, etc, to fill out the middle section once it's expanded.

As for it being annoying... I'm not sure I agree. To me, the underlying spirit of MKS is to -not- have to ship things up. Material Kits are basically a third-tier product on the manufacturing tree (mining, precursor production, then MKs). That means it's not always feasible to manufacture them right away (or at all for a small mining outpost), so you have to ship some up. Water is first-tier... just mining. And KPBS has that lovely inline water drill already built in. :wink: So rather than having to ship up your water, that just means having enough power generation and cooling to run the drill, and enough supplies to handle the hour or so it'll take it to generate enough water to expand the greenhouse. That, to me, adds variety and interest to the gameplay, rather than annoyance.

7 hours ago, DStaal said:

200 MK's are 0.2 tons.  How many kilograms that is depends on which 'ton' you're using.  :wink: It's also 200 liters of storage space, which is how we're tending to think of things.  Current thought is to use ~100 MK's to deploy one module - which seems reasonable for materials to secure and seal the deployment.

 
1

The game is quite explicit about a Ton being a Metric Ton. If you use the middle click in the VAB, all masses are given in Kilograms. In the parts list, they're given in Tons. They line up perfectly as 1000 kg = 1 ton.

In general, I've never seen the game not consistently use SI units.

Edited by FirroSeranel

Share this post


Link to post
Share on other sites
6 minutes ago, FirroSeranel said:

How do you split up quotes to reply piece by piece? I've tried normal forum commands like (/quote) with square brackets, and it just gets all screwed up in the preview. :/

Quote, delete what you don't want, Quote, delete what you don't want...  Ad nausium.  :wink:

6 minutes ago, FirroSeranel said:

Anyway, the workbench deployment is a -very- interesting idea, but... are you sure that's possible? I really like it if it is.

I'm sure you can stick a Kerbal in a workbench, EVA them from there, and deploy a module with them using the resources in the workbench.  :wink:

7 minutes ago, FirroSeranel said:

For the Mun landers, note that that's for -orbital- dark side transit. Landed dark side transit pretty much precludes the use of batteries and solar panels, as it takes huge amounts of time. AmpYear actually estimates the EC requirement for a landed dark side transit as infinite. So pretty much any ground base (which is what KPBS is designed for) is going to have generation and sufficient storage. There's probably enough EC simply built into the modules to make it a trivial matter; there certainly is in MKS parts. I haven't actually included even a single EC storage part in my Minmus base, and it still has six figures of EC storage.

That does depend a bit on how a particular player builds bases.  I tend to land out smaller pieces that may not have enough to do things on their own and join them up.  It's not uncommon to have my first crew of Kerbals sit out half a night with no power...

Later on, sure - I'll have added on more power and generation to handle things.  But that may not have been my top priority.

10 minutes ago, FirroSeranel said:

Re: Biologist... Well, how about a biologist on EVA then? That would just be a matter of changing the skill required for deployment, right?

In RoverDude's code, yeah.  It's not something in the config file however.  (And honestly, if this is the type of thing you're looking for - install Pathfinder and ignore this mod.  You'll get this type of behavior out of the KPBS parts.)

13 minutes ago, FirroSeranel said:

Also, MKS modules require a certain skill to be present for other buttons to function, as does stock for that matter; a science lab won't perform research without a Scientist present, no matter how many times you click the button. How is this any different? It just ties a different class to a different module, just like MKS does.

It's not exposed to modification though.  There would need to be a change in the plugins we're piggybacking on.  (I'm not writing a plugin for this mod.  It kinda would defeat the purpose.)

15 minutes ago, FirroSeranel said:

Re: three different parts... Is there a coding reason why there needs to be a 'standard cost'? There isn't in MKS. I'm not sure I agree that it needs to be different. The greenhouse is an inherently space-filled part, because the plants need room and light to grow. I could totally see a habitation module requiring Material Kits, as there might not be enough room in the collapsed state for all of the furniture and equipment. So if the beds and life support are built into the wall sections for example, they'd have to ship up food prep equipment, exercise equipment, tables and chairs, etc, to fill out the middle section once it's expanded.

No particular coding reason - but as a player, if I saw these three parts that had the same size and form factor, and deployed in the same way, I'd expect them to have the same cost to deploy.  These aren't inflatables, and their IVAs show layouts that are designed to not interfere with each other in their collapsed state (and are bolted in), so I don't think we need to account for interior furnishings. I'm open to the idea of specific costs on top of that - but you'd have to really talk me into it if you want more resources, as even just playing around with both MaterialKits and SpecializedParts was easily more than twice as annoying in my opinion.

I made the point earlier that there's no real gameplay difference between 1 and 100 units of any resource - either one means you can deploy multiple from one of the smallest container available.  There's also no real gameplay difference between 2 units of different resources and *400* units of one resource - either way you need two of the smallest containers.

23 minutes ago, FirroSeranel said:

As for it being annoying... I'm not sure I agree. To me, the underlying spirit of MKS is to -not- have to ship things up. Material Kits are basically a third-tier product on the manufacturing tree (mining, precursor production, then MKs). That means it's not always feasible to manufacture them, so you have to ship some up. Water is first-tier... just mining. And KPBS has that lovely inline water drill already built in. :wink: So rather than having to ship up your water, that just means having enough power generation and cooling to run the drill, and enough supplies to handle the hour or so it'll take it to generate enough water to expand the greenhouse. That, to me, adds variety and interest to the gameplay, rather than annoyance.

You can always recover MaterialKits from discarded parts however - that's a zero-tier solution for small amounts.  (And we are talking small amounts.)  Water is first-tier - if you have a drill.  Which is 0.9 tons of equipment that will be useless once the Greenhouse is deployed - because the Greenhouse doesn't use water.  (Ok, the two planetary cultivators we add based on the greenhouse do.  But the actual 'Greenhouse' doesn't.  :wink: )  Oh, and of course you can't depend on water everywhere you'd want a base.  So it'd become actually *easier* to ship it up.  In a container.  Which you'll never use again, until you expand to having a Central Hub, most likely.

So it's annoying - It's a hoop that doesn't have anything to do with the part, and which doesn't add to anything that the part will be useful for down the road.  It *might* be useful in a large base - but it doesn't have to be, and it's usefulness is entirely situational and dependent on your later plans.  Whereas MaterialKits - you almost always have a couple of descent engines you never plan on using again.  They'll provide enough MaterialKits to deploy a part or two, and then you can use what's left over to do routine maintenance on your production equipment - including your Greenhouse.  If you're using a Workshop for that storage, it has enough for the initial deployment, and your Engineer can then make that their work post to keep your base in good shape.  It all builds on each other, instead of being an extra piece off to the side.

Share this post


Link to post
Share on other sites
9 hours ago, DStaal said:

Quote, delete what you don't want, Quote, delete what you don't want...  Ad nausium.  :wink:

Actually, I found out that if you highlight some text in someone else's post, then hover over it, a "quote this" button shows up nearby, that quotes just that text. :D

9 hours ago, DStaal said:

It's not exposed to modification though.

Gotcha. I didn't know. 's why I asked. :wink:

9 hours ago, DStaal said:

I made the point earlier that there's no real gameplay difference between 1 and 100 units of any resource - either one means you can deploy multiple from one of the smallest container available.  There's also no real gameplay difference between 2 units of different resources and *400* units of one resource - either way you need two of the smallest containers.

 

True. And since part count, both per vessel and in the scene, is critical to performance of bases, graphically and physics-wise... why require a token amount that can easily be recovered from a descent engine or two at all, and require an extra part? The furniture thing is just my way of rationalizing it taking materialkits at all. Really, I kind of don't see the point. The several tens of thousands of MK required to inflate, say, an 8-kerbal base's worth of greenhouses and living quarters, means setting up a manufacturing chain, or disassembling one -hell- of a landing stage, or both, and having truly meaningful amounts of storage for them built into the base, at least at first. Plus the later planetary greenhouses are almost entirely what I'm talking about. The ones that are just flashy Nom-o-Matics don't particularly interest me personally. It's not exciting to me for whatever reason. I don't usually even include them in my base designs, despite that that wastes Mulch. It just... doesn't suit my taste. *shrugs* Not that you shouldn't include them or anything of course.

9 hours ago, DStaal said:

(And honestly, if this is the type of thing you're looking for - install Pathfinder and ignore this mod.  You'll get this type of behavior out of the KPBS parts.)

I like the resource chains and the challenge of MKS. I like that it transforms the game from stock's "go fetch science points from different biomes", into actually scanning and mapping planets, scouring them for the best locations, planning out what resources to get from where, and so on. I like the Duna and Ranger modules. They feel advanced but realistic. I just... really don't like the Tundra modules. I don't like the NASA design they were copied off of. To me, it looks like they landed a chunk of the ISS, rather than designing something that's actually built for the ground, and if Duna could Recycle, and could make Silicon, Refined Exotics, Colony Supplies, and Specialized Parts, I'd just forget about Tundra unless I'm building an orbital station, and never look back.

On the other hand, I like the KPBS models a lot, but I don't like how simple it is to "colonize" with them, or that the upper limit of their usefulness is to just be able to say you have a colony, not to -do- much of anything with it, aside from maybe mine fuel, which frankly is not that hard to do in stock with a totally automated system with no kerbals at all. If I'm gonna go to the trouble and expense and challenge of building permanent kerbal colonies, A: I want it to feel like I've really accomplished something, which MKS does extremely well... and B: I want it to be able to -do- something for me, which the integration with Workshop and Ground Construction do.

So I'm interested in this mod to basically be able to play MKS with prettier parts that make more sense to me for a near-future land base. Of course, it seems RD is making some rather gorgeous models for a larger form factor for MKS, so I dunno. I will check out Pathfinder, though. I'd not heard of it until a few days ago.

So...what am I saying, in terms of this discussion? *ponders*

I guess I'm saying, "go big or go home", in a way. Either make the resources required to deploy serve as a meaningful barrier that takes significant effort, to give the player a sense of achievement, or assume that the KPBS modules are inherently well-designed, and just need to expand with hydraulics and then nothing... no bolts to do up, nothing. An MK requirement that really just boils down to a single small storage part and an engine to disassemble seems to me like creating extra busy-work with no real challenge; very small hoops for the player to arbitrarily have to jump through. And it just seems... I dunno. It just doesn't sit right with me.

The problem, obviously, is that a serious quantity of MKs would make no sense, since they're not really inflatables. And yet to make them deployable with no effort kind of defeats the spirit of the Duna/Ranger feel of MKS (though not a pure Tundra base, actually). So instead you're faced with basically arbitrarily choosing a small number. I dunno... it's a tough choice, honestly. I can see why you're torn.

Share this post


Link to post
Share on other sites
16 minutes ago, FirroSeranel said:

I guess I'm saying, "go big or go home", in a way. Either make the resources required to deploy serve as a meaningful barrier that takes significant effort, to give the player a sense of achievement, or assume that the KPBS modules are inherently well-designed, and just need to expand with hydraulics and then nothing... no bolts to do up, nothing. An MK requirement that really just boils down to a single small storage part and an engine to disassemble seems to me like creating extra busy-work with no real challenge; very small hoops for the player to arbitrarily have to jump through. And it just seems... I dunno. It just doesn't sit right with me.

The problem, obviously, is that a serious quantity of MKs would make no sense, since they're not really inflatables. And yet to make them deployable with no effort kind of defeats the spirit of the Duna/Ranger feel of MKS (though not a pure Tundra base, actually). So instead you're faced with basically arbitrarily choosing a small number. I dunno... it's a tough choice, honestly. I can see why you're torn.

Yep.  You're getting caught up to where we are now.  :wink:  A large requirement of MaterialKits doesn't make sense - RoverDude uses that to balance the low mass of the inflatables, but we don't need to do that.  On the other hand, this pack is to supposed to 'MKS-ize' KPBS, and under MKS it takes some effort to deploy a part - and I do want to keep that.  Being able to press a button on Kerbin to have a hab deploy seems a bit silly to me - there should be someone there checking it out to make sure things work, and the very least, for any habitable parts.

And for long-term use it makes sense to want something a bit more fail-safe to hold your structure in place.  If it's just hydraulics or a motor - well, if they fail and something bumps your base, your base will fold back in on itself, if only by a few inches.  But a few inches means wires don't line up, gaskets aren't in place, etc.  Depending on your design, it might be a big problem or a small one, but it will be a problem.

Better to have it deploy and then have your crew going around to secure things into place with mechanical fasteners - something that can't backtrack or release.  A few strategically placed bolts, a 'weatherstrip' over the seal, and the place will be much stronger, and more damage-resistant.  So it does make sense to have some small amount of MaterialKits used to deploy it.

I'll admit, I hate sticking small containers on that I don't use for much.  A rack is *always* an inconvenience in a base design, since I play with CLS.  I was trying to think of alternatives when I remembered one of the first parts this pack added: The workbenches.  They already hold as much as small storage container and are designed explicitly for this type of thing - and have use further into the life of the base.  So then I don't worry about that as much, because there are two options just from this pack, as well as the more normal MKS options.

100 liters of MaterialKits actually makes sense to me - most of that would be in long 'weatherstrips' for reinforcing the seals.  They aren't much, they are easy to install - but automating their install defeats their purpose, as they need to be securely and permanently attached to both sides of the seal.  So we have a realistic use-case as justification for a moderate amount of MaterialKits and needing a Kerbal to deploy.  Making the hoop not completely arbitrary in the end - which was the goal: To see if there was a realistic amount of something that could be what they needed to apply.  There is, and we even have a good way to carry or store it to make it accessible.

Share this post


Link to post
Share on other sites
17 minutes ago, DStaal said:

Yep.  You're getting caught up to where we are now.  :wink:  A large requirement of MaterialKits doesn't make sense - RoverDude uses that to balance the low mass of the inflatables, but we don't need to do that.  On the other hand, this pack is to supposed to 'MKS-ize' KPBS, and under MKS it takes some effort to deploy a part - and I do want to keep that.  Being able to press a button on Kerbin to have a hab deploy seems a bit silly to me - there should be someone there checking it out to make sure things work, and the very least, for any habitable parts.

And for long-term use it makes sense to want something a bit more fail-safe to hold your structure in place.  If it's just hydraulics or a motor - well, if they fail and something bumps your base, your base will fold back in on itself, if only by a few inches.  But a few inches means wires don't line up, gaskets aren't in place, etc.  Depending on your design, it might be a big problem or a small one, but it will be a problem.

Better to have it deploy and then have your crew going around to secure things into place with mechanical fasteners - something that can't backtrack or release.  A few strategically placed bolts, a 'weatherstrip' over the seal, and the place will be much stronger, and more damage-resistant.  So it does make sense to have some small amount of MaterialKits used to deploy it.

I'll admit, I hate sticking small containers on that I don't use for much.  A rack is *always* an inconvenience in a base design, since I play with CLS.  I was trying to think of alternatives when I remembered one of the first parts this pack added: The workbenches.  They already hold as much as small storage container and are designed explicitly for this type of thing - and have use further into the life of the base.  So then I don't worry about that as much, because there are two options just from this pack, as well as the more normal MKS options.

100 liters of MaterialKits actually makes sense to me - most of that would be in long 'weatherstrips' for reinforcing the seals.  They aren't much, they are easy to install - but automating their install defeats their purpose, as they need to be securely and permanently attached to both sides of the seal.  So we have a realistic use-case as justification for a moderate amount of MaterialKits and needing a Kerbal to deploy.  Making the hoop not completely arbitrary in the end - which was the goal: To see if there was a realistic amount of something that could be what they needed to apply.  There is, and we even have a good way to carry or store it to make it accessible.

 

*nods* I like it. Your reasoning is sound. And it's not like you can't disassemble the MK storage once you've deployed. A full-service base will have some designated storage for MKs anyway, as they're a precursor as well, for Machinery, Colony Supplies, ships, and Workshop parts.So launching a small container for them with each smaller outpost isn't that big of a deal ultimately. What I really wish is that deployment was defined as a consumer for Material Kits, so that it'd pull them from local distributors... it kinda doesn't make sense that they don't, RP-wise. The hoops I had to jump through, piping "material kits" through a hose of all things, to a rover, to drive literally 20 meters, mostly to turn the thing around, to then pipe them into my mining outpost, instead of carrying them the 20m, made no sense whatsoever.

Might be something to talk to RD about.

Share this post


Link to post
Share on other sites
9 minutes ago, FirroSeranel said:

*nods* I like it. Your reasoning is sound. And it's not like you can't disassemble the MK storage once you've deployed. A full-service base will have some designated storage for MKs anyway, as they're a precursor as well, for Machinery, Colony Supplies, ships, and Workshop parts.So launching a small container for them with each smaller outpost isn't that big of a deal ultimately. What I really wish is that deployment was defined as a consumer for Material Kits, so that it'd pull them from local distributors... it kinda doesn't make sense that they don't, RP-wise. The hoops I had to jump through, piping "material kits" through a hose of all things, to a rover, to drive literally 20 meters, mostly to turn the thing around, to then pipe them into my mining outpost, instead of carrying them the 20m, made no sense whatsoever.

Might be something to talk to RD about.

That's definitely something to talk to RD about.  Note that for us at least the new KIS-mountable Kontainers (and the rack-mountable ones as well, though not quite as easily) mean that you can just carry the resources over.

Share this post


Link to post
Share on other sites
1 minute ago, DStaal said:

That's definitely something to talk to RD about.  Note that for us at least the new KIS-mountable Kontainers (and the rack-mountable ones as well, though not quite as easily) mean that you can just carry the resources over.

 
 

Well... kind of. With a rover and multiple kerbals, at any rate. Not sure that's any easier than the KAS-pipes.

Well, for small amounts it'd be carriable, I should say. But I need 16,000. 8 tons at a time, for 2 Hab modules. XD That's 9 kerbals.

Edited by FirroSeranel

Share this post


Link to post
Share on other sites
19 minutes ago, FirroSeranel said:

Well... kind of. With a rover and multiple kerbals, at any rate. Not sure that's any easier than the KAS-pipes.

Well, for small amounts it'd be carriable, I should say. But I need 16,000. 8 tons at a time, for 2 Hab modules. XD That's 9 kerbals.

Which is why I said 'for us' - the backpack-carryable Kontainers can hold about 1000 MK, IIRC.  That's plenty for deploying these parts, but a drop in the bucket for the MKS inflatables.  :wink:

Share this post


Link to post
Share on other sites

My ears were burning :wink:

Did not have a chance to read the whole thread... but saw some discussion on mass/volume/etc. - and assuming the goal is MKS balance given the nature of the mod.

Short version.  A converter's capabilities are driven by mass OR volume, whichever is most restrictive (take your pick). 

So base efficiencies off of the final deployed mass or final deployed volume, whichever is more restrictive.  You can't have a farm in a lead thimble, and you can't have a refinery in a giant (empty) balloon.

In MKS land, the only reason there's a cost for deployment is to consume/reassign mass (this by the way is done via a hidden resource so that you can launch light stuff and turn it into heavy stuff).  If you don't need to adjust mass, then no need to charge for deployment (and just use the deployed volume and deployed mass as noted above).

@FirroSeranel - explain what you mean by deploying being an MK consumer?  There's a bit of something I am working on that will eliminate the need to have local storage to take advantage of planetary logistics (ideal for your one-offs), but that may or may not be what you're looking for.

Share this post


Link to post
Share on other sites
9 minutes ago, RoverDude said:

My ears were burning :wink:

Did not have a chance to read the whole thread... but saw some discussion on mass/volume/etc. - and assuming the goal is MKS balance given the nature of the mod.

Short version.  A converter's capabilities are driven by mass OR volume, whichever is most restrictive (take your pick). 

So base efficiencies off of the final deployed mass or final deployed volume, whichever is more restrictive.  You can't have a farm in a lead thimble, and you can't have a refinery in a giant (empty) balloon.

Interesting.  That's not *quite* the same as how I understood it - but I don't think it would have made much if any difference to how we balanced things.  I just sent a PR this morning to Nils277 with our LS-only changes, so hopefully that'll be ok.  Either way, we generally tried to balance against both, and got fairly close.

Of course, we were talking about farms and recyclers at this point.  Refineries are still to come.  :wink:

12 minutes ago, RoverDude said:

In MKS land, the only reason there's a cost for deployment is to consume/reassign mass (this by the way is done via a hidden resource so that you can launch light stuff and turn it into heavy stuff).  If you don't need to adjust mass, then no need to charge for deployment (and just use the deployed volume and deployed mass as noted above).

This I was aware of - part of the discussion was how we wanted to do this without upsetting the balance of the parts.  We knew from a pure balance standpoint that the resources weren't necessary for the mass, but we wanted some of the feel of having them.  Hence a discussion on how many to use to make it feel realistic, non-trival, and yet not unbalance things.  :wink: (This is part of this pack, not part of the PR I sent to Nils, as it's effectively an MKS mechanic, not a USI one.  Which also means that the parts should balance fairly well either with or without the resources, as people will be using them both ways.)

16 minutes ago, RoverDude said:

@FirroSeranel - explain what you mean by deploying being an MK consumer?  There's a bit of something I am working on that will eliminate the need to have local storage to take advantage of planetary logistics (ideal for your one-offs), but that may or may not be what you're looking for.

That's basically what he was looking for - a way to deploy something when he has all the resources 50 meters away in another ship.  Having to run a pipe across is a bit odd.

Share this post


Link to post
Share on other sites

If the resources are 50m away no pipe is needed, it should pick them up automatically for mks deployments

Share this post


Link to post
Share on other sites
50 minutes ago, RoverDude said:

My ears were burning :wink:

Did not have a chance to read the whole thread... but saw some discussion on mass/volume/etc. - and assuming the goal is MKS balance given the nature of the mod.

Short version.  A converter's capabilities are driven by mass OR volume, whichever is most restrictive (take your pick). 

So base efficiencies off of the final deployed mass or final deployed volume, whichever is more restrictive.  You can't have a farm in a lead thimble, and you can't have a refinery in a giant (empty) balloon.

29 minutes ago, DStaal said:

Interesting.  That's not *quite* the same as how I understood it - but I don't think it would have made much if any difference to how we balanced things.  I just sent a PR this morning to Nils277 with our LS-only changes, so hopefully that'll be ok.  Either way, we generally tried to balance against both, and got fairly close.

Of course, we were talking about farms and recyclers at this point.  Refineries are still to come.  :wink:

I think we only got creative in two ways: the recycler containers, and our focus on floor space for habitation purposes. Unfortunately, the recycler container profile was a little restrictive, so we've made them more powerful than they *should* be volume-wise, but they are also much heavier. The alternative was going to be to make the recycling containers too weak to be useful. As for habitation times, we found that Nils' base parts tend to have a decent sized footprint, but they are only as tall as a kerbal needs. This means that they aren't terribly voluminous (compared to something spherical or cylindrical) but all of the space is useful living space; there aren't any awkward curves or anything. This is why we gave the base parts each a small hab multiplier. What I found was that the KPBS MK1 habitat would have less hab time than the Ranger mini hab even though they had roughly the same footprint. The mini hab, though, got very tall in the centre, so it had a higher volume. The MK1 habitat doesn't get nearly as tall, but it also doesn't lose the space around the edges either. Adding a small hab multiplier to base parts seemed to be a decent compromise.

Quote

In MKS land, the only reason there's a cost for deployment is to consume/reassign mass (this by the way is done via a hidden resource so that you can launch light stuff and turn it into heavy stuff).  If you don't need to adjust mass, then no need to charge for deployment (and just use the deployed volume and deployed mass as noted above).

Quote

This I was aware of - part of the discussion was how we wanted to do this without upsetting the balance of the parts.  We knew from a pure balance standpoint that the resources weren't necessary for the mass, but we wanted some of the feel of having them.  Hence a discussion on how many to use to make it feel realistic, non-trival, and yet not unbalance things.  :wink: (This is part of this pack, not part of the PR I sent to Nils, as it's effectively an MKS mechanic, not a USI one.  Which also means that the parts should balance fairly well either with or without the resources, as people will be using them both ways.)

This reminds me: if we're using the USI deployment module and USI converter/other modules, does that mean that the deployable base parts can only use their functions once they have been deployed? I haven't actually played around with this any (since I am a slave to 'the rules') but it seems like something we should try to ensure.

Share this post


Link to post
Share on other sites

The resource transfer problem is solved... MKS does behave as I was proposing. My issue was a conflict (no bugs, just unfortunate overlap of features) between MKS's resource management, and GPOSpeedFuelPump.

Basically, all parts with local warehousing were set to lower priority in GPO than consumers (without warehousing), so it was immediately and thoroughly removing -all- resources from the warehouses to send to the production modules' internal storage, leaving them empty. So when I tried to use resources in another ship, there were no warehoused resources to pull from.

Then when I would pipe resources in manually, it still wouldn't work, because I had to have local warehousing off on the outpost, or the main base, thanks to GPO, would suck them out right away. Warehousing of course being -how- the engineer can actually use the resources to switch sifters/deploy modules, it wasn't working.

Edited by FirroSeranel

Share this post


Link to post
Share on other sites

Just wanted to drop in and say bravo to everyone working on this.

Once upon a time, I myself tried creating a "compatibility layer" between KPBS and UKS... but I was hampered by a lack of texturing skills and I struggled to keep up with the combined development speed of both mods. So it is great to see others in the community have apparent success here.

Share this post


Link to post
Share on other sites

Ok, status updates:  Nils277 has got the patches we're sending him - he said he'll be looking them over this week and roll them into the next release of KPBS - which will be when KSP 1.3 hits.  I've updated the Readme and Changelog, so we're basically ready for that - I may poke around at the Central Hub a bit, but that's just twiddling.  The version file will need to be updated as well, but I want to leave that until the very last thing.

I've created a new project on the Github page for stage 3: https://github.com/DanStaal/KPBStoMKS/projects/2  Currently it's pretty empty - I haven't moved any of the per-existing issues to it because I'm not entirely sure we want to use that part split - it was designed under the previous version of MKS, without having the two industrial parts that were added to KPBS for EL integration.  There's also a branch on the repository for us to work on stage 3 in.  (The advantage of the complicated way I'm using Git here is that I *can* do this: The 'Development' branch at this point should basically be for any final tweaks to stage 2, and we can work on stage 3 in it's own branch.)

Share this post


Link to post
Share on other sites

Ok, question for thought/debate:

Should the K&K parts work as efficiency parts for the USI line of parts, or should they be separate?  The first has the advantages of interoperablity, while the second allows us more flexibility on design.  This can be by part to an extent: Any part can get efficiency boosts from one set of efficiency parts, and efficiency parts can switch between being efficiency modes.

One thing to note is that the idea of a two-part industrial setup (going back to the diagram I posted at the beginning of the thread) probably requires that we separate the efficiency lines, at least for that set of parts.  So one option would be to have separate lines for industry and interoperate with the USI efficiency line for LS.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.