Jump to content

[1.2.2] [0.9.5] KPBS/MKS Integration Pack


DStaal

Recommended Posts

9 minutes ago, DStaal said:

No problem.  Thanks for the PR.  :wink:  Am I correct the issue you're trying to solve is that the parts don't have the same fuel capacity as their pure KPBS equivalents?  If so, I see your point, but I think that's probably the wrong solution - we've likely got *all* of the contents undersized...   (CRP resources all standardized on what '1 unit' means - but base KSP resources aren't standardized.  Looks like I've made the dumb mistake of not compensating for that on the initial creation of these parts, while still compensating on the calculations, meaning everything's too small.)

np, glad you look into it!

Yes, I believe it might just be good to have something equal like the "stock" KBPS containers. I would not mind you change the PR at your preference and idea but the current one if way too low tho.
Idea: make it half the KBPS ones.

Link to comment
Share on other sites

  • 1 month later...

Hey @DStaal, what are the current thoughts on the status of the balance for USI-LS?  Has it been gone through against RD's Balance Spreadsheet to make sure everything is kinda in line with RD's recommendations?

My personal priorities for what I want to check first is to make sure USI-LS is properly balanced, then massage USI-MKS.

Link to comment
Share on other sites

Just as a test of current balance, I did a quick run through for the KPBS Greenhouse.  For a volume calculation I eyeballed it, when expanded it looks to have very similar volume to an USI-MKS 2.5m Tundra module so I used the calculations for that (Volume of 19.64, mass of between 2.9 and 3.9 for this kind of mostly-open interior volume usage).  Also, it looks like the greenhouse has had its capacity bumped to 3 from 2 recently?

Keeping the resources the same at 400/400/400, according to RD's spreadsheet the following specs would keep it balanced with the rest of MKS:

  • Mass: 3.415 (down from 3.8)
  • Multiplier: 1.6 for 3 crew (Up from 1)
  • EC Storage: 1200 (Currently 0, but all the other USI greenhouses have some kind of EC storage so I ballparked a mostly similar figure)
  • Conversion: .0007 Mulch and .00007 Fertilizer for .00077 Supplies (This is roughly 1/3 of the current .00204 Mulch throughput)
  • EC Usage: 1.54 (Down from the current 5.28)

To my eye, this makes pretty good sense.  Currently the KPBS greenhouses feel way overpowered in terms of throughput, this backs that down a lot but leaves us a reason to chose them over a stock USI part for some situations.  No USI parts act as both converters and a hab multiplier, so this is unique in that way without overpowering everything else.

Any thoughts?

Nevermind this is wrong.  I've got a sheet I'm taking notes in here if anyone would like to see: https://docs.google.com/spreadsheets/d/1vQYEpfq3YMRCbIYQUJdH_hyT2GsjzMR_nPrIBD7Seb0/edit?usp=sharing

 

Edited by tsaven
I'm wrong
Link to comment
Share on other sites

18 hours ago, tsaven said:

Hey @DStaal, what are the current thoughts on the status of the balance for USI-LS?  Has it been gone through against RD's Balance Spreadsheet to make sure everything is kinda in line with RD's recommendations?

My personal priorities for what I want to check first is to make sure USI-LS is properly balanced, then massage USI-MKS.

We actually spent quite a bit of time and have what we believe to be two good balance sets for USI-LS - the one we submitted to KPBS as the 'standard' and the one integrated into this pack.  (Which uses some MKS-specific features to expand options.)  We even have a decent rough outline for further MKS support.  You can see current issues tracking this and a rough idea of current status here: https://github.com/DanStaal/KPBStoMKS/projects/2

General thoughts are to have a bit more emphasis on the 'efficiency' mechanic than standard MKS - basically to have a paired set of parts, one manned and one automated for each of the two general stages of resource extraction/processing, and try to balance them so that you typically want to build both as a pair.  The Central Hub should rarely be useful on it's own - even just as hab space.  However, it should offer good bonuses across the board to *other* parts, so that you'll want one on any decent sized base.  (It gets lots of multipliers and efficiency modes - but not much in the way of direct modes.)  (BTW: in one of your deleted posts (I get them via email) you mentioned changing the science multiplier.  I *hate* that: It's 'invisible' in-game, and is therefore just confusing to the user.  As far as I'm concerned *all* labs should have the same multiplier, unless and until the UI changes to include that data.)

I'll try to take a look at your spreadsheet in a bit.  We had some extensive thoughts, and and I know I didn't always translate them to the configs I've got in-progress completely.

Link to comment
Share on other sites

3 hours ago, DStaal said:

We actually spent quite a bit of time and have what we believe to be two good balance sets for USI-LS - the one we submitted to KPBS as the 'standard' and the one integrated into this pack.  (Which uses some MKS-specific features to expand options.) 

Gotcha.  Right now I only have only compared the 'Standard' configs to RD's guidelines.  I haven't looked at this MKS pack yet.

Short version for the 'Standard' config is that most of the KPBS parts get nerfed, but most also get lighter.  This is just pulling the numbers directly from RoverDude's spreadsheet, and the biggest constraint is the physical volume of the KPBS parts.  They're so much physically smaller than his USI parts that they're really limited in terms of how much efficiency/throughput/features they can have.  The volume numbers I'm using are guestimates from putting them next to RoverDude's parts in the editor and eyeballing them; but if Nills wants to chime in with more precise numbers of the models I can recalculate everything.

But there's still a lot of fiddling that can be done, especially with regards to functionality.  For example, should we remove more multiplier from the greenhouse to give it more throughput capacity?

Regarding the Command Hub:

I also agree with your idea that the Command Hub shouldn't be self sufficient, and now I understand why you guys gave it a Hab Multiplier instead of more Hab Bonus.  That's the correct decision, so I'm going to change my spreadsheet to reflect it.  That will give me room to un-nerf the science lab as well, which I had to do when using Hab Bonuses to keep it all under the volume limitation.  Seems like it'll still have to be nerfed in some way. 

Edited by tsaven
I was wrong
Link to comment
Share on other sites

Hey, I don't know if this is intentional or a known issue, but it seems that when I have the Development pack installed in the game all the expandable modules now have a ton of stuff crammed inside them.  Looks like random panels and things?  This affects the Laboratory, MK2 hab, Greenhouse and both cultivators.

 

PLS81ru.jpg

Link to comment
Share on other sites

44 minutes ago, tsaven said:

Hey, I don't know if this is intentional or a known issue, but it seems that when I have the Development pack installed in the game all the expandable modules now have a ton of stuff crammed inside them.  Looks like random panels and things?  This affects the Laboratory, MK2 hab, Greenhouse and both cultivators.

Does it show that when expanded?  And does it only show that when this pack is installed?

Non-expanded that could be considered normal.  :wink:

 

Also, I'm actually all for just pulling the science lab out of the Central Hub when we do this.  The hub needs more of an overhaul with this pack than most parts, and I get the feeling it's just got the lab because in base KSP it should be *something* other than just a command pod.  With MKS mechanics there's plenty else for it to be.

Edited by DStaal
Link to comment
Share on other sites

1 hour ago, DStaal said:

Does it show that when expanded?  And does it only show that when this pack is installed?

Non-expanded that could be considered normal.  :wink:

Also, I'm actually all for just pulling the science lab out of the Central Hub when we do this.  The hub needs more of an overhaul with this pack than most parts, and I get the feeling it's just got the lab because in base KSP it should be *something* other than just a command pod.  With MKS mechanics there's plenty else for it to be.

Yeah, it's with them expanded.  And it only shows when this pack is installed.  Only other things I have installed are MKS, USI-LS and KAS/KIS.  When I remove this dev pack, everything looks as it should.

YBicu6M.jpg

lsCoxa9.jpg

wrEKeaz.jpg

 

At least for when used with USI-LS, I think pulling the Science Lab out of the Command Hub is an excellent idea.  That removes more of the "Entire-Base-in-a-single-part" aspect of it, and gives more room for buffing back the multiplier to 1.5.

You have any thoughts on the changes to the habs, greenhouse and recycler?

Edited by tsaven
typo, clarification
Link to comment
Share on other sites

I was waiting to give a response until I had time to do a proper in-depth response, but it's looking like that will be next year, so...

For the visual glitches, I'm guessing that's because we swap out which module does the extending so we can use some USI mechanics.  This may be something we want to switch back - it might be worth talking to Nils on whether getting resources to expand can be a thing using his plugin.

As for the other USI-LS questions - my main response is to go back through this thread.  We had some discussions on pretty much every part, as well as some overall philosophy.  You can see most of our thoughts, ideas, what we chose/rejected and why.  There is a little discussion in GitHub issues on specific parts, but most of it was here.

Link to comment
Share on other sites

  • 2 weeks later...

Okie dokie - the new ModuleManger 3.0.0 is out and it seems KPBStoMKS is the first one I found to be pinged for adding in multiple passes on the parts. I can understand why there is multiple with wanted to load after both mods this mod refers to.

As this results in the patch not working, any idea which one should be the one left on the patch? PlanetarySurfaceStructures or USITools? or is there another option?

[ERR 23:36:00.970] [ModuleManager] Error - more than one pass specifier on a node: KPBStoMKS/Part_Mods/Inflation_changes/@PART[KKAOSS_Habitat_MK2_g]:AFTER[PlanetarySurfaceStructures]:AFTER[USITools]

[ERR 23:36:00.973] [ModuleManager] Error - more than one pass specifier on a node: KPBStoMKS/Part_Mods/Inflation_changes/@PART[KKAOSS_Greenhouse_g,KKAOSS_LS_MKSAddon_Greenhouse*]:AFTER[PlanetarySurfaceStructures]:AFTER[USITools]

[ERR 23:36:00.976] [ModuleManager] Error - more than one pass specifier on a node: KPBStoMKS/Part_Mods/Inflation_changes/@PART[KKAOSS_Science_g]:AFTER[PlanetarySurfaceStructures]:AFTER[USITools]

 

Edited by wile1411
Link to comment
Share on other sites

@wile1411 Where did you get that version of the file (KPBStoMKS/Part_Mods/Inflation_changes)? All the versions I can find on GitHub use  :AFTER[PlanetarySurfaceStructures]:NEEDS[KolonyTools]

 

However to answer the question in general. If a patch should run after modA, modB, ..., modN then use :NEEDS[modA,modB, ... ,modN]:AFTER[modN] where modN is the last mod in alphabetic order.

Link to comment
Share on other sites

3 minutes ago, Aelfhe1m said:

@wile1411 Where did you get that version of the file (KPBStoMKS/Part_Mods/Inflation_changes)? All the versions I can find on GitHub use  :AFTER[PlanetarySurfaceStructures]:NEEDS[KolonyTools]

 

However to answer the question in general. If a patch should run after modA, modB, ..., modN then use :NEEDS[modA,modB, ... ,modN]:AFTER[modN] where modN is the last mod in alphabetic order.

I checked the version file and it's the same one as listed in the Aug release on Github.

I downloaded that version again and found that yeah, it doesn't have the double pass. I've reinstalled and should be good if that's the default. No idea where the extra pass game from

Link to comment
Share on other sites

  • 2 months later...
On 11/20/2017 at 5:47 AM, DStaal said:

I was waiting to give a response until I had time to do a proper in-depth response, but it's looking like that will be next year, so...

For the visual glitches, I'm guessing that's because we swap out which module does the extending so we can use some USI mechanics.  This may be something we want to switch back - it might be worth talking to Nils on whether getting resources to expand can be a thing using his plugin.

As for the other USI-LS questions - my main response is to go back through this thread.  We had some discussions on pretty much every part, as well as some overall philosophy.  You can see most of our thoughts, ideas, what we chose/rejected and why.  There is a little discussion in GitHub issues on specific parts, but most of it was here.

Hey DStaal, I know we're digging up ancient history here and I don't seem to be able to devote solid time to mods (Work and other hobbies keep getting in the way), and I'm not sure how much effort you feel like putting into this now anyway with yet another big USI release on the horizon.

I personally would vote for not requiring any resources to expand the KPBS parts.  I think it's one thing that can differentiate KPBS parts from USI stock parts, and I personally like it.

I view the KPBS expansions as more like the slide-outs on an RV, because even when contracted the parts are still very big and heavy.  While the USI stock parts that require resources are generally tiny when collapsed when compared to their fully expanded size.  The USI stock stuff is almost like an inflatable tent when compared to the already large and heavy KBPS parts.

Link to comment
Share on other sites

15 hours ago, tsaven said:

Hey DStaal, I know we're digging up ancient history here and I don't seem to be able to devote solid time to mods (Work and other hobbies keep getting in the way), and I'm not sure how much effort you feel like putting into this now anyway with yet another big USI release on the horizon.

I personally would vote for not requiring any resources to expand the KPBS parts.  I think it's one thing that can differentiate KPBS parts from USI stock parts, and I personally like it.

I view the KPBS expansions as more like the slide-outs on an RV, because even when contracted the parts are still very big and heavy.  While the USI stock parts that require resources are generally tiny when collapsed when compared to their fully expanded size.  The USI stock stuff is almost like an inflatable tent when compared to the already large and heavy KBPS parts.

Not much with a new big release - and I'll admit I tend to work on this in spurts...  (What I'd really like to do is *reverse* the spreadsheet that @RoverDude made, as it's set up more for a part maker that knows what the parts are supposed to do and wants their stats, when almost everyone but him has parts where they know the stats but want to know what the parts should do.)

I still like the theory of requiring a little bit of resources, for reasons I've given - however there's a more practical consideration that should take priority and that I should update them based on: It currently causes a bug.  RoverDude's expansion plugin doesn't handle IVA's, and Nils277's does, and the parts have nice IVA's.  Currently switching code to use resources means the IVA's don't work - and I don't think that's worth my thoughts on the small amount of expansion resources.

If I get a chance and think of it, I'll work on it.  If there's a PR to fix that bug, I'll take it.  :wink: 

Link to comment
Share on other sites

2 hours ago, DStaal said:

  (What I'd really like to do is *reverse* the spreadsheet that @RoverDude made, as it's set up more for a part maker that knows what the parts are supposed to do and wants their stats, when almost everyone but him has parts where they know the stats but want to know what the parts should do.)

The only rub is that it would be hard to do this for things that support multiple processes (even simple ones like mixed hab).

Link to comment
Share on other sites

15 minutes ago, RoverDude said:

The only rub is that it would be hard to do this for things that support multiple processes (even simple ones like mixed hab).

True - but iterating mass/volume assigned to different roles to a defined total is likely to be more accessible to a third-party modder than iterating roles and efficiencies to find mass/volume totals that match a current number.  Even if the spreadsheet only does one process at a time and the modder has to do the split themselves, I think it'd be easier to work with.

(Though again - I see why you would build the spreadsheet the way you did, and why it's the most useful configuration for you.)

Link to comment
Share on other sites

12 hours ago, DStaal said:

Not much with a new big release - and I'll admit I tend to work on this in spurts...  (What I'd really like to do is *reverse* the spreadsheet that @RoverDude made, as it's set up more for a part maker that knows what the parts are supposed to do and wants their stats, when almost everyone but him has parts where they know the stats but want to know what the parts should do.)

I still like the theory of requiring a little bit of resources, for reasons I've given - however there's a more practical consideration that should take priority and that I should update them based on: It currently causes a bug.  RoverDude's expansion plugin doesn't handle IVA's, and Nils277's does, and the parts have nice IVA's.  Currently switching code to use resources means the IVA's don't work - and I don't think that's worth my thoughts on the small amount of expansion resources.

If I get a chance and think of it, I'll work on it.  If there's a PR to fix that bug, I'll take it.  :wink: 

I wonder if there's a way to maybe just make it consume electrical resources, and a LOT of them?  I'm still so new to the coding aspect of this, but I wonder if there's an easy way to have it require 1,000ec/sec or something for the 4 seconds that the parts are moving.  That would give a bit more challenge as you'd need some other stuff to expand it, but it's not nearly as much of a logistics challenge as bringing the thousands of mkits needed to expand the USI inflatable parts.

Either way, fixing this bug might be a good newbie project, so perhaps I'll take a crack at it. I'm still very slowly learning the tricks of MM and the other aspects of coding for KSP.  I get motivation and time in spurts as well, and I have to balance it against my motivation to pay attention to the things in my life that keep me employed. :)

9 hours ago, DStaal said:

True - but iterating mass/volume assigned to different roles to a defined total is likely to be more accessible to a third-party modder than iterating roles and efficiencies to find mass/volume totals that match a current number.  Even if the spreadsheet only does one process at a time and the modder has to do the split themselves, I think it'd be easier to work with.

(Though again - I see why you would build the spreadsheet the way you did, and why it's the most useful configuration for you.)

I think even he runs into this problem a little bit, from watching his how-to video on using the spreadsheet.  He knows the cube of the part, and has to fiddle with the ratios and capabilities until the end result is the number he wants.  It does require a good amount of back-and-forth, but I'm not sure there's a better way to do it.  Given how complicated the spreadsheet can quickly get, I'm not sure there would be a way to reverse it back to source numbers because the same end result of mass/cube can be achieved by thousands of different combinations.

Link to comment
Share on other sites

  • 1 month later...

(How) Is the K&K Greenhouse container supposed to work? Does it work on its own like the MKS nomomatic things? I have one and with or without scientists at the base it doesn't produce and indicates "zero efficiency"

Link to comment
Share on other sites

15 hours ago, juanml82 said:

(How) Is the K&K Greenhouse container supposed to work? Does it work on its own like the MKS nomomatic things? I have one and with or without scientists at the base it doesn't produce and indicates "zero efficiency"

It should work fine on it's own.  (Just tested in my install.)  Can we get a picture?

Link to comment
Share on other sites

On 3/29/2018 at 9:28 PM, juanml82 said:

Sorry it took so long, I went over this every way I could think of...

I still don't see what's adding that 'Dump Excess Oxygen' button, or what's causing your behavior.  Obviously something else is affecting that part, but I don't see evidence of a patch doing it.

This is definitely a mod interaction, not something purely with this mod (which doesn't actually do anything to that part, besides add MKS weight-balancing).  You're going to need to start checking other mods you have that might affect it - I'd start with anything that might have added that Oxygen button in.

Link to comment
Share on other sites

This thread is quite old. Please consider starting a new thread rather than reviving this one.

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.

×
×
  • Create New...