[1.12.x] USI Life Support

[RedParadize]

Hello RoverDude.

First of, awesome work! I realy like what you did with MKS/OKS. I am realy entusiast about those modular inflatable part, great stuff. I noticed that You didn't include storage for TAC resource in them. So I decided to take a look at your life support system. I like the single resource system, its better, but I have some issues with the Life support status, in VAB is empty box, it doesn't update when I had/remove supply. I have to lunch the ship to see how much time I have left. Is it normal or do I have a issue with my install?

I also have some suggestion (like all my suggestion, its extravagant and allot of work):

I like the idea of riots when out of supply. But instand of having the original team immune to it. Its the badass that should be immune. Right now, the only thing that badass do is smiling all the time, that would be something that make them valuable. Also. instand of having a fixed 15 days without supply. It would be great if it was proportional to (Braveness + Experience) / Dumbness.

Just to go a bit furter, hard mode: Badass could have a chance to control the panicing crews and ration them for a longer period. ( Voice acting: Jeb is Captain Kirk and Valentina is Hellen Riplay. On Hellium of course). If Badass don't manage to constrain the panicing crew, and over time it will happen, they will riot and start to randomly destroy stuff, crash into something, head straight back Kebin and burn all the fuel etc...

Crew selection is a serious business.

- - - Updated - - -

Great work! I have one suggestion though, more roleplay-ish. I like the idea that Kerbal don't die by default (indeed I've done goofed and still do sometimes) and the idea of them going on a strike is funny.

I like to pretend that, instead of refusing to work, the advanced kerbal technology has devised an "hibernation" mode. Whenever they run out of the time they will allow themeselves to be hungry, they sit down and put themselves on stasis (with 0 consumption) for an indeterminate amount of time, programming the Pod to "wake" them up as soon as supplies are there.

I think it fits better the idea of life support. I know it's totally irrelevant and there's no need to change anything, but just pitching my idea.

Deep freeze does that with dedicated part. You might want to take a look at it, good stuff.

[Hevak]

VAB window doesn't work, it's the same issue for all I'm pretty sure. Also not sure if it was intended to work like the TAC one where it is for building. Think it was just meant to show the status of what craft you have out already. Idk really.

The 15 days bit was a conscious choice he made instead of adding resources to every command pod like TAC does, it's something he never liked about TAC. Also the changing of consumption based on courage/ stupidity/ experience is probably a little bit too difficult to me. It would make it extremely difficult to plan and work with Lifesupport if every kerbal is using the stuff at different rates. It would also probably be quite difficult to code the timers and stuff. Espcially if you have a base or something where you're adding kerbals later. Like you have a ship with LS for plenty of time left, yet rescue a kerbal or pick up a kerbal to bring home and suddenly you're now short on Lifesupport and your trip is doomed.

your other suggestions while some are cool, he will probably say out of scope of the mod. And really I don't want a feature like that myself. So if anything it would definitely need to be totally optional. And really if it is,I think those kinds of things are better done as a seperate mod that can integrate with the life support mod, or any LS mod if wanted. Just seems like it would be better served as a distinct thing. Just my thoughts.

RE: TAC storage for mks, he simply didn't make dedicated parts for TAC resources as to not clutter up the parts list, because as he said when he changed mks to USI LS, TAC has plenty of containers to use for it's own resource storage. MKS still works with TAC though.

- - - Updated - - -

@Roverdude.

So I have had an issue pop up though I'm not sure if it happens every time. I launched a craft up with no supplies into LKO to do the kerbin first contract to dock two ships together. So I launched the first craft, then went back to VAB and launched a second craft exactly the same and then did the whole rendezvous thing. Well when I got into orbit after about idk 30-40 mins or so of game time the first crafts timer in the LS window said it had been in orbit for like 10 days.

then a day or so later of kerbin time, I launched a craft into orbit with a mun lander on it, moved a kerbal pilot to the lander, undocked it and then landed the launch craft. Then I launched the actual craft I was going to send to dock with the lander and carry it to the mun, and had the same issue pop up. This time the timer said that the lander craft had been in orbit for 12 days, really it had only been in orbit for maybe an hour. The craft for the trip to the moon had Lifesupport supplies on it, enough for 50 days. And when I docked with the lander, it immediately lost 12 days worth of supplies that it thought the lander was behind.

Very strange. And I'm trying to see if I can replicate this consistently and find more info about this issue. Other than this I mean everything works fine with Life support. I'm not getting any errors or anything that I can see. And it seems to only happen to timers on ships with no supplies on board and strangely only in LKO. As I sent a quick mun trip flyby with no supplies on it and it never had any issues with the timers. And it's possibly only craft that has a docking port. Both were stock docking ports. But I've sent many craft into orbit and had them there for some time wiith no supplies to launch satellites that had separators on them. And I never noticed an issue with timers on them either.it was only the ones that had docking ports.

Edited July 27, 2015 by Hevak

[cantab]

Really only looked at this briefly so far, but a barrage of questions/feedbacks:

What made you decide to put all the parts in the same relatively early tech node?

Is there a GUI to change the settings? If so how do you get to it? If not do you plan on adding that? Relatedly, do you plan on moving those settings into the save file so they can be different for different saves?

What does the line

HomeworldAltitude = 50000

mean in the GameData/UmbraSpaceIndustries/LifeSupport/Settings.cfg file?

What's the supplies consumption rate of the Kerbals? In what if any situations will they not consume available, unlocked supplies? (Eg landed on Kerbin?)

Do you plan on adding a tool in the VAB to check LS duration, a la TAC LS?

[Superfluous J]

What does the line

HomeworldAltitude = 50000

mean in the GameData/UmbraSpaceIndustries/LifeSupport/Settings.cfg file?

What's the supplies consumption rate of the Kerbals? In what if any situations will they not consume available, unlocked supplies? (Eg landed on Kerbin?)

I can't answer the planning questions but these 2 I know. The setting is the altitude over the ground of your home world that - if you are under it - your Kerbals no longer need life support to function. The main reason for this I believe is so they can pull the chutes upon returning even if they don't have any supplies left.

Kerbals eat 1.08 noms per (6 hour) day. It's close enough to 1 that I just put 1 per day per kerbal and round up to the nearest supply container. Why? Because math. 6 hours is 21600 seconds, and if you divide that by 20000 you get 1.08

Edited July 29, 2015 by 5thHorseman

[goldenpsp]

Do you plan on adding a tool in the VAB to check LS duration, a la TAC LS?

unlike TAC it's pretty easy to calculate LS duration. you can pretty much use 1 supply per kerbal per day.

[RoverDude]

This. I intentionally made sure noms were about 1 unit per day, keeps things simple. Simple is good.

[goldenpsp]

Well it was all good until Rover told us what noms taste like...

[Svm420]

This. I intentionally made sure noms were about 1 unit per day, keeps things simple. Simple is good.

Would you consider exposing the variables used to calculate

[COLOR=#333333][FONT=Consolas]secsPerDay
[/FONT][/COLOR][COLOR=#333333][FONT=Consolas]secsPerYear

in the settings for those of us using real time?

[Dante80]

Started using this today, I really like the Kerbal feel it has.

A couple of questions/suggestions.

1. I know that you want to keep the part number down, but I think a 0.625m supply container would be handy to have for some situations.

2. It might be just me, but I think that the number of noms in each container is too big. Have you thought of bringing the number down a little (or the mass/cost up) for balancing reasons?

3. Have you thought about spreading the parts the mod has in a way that makes the career experience more balanced?

Keep the goodness coming, and many thanks. C:

Edited August 5, 2015 by Dante80

[kugelzucker]

i know, i know. roverdude said that we should use KAC to stop warp before our kerbals lose weight, but i would like to ask if this might be a possibility in the future. i'd even up my patreon-pledge

love the LS, scratch that, ALL your mods. thank you!

[Voyager275]

I like how this mod works. The only thing I changed was that kerbals died after 15 days without supplies. Great life support mod

Edited August 9, 2015 by Voyager275

[Vorg]

I like how this mod works. The only thing I changed was that kerbals died after 15 days without supplies. Great life support mod

USIL is more in the spirit of kerbal in that they are hard to kill. If you want critical LS, it has been mentioned that there is a config option to do that.

[Kowgan]

USIL is more in the spirit of kerbal in that they are hard to kill. If you want critical LS, it has been mentioned that there is a config option to do that.

I guess that's exactly what he changed.

[prog]

If only there will be option to make death occur not instead of strike but after configurable amount of time in strike mode...

[Tarheel1999]

If only there will be option to make death occur not instead of strike but after configurable amount of time in strike mode...

What would that add to gameplay exactly? You can control both death and supply time (number of days without supplies) now. If 15 days is too short you could up that to 30 and set death=true. I'm not sure exactly how your proposal is different from this from a gameplay standpoint.

[Superfluous J]

What would that add to gameplay exactly? You can control both death and supply time (number of days without supplies) now. If 15 days is too short you could up that to 30 and set death=true. I'm not sure exactly how your proposal is different from this from a gameplay standpoint.

It would give you a window to return without killing them, so long as you aimed well enough. Also, after they died you could presumably re-start operations with the now-empty vessel's probe core.

Neither of these are possible to simulate now, and would give possibly interesting (and morbid) wrinkles to gameplay.

[Felbourn]

It doesn't look like the ECAmount is used?

In:

protected override ConversionRecipe PrepareRecipe(double deltatime)

there's a line:

var ecAmount = 0.01f;

maybe you want it to be this? Not sure yet.

var ecAmount = LifeSupportSetup.Instance.LSConfig.ECAmount;

In the same way, maybe the next lines could be set via config as well.

var supAmount = 0.00005f;

var scrapAmount = 0.00005f;

Speaking of constants, it would be nice if this was in the config in case we have a custom game where the names are different.

private List<string> vetNames = new List<string>{"Bill Kerman","Bob Kerman","Jebediah Kerman","Valentina Kerman"};

Also...

I'm not sure why this says SuppliesLeft=0

{
name = LifeSupportScenario
scene = 5, 7, 6
LIFE_SUPPORT_SETTINGS
{
VESSEL_DATA
{
VesselId = 06d305d8-6a78-4a52-9f2b-1cae65bc29f0
VesselName = KS3-1
SuppliesLeft = 0
NumCrew = 1
LastFeeding = 98144.345281596
LastUpdate = 99500.8738755161
}
}
}

	SCENARIO

because in that craft there is this part:

VESSEL
{
pid = 06d305d86a784a529f2b1cae65bc29f0
name = KS3-1
type = Station
sit = ORBITING
etc
PART
{
name = crewtube-25-2
cid = 4293775016
uid = 1364596920
mid = 650692890
launchID = 86
etc
RESOURCE
{
name = Supplies
amount = 200
maxAmount = 200
flowState = True
isTweakable = True
hideFlow = False
flowMode = Both
}
[/spoiler]

Edited August 8, 2015 by Felbourn

[Tarheel1999]

It would give you a window to return without killing them, so long as you aimed well enough. Also, after they died you could presumably re-start operations with the now-empty vessel's probe core.

Neither of these are possible to simulate now, and would give possibly interesting (and morbid) wrinkles to gameplay.

If you are only running a single manned mission at a time, maybe. But if you run multiple manned missions, ultimately I don't think that is how it's going to work out. Let's assume a hypothetical with 15 days of supplies with death occurring 15 days after a loss of supplies vs supplies set to 30 days and death=true. Under both scenarios, the kerbals die after 30 days without supplies. In both cases the kerbals need to be returned or rescued within 30 days. If it's the loss of control that is easily self-imposed. So how exactly does gameplay differ between the two especially when most people have multiple manned missions operating at the same time.

Big picture - death=false means you don't have to carefully watch your kerbal's life supplies because they can always be rescued. With death=true you have to watch supplies with an eagle eye to avoid death. When you mix the two, you end up having to carefully watch supplies largely eliminating the benefit of no death. The only way this makes sense is if 1) you carefully monitor supply levels of all manned missions and plan properly and 2) want kerbals to die when you fail. At which point simply set death=true and be done with it.

[Superfluous J]

If you are only running a single manned mission at a time, maybe. But if you run multiple manned missions, ultimately I don't think that is how it's going to work out. Let's assume a hypothetical with 15 days of supplies with death occurring 15 days after a loss of supplies vs supplies set to 30 days and death=true. Under both scenarios, the kerbals die after 30 days without supplies. In both cases the kerbals need to be returned or rescued within 30 days. If it's the loss of control that is easily self-imposed. So how exactly does gameplay differ between the two especially when most people have multiple manned missions operating at the same time.

What if they go on strike after 15 days, and die after 400 days? You can get far in a Kerbal year, but it's still a short time if you're out at Jool. And don't start with "self imposed." With that thought, you don't need this mod at all. Just bring an extra tank of Monoprop and pretend it's food, and if you have any unforseen problems crash the ship to kill the crew.

I don't see the difference between multiple missions and running only one. The only thing I can think of that that affects is it'd be easier - with a single mission - to "self impose" your rules because you don't have to keep track of only one ship at a time.

Note: I'm not arguing whether or not it's a good idea or not. And I'm surely not trying to convince you of it. I'm merely pointing out that there ARE gameplay differences that can be exploited and - who knows - may add to the fun and problem solving.

[prog]

If 15 days is too short you could up that to 30 and set death=true. I'm not sure exactly how your proposal is different from this from a gameplay standpoint.

Main difference is - wiith 30 days lifespan kerbals will WORK full 30 days while with 15+15 days they will work only 15 days and another 15 days they will do nothing being on strike. (And I'd rather use 10+300 or so, not 15+15)

[Yski]

I just got wrecked. One of my kerbals tossed all my supplies out of an airlock, and my entire space program now consists of a grand total of two kerbals. RIP Mun station

[Superfluous J]

I just got wrecked. One of my kerbals tossed all my supplies out of an airlock, and my entire space program now consists of a grand total of two kerbals. RIP Mun station

Hey at least the new ones will be cheaper to hire!

(because that makes total sense)

[Kuansenhama]

The parts are not showing up in my game.

[goldenpsp]

The parts are not showing up in my game.

That's unfortunate. Would you like to provide some details so that we can try to help troubleshoot rather than just feel bad for you? Lack of parts is typically a bad installation. Maybe start with a screenshot of your gamedata folder.

[mhoram]

It tried to find out when the Nom-O-Matic 5000 is useful for trips. This comparison is USI-LS only and does not include infos about UKS.

Here is a chart from a mass-efficiency point-of-view:

- horizontal axis: number of Kerbals

- vertical axis: number of years of the trip

Different Colors:

- Supplies only is best choice

- Supplies + Nom-O-Matic 5000 is best choice

- Supplies + Fertilizer + Nom-O-Matic 25k is best choice

Currently the following choices are most efficient:

- Up to 3 years: bring your supplies only

- One Kerbal between 7 and 21 years: Nom-O-Matic 5000

- at least 7 years: Nom-O-Matic 25k

- at least 10 Kerbals: Nom-O-Matic 25k

- 4-6 years and 1-9 Kerbals: Supplies or Nom-O-Matic 25k

So I would bring the Nom-O-Matic 5000 only if I have a single Kerbal on the trip for 7-21 years, which puts the part for me into the category "will probably use it never".

In this regard I want to suggest the following change to USI-LS: reduce the mass of Nom-O-Matic 5000 from 1500 kg to 600 kg. (Also tried differrent values, but this would be my favourite)

Here is how the chart looks like with these changes:

It looks much more interesting:

- Up to 2 years: Bring your supplies only

- 3 years: Nom-O-Matic 5000

- Single Kerbal 13-28 years: Nom-O-Matic 5000

- at least 13 years: Nom-O-Matic 25k

- rest: Mixture between Nom-O-Matic 5000 and Nom-O-Matic 25k

This change makes Life support a bit easier, because less mass is needed for some Kerbal-duration combinations.

On the other hand it makes Life support planning a bit harder, because the decision which method to use with regards to mass efficiency becomes more complex and diverse.

@RoverDude: Don't know if my suggestion fits into your plan with USI-LS but I wanted to share it anyway.