[1.12.x] USI Life Support

[RoverDude]

53 minutes ago, tater said:

This:

	SCENARIO
	{
		name = LifeSupportScenario
		scene = 5, 7, 6
		LIFE_SUPPORT_SETTINGS
		{
			STATUS_DATA
			{
				KerbalName = Ribsy Kerman
				LastMeal = 44977776.7516371
				LastOnKerbin = 44977772.3516364
				MaxOffKerbinTime = 1016977772.35164
				LastVesselId = 0cc1243c-29ea-4418-9ae1-342b40db4501
				TimeInVessel = 0
				IsGrouchy = False
				OldTrait = Scientist
				LastUpdate = 44977776.7516371
			}
			STATUS_DATA
			{
				All the other kerbals look like the example above.
	}

All the other KerbalNames until you get to the close } of this section (name = LifeSupportScenario) of SCENARIO.

I know it's a Kerbin month... How long is a Kerbin month? An Earth month is defined (originally) by the Moon. Kerbin has 2 moons, so which month is it, or is it arbitrary?

A Munar month is ~6 days. A Minmus month is around 50 days. If you divide the Kerbin year into equal sections, you can also get six 71 periods. Which is it?

30 6 hour days

[Fraz86]

2 hours ago, RoverDude said:

The general rule of thumb is that something is either a multiuplier, or adds KerbalMonths.

If it adds more space (KerbalMonths) add months equal to mass * 5

If it is a multiplier, set multiplier equal to the mass.

In either case, make sure you add ReplacementParts equal to: crew capacity + Kerbal Months. * 100

Hmm, I apologize, but I'm still a bit confused. I'm specifically trying to understand exactly what this does:

MODULE

{

name = ModuleHabitation

KerbalMonths = 12

} 

My in-game testing indicates that it doesn't quite act through straitforward addition or multiplication of the habitation value. It looks like every seat on a vessel contributes a default of 1 KM to the habitation value. If a ModuleHabitation is present, then it looks like the aforementioned habitation value is multiplied by (1 + sum of KerbalMonths values defined in all ModuleHabitations). Is that right?

Edited January 21, 2016 by Fraz86

[Ignalion]

Hi there.

Guys, I have a little question. I'm not sure this is proper place to ask, maybe MKS is more appropriate, but anyway.

Is there any doc for current life support\MKS\Resource cycles? Because the wiki is far outdated and I can't find any relevant info about this for now?

Thanks.

[RoverDude]

It just changed in the past couple of days so I expect the wiki needs a bit to catch up.  There are release notes with the changes in the MKS thread, and I'm working on documentation for folks new to the Kolonization mods.

30 minutes ago, Fraz86 said:

Hmm, I apologize, but I'm still a bit confused. I'm specifically trying to understand exactly what this does:

MODULE

{

name = ModuleHabitation

KerbalMonths = 12

} 

My in-game testing indicates that it doesn't quite act through straitforward addition or multiplication of the habitation value. It looks like every seat on a vessel contributes a default of 1 KM to the habitation value. If a ModuleHabitation is present, then it looks like the aforementioned habitation value is multiplied by (1 + sum of KerbalMonths values defined in all ModuleHabitations). Is that right?

Not quite.

It is 1 month per crew cap (configurable) then we add in the KerbalMonths.  The only multiplier is if you have a HabMultipler.

KerbalMonths is turned into seconds for computation purposes - a KerbalMonth being equal to 30 6-hour days (so 180 hours).

[JCM]

On 28/04/2015 at 10:13 AM, Enceos said:

For some bizarre reason USI Life Support makes crafts in orbit spin and disintegrate.

I have only the MKS and USI LS installed here:

 

 

When I remove USI LS, vessels behave normally. The window in the corner is an Exception Detector which shows the NRE and errors logged.

Here's my output_log.txt

So, I just saw that happening with the latest version, running no other mods, any info on why it's happening?

 

Same than the post above, it only happens on training, which is kinda strange.

[Angelo Kerman]

1 hour ago, RoverDude said:

Good deal - just make sure you include a life support config that lights up the hab options (the UKS one does it).  I intentionally default them as *off* because I did not want to break other mods that have USI-LS support.

(edit)

Remember that LS configs are additive, so you just make your own, drop it in your mod, and it will automagically delta to the most pessimistic combination that it finds.

Cool beans. I'll poke around and see what I find. Thanks again, looking forward to giving the mod a try.

[RoverDude]

30 minutes ago, JCM said:

So, I just saw that happening with the latest version, running no other mods, any info on why it's happening?

 

Same than the post above, it only happens on training, which is kinda strange.

All bets are off for support during training or tutorials.  So I would not recommend running them with mods.

[Fraz86]

5 hours ago, RoverDude said:

Not quite.

It is 1 month per crew cap (configurable) then we add in the KerbalMonths.  The only multiplier is if you have a HabMultipler.

KerbalMonths is turned into seconds for computation purposes - a KerbalMonth being equal to 30 6-hour days (so 180 hours).

My observations seem to demonstrate different behavior. Starting with a Mk1-2 Pod the total Habitation is 90d, as expected. The Hitchhiker should add 480d (120d from crew cap of 4 + 360d from ModuleHabitation with 12 KerbalMonths). Thus, a Mk1-2 Pod + Hitchhiker should have a total Habitation rating of 560d (1y135d). Instead, as seen in the screenshot below, it has 2730d (6y180d). Incidentally, 7 (total crew cap) x 13 (1 + 12KM) x 30d = 2730d, which is the basis for my previously posted formula.

The same relationship can be demonstrated with every combination of parts I have tested. For example, the Mk2 Crew Cabin lacks a ModuleHabitation, and thus, typically adds only 120d (30d x crew cap of 4). This is confirmed in the below screenshot, which shows a total Habitation value of 210d for the Mk1-2 Pod (90d) + Mk2 Crew Cabin (120d), as expected.

Given that the Mk1-2 Pod + Hitchhiker was previously shown to have a Habitation rating of 2730d, we might expect that adding a Mk2 Crew Cabin (120d) would give a total of 2850d (6y300d). Instead, as seen below, the total is 4290d (10y40d). Clearly the Habitation rating of this craft is not additive, as it is greater than the sum of its parts (4290d for all 3 parts versus 120d for only Mk1-2 + Cabin and 2730d for Mk1-2 + Hitchhiker). Again, this result is consistent with my previously posted formula, as 11 (total crew cap) x 13 (1 + 12KM) x 30d = 4290d (10y40d).

 

EDIT:

In retrospect, it's obvious that you meant that ModuleHabitation adds 12KM to the habitation rating of the vessel at max crew. This strikes me as an odd way to calculate the rating, though, as it means that the Hitchhiker adds 12KM to every seat on the entire vessel. Given that seats other than the Hitchhiker start with only a 1KM rating, the Hitchhiker basically increases the Habitation value of every seat by 1200%. This could be very powerful when applied to a vessel that already has a large number of seats (e.g., with a Mk3 Passenger Module), and I'm not sure it makes a lot of sense either. Though, if this behavior is intentional, I would be happy to better understand your reasoning.

Edited January 22, 2016 by Fraz86

[Iam aspaceman]

On 1/19/2016 at 1:29 AM, RoverDude said:

0.3.0 IS UP!

• EVA timer is now based on how long the kerbal has been EVA.
• Habitation space is now a thing - see the forum for details.
• The in-flight view has had a visual refresh to reflect the new data.
• Multiple LS configs are now supported, with a delta inclusive of the most pessimistic changes being used.
• Added displays to the tracking station, space center, and VAB/SPH
• SPH display includes build aid information for the current vessel
• Reduced mass of Nom-O-Matic 5000
• Kerbals no longer raid the supply tins - but they will unlock all of them.
• Corrected stack nodes for nom tanks
• Kerbals in command seats should properly consume supplies
• Recyclers and Habitation calculations, if enabled, can extend to nearby landed vessels to better facilitate disconnected bases.

Trying to sort this all out.  My 4 Kerbal mission to Minmus had 100 supplies and when this updated it went from 4 supplies / day to consuming 81 supplies / day...?  Needless to say, they all left as soon as I took off....so not sure what to do to save a 5 yr career game.  Ideas?  Also, why?  Why change the number of supplies per kerbal per day?  Where is this all outlined and explained?

The Habitation space referred to above...isn't this the forum?  Or do I need to go someplace else to get caught up?

Thanks!

[mcortez]

19 minutes ago, Iam aspaceman said:

The Habitation space referred to above...isn't this the forum?  Or do I need to go someplace else to get caught up?

There was some discussion and preview tidbits both here and on the MKS Kolonization thread starting back last week of December.  You can of course always roll back to the previous version, or adjust the consumption in the cfg file back to the old value (.00005 per second I think, might need another zero.)

[goldenpsp]

25 minutes ago, Iam aspaceman said:

Trying to sort this all out.  My 4 Kerbal mission to Minmus had 100 supplies and when this updated it went from 4 supplies / day to consuming 81 supplies / day...?  Needless to say, they all left as soon as I took off....so not sure what to do to save a 5 yr career game.  Ideas?  Also, why?  Why change the number of supplies per kerbal per day?  Where is this all outlined and explained?

The Habitation space referred to above...isn't this the forum?  Or do I need to go someplace else to get caught up?

Thanks!

Yea this is the forum.  Go back maybe 5-10 pages and get caught up 

For your specific question, if you are using MKS it increases supply consumption a LOT.  You can fix by editing the cfg file in MKS.  USI-LS uses the most pessimistic setting if it sees multiple cfg files.

[PocketBrotector]

I just got done digging through the logic in the source code, so I may be able to bring some clarification to the habitation formulas. If these descriptions are useful perhaps they can be the basis for a wiki page or whatever other documentation is created. 

Total hab time = (sum of all parts' Kerbal-Months + config's base hab time [default one month or thirty days]) * (sum of all parts' hab multipliers + 1) * (sum of all parts' crew capacity / number of crew) * config's hab multiplier [default 1]

Breakdown:

• Kerbal-Months are specified on a per-part basis. The only stock part with any kerbal-months is the Hitchhiker Can, which has 12 months. UKS adds the inflatable hab modules (3.75 KM's for the surface version and 6.25 KM's for the orbital version)
• The base hab time is specified in the config file. Default is one month (thirty six-hour days.)
• Parts with hab multipliers only exist in UKS at the moment; the Kerbitat has a multiplier of 3, and the Aeroponics module has a multiplier of 1.25
• The config file's hab multiplier is 1 by default.

All vessels within 150m are considered when calculating habitation and recycler mechanics.

So I just built an interplanetary ship with a kerbitat (hab multiplier 3, crew capacity 2), inflatable hab ring (kerbal-months 6.25, crew capacity 10), and five additional crew capacity. With three crew, my habitation time is:

(6.25 + 1 kerbal-months) * (3 + 1 hab multiplier) * ((10 + 2 + 5 crew capacity) / 3 crew) * 1 = 164.333 months, or 4930 days, or 11.57 years.

[RoverDude]

2 hours ago, Fraz86 said:

My observations seem to demonstrate different behavior. Starting with a Mk1-2 Pod the total Habitation is 90d, as expected. The Hitchhiker should add 480d (120d from crew cap of 4 + 360d from ModuleHabitation with 12 KerbalMonths). Thus, a Mk1-2 Pod + Hitchhiker should have a total Habitation rating of 560d (1y135d). Instead, as seen in the screenshot below, it has 2730d (6y180d). Incidentally, 7 (total crew cap) x 13 (1 + 12KM) x 30d = 2730d, which is the basis for my previously posted formula.

The same relationship can be demonstrated with every combination of parts I have tested. For example, the Mk2 Crew Cabin lacks a ModuleHabitation, and thus, typically adds only 120d (30d x crew cap of 4). This is confirmed in the below screenshot, which shows a total Habitation value of 210d for the Mk1-2 Pod (90d) + Mk2 Crew Cabin (120d), as expected.

Given that the Mk1-2 Pod + Hitchhiker was previously shown to have a Habitation rating of 2730d, we might expect that adding a Mk2 Crew Cabin (120d) would give a total of 2850d (6y300d). Instead, as seen below, the total is 4290d (10y40d). Clearly the Habitation rating of this craft is not additive, as it is greater than the sum of its parts (4290d for all 3 parts versus 120d for only Mk1-2 + Cabin and 2730d for Mk1-2 + Hitchhiker). Again, this result is consistent with my previously posted formula, as 11 (total crew cap) x 13 (1 + 12KM) x 30d = 4290d (10y40d).

 

EDIT:

In retrospect, it's obvious that you meant that ModuleHabitation adds 12KM to the habitation rating of the vessel at max crew. This strikes me as an odd way to calculate the rating, though, as it means that the Hitchhiker adds 12KM to every seat on the entire vessel. Given that seats other than the Hitchhiker start with only a 1KM rating, the Hitchhiker basically increases the Habitation value of every seat by 1200%. This could be very powerful when applied to a vessel that already has a large number of seats (e.g., with a Mk3 Passenger Module), and I'm not sure it makes a lot of sense either. Though, if this behavior is intentional, I would be happy to better understand your reasoning.

 

The ratings are based on max crew.  If you reduce crew, you dramatically increase available space, reduce crowding, and reduce wear and tear on the various systems.  So, your setup above would be perfectly fine for a pair of Kerbals to do a jaunt to and from Duna - plenty of space.  But not so good if you stuffed it to the max.

Just because I can sit seven people in my SUV and can tolerate stuffing seven people in it to go out to lunch does not mean I'd want to stuff seven people in it for a cross-country road trip, despite being the same SUV, and having the same (optimistic) listed capacity as 'seven adults'.

2 hours ago, Iam aspaceman said:

Trying to sort this all out.  My 4 Kerbal mission to Minmus had 100 supplies and when this updated it went from 4 supplies / day to consuming 81 supplies / day...?  Needless to say, they all left as soon as I took off....so not sure what to do to save a 5 yr career game.  Ideas?  Also, why?  Why change the number of supplies per kerbal per day?  Where is this all outlined and explained?

The Habitation space referred to above...isn't this the forum?  Or do I need to go someplace else to get caught up?

Thanks!

Read the past few pages - there were a few pre-warnings.  Also, if you saw that jump in supply usage, it means you have some of the kolonization bits - who's changelog also covers this (and which modules make the best recyclers).  

1 hour ago, goldenpsp said:

Yea this is the forum.  Go back maybe 5-10 pages and get caught up 

For your specific question, if you are using MKS it increases supply consumption a LOT.  You can fix by editing the cfg file in MKS.  USI-LS uses the most pessimistic setting if it sees multiple cfg files.

Sorry, you should not 'Fix' this by editing the config file - this is absolutely by design because MKS includes bits that end up dramatically reducing supply usage (to the tune of 75%, and you will soon have a 95% module for surface use).  If folks reduce this back down to pre-release levels (i.e. one supply per day) once recyclers kick in, consumption will be so low that you might as well not install this mod, because you will have ten Kerbals sharing a cracker for a twenty year trip, and being totally cool with it.

[RoverDude]

18 minutes ago, PocketBrotector said:

I just got done digging through the logic in the source code, so I may be able to bring some clarification to the habitation formulas. If these descriptions are useful perhaps they can be the basis for a wiki page or whatever other documentation is created. 

Total hab time = (sum of all parts' Kerbal-Months + config's base hab time [default one month or thirty days]) * (sum of all parts' hab multipliers + 1) * (sum of all parts' crew capacity / number of crew) * config's hab multiplier [default 1]

Breakdown:

• Kerbal-Months are specified on a per-part basis. The only stock part with any kerbal-months is the Hitchhiker Can, which has 12 months. UKS adds the inflatable hab modules (3.75 KM's for the surface version and 6.25 KM's for the orbital version)
• The base hab time is specified in the config file. Default is one month (thirty six-hour days.)
• Parts with hab multipliers only exist in UKS at the moment; the Kerbitat has a multiplier of 3, and the Aeroponics module has a multiplier of 1.25
• The config file's hab multiplier is 1 by default.

All vessels within 150m are considered when calculating habitation and recycler mechanics.

So I just built an interplanetary ship with a kerbitat (hab multiplier 3, crew capacity 2), inflatable hab ring (kerbal-months 6.25, crew capacity 10), and five additional crew capacity. With three crew, my habitation time is:

(6.25 + 1 kerbal-months) * (3 + 1 hab multiplier) * ((10 + 2 + 5 crew capacity) / 3 crew) * 1 = 164.333 months, or 4930 days, or 11.57 years.

Yup.  Point being that getting your hab value up for interplanetary trips is really not that big of a deal.  This is by design.  If you threw three Kerbals with that kind of hardware and space, they should have no problem going to Eeloo and back.  In short, interplanetary vehicles should look interplanetary, but it should also be pretty easy to achieve it with the parts provided.

[PocketBrotector]

8 minutes ago, RoverDude said:

Yup.  Point being that getting your hab value up for interplanetary trips is really not that big of a deal.  This is by design.  If you threw three Kerbals with that kind of hardware and space, they should have no problem going to Eeloo and back.  In short, interplanetary vehicles should look interplanetary, but it should also be pretty easy to achieve it with the parts provided.

Yessir. At first I was a bit wary of the extra variables, but in the end I needed about twice as much life support mass as I would have pre-update to build a viable, flexible interplanetary shuttle for smallish crews. With UKS it was critical to pile on as many multipliers as possible to boost both habitation and recycling/conversion, but the final part count was still modest.

[Fraz86]

1 hour ago, RoverDude said:

The ratings are based on max crew.  If you reduce crew, you dramatically increase available space, reduce crowding, and reduce wear and tear on the various systems.  So, your setup above would be perfectly fine for a pair of Kerbals to do a jaunt to and from Duna - plenty of space.  But not so good if you stuffed it to the max.

Just because I can sit seven people in my SUV and can tolerate stuffing seven people in it to go out to lunch does not mean I'd want to stuff seven people in it for a cross-country road trip, despite being the same SUV, and having the same (optimistic) listed capacity as 'seven adults'.

I understand. My confusion is with respect to the manner in which ModuleHabitation's KerbalMonths dramatically enhances the habitation value of all seats on the vessel. To use your SUV example, adding a Hitchhiker is like towing a small camper trailer behind the SUV that can tolerate stuffing 4 people inside. Somehow, adding the camper makes it possible for 11 people to travel 13x as long as would be possible with 7 people in the SUV alone. Even if it were a large bus capable of carrying 50 people, towing a single small camper would allow 54 people to travel 13x as long as the bus alone. It just doesn't seem to make much sense that the Hitchhiker's effect scales perfectly with the total capacity of the vessel, providing more and more benefit the greater the total crew capacity.

[Brigadier]

I've attached supplies directly to the command pod of a rocket.  The Life Support Status window displays the supply situation (and I have no idea, based on the above discussion, if it's correct or not) which I find acceptable for the mission.  The Engineer's Report, however, states that supplies are present but that they are not used by or connected to anything that needs them.  I originally had the containers on the fuel tank just below the decoupler and had the same outcome.

Is this the intended behavior?  It seems contradictory or, at best, confusing.

As you can see (hopefully) in the linked image, it says something about RocketParts in the command pod, too, and I'm not so sure about that one either.

Edit: BTW, on the launchpad, the Life Support window matches what was shown in the VAB, and the supplies are being consumed.

Edited January 22, 2016 by Brigadier
More info

[RoverDude]

5 hours ago, Fraz86 said:

I understand. My confusion is with respect to the manner in which ModuleHabitation's KerbalMonths dramatically enhances the habitation value of all seats on the vessel. To use your SUV example, adding a Hitchhiker is like towing a small camper trailer behind the SUV that can tolerate stuffing 4 people inside. Somehow, adding the camper makes it possible for 11 people to travel 13x as long as would be possible with 7 people in the SUV alone. Even if it were a large bus capable of carrying 50 people, towing a single small camper would allow 54 people to travel 13x as long as the bus alone. It just doesn't seem to make much sense that the Hitchhiker's effect scales perfectly with the total capacity of the vessel, providing more and more benefit the greater the total crew capacity.

No.  Again, it's a multiplier.  We tally total KM them multiply it by the crew ratio.

So a vessel designed to hold 10 crew for 20 months will hold 1 crew for 200 months.  Again, this is absolutely by design.  This is not a defect, this is the way it works.  Provide your Kerbals a lot more space, and the hab value is extended by the ratio of current crew to the maximum crew of the vessel.  

Even a Mk-1-2 pod with zero extra bonus can go from 30 days (3 crew) to 90 days (1 crew).  Same formula.  This is why the hab month bonuses are fairly low.

7 hours ago, PocketBrotector said:

Yessir. At first I was a bit wary of the extra variables, but in the end I needed about twice as much life support mass as I would have pre-update to build a viable, flexible interplanetary shuttle for smallish crews. With UKS it was critical to pile on as many multipliers as possible to boost both habitation and recycling/conversion, but the final part count was still modest.

Totally by design   You're still at twice as much because the last level of UKS recyclers have not been added yet, hence the extra headroom in what's currently out there now.  Also, packing a non-recycle pod for a Gemini style mission, the relative mass of the food, water, etc. feels a lot more 'right' than it did in the previous version.

3 hours ago, Brigadier said:

I've attached supplies directly to the command pod of a rocket.  The Life Support Status window displays the supply situation (and I have no idea, based on the above discussion, if it's correct or not) which I find acceptable for the mission.  The Engineer's Report, however, states that supplies are present but that they are not used by or connected to anything that needs them.  I originally had the containers on the fuel tank just below the decoupler and had the same outcome.

Is this the intended behavior?  It seems contradictory or, at best, confusing.

As you can see (hopefully) in the linked image, it says something about RocketParts in the command pod, too, and I'm not so sure about that one either.

Edit: BTW, on the launchpad, the Life Support window matches what was shown in the VAB, and the supplies are being consumed.

Stock has no idea what supplies are, nothing I can do about that.

[goldenpsp]

7 hours ago, RoverDude said:

Sorry, you should not 'Fix' this by editing the config file - this is absolutely by design because MKS includes bits that end up dramatically reducing supply usage (to the tune of 75%, and you will soon have a 95% module for surface use).  If folks reduce this back down to pre-release levels (i.e. one supply per day) once recyclers kick in, consumption will be so low that you might as well not install this mod, because you will have ten Kerbals sharing a cracker for a twenty year trip, and being totally cool with it.

Rover,

I apologize but I think you misunderstood.  I was only recommending a "fix" to I am a spaceman due to his specific circumstance.  according to his post he launched a mission under the old version and as a result that mission has insufficient supplies.  If he wanted to save his "save" one option would be to temporarily change the consumption down to the old levels, at least until he completes that mission or sends out more supplies.  I was not clear but it was not my intent that it would be a permanent change.

[Fraz86]

12 hours ago, RoverDude said:

No.  Again, it's a multiplier.  We tally total KM them multiply it by the crew ratio.

So a vessel designed to hold 10 crew for 20 months will hold 1 crew for 200 months.  Again, this is absolutely by design.  This is not a defect, this is the way it works.  Provide your Kerbals a lot more space, and the hab value is extended by the ratio of current crew to the maximum crew of the vessel.  

Even a Mk-1-2 pod with zero extra bonus can go from 30 days (3 crew) to 90 days (1 crew).  Same formula.  This is why the hab month bonuses are fairly low.

I'm sorry, I don't think I'm expressing my point very clearly. I understand exactly how the habitation values are calculated, I hear you that it is by design, and I see how it makes some sense from a certain perspective. I'm trying to draw attention to to what I believe to be silly/counter-intuitive implications of the current system.

Perhaps a more extreme in-game example would help. Imagine an enormous colonization ship with 10 Mk3 Passenger Modules. It can carry 160 Kerbals for 1 month. Seems reasonable. Add a single Hitchhiker, and now the ship can carry 164 Kerbals for 13 months. Thematically, the implication is that all 164 Kerbals onboard are somehow utilizing this single Hitchhiker in such a way that allows all 164 of them to remain comfortable 13x as long as they would without it. If we imagine that those 164 Kerbals are taking turns (in groups of 4) relaxing in the comfort of the Hitchhiker, each Kerbal would spend only ~8.8 minutes per day in the Hitchhiker, and yet those 8.8 minutes apparently allow them to tolerate 13 months of travel instead of only 1. That strikes me as rather incredible.

My point is simply that, as the size of a vessel and its crew increases, one would intuitively expect a greater number of Hitchhikers would be required in order to achieve the same benefit. One would expect a cap on the number of Kerbals that can benefit from a single Hitchhiker, or at least diminishing returns. Instead, a Hitchhiker is cabaple of providing the same benefit per total crew capacity for any capacity.

The silliness becomes more pronounced if viewed from the perspective of a single Kerbal (or with any low crew:capacity ratio) instead of max crew. With the above-described colony ship, the addition of the Hitchhiker takes the single-Kerbal habitation time from 160 months to 2132 months. That's an increase of 81.6 years resulting from the addition of a single Hitchhiker.

If that's how you want it to work, of course that's your prerogative - I'm not trying to tell you what to do, and I don't mean to be a pain. I'm merely trying to illustrate that there are some thematically counter-intuitive consequences of the current calculation method, which you may or may not want to address.

Edited January 23, 2016 by Fraz86

[Brigadier]

5 hours ago, RoverDude said:

Stock has no idea what supplies are, nothing I can do about that.

Ok, thanks, that makes sense.  Stock obviously sees the supply container and the supplies (otherwise it wouldn't flag them by name in the Engineers' Report) but doesn't understand the consumer relation.  I never noticed it before.

[apocriva]

1 hour ago, Fraz86 said:

Perhaps a more extreme in-game example would help. Imagine an enormous colonization ship with 10 Mk3 Passenger Modules. It can carry 160 Kerbals for 1 month. Seems reasonable. Add a single Hitchhiker, and now the ship can carry 164 Kerbals for 13 months.

Maybe I'm understanding the hab modifiers incorrectly, but wouldn't going from 160 to 164 crew spots filled with 160 crew change the hab time from 30 days to 30.75 days? (164 / 160 * 30)

[mcortez]

17 minutes ago, apocriva said:

Maybe I'm understanding the hab modifiers incorrectly, but wouldn't going from 160 to 164 crew spots filled with 160 crew change the hab time from 30 days to 30.75 days? (164 / 160 * 30)

I think the problem Fraz86 is pointing out, is that with that one part (and it might be one of only 3 or 4 parts configured like it) provides not only crew slots that work as you describe, but also provides a HabitationModule addition of 12 kerbal months which gets multiplies by the crew ratio.

With the way its currently setup it multiplies (crew ratio) * (KerbalMonths in part configurations + 1)

So a Mk1-2 with 3 crew gets a total of (1) * (1 kerbal months) for a total of 30 days.

Add one hitchhiker and it goes to (2.33) * (1 + 12 kerbal months) for a total of 909 days.  So its a huge step up for an increase of very little weight.

My suggestion would be to either remove the kerbalmonth modifer and only use the multiplier config option (and tune the hitchhiker to down to something like 1.5) or reserve HabitatModule multipliers to only components that do not themselves add crew slots  or do it like this:

Have two ratios, one of crew to total seats of vessel (TtlCrwRatio) and a ratio of crew to seats in modules with KerbalMonth modifiers (KMCrewRatio).  Then modify the calculation to:

(TtlCrwRatio * HabitationModule.Multiplier) + (KMCrewRatio * HabitationModule.KerbalMonths)

With this change mk1-2 + hitchhiker and a total of 3 crew wouldbe:

 (((7/3) * 1) + ((4/3) * 12)) =~550  days versus 909 with current config.

Same configuration with a full crew would be:

(((7/7) * 1) + ((4/7) * 12)) =~ 210

Versus 361 with current.  So a good boost, still bigger than it probably should, but not huge.

Personally I don't have a problem with multiple kinds of habitation multipliers, its just with this specific low weight 4 seat part with a very larger multiplier seems a bit broken when it gets incorporated into big designs.  Using it to make a 1 or 2 man crew in a capsule be able to get to the edge of the system is one thing, being able to take a huge 60 crew ship add one hitchhiker container and have it marginally decrease their crew ratio but then multiply their range by 13 (versus 1) seems a touch over powered   especially one the hab parts specifically designed as colony parts increase the multiplier by less than 5.

59 minutes ago, apocriva said:

Maybe I'm understanding the hab modifiers incorrectly, but wouldn't going from 160 to 164 crew spots filled with 160 crew change the hab time from 30 days to 30.75 days? (164 / 160 * 30)

Forgot to address this example, it would be:

(164 / 160) * (1 + 12) * 30

(Crew Ratio) * (Minimum Months From Config + KerbalMonths modifier from that specific part) * (30 days per month)

[CovertJaguar]

7 hours ago, RoverDude said:

Stock has no idea what supplies are, nothing I can do about that.

Would it be possible to add a zero value consumer to pods to make the game think something is using them? I think I've seen other mods do that (AmpYear?).

[mitko]

On the question of balance between USI-LS and UKS, I think that the huge difference in basic rate of consumption of supplies between the two mods renders the Nom-O-Matics useless if both UKS and USI-LS are installed. Since UKS seems well balanced, a way to mitigate that irrelevance could be to increase the rate of supply consumption in USI-LS to one third or a half of the basic rate in UKS and adjust the Nom-O-Matics accordingly. That way these two parts will still be useful with UKS installed without really competing with UKS' native parts. That could also be good for those players who use CTT since the agro modules show up quite late in that tech tree.