[1.2.2] [0.9.5] KPBS/MKS Integration Pack

[dboi88]

Just now, DStaal said:

I look forward to them.  As for the animations: If it were just a stand-alone animation, I suspect there would be no problem.  But in this case an animation deploys *only* when something else happens: The crew capacity increases, an IVA is changed/added, some resources are consumed, etc.  That's where I think the problem lies.

However, I'd admit I didn't do a very thorough investigation - I just tried the two most obvious MM options, and found that while the resources were consumed and other changes appeared to occur, the animation didn't play.  Feel free to poke if you want.

You're right it isn't as simple as it seems just switching the animations don't work, but still an animation in Unity as far as i know is just set to play always or not, then you can call the name of the animation in all sorts of different modules if it isn't set to play always, I've messaged RD to see if he can poke us in the right direction. I'd have assumed that the stock override modules are what is changing the configs but i'd have imagined that it would still just call the animation to play as normal.

[dboi88]

[dboi88]

Switchable tanks are all done  

 

[Merkov]

On 2/12/2017 at 11:25 AM, DStaal said:

Ok, here's a suggestion for balancing the MK-1 habitat, with a 2.5m Tundra for comparison:

Part	PartName	Mass	Seats	CrewAffect	Months	Multiplier	EC/s	Machinery	Machinery/s
Tundra Kerbitat	Tundra_Kerbitat250	7.65	2	4	18.5	0	0.4625	0	0
MK1 Habitat	KKAOSS_Habitat_MK1_g	1.7	3	3	10	0	0.45	550	0.004

If I've got the math right, that should run out of machinery at the same time as you run out of habitation, for a full module.

Comments? Suggestions?  Should I use this same basic formula for the rest?  (If I can remember what it was...)

Alright, trying to play around with RoverDude's spreadsheet a bit. First thing I'm noticing is that I don't think the CrewAffect actually does anything when it's applied to hab quarters and not hab common. I know that the 2.5m Kerbitat holds 2 crew, says that the hab quarters setting adds 18.5 months and affects 4 crew members, but all it seems to do is add 18.5 months which is divided among however many crew are on board.

Also worth noting, I'm having a bit of trouble figuring out how to calculate volume. Using KIS is an easy solution. KIS tells me that a MK1 habitat is ~10700 L (I'll be using m³ going forward, so 10.7 m³, but KIS uses L). However, according to RoverDude's spreadsheet at 2.5m Tundra part should have a volume of about 19 m³. Throwing a 2.5 m Kerbitat into a KIS Kontainer gets you a volume of... 35 m³. Now, maybe some of that is the parts at the end that taper down to 1.25 m but RoverDude doesn't consider them as part of the actual working volume (which would be fair, since you can remove those bits entirely depending on which node you attach them to) but that's a big difference in volume. Looking at RoverDude's spreadsheet, he bases his numbers on his parts having a diameter of 2.5 m and being 4 m long. I have no idea how to find proper dimensions for KPBS parts. Best I can tell, they're 2.5 m in diameter, and the mk1 habitat looks like it's about 3 m long when comparing it to some other KSP parts...? I couldn't find a way to make Blender tell me, either. using those numbers, I get a volume of just 7.4 m³, which is noticeably less. Another problem I noticed with the KIS way of finding volume is that the mk2 habitat always has the same volume as the mk1, even if you deploy it before storing it. 

Basically, if I'm mistaken about any that, then everything that follows is pointless . 

Of the parameters that you posted above, the only ones that RoverDude's spreadsheet let you directly manipulate are the crew capacity, crew affect (which I believe is irrelevant in this case), multiplier, and machinery. The spreadsheet also lets you manipulate resource storage, which is not listed in your table. Notably, it does NOT let you manipulate consumption rates for machinery or EC, but instead gives you suggestions based on the rest of the data. So, putting in just a crew of 3 and 10 months hab time gives me a recommended volume of 10.75 m³, and a recommended total mass of 1.55. That is completely without machinery, which is actually good news on the mass side; it means that with those numbers, we don't need to add a bunch of mass. The problem in this case in volume. We are right at the limit of what KIS says the Mk1 habitat is, and about 50% over what I rough guess was. Adding a bit of storage space for supplies, a bit of mulch, and some EC only makes that worse. In RoverDude's video, he mentioned that hab quarter parts will tend to be volume-intensive, and hab common parts will tend to be mass-intensive. While we can always add machinery to make parts more massive, we can't exactly add volume... 

Now, maybe we decide that we aren't going to follow the formula too strictly, or maybe we decide that, since KPBS parts all have flat bottoms that their volume usage is more efficient than the cylinders that make up most parts. Maybe the fact that they are base parts meant for surfaces (with gravity and whatnot) means that they are inherently more comfortable. As another option, we could just add machinery to the thing anyway and make it more massive to balance the smaller volume. Regardless, it's something we have to look at and make a conscious decision about. 

As an aside, RoverDude's spreadsheet only recommended the habitat require 2.5 EC/s to run, so there's that. 

On the topic of storage, I believe the mk1 habitat currently has 150 EC, 160 Supplies and 75 Mulch. Throwing those numbers into the calculation I had above had a pretty negligible on both the recommended volume and mass (an extra 0.3 m³ and an extra 0.03 tonnes, respectively). 

Thoughts? 

[dboi88]

I also got the animations working using USI_animation so you can now require materialkits for expansion. Turns out it only didn't work first try because i forgot to install USI_tools  

	MODULE
	{
		name = USIAnimation
		deployAnimationName = Habitat_MK2_deploy
		inflatable = true
		shedOnInflate = true
		CrewCapacity = 6
		ResourceCosts = MaterialKits,1000,ElectricCharge,100
	}

 

[DStaal]

A quick check of numbers, and I think KIS is computing the volume of the 'bounding box' - so the total length, times the height at tallest, times the width at widest.  Assuming the tapers add 0.8m to each end, you get the KIS numbers from RoverDude's numbers.  The KPBS parts are closer to filling out the whole rectangle, so for the non-deployable ones you can work with the KIS numbers as a general guideline.  (There's probably a way to work out the exact fill percentage.)

I did have one resource storage listed on my table: Machinery.    That was the 550.  But it sounds like the mass problem won't be as bad as we thought it was.  Thanks for running things through.  I can't focus on this to well at the moment, but it sounds like we're in decent shape.

Oh, and thanks @dboi88.  I have no idea why I couldn't get that to work for me; that looks pretty close to what I had...

[Merkov]

17 minutes ago, DStaal said:

A quick check of numbers, and I think KIS is computing the volume of the 'bounding box' - so the total length, times the height at tallest, times the width at widest.  Assuming the tapers add 0.8m to each end, you get the KIS numbers from RoverDude's numbers.  The KPBS parts are closer to filling out the whole rectangle, so for the non-deployable ones you can work with the KIS numbers as a general guideline.  (There's probably a way to work out the exact fill percentage.)

I did have one resource storage listed on my table: Machinery.    That was the 550.  But it sounds like the mass problem won't be as bad as we thought it was.  Thanks for running things through.  I can't focus on this to well at the moment, but it sounds like we're in decent shape.

Oh, and thanks @dboi88.  I have no idea why I couldn't get that to work for me; that looks pretty close to what I had...

Sorry, I forgot to mention machinery. I deliberately left it out because it seemed like that particular part didn't require it. If I start going through the rest of the main KPBS parts in a similar fashion, where/how do you want me to post what I come up with? If I make a post with a table, then keep editing that post as I go along, does that work? Otherwise, I could make a GitHub issue and add comments as I go or something...? 

@dboi88 That's fantastic! I'll try to keep the mass of MaterialKits in mind as an option for deployable parts as I run balancing numbers. 

@DStaal, a page ago or so, you said you wanted to set logistics ranges. As I recall, MKS by default only has scavenging range (150 m) and all parts with ModuleResourceDistributor have a 2 km range. I wasn't aware that there was a way to adjust those ranges. I'll have a quick peek through the files and see if/where we have and duplicating modules and whatnot. 

For the .version file, I've whipped up a quick draft of one, though of course you may decide to change some things. (What version we're on, for instance). If I've done this right, then it should be looking at whatever the .version file is in the Release branch. It should also be looking at the changelog in that branch, though that feature is optional. I figured that was sort of how you would want things to work: things are worked on in the Development branch, the current released version is in the Release branch. File hierarchy is important to AVC (since GitHub's URL is based on the project's file hierarchy) so if we make changes to the file structure, we'll have to adjust the .version file. On that note... 

Do you think there's any value in making a GameData -> KPBStoMKS -> (rest of stuff) set of folders on Github? That way, when someone downloads the pack, they get a GameData folder and go from there. That sort of seems like the standard that most of the KSP community recognizes, so I thought I would bring it up. That would also affect the .version file. (Not that that's a big deal. Unless I've done something wrong, making a .version file was SUPER easy. I probably did something wrong .)

[DStaal]

7 minutes ago, Merkov said:

Sorry, I forgot to mention machinery. I deliberately left it out because it seemed like that particular part didn't require it. If I start going through the rest of the main KPBS parts in a similar fashion, where/how do you want me to post what I come up with? If I make a post with a table, then keep editing that post as I go along, does that work? Otherwise, I could make a GitHub issue and add comments as I go or something...?

 

The main point of using machinery was to offset mass - if don't need it for that, then we can approach things a different way.    Mostly just mentioning because I had included it, and it would have been a 'resource' as far as that spreadsheet goes.

But yeah, either a table here or update this table: https://github.com/DanStaal/KPBStoMKS/blob/feature/Life-Support/Parts_Table.md Which I setup as a work-in-progress table.  Whichever works best for you.

12 minutes ago, Merkov said:

, a page ago or so, you said you wanted to set logistics ranges. As I recall, MKS by default only has scavenging range (150 m) and all parts with ModuleResourceDistributor have a 2 km range. I wasn't aware that there was a way to adjust those ranges. I'll have a quick peek through the files and see if/where we have and duplicating modules and whatnot.

There used to be a way - though from looking at it I think it's either unused or depreciated entirely in the current version of MKS.  I decided to give the 'Planetary Control Module' 2km - but not PL, which remains a Central Hub exclusive.

14 minutes ago, Merkov said:

For the .version file, I've whipped up a quick draft of one, though of course you may decide to change some things. (What version we're on, for instance). If I've done this right, then it should be looking at whatever the .version file is in the Release branch. It should also be looking at the changelog in that branch, though that feature is optional. I figured that was sort of how you would want things to work: things are worked on in the Development branch, the current released version is in the Release branch. File hierarchy is important to AVC (since GitHub's URL is based on the project's file hierarchy) so if we make changes to the file structure, we'll have to adjust the .version file. On that note... 

Do you think there's any value in making a GameData -> KPBStoMKS -> (rest of stuff) set of folders on Github? That way, when someone downloads the pack, they get a GameData folder and go from there. That sort of seems like the standard that most of the KSP community recognizes, so I thought I would bring it up. That would also affect the .version file. (Not that that's a big deal. Unless I've done something wrong, making a .version file was SUPER easy. I probably did something wrong .)

Yep, doing the .version file and changelog off the Release branch is the idea - that way we can play in the Dev branch.

And do think the download should probably have the 'GameData -> KPBStoMKS' hierarchy - but I don't think Github should have it.  Github just has the KPBStoMKS folder, and putting that in a 'GameData' wrapper is part of the release process.  That keeps git clean of 'extra' folders, and makes it simpler to keep track of, IMHO.

(And I expect making a .version file is super easy - how else can you get dozens of lazy mod makers to include it?  )

[Merkov]

1 minute ago, DStaal said:

The main point of using machinery was to offset mass - if don't need it for that, then we can approach things a different way.    Mostly just mentioning because I had included it, and it would have been a 'resource' as far as that spreadsheet goes. 

I admit, you DID mention it, and I DID leave it out.  

1 minute ago, DStaal said:

But yeah, either a table here or update this table: https://github.com/DanStaal/KPBStoMKS/blob/feature/Life-Support/Parts_Table.md Which I setup as a work-in-progress table.  Whichever works best for you. 

I completely missed that table. I'll start playing. 

1 minute ago, DStaal said:

There used to be a way - though from looking at it I think it's either unused or depreciated entirely in the current version of MKS.  I decided to give the 'Planetary Control Module' 2km - but not PL, which remains a Central Hub exclusive. 

Sounds good to me. Do parts with PL automatically become resource distributors? If not, then I'll make sure the hub is one, as well. As much as I don't like giving the hub tons of modules, it would be weird if the hub could access PL but not resources on vessels within 2 km. 

1 minute ago, DStaal said:

Yep, doing the .version file and changelog off the Release branch is the idea - that way we can play in the Dev branch. 

Yay, I'm figuring stuff out! 

1 minute ago, DStaal said:

And do think the download should probably have the 'GameData -> KPBStoMKS' hierarchy - but I don't think Github should have it.  Github just has the KPBStoMKS folder, and putting that in a 'GameData' wrapper is part of the release process.  That keeps git clean of 'extra' folders, and makes it simpler to keep track of, IMHO.

...I take back my figuring things out comment. I don't know how wrappers work and stuff... I DO know that if you have an empty folder (or a folder that contains only another folder) that GitHub just skips to first point when you can actually see a real file when you select the top folder (I forked your repo and played around with it a bit just to see how that works). Anyway, if you say we don't need it and it can all be taken care of at the release process, I will trust you because computers are scary . 

1 minute ago, DStaal said:

(And I expect making a .version file is super easy - how else can you get dozens of lazy mod makers to include it?  )

That'll make it all the worse when mine doesn't work.  

[Merkov]

On 2/20/2017 at 8:32 AM, DStaal said:

Well, the last release of my integration pack was 0.9.1.  I'd actually think stage 1 should be '1.0.0 beta', and stage 2 should be '1.0.0' - with the actual patches from stage 2 being integrated into KPBS, to replace it's current USI-LS patches.  I'm not sure how well KSP-AVC would support that versioning scheme however.  I haven't looked at how it handles this.

Just reading back a bit, I stumbled upon this quote. Looking at AVC, it basically wants up to four numbers for a version: a major number, a minor number, a patch number, and a build number. For now, I'll just build the version file as 1.0.0 (it looks like if you leave the build number as 0 then AVC just omits it, which is nice) and we can figure the rest out how we want to address stage 2 when we are closer to being done stage 2. 

On that topic, I guess for stage 2 we'll basically build the USI-LS patches in your repo, then give them to Nils when we're done, and once he's incorporated them into KPBS we'll remove them from our repo? It seems like there is a chance that there won't ever really be a stage 2 "release" per se. 

*EDIT* I actually had another thought about this. This may sound weird, but I think we'll actually need to have 2 seperate sets of USI-LS configs: one for use with MKS, and one for use without. At the very least, some things will have to change. Specifically, things like the greenhouse. I was happily going along writing a config, looking at the fact that it does cultivation which uses water and dirt or water and substrate... and then I realized that USI-LS users don't use dirt or substrate. KPBS adds water scanning and drills with USI-LS, so you can get water, but not the rest. MKS users definitely should be able to do MKS-style cultivation, but non-MKS users can't. Basically, we need two sets of configs for the greenhouse. There may be other parts in this situation, but this is the one I just ran into. 

I guess I'll start looking at balancing both ways for now. If nothing else, I suppose it will save a bit of time dealing with the conversions during stage 3. /*EDIT*

Quote

I wasn't necessarily thinking a 'new' part - just adding it to either the ISRU or the Workshop.  (I was actually leaning towards it being the Workshop - then in stage 3 we have it swap out for the actual production.)  I'm going to investigate for a bit whether MM can just add the Machinery requirement by itself, or whether we would need to have a full different block.  If it's the latter, I think adding in the converter is the cleaner option, requiring less maintenance long-term.  If it's the former, then it's less confusing to players to not have to deal with the resource unless it's a common resource, and the parts would only be slightly overpowered when MKS isn't installed, which could even be rectified by adjusting the mass in a conditionally applied patch.

You know, the more I think about it, the more I like your idea of adding this to the Workshop, if it's needed at all. I know that the mk1 habitat worked out nicely not to need any machinery, and hopefully that trend continues for stuff that only needs USI-LS. If it doesn't, and we do need machinery, then I'm definitely leaning more and more toward your idea of making the Workshop produce Machinery from Ore. 

If it turns out that there's really only one or two parts that are way off mass-wise, it may be worth bringing it up with Nils to see how he feels about us changing the offending part's mass instead. Adding an entire resource (from the perspective of a non-MKS user) just to balance one or two parts seems a little silly. 

Edited February 22, 2017 by Merkov
I found a problem...

[Merkov]

I think I've found a weird oddity in RoverDude's spreadsheet. There's a spot for putting in a value associated with "Admin Modules". In the spreadsheet, it gives some sample values: MPL = 5, survey/logistics = 3, PL = 10. Now, we talked about the central hub being the only part that has access to PL. So, I typed in a crew capacity of 6 and an admin module rating of 10 (assuming logistics is included in PL) and... I immediately was told I needed a volume of 36.5 m3 and a mass of 7.1. For comparison, the hub's volume is a hair over 30 m3, and its mass is 7.5. The thing is, there has to be something wrong either with how I'm reading this or something else, because the Duna logistics module has access to PL and holds 2 crew members. Putting in those values (and nothing else) gives me a suggested volume of 35.5 m3 and a mass of 6.7. According to the spreadsheet, a Duna module only has a volume of 12.89, and the Duna Logistics Centre has a mass of 2.2. 

Point is, I'm a little suspect of that Admin Module value. @RoverDude, am I just not interpreting this right? 

So for everyone else, let's look at the Central Hub: Volume, 30 m3 (KIS says 42, but it's crazy. I used Nils' blueprint instead), mass is 7.5. It holds 6 kerbals, and has 150 EC. I gave it no other resources of its own (it relies on other parts having them) and for now just gave it an admin module value of 3 (which is the survey/logistics value. Less than the MPL value of 5, and doesn't include the PL 10 value). Then I gave it an 85% efficiency recycler (92.5% purifier) which only affects 1 kerbal. Finally, I gave it a 1.2 times hab multiplier for 2 kerbals, plus 2 extra bonus months. This made it work out to just a hair over 30 m3 (which is pretty much exactly what I came out with before I got rid of my decimals) and a mass of 7.6, which is pretty close. 

If I ignore the Admin Module entirely, I can still give it the 85/92.5% recycler/purifier, plus a 1.2 times hab multiplier for 5 kerbals plus 3 bonus kerbal months. That gets us right at 30 m3 and 7.5 tonnes. 

Finally, it is possible with that first option to make a bigger multiplier (or make it affect more kerbals) by adding machinery. Hab multipliers add a lot more mass than volume, so there is room to play with that if we really want to. Of course, that means we have to think about if we want machinery to exist in USI-LS installs without MKS. 

Any thoughts on these? 

[DStaal]

3 hours ago, Merkov said:

...I take back my figuring things out comment. I don't know how wrappers work and stuff... I DO know that if you have an empty folder (or a folder that contains only another folder) that GitHub just skips to first point when you can actually see a real file when you select the top folder (I forked your repo and played around with it a bit just to see how that works). Anyway, if you say we don't need it and it can all be taken care of at the release process, I will trust you because computers are scary .

You're assuming I only care about how *Github* lays things out.    Most important to me is my local repository - which happens to be a folder in my active GameData folder.

2 hours ago, Merkov said:

Just reading back a bit, I stumbled upon this quote. Looking at AVC, it basically wants up to four numbers for a version: a major number, a minor number, a patch number, and a build number. For now, I'll just build the version file as 1.0.0 (it looks like if you leave the build number as 0 then AVC just omits it, which is nice) and we can figure the rest out how we want to address stage 2 when we are closer to being done stage 2. 

On that topic, I guess for stage 2 we'll basically build the USI-LS patches in your repo, then give them to Nils when we're done, and once he's incorporated them into KPBS we'll remove them from our repo? It seems like there is a chance that there won't ever really be a stage 2 "release" per se. 

*EDIT* I actually had another thought about this. This may sound weird, but I think we'll actually need to have 2 seperate sets of USI-LS configs: one for use with MKS, and one for use without. At the very least, some things will have to change. Specifically, things like the greenhouse. I was happily going along writing a config, looking at the fact that it does cultivation which uses water and dirt or water and substrate... and then I realized that USI-LS users don't use dirt or substrate. KPBS adds water scanning and drills with USI-LS, so you can get water, but not the rest. MKS users definitely should be able to do MKS-style cultivation, but non-MKS users can't. Basically, we need two sets of configs for the greenhouse. There may be other parts in this situation, but this is the one I just ran into.

Yeah, that dual-stream stage 2 is sounding like the most likely option.    And I'm thinking I don't really want a 'full' release until we get to stage 2 - I'll do a 'beta' release in this thread once I get dboi88's textures merged in and the docs written.  (I've got the readme mostly done.)

On the greenhouse specifically: I mentioned I like the idea of having at least one mode of it being a food+hab bonus - a 'garden' that produces useful food but is also a place to hang out and get a feel for something that's not steel and dirt.  Not sure if we want that instead of one of the normal three, or if it should be a modification of one of them.

24 minutes ago, Merkov said:

I think I've found a weird oddity in RoverDude's spreadsheet. There's a spot for putting in a value associated with "Admin Modules". In the spreadsheet, it gives some sample values: MPL = 5, survey/logistics = 3, PL = 10. Now, we talked about the central hub being the only part that has access to PL. So, I typed in a crew capacity of 6 and an admin module rating of 10 (assuming logistics is included in PL) and... I immediately was told I needed a volume of 36.5 m3 and a mass of 7.1. For comparison, the hub's volume is a hair over 30 m3, and its mass is 7.5. The thing is, there has to be something wrong either with how I'm reading this or something else, because the Duna logistics module has access to PL and holds 2 crew members. Putting in those values (and nothing else) gives me a suggested volume of 35.5 m3 and a mass of 6.7. According to the spreadsheet, a Duna module only has a volume of 12.89, and the Duna Logistics Centre has a mass of 2.2. 

Point is, I'm a little suspect of that Admin Module value. @RoverDude, am I just not interpreting this right? 

So for everyone else, let's look at the Central Hub: Volume, 30 m3 (KIS says 42, but it's crazy. I used Nils' blueprint instead), mass is 7.5. It holds 6 kerbals, and has 150 EC. I gave it no other resources of its own (it relies on other parts having them) and for now just gave it an admin module value of 3 (which is the survey/logistics value. Less than the MPL value of 5, and doesn't include the PL 10 value). Then I gave it an 85% efficiency recycler (92.5% purifier) which only affects 1 kerbal. Finally, I gave it a 1.2 times hab multiplier for 2 kerbals, plus 2 extra bonus months. This made it work out to just a hair over 30 m3 (which is pretty much exactly what I came out with before I got rid of my decimals) and a mass of 7.6, which is pretty close. 

If I ignore the Admin Module entirely, I can still give it the 85/92.5% recycler/purifier, plus a 1.2 times hab multiplier for 5 kerbals plus 3 bonus kerbal months. That gets us right at 30 m3 and 7.5 tonnes. 

Finally, it is possible with that first option to make a bigger multiplier (or make it affect more kerbals) by adding machinery. Hab multipliers add a lot more mass than volume, so there is room to play with that if we really want to. Of course, that means we have to think about if we want machinery to exist in USI-LS installs without MKS. 

Any thoughts on these? 

First thought: Personally, I want to pull the recycler out of that part entirely - Keep the purifier, but there are other recycler parts; this increases their range, but doesn't supplant them.  That then frees up some space and mass - some of that will be used by industrial efficiency parts in stage 3, at least for MKS.  And the flip side of that is that PL is only MKS, not LS - so for a pure LS patch we can ignore the Admin Module(s) as irrelevant.  I'm also suspect of the direct hab months, though I'm less set on that.

But this part is quite likely to be the biggest difference between 'just USI-LS' and 'MKS': What I'm thinking for it would be all efficiencies and admin modules, pulling Kerbals out of their bunks when they need to do paperwork and stuff - which should take space and mass, I just haven't had time to run numbers.  (Honestly, I've barely got time to think at the moment.)  So, for the moment compute it as pure USI-LS: Hab(s) and purifier, as that's the next patch that needs to be written.  We can override in stage 3.

[Merkov]

 

7 minutes ago, DStaal said:

Yeah, that dual-stream stage 2 is sounding like the most likely option.    And I'm thinking I don't really want a 'full' release until we get to stage 2 - I'll do a 'beta' release in this thread once I get dboi88's textures merged in and the docs written.  (I've got the readme mostly done.)

I sent you a PR with that .version file. At least, I really hope I did. Once things get packaged for release, you might have to make a change or two, but it should be good for now...?

7 minutes ago, DStaal said:

On the greenhouse specifically: I mentioned I like the idea of having at least one mode of it being a food+hab bonus - a 'garden' that produces useful food but is also a place to hang out and get a feel for something that's not steel and dirt.  Not sure if we want that instead of one of the normal three, or if it should be a modification of one of them. 

Oh yeah, I remember you saying that. I like that idea. 

7 minutes ago, DStaal said:

First thought: Personally, I want to pull the recycler out of that part entirely - Keep the purifier, but there are other recycler parts; this increases their range, but doesn't supplant them.  That then frees up some space and mass - some of that will be used by industrial efficiency parts in stage 3, at least for MKS.  And the flip side of that is that PL is only MKS, not LS - so for a pure LS patch we can ignore the Admin Module(s) as irrelevant.  I'm also suspect of the direct hab months, though I'm less set on that.

But this part is quite likely to be the biggest difference between 'just USI-LS' and 'MKS': What I'm thinking for it would be all efficiencies and admin modules, pulling Kerbals out of their bunks when they need to do paperwork and stuff - which should take space and mass, I just haven't had time to run numbers.  (Honestly, I've barely got time to think at the moment.)  So, for the moment compute it as pure USI-LS: Hab(s) and purifier, as that's the next patch that needs to be written.  We can override in stage 3.

As far as I can tell, the spreadsheet actually makes you figure out a recycler percentage, then bases a purifier percentage off of that. We could just not include a recycler and "refund" ourselves some mass, but there's no calculation for that that I know of. 

I guess what I'm wondering is, do we: 

1) want to make the LS parts balanced against just USI-LS for now, knowing that they'll be overpowered once we start adding MKS modules, or

2) do we want to calculate for full MKS, then remove the MKS bits? 

The latter makes the LS parts a bit underpowered when running just USI-LS, but it means that everyone will have the same LS values and we only have to make the calculations once. The former makes it quicker to calculate things now, but once we start stage 3 we will either:

A) have to give Nils new balancing patches to replace the ones we will have just given him, and that new patch will make everything much less powerful than it was previously (which could be bad for existing saves), or 

B) override the patches we give Nils on our end, which would mean that both MKS and non-MKS users have parts that are balanced to their respective games, but have completely different values to each other. Maybe that's not a bad thing, but it seems... odd. I'm worried about ending up in an MKS-EL situation where people aren't seeing the behaviour (or powers) they are expecting and it just becoming a nightmare. Alternatively, there's: 

C) some other idea I haven't thought of yet. 

Don't worry about not being able to think about this right now. It won't kill me to have to wait for an answer. It just so happens that today I had a fair bit of time to play with numbers. 

[DStaal]

I'm leaning towards 1:B as the option to go with: Focus on LS patches in isolation for the official KPBS release, and then have this patchset adjust things when it's installed.  Hopefully it won't be huge amounts of differences in most parts.

[Merkov]

Sounds good. I'll get working on it. 

[dboi88]

Can't wait for a release! You're doing a really good job here guys

[Merkov]

Okay, I am focusing on USI-LS alone, but I wanted to sort out what I saw as problems calculating PL values, so I took my issues to RD, asking what it means for a part to have access to PL, and got this interesting answer: 

8 minutes ago, RoverDude said:

It emulates stockpiling piles of stuff, so figure it's mostly a packaging and distribution center, forklifts, and rovers.  i.e. it's something where there will be replacement models at some point

Tho to add, in reality, planetary and orbital logistics will both be getting an overhaul both from a code standpoint and a model standpoint.  What we have now is more of an interim step.

(The whole small conversation can be found in the MKS thread.) 

RoverDude also made the comment that a part that handles PL generally won't have room to handle anything else (which makes sense, if it's basically warehouse/big post office). Obviously we can't know what this overhaul of his will be or how to balance for it, but I'm wondering if maybe the KPBS rover garage should have access to PL? It's voluminous, and it would make sense as a hub where delivery rovers come to and depart from. Just something to think about. 

Okay, back to USI-LS numbers. 

[DStaal]

What it sounds like to me is that he's planning on redoing it again - I say keep with what we have at the moment, and rethink if/when he releases his redo. 

(But yes: If he's thinking the warehouse is the part that has it, then it should probably be the garage when that happens.  At the moment, I more got the feeling it was the coordination office part that has it - which is the central hub.)

[FellipeC]

I know this is silly, but... How you download it from Gitlab?

[DStaal]

16 minutes ago, FellipeC said:

I know this is silly, but... How you download it from Gitlab?

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.

[FellipeC]

That said I'll wait for a proper release, thank you @DStaal

[DStaal]

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

[dboi88]

8 minutes ago, DStaal said:

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

Ohh gutted, i know you're pain, hope it heels quickly.

[Merkov]

For those of you watching the forum, but not GitHub, I've posted a modified copy of the LS parts table that DStaal posted on page 2 on this issue page: https://github.com/DanStaal/KPBStoMKS/issues/1 

Basically, I plan on just editing that one comment of mine as I come up with values. 

@DStaal back to the Central Hub: for the straight stage 2, USI-LS-only balance pass, you had indicated that you wanted to see just a purifier and hab multiplier. RoverDude's spreadsheet doesn't really distinguish between purifiers and recyclers (basically, you put in what you want your recycler to be, and it tells you what a purifier would be ON TOP of that recycler). With all of that in mind, I wanted to run some numbers by you:

1) We still have one of the options I mentioned earlier: an 85% recycler for 1 kerbal is rated as a 92.5% purifier for 1 kerbal. The purifier uses 19.25 EC/s and 0.0085 Water/s. Add a 1.2 times hab multiplier for 5 kerbals plus 3 hab months (those are just used to justify extra volume when you add a hab multiplier). That hab stuff uses 2.25 EC/s. This works out almost perfectly to the 30 m³ volume and 7.5 t mass.

2) If we assume that a recycler would simply add mass, then we could try a 95% purifier (which would be a 90% recycler, but nevermind that) which uses 31.75 EC/s and 0.009 Water/s. Tack on a 1.2 hab multiplier for 5 kerbals, no kerbal months costing 1.5 EC/s and you get a volume just under the 30 m³ plus a mass of just under 10 t. That's a fair bit heavier than the 7.5 t that we're working with, but we have to decide how massive the recycler would be. 

3) Another option would be to make the purifier less efficient (90%, which only costs 6.75 EC/s and 0.008 Water/s) and boost the hab multiplier to 2 for 6 kerbals, costing 3 EC/s. Volume is still good, this puts us just under 8 t, which is only half a tonne more than the Hub. Removing half a tonne for the recycler makes sense to me, but I guess it depends on how powerful we want that purifier to be. 

4) If we want a bit more efficiency out of that purifier, we could bump it back up to the 92.5% I mentioned before (19.25 EC/s, 0.0085 Water/s) plus a 1.5 hab multiplier for 5 kerbals + 1.5 bonus months (2.25 EC/s). This works out to just under 30 m³ and 8.2 tonnes. If we assume a purifier without recycler saves us 700 kg, then we're on target. 

There are obviously more combinations I can play with. Do any of these stand out to you guys? Would you rather see a more powerful purifier or a larger hab multiplier? 

[Merkov]

I also had a thought about the Algae Container: what if, instead of turning ore and mulch into fertilizer, it used ore and water instead? I know that fertilizer is supposed to be solid(ish) and base USI-LS doesn't use water, but KPBS adds water drills when USI-LS (or any LS mod, I think) is installed, and we're already talking about using it in the Central Hub's purifier. I would probably make the conversion rate a little more reasonable than the stock 1.25 m ISRU's Ore -> Fertilizer option. 

This would give USI-LS players something a little bit different, make use of the K&K water drill, and avoid turning mulch into fertilizer, which I'm still not a huge fan of. I know that 10 supplies turns into 10 mulch + 1 fertilizer = 11 supplies, so if you use 1 mulch to make 1 fertilizer you're technically okay, it still just seems like you could accidentally end up leaving it on while your base is empty, and come back to a base full of fertilizer but very low on supplies and mulch. As an alternative, maybe having a way of using ore, water, and fertilizer to make supplies (similar to MKS's cultivation options, but with Ore) would be a way to change things up. 

On the topic of water and KPBS, I know that when MKS is installed, the stock Narrow Band Scanner and Surface Scanner detect water. Does anyone know off the top of their heads if this happens without MKS? I know that water is a CRP resource. I'm trying to see if there is any need for the K&K water scanning parts to remain in a USI-LS install. If they are needed with USI-LS, it may be worth removing them via MM patch when the full MKS is installed when we reach stage 3.