[1.2.2] [0.9.5] KPBS/MKS Integration Pack

[Merkov]

1 hour ago, dboi88 said:

The MKS tank textures are done

Those look fantastic!

[DStaal]

Now I've just got to do my part.  And hope my MM magic is as good as I think it is. 

But yes, beautiful.

[DStaal]

So, looking through other LS parts.  What do people think of these as a fluids-Kontainer and a long-range power transmitter?

[DStaal]

(DAMN THIS FORUM SOFTWARE!!!!!!)

 

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...)

[dboi88]

The firespitter switchable texture/resource containers are working . . . .

[DStaal]

So, dboi88 is still working on some texturing - and I want to tweak some of the logistics patches - but here's what I'm planning on for 'new parts' in the stage one release:

I'm open to life-support suggestions, but this has been my focus so far; I wanted to get this done.    I think I've got all the parts in place, minus a couple of textures.

[LatiMacciato]

got some questions:

1) Will there be a USI-LS/TAC-LS/Snacks specific seperation happen like it is already within KBPS/Kerbetrotter?
2) Would you include soil and their recycler functions from Snacks too?

Ty

[DStaal]

5 minutes ago, LatiMacciato said:

got some questions:

1) Will there be a USI-LS/TAC-LS/Snacks specific seperation happen like it is already within KBPS/Kerbetrotter?
2) Would you include soil and their recycler functions from Snacks too?

Ty

This is just an add-on for KPBS, so all parts currently in KPBS will still be there.  It's focused on MKS parts, materials, and toolchain because it's a complex one.  I am putting in appropriate ':NEEDS' blocks, so if you were to install this with MKS but not USI-LS, you'll only get the MKS parts.  (And if you were to do things like pull Konstruction out of MKS, you'd automatically lose the construction ports I'm adding.)  I'm not overriding any parts currently in KPBS - either I'm adding modules (like logistics) that they need for MKS, or I'm duping and renaming, so you get entirely new parts, so I won't interfere with anyone else adding stuff in to the current parts.  (Well, with one exception: Pathfinder does a lot of messing with KPBS parts, and changes many of them around completely - I've got a patch set in here to remove all of that to give you the basic parts mostly back.  I should still do the fuel tanks, but I want do see if I can figure out a better way than just re-writing the tank configs once Pathfinder deletes and replaces them.)

Basically: I don't interfere with anything KPBS already does, and the focus of this pack is on USI mods.  If you want a Snacks recycler, you should probably take it up with Nils277 in the main KPBS thread, because that's the right place for it.  (I even plan on pushing our USI-LS patches upstream to him, once we finish them.)

If once we finish stage three you can tell me where Snacks fits in to those parts (if needed), then I'll be glad to take PRs on including support.    I'm already trying to write in CLS support where it's appropriate, as it's another mod I use.  But the focus of this pack is making KPBS parts equal partners to USI parts when you have MKS (and USI-LS) installed.

[LatiMacciato]

very cool news and i love what I just read!

I could add-up some of the new parts as recyclers to my repo (check my sig) .. once you guys are done with the magic.

The recyclers are just available if you have soil activated in settings .. its a sorta advanced snacks mode.

Edited February 15, 2017 by LatiMacciato

[DStaal]

7 minutes ago, LatiMacciato said:

very cool news and i love what I just read!

I could add-up some of the new parts as recyclers to my repo (check my sig) .. once you guys are done with the magic.

The recyclers are just available if you have soil activated in settings .. its a sorta advanced snacks mode.

Sounds good - but again, I suggest you submit them directly to Nils: He supports multiple LS mods (including Snacks) at the moment, and is quite likely to be willing to support more.  He even has several models for recyclers in the parts collection, so all you'd need to do is give him the configs.

[LatiMacciato]

3 minutes ago, DStaal said:

Sounds good - but again, I suggest you submit them directly to Nils: He supports multiple LS mods (including Snacks) at the moment, and is quite likely to be willing to support more.  He even has several models for recyclers in the parts collection, so all you'd need to do is give him the configs.

I did license my repo via MIT and its actually just 1 config for the greenhouse and the LS-container .. eg. the blue double-sized plant container (KKAOSS_LS_container_greenhouse). if it's necessary i'll throw @Nils277 a post in the KBPS thread.

[Merkov]

On 14/02/2017 at 5:41 PM, DStaal said:

So, dboi88 is still working on some texturing - and I want to tweak some of the logistics patches - but here's what I'm planning on for 'new parts' in the stage one release:

I really like the new parts. K&K construction ports are a fantastic idea. 

[DStaal]

8 hours ago, Merkov said:

I really like the new parts. K&K construction ports are a fantastic idea. 

It was an obvious idea: Typically you send these parts up in pieces so that you can assemble them into a base - which is never taken back apart.  So having them weld makes sense.  They should work with the standard medium-sized construction ports as well - though I haven't tested that, and it wouldn't surprise me if there is weirdness.

I've been going over things, and it's getting close to stage-one release.  One thing I was hoping for, but can't seem to make work, was to have deployment of the parts require MaterialKits - unfortunately Nils and RoverDude both have custom classes for deployment, and it doesn't look like I can substitute RoverDude's class for Nils' and make things work.  (Well: You get functional parts.  They just don't actually change their appearance.)

[Merkov]

44 minutes ago, DStaal said:

It was an obvious idea: Typically you send these parts up in pieces so that you can assemble them into a base - which is never taken back apart.  So having them weld makes sense.  They should work with the standard medium-sized construction ports as well - though I haven't tested that, and it wouldn't surprise me if there is weirdness.

I mean, it's obvious to me now that you've mentioned it .

44 minutes ago, DStaal said:

I've been going over things, and it's getting close to stage-one release.  One thing I was hoping for, but can't seem to make work, was to have deployment of the parts require MaterialKits - unfortunately Nils and RoverDude both have custom classes for deployment, and it doesn't look like I can substitute RoverDude's class for Nils' and make things work.  (Well: You get functional parts.  They just don't actually change their appearance.)

That's a shame, but understandable. I'm guessing that to make it work would require rebuilding the animation in Unity using USITools' system or something? If so, sounds like something that can be pushed back to stage 3 of your plan, or dropped entirely if it's unfeasible. Is there anything else still missing on the stage 1 side of things?

[Merkov]

Also, going way back to your thoughts about GitLab vs GitHub, it seems that my work computer network simply refuses to play nice with GitLab, so I'll probably have to watch development on the GitHub side. On that note, I just looked at the "Issues" tab for the heck of it. Most of the issues are ones you opened last year. Is there a way we could use the issues tab to track what we want to get done in our various stages?

As an update on my quest to learn Blender and build a KPBS-to-MKS adaptor, I keep hearing people say that once you learn Blender, its interface becomes intuitive. I can believe that, but I am not quite there yet. Most of what I have come up with so far is pretty blocky, and usually I end up having a weird edge or vertex somewhere that throws me off. Also, do people tend to place KPBS parts directly on the ground, or do people use the underside landing gear much? I'm trying to get as good of a height match as possible, but I expect whatever I come up with will always work best when attached with flex-o-tubes or the like. I also never realized just how tall Duna parts are compared to KPBS stuff, so that affects the shape of this thing, too.

(Now, if I were to learn how to somehow make this thing animated and tie into RoverDude's Konstruction mod and use the servo controls to allow you to precisely adjust its height, that would be awesome, but see my posts around this forum for examples of me not being particularly good at computer-ing... I can dream, right ?)

[Merkov]

Okay, I'm sorry to keep spamming this thread, but for those who didn't see, this happened:

48 minutes ago, RoverDude said:

Ok... balance guidelines are out, along with a video covering how they work.  Go make stuff

 

https://youtu.be/a0oqO3xbswk

 

Just in time for finalizing stage 1 and getting to work on stage 2!

[DStaal]

2 hours ago, Merkov said:

That's a shame, but understandable. I'm guessing that to make it work would require rebuilding the animation in Unity using USITools' system or something? If so, sounds like something that can be pushed back to stage 3 of your plan, or dropped entirely if it's unfeasible. Is there anything else still missing on the stage 1 side of things?

I honestly have no idea what it would require - it depends heavily on the internals of the respective expandable deployment code bases.  Both appear to have overridden stock and extended, but they have slightly different options, and must have tied into their animations differently.  I'm ok with dropping it: I wanted to put in a *little* of MaterialKits to deploy, but not much; the idea being that USI's are proper 'inflatables': You ship up the shell, inflate it, and fill it.  K&K's parts are 'deployable': You ship it up, unfold, and it's all in place, minus a few screws and stuff to hold it there.

For stage 1... I need to go through and figure out/remember how to set ranges for the different logistics.  The main one local logistics: I figure the central hub should be 2km, but the inline control station should give a bonus - probably 500m.  We don't have all the textures yet, but that can come later.  Also, some cleanup should be done: The patches currently add in things to a couple of parts twice, etc.  If people want to poke at it, I've just synced in everything to the Development branch - feel free to grab and comment.  (Or submit PRs to fix anything.)  Also, I need to learn how to create an AVC file.

(And one other thing I'd like to do on the GitLab side is write a script to automatically create a release zip.  Being able to do that type of thing is why I like GitLab - but that doesn't have to happen.)

2 hours ago, Merkov said:

Also, going way back to your thoughts about GitLab vs GitHub, it seems that my work computer network simply refuses to play nice with GitLab, so I'll probably have to watch development on the GitHub side. On that note, I just looked at the "Issues" tab for the heck of it. Most of the issues are ones you opened last year. Is there a way we could use the issues tab to track what we want to get done in our various stages?

Easily.    Basically, each stage should be a milestone, and different issues can be what we want to get done - assign them to a milestone and it'll keep track of how close we are to that, as we mark them completed.  The issues I have in there are our ideas from the previous version of MKS on how to make a 'same but different' set of parts: I'm still considering them a general guideline for what I'd like to see for stage 3, though things may need to be adjusted.

Also, I'd like to get working on stage 2, so if anyone wants to start running numbers through RoverDude's spreadsheet, feel free to put them into the 'Life-Support' branch, or just to post them here.  My thought is that we shouldn't play with the base mass of the KPBS parts to much - instead we add a machinery requirement and use machinery to make up the mass difference.   (And maybe make the total just a bit on the light side, as the machinery will be consumed.)  But we could really use someone to work out the (approximate) volume of the various KPBS parts, so we can throw that in to the calculations.

[Merkov]

6 hours ago, DStaal said:

I honestly have no idea what it would require - it depends heavily on the internals of the respective expandable deployment code bases.  Both appear to have overridden stock and extended, but they have slightly different options, and must have tied into their animations differently.  I'm ok with dropping it: I wanted to put in a *little* of MaterialKits to deploy, but not much; the idea being that USI's are proper 'inflatables': You ship up the shell, inflate it, and fill it.  K&K's parts are 'deployable': You ship it up, unfold, and it's all in place, minus a few screws and stuff to hold it there.

Yeah, MaterialKits to deploy would have been a nice-to-have. Not worth any huge amount of effort, though. Dropping it is the right choice.

6 hours ago, DStaal said:

For stage 1... I need to go through and figure out/remember how to set ranges for the different logistics.  The main one local logistics: I figure the central hub should be 2km, but the inline control station should give a bonus - probably 500m.  We don't have all the textures yet, but that can come later.  Also, some cleanup should be done: The patches currently add in things to a couple of parts twice, etc.  If people want to poke at it, I've just synced in everything to the Development branch - feel free to grab and comment.  (Or submit PRs to fix anything.)  Also, I need to learn how to create an AVC file.

(And one other thing I'd like to do on the GitLab side is write a script to automatically create a release zip.  Being able to do that type of thing is why I like GitLab - but that doesn't have to happen.)

I'm working this weekend (I started writing this response at about 10:00 MST. It is now 18:00 MST. Stupid work.) but I'll have most of next week free. If you don't get to it first, I'll see about researching a .version file for AVC. I'll add comments to the github issue, but how do we want the versioning of this thing to work? Do we want to bother with mini AVC? My thought is that if someone wants version checking, they'll have AVC proper. Also, having mini AVC for an interoperability mod seems... odd.

6 hours ago, DStaal said:

Easily.    Basically, each stage should be a milestone, and different issues can be what we want to get done - assign them to a milestone and it'll keep track of how close we are to that, as we mark them completed.  The issues I have in there are our ideas from the previous version of MKS on how to make a 'same but different' set of parts: I'm still considering them a general guideline for what I'd like to see for stage 3, though things may need to be adjusted.

Cool. I think I've got all of that.

6 hours ago, DStaal said:

Also, I'd like to get working on stage 2, so if anyone wants to start running numbers through RoverDude's spreadsheet, feel free to put them into the 'Life-Support' branch, or just to post them here.  My thought is that we shouldn't play with the base mass of the KPBS parts to much - instead we add a machinery requirement and use machinery to make up the mass difference.   (And maybe make the total just a bit on the light side, as the machinery will be consumed.)  But we could really use someone to work out the (approximate) volume of the various KPBS parts, so we can throw that in to the calculations.

In the video that RoverDude posted, he has guidelines on wet (with machinery) mass and dry (without machinery) and all kinds of stuff. I'll try playing with the numbers on my days off and see what I can come up with. Part of me wishes that we could do calculations in the opposite direction to what he has done; instead of saying what efficiencies, converters, etc. you want on a part and it spitting out mass and volume amounts, I wish I could put in mass and volume amounts, tell it what I want the part to do, and have the spreadsheet tell me how efficient/what the throughput would be. As it is, this way it just will take some trial and error. As we progress into the "similar but different" of stage 3, I'm also not terribly worried about there being some differences between the way we achieve balance with KPBS parts.

[DStaal]

1 hour ago, Merkov said:

I'm working this weekend (I started writing this response at about 10:00 MST. It is now 18:00 MST. Stupid work.) but I'll have most of next week free. If you don't get to it first, I'll see about researching a .version file for AVC. I'll add comments to the github issue, but how do we want the versioning of this thing to work? Do we want to bother with mini AVC? My thought is that if someone wants version checking, they'll have AVC proper. Also, having mini AVC for an interoperability mod seems... odd.

I'm technically working 13-hour days three days a week, an 8-hour day two days a week, and two 5-hour days.  Some of that I can dual-work KSP in. 

Anyway, I was just thinking having the version file, for those who want it.  Honestly, if you're running MKS and aren't running full KSP-AVC, you should be: It's the best way to make sure you've got updated versions of all of the parts.

1 hour ago, Merkov said:

In the video that RoverDude posted, he has guidelines on wet (with machinery) mass and dry (without machinery) and all kinds of stuff. I'll try playing with the numbers on my days off and see what I can come up with. Part of me wishes that we could do calculations in the opposite direction to what he has done; instead of saying what efficiencies, converters, etc. you want on a part and it spitting out mass and volume amounts, I wish I could put in mass and volume amounts, tell it what I want the part to do, and have the spreadsheet tell me how efficient/what the throughput would be. As it is, this way it just will take some trial and error. As we progress into the "similar but different" of stage 3, I'm also not terribly worried about there being some differences between the way we achieve balance with KPBS parts.

Do note that I think the spreadsheet is built using a lot of intrinsic assumptions - some of which RoverDude isn't even fully aware of himself.  Those assumptions are what MKS is built on - but following them too closely will just get you more MKS parts.

Anyway, I had a suggestion for the MK-1 habitat somewhere above in this thread - feel free to see how badly it works in the spreadsheet, if you have time.    Also, I had an idea today to have the greenhouse switch between a pure greenhouse mode and a 'garden' mode - lower food production, but also gives a hab multiplier.  (Dedicate some of the volume to 'walk around' space, instead of packing the plants in.)

The other question I have is about Machinery - it's a CRP resource, but if someone's running USI-LS without MKS they don't have a way to produce it off-world.  Do we care?  Should we have variants of the parts that don't use machinery to balance?  Do we make a part that can make Machinery from Ore that only exists if you *don't* have MKS?  If so, what's the ratio?

[RoverDude]

2 hours ago, DStaal said:

Do note that I think the spreadsheet is built using a lot of intrinsic assumptions - some of which RoverDude isn't even fully aware of himself. 

Not sure what this means or if you are referring to some other spreadsheet... but the integration one lived and breathed for months now  

[Merkov]

18 hours ago, DStaal said:

I'm technically working 13-hour days three days a week, an 8-hour day two days a week, and two 5-hour days.  Some of that I can dual-work KSP in. 

That sounds complicated. 12 hour days, four-on, four-off.

18 hours ago, DStaal said:

Anyway, I was just thinking having the version file, for those who want it.  Honestly, if you're running MKS and aren't running full KSP-AVC, you should be: It's the best way to make sure you've got updated versions of all of the parts.

I agree, AVC deserves way more credit than it gets. What I meant by my question was: are we going to call the pack version 0.1 when we hit stage 1, 0.2 at stage 2, etc? Are we not going to make a release until we're done stage 2...? How do you want the "versioning" to look?

Incidentally, I volunteered to look at making the AVC file because the instructions on Cybutek's web page looked pretty easy .

18 hours ago, DStaal said:

Anyway, I had a suggestion for the MK-1 habitat somewhere above in this thread - feel free to see how badly it works in the spreadsheet, if you have time.    Also, I had an idea today to have the greenhouse switch between a pure greenhouse mode and a 'garden' mode - lower food production, but also gives a hab multiplier.  (Dedicate some of the volume to 'walk around' space, instead of packing the plants in.)

I'll play around with these tonight. I forget what the volume of KPBS parts is (I don't even know if there's a good way to find it... I'll probably look at the measurements in blender or unity or something. Would KIS tell me...?)

18 hours ago, DStaal said:

The other question I have is about Machinery - it's a CRP resource, but if someone's running USI-LS without MKS they don't have a way to produce it off-world.  Do we care?  Should we have variants of the parts that don't use machinery to balance?  Do we make a part that can make Machinery from Ore that only exists if you *don't* have MKS?  If so, what's the ratio?

I'd be interested in seeing how KPBS parts fare compared to the base USI-LS parts and stock parts balance-wise. If the parts are a little overpowered with USI-LS but not MKS, I think I'm okay with that. I'd like to get balance as close as possible with MKS (even if we play with interesting ways to balance things) but if that means that removing machinery would make things pseudo-unbalanced in a USI-LS but no MKS environment, that's probably okay...? Obviously, if things are way out of whack, we might have to do something.

If we decide to keep Machinery, my suggestion would be to make the KPBS ISRU have a low-efficiency option to produce it. Machinery isn't consumed very quickly, and base USI-LS already gives players the handy 1.25m Ore to Fertilizer option. Since machinery would only be needed for KPBS stuff, it makes some sense to me to have the KPBS ISRU do that conversion. Also, since RoverDude didn't seem to think it was necessary (and frankly, neither do I) to make a new converter for Ore to Fertilizer, I don't think we need to bother making a new converter for this.

[DStaal]

17 hours ago, Merkov said:

That sounds complicated. 12 hour days, four-on, four-off.

It's not that complicated: Two jobs, with three days of overlap per week.  Both are basically 'be on call and available - and we'll pay you when you actually do something', but one is on-call at the computer and the other isn't.

17 hours ago, Merkov said:

I agree, AVC deserves way more credit than it gets. What I meant by my question was: are we going to call the pack version 0.1 when we hit stage 1, 0.2 at stage 2, etc? Are we not going to make a release until we're done stage 2...? How do you want the "versioning" to look?

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.

(But yeah, I figured it was probably pretty easy - I just haven't had time to look at it myself.)

17 hours ago, Merkov said:

I'll play around with these tonight. I forget what the volume of KPBS parts is (I don't even know if there's a good way to find it... I'll probably look at the measurements in blender or unity or something. Would KIS tell me...?)

I'd be interested in seeing how KPBS parts fare compared to the base USI-LS parts and stock parts balance-wise. If the parts are a little overpowered with USI-LS but not MKS, I think I'm okay with that. I'd like to get balance as close as possible with MKS (even if we play with interesting ways to balance things) but if that means that removing machinery would make things pseudo-unbalanced in a USI-LS but no MKS environment, that's probably okay...? Obviously, if things are way out of whack, we might have to do something.

If we decide to keep Machinery, my suggestion would be to make the KPBS ISRU have a low-efficiency option to produce it. Machinery isn't consumed very quickly, and base USI-LS already gives players the handy 1.25m Ore to Fertilizer option. Since machinery would only be needed for KPBS stuff, it makes some sense to me to have the KPBS ISRU do that conversion. Also, since RoverDude didn't seem to think it was necessary (and frankly, neither do I) to make a new converter for Ore to Fertilizer, I don't think we need to bother making a new converter for this.

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.

[DStaal]

Ok, did a pass on the logistics.  I think I've got it, but I'll be playing around a bit to test.  Anyone else is free to do so as well - Sometime soon I'll update the readme, changelog, version, and put out a stage-1 release unless people spot any glaring bugs.

[dboi88]

I should get the models and textures over sometime in the next 12 hours.

I'll take a look at the animations. An animation is an animation in unity you don't tie into any mods code base so I see no reason we can't swap out the deploy modules to use MaterialKits. 

[DStaal]

3 hours ago, dboi88 said:

I should get the models and textures over sometime in the next 12 hours.

I'll take a look at the animations. An animation is an animation in unity you don't tie into any mods code base so I see no reason we can't swap out the deploy modules to use MaterialKits. 

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.