[1.12.x] USI Life Support

[oglommi]

The crew on my ship turned grumpy despite having supplies and don't want to work anymore. After warping to a maneuver node my supplies and fertilizer in my nom-o-matic 500 dissapeared and the crew turned grouchy, despite having a 3.75 lifesupport tank full of supplies. The Crew refuses to come back to work despite me cheating in more fertilizer and balancing out the supplies. They are gluttonous sinners and are eating like crazy but not working.

 

Help

Edited March 2, 2016 by oglommi

[ExplorerKlatt]

1 hour ago, oglommi said:

The crew on my ship turned grumpy despite having supplies and don't want to work anymore. After warping to a maneuver node my supplies and fertilizer in my nom-o-matic 500 dissapeared and the crew turned grouchy, despite having a 3.75 lifesupport tank full of supplies. The Crew refuses to come back to work despite me cheating in more fertilizer and balancing out the supplies. They are gluttonous sinners and are eating like crazy but not working.

 

Help

Do you have EC?

[oglommi]

Yes I have EC, I have everything.

 

The problem was not enough workspace. They turned grumpy because all the capsules where full of people.

 

 

[RoverDude]

Looks like I missed a lot in this thread   I'll be bundling up an update with the new PR's and reviewing the current issue logs.

[nathan1]

9 hours ago, Kobymaru said:

Thanks a lot! I'm gonna check out the changes when I get home, and to some testing. A note though, RoverDude likes his changes against the DEVELOP branch for some reason (I gotta ask him why, some time...). Could you rebase it?

While we're at it, what if we compile a suite of tests ranging from something as easy as "timewarp focused vessel and check if consumption is correct" to all of the docking/undocking business?

I had based it on the dev branch, but the dev branch has moved on. I'll rebase it so it's up-to-date.

Unfortunately there's a pretty big bug with my changes currently: if you run out of supplies during catch-up then the negative effects will not get applied. I know the exact line of the code that's the problem, but the root of the problem is subtle differences for detecting that catch-up is in progress (so that it doesn't kill your kerbals during catch-up if your vessel/base is in the middle of creating resources at the same time as they're being consumed) between what the code used to do and my changes. For now I'm mulling over what I can do to fix it...

A suite of tests is a good idea. Were you thinking something automated, or a list on the wiki? I'd recommend keeping it as concise as possible; if it's short and to the point then it's a convenient check-list for testing, but if it's long and verbose then people will avoid it and it will quickly become out of date.

[Kobymaru]

25 minutes ago, nathan1 said:

Unfortunately there's a pretty big bug with my changes currently: if you run out of supplies during catch-up then the negative effects will not get applied. I know the exact line of the code that's the problem, but the root of the problem is subtle differences for detecting that catch-up is in progress (so that it doesn't kill your kerbals during catch-up if your vessel/base is in the middle of creating resources at the same time as they're being consumed) between what the code used to do and my changes. For now I'm mulling over what I can do to fix it...

Since RoverDude is back, we should leave the heavy coding to him

25 minutes ago, nathan1 said:

A suite of tests is a good idea. Were you thinking something automated, or a list on the wiki? I'd recommend keeping it as concise as possible; if it's short and to the point then it's a convenient check-list for testing, but if it's long and verbose then people will avoid it and it will quickly become out of date.

I live by the "something is better than nothing" principle. So automatic would be awesome, but for now at least a check-list would be good. The idea is just a little helper for RoverDude and people who make pull requests, to check if their code breaks other stuff.

[JPLRepo]

I've been reading back a few pages and noticed a few bugs related to un-kerbal'd vessels.
I also picked this up last week and  I submitted a PR that Roverdude applied today to fix the life support recipe processing for when a vessel is un-crewed for a period of time. The life support recipe would then play catch-up and consume all the supplies for the entire period of time it was un-crewed. So next version should fix that.

[RoverDude]

I'll be doing an interim release today - that should give folks a nicer base to work off of.

And I take PRs against dev since that's what I work against   Master is only for the released versions

[RoverDude]

0.3.13 - 2016.03.02
-------------------
Remove ReplacementParts input ressource from MPL (thanks far-lobyte!)
Fixed issue with empty vessels and supply consumption upon Kerbals entering (thanks JPLRepo!)
added more info to the VAB info windows (Thanks bennord!)
Orbiting/Splashed/Landed should display correctly now.
Both hab time and homesickness time are shown.  When either timer expires, the habitation effect takes place.
Corrected an issue that was causing hab time to incorrectly reset.
Fixed an issue where supply consumption was out of sync with recyclers/etc. during catch-up mechanics.
Fixed an issue causing diminishing returns for recyclers 
Fixed an issue where certain settings were not having effects

 

[Side note - the VAB display also has an update but I'd consider this experimental for now]

[Kaa253]

@RoverDude Wonderful, thank you for the update. Can't wait to try it out. 

[jofwu]

I was digging through the code for how multiple Recycler work earlier, which turned out to have some issues which are now fixed. Since I got nice and cozy with what's going on I thought I'd explain for anyone else who's curious for the gory details:

A Recycler has an Efficiency and a Crew Capacity. So for example the stock MPL (Science Lab) is modified by USI-LS to have 70% Efficiency and a Crew Capacity of 5. This means your usual consumption rate of 16.2 Supplies per Kerbal-day will be reduced by 70% (i.e. multiplied by 1 - 0.7 = 0.3) for up to 5 Kerbals. So one Kerbal with an activated Science Lab would eat 1*16.2*0.3 Supplies/day. Two Kerbals would eat 2*16.2*0.3 Supplies/day. Five Kerbals would eat 5*16.2*0.3 Supplies per day.

After you exceed the Crew Capacity, the Efficiency is reduced proportionally to how far over capacity you are. Say you've got 8 Kerbals in a ship/colony with a single activated Science Lab. Instead of getting the 70% discount you're going to get 5/8ths of that discount. For 10 Kerbals (two times overcapacity) you're only going to get 5/10 = 1/2 of the Science Lab's normal rate. So 10 Kerbals with a Science Lab will only get an "effective efficiency" of 0.7*(5/10) = 0.35. And then, as before, 35% efficiency translates to a 1 - 0.35 = 0.65 reduction. In the end your Kerbals will collectively consume Supplies at a rate of 10*16.2*(1-0.7*5/10) = 10*16.2*(0.65) Supplies/day. With a second Science Lab you would no longer be overcapacity so you wouldn't see the efficiency reduction. You'd simply have 10*16.2*0.3 Supplies/day. Big difference.

Lastly I'll talk about having multiple activated Recyclers in your colony. There's two key ideas. First, the effective efficiencies for each Recyler part simply add up into a single colony-wide effective efficiency. Second, that number is limited by the efficiency of your most efficient part. So let's look at some numbers... I just talked about having two Science Labs. The math isn't actually as simple as I made it sound. You have to look at each Recycler separately. Since they're the same part in this case, the math for each is the same. You've got 10 Kerbals, a Crew Capacity of 5, and an Efficiency of 70%. So that's 0.7*(5/10) = 0.35. But you've got two of them, so they add together: 0.35 + 0.35 = 0.7 = 70%. But what happens if you had 9 Kerbals with two Science Labs? That's an efficiency of 0.7*(5/9) = 0.39 each, producing a sum of 0.39 + 0.39 = 0.78. In this case, since we're higher than the max single-part efficiency of 70%, we cap things off at 70% instead of allowing for a 78% efficiency. Now, if you're running over the capacity of both you'd see a reduction just as you'd expect. If you have 14 Kerbals and two Science Labs that's 0.7*(5/14) = 0.25 each or 0.5 total. Since this is less than the 70% cap we go with 50%. Your Kerbals will consume at a rate of 14*16.2*(1-0.5) = 14*16.2*0.5.

Hopefully this clears things up for anyone like myself who wonders!

[Brigadier]

1 hour ago, RoverDude said:

[Side note - the VAB display also has an update but I'd consider this experimental for now]

I'm not so sure I want to know what this means

[DStaal]

It's nice - a bit more of a breakdown of what's going on with the vessel you're designing.

[merlinux]

Hi all,

Im sorry to ask those questions which Im sure have been answered in the past somewhere in this thread. But searching has been a bit of a hit and miss. I have been away from KSP for more than a year now. Tried a bit of 1.0 when it first came out but that's it. I have used USI mods a lot in the past but things have changed so much

So I play in sandbox mode, never been a fan of the grinding that career requires. Now I have set up a mockup base at KSC and a space station in mun orbit and I have trouble understanding how LS works. When I look at my stats the kerbals on kerbin have ran out of supplies yet hab andhome stats still show some high values, and on the space station I have also very values. What does exactely 'hab' and 'home' mean? I supposed 'home' is for the homesick time?

Is it because I play sandbox and it is meant to be played on career?

[nathan1]

3 hours ago, RoverDude said:

0.3.13 - 2016.03.02
-------------------
Remove ReplacementParts input ressource from MPL (thanks far-lobyte!)
Fixed issue with empty vessels and supply consumption upon Kerbals entering (thanks JPLRepo!)
added more info to the VAB info windows (Thanks bennord!)
Orbiting/Splashed/Landed should display correctly now.
Both hab time and homesickness time are shown.  When either timer expires, the habitation effect takes place.
Corrected an issue that was causing hab time to incorrectly reset.
Fixed an issue where supply consumption was out of sync with recyclers/etc. during catch-up mechanics.
Fixed an issue causing diminishing returns for recyclers 
Fixed an issue where certain settings were not having effects

 

[Side note - the VAB display also has an update but I'd consider this experimental for now]

A new bug is introduced with this version: supplies consumption scales up with the Unity physics time-step (instead of consuming supplies once every second it's consuming supplies every FixedUpdate - so supply consumption appears to be about 25x higher in this version on my machine, consuming more than 1 supply every minute). The check referred to in this comment in the source appears to have been moved after supply consumption and needs to happen before instead (as it was before this version).

[oglommi]

Hey hey everybody. Just wondering if there are other factors making the crew grouchy other than supplies and workspace?

[Tossy64]

On 2/14/2016 at 8:21 PM, RoverDude said:

0.3.12 - 2016.02.13
-------------------
Various display bug fixes

1.  This changed, yes it is the new default

2.  That should just be visual, but I'll take a peek

3.  Sorry, can't control MechJeb

4.  See if that still occurs in the new patch - if so, logging github issues is the best way to get things changed

So will you update the first post description, if the orange suit exemption is no longer a thing? Is there a better "manual" for how this works, because the first post doesn't mention this habitability concept either.

[RoverDude]

4 hours ago, merlinux said:

Hi all,

Im sorry to ask those questions which Im sure have been answered in the past somewhere in this thread. But searching has been a bit of a hit and miss. I have been away from KSP for more than a year now. Tried a bit of 1.0 when it first came out but that's it. I have used USI mods a lot in the past but things have changed so much

So I play in sandbox mode, never been a fan of the grinding that career requires. Now I have set up a mockup base at KSC and a space station in mun orbit and I have trouble understanding how LS works. When I look at my stats the kerbals on kerbin have ran out of supplies yet hab andhome stats still show some high values, and on the space station I have also very values. What does exactely 'hab' and 'home' mean? I supposed 'home' is for the homesick time?

Is it because I play sandbox and it is meant to be played on career?

Hab = how long they will stay in their current abode (i.e. if you go from a cushy base to a tiny capsule, this changes).  Home = how long they can stay off of Kerbin based on the very best hab they have ever had.

So a guy stuffed in a capsule has low values on both.  A guy launching in a giant colony ship probably has high values on both.  But if he is sent off in a small rover later, home will be high, hab will be small (so while you can extend hab with nice bases, they either need to stay there, or come back after short jaunts).  Example would be a trip to Duna with a larger command ship with lots of hab space, and a small surface lander that just needs enough hab to last getting down to the surface and back.

4 hours ago, nathan1 said:

A new bug is introduced with this version: supplies consumption scales up with the Unity physics time-step (instead of consuming supplies once every second it's consuming supplies every FixedUpdate - so supply consumption appears to be about 25x higher in this version on my machine, consuming more than 1 supply every minute). The check referred to in this comment in the source appears to have been moved after supply consumption and needs to happen before instead (as it was before this version).

The line is moved in the correct place, but there's very likely another bug causing over-consumption.

3 hours ago, oglommi said:

Hey hey everybody. Just wondering if there are other factors making the crew grouchy other than supplies and workspace?

That should be it - tho it's hab space not work space   Also, it can be EC as well, not just supplies.

2 hours ago, Tossy64 said:

So will you update the first post description, if the orange suit exemption is no longer a thing? Is there a better "manual" for how this works, because the first post doesn't mention this habitability concept either.

It's a thing that's selectable, will fiddle with the OP as I have time

[Kowgan]

Did you increase the hab value for pods, from 30 days per seat to 150d?

Spoiler

Also, all those kerbals' home being 105 years looks weird, almost like not right.

Spoiler

 

[RoverDude]

Default for USI-LS (without UKS or MKS-Lite) has a much longer hab time, yes

 

Just uploaded a new version that should fix the overconsumption problem

[Kowgan]

Overconsumption is still happening here on old vessels, even while not warping.

I'm trying to find the correct numbers, but I noticed that kerbals were eating twice as much in one of the vessels. At another vessel with 4 kerbals, 10 days of supplies were consumed in 1h40m. In that same vessel, the MPL's Life Support module stopped working. It works normally on new vessels.
Resetting LifeSupportScenario didn't solve the issues.

Also, HomeWorldAltitude doesn't prevent kerbals from eating supplies in a vessel at the launchpad.

Edited March 3, 2016 by Kowgan

[merlinux]

1 hour ago, Kowgan said:

Did you increase the hab value for pods, from 30 days per seat to 150d?

  Reveal hidden contents

Also, all those kerbals' home being 105 years looks weird, almost like not right.

  Reveal hidden contents

 

How well so my sandbox game is just showing normal numbers then I thought the home was way way to high and maybe it would be different if I played career.

[Kowgan]

@merlinux Turns out it's a desync glitch between versions. Removing the LifeSupportScenario section from my save file solved it. Remember to backup, always.

[merlinux]

@Kowgan Okie I'll have a look. Been a while since I last looked at a persistent file. how fun!

Edited March 3, 2016 by merlinux

[RoverDude]

Let me tinker with it.