[1.8+] Kerbal Health 1.6.8 (2024-01-22)

[garwel]

52 minutes ago, cyberpunkdreams said:

It did, although not with much ablator on it. I'm not saying that there's a bug or that the maths is wrong, but it does seem incongruous that one small vessel docked to the station should have such a big impact. Maybe the heat shields need to be given less influence in favour of build-in shielding?

I'll see how it can be improved. BTW, ablator doesn't affect shielding; it's a separate resource called RadShield, which you can add to the heat shields and other parts. But heat shields provide pretty good shielding by themselves.

[R-TEAM]

Hi,

 

nice mod ....

but it looks it dont play well/without limitations with mods like RemoteTec,TAC-LS ...

wait over improvements on this mod interaction to install it ...

 

Regards

[garwel]

58 minutes ago, R-TEAM said:

Hi,

 

nice mod ....

but it looks it dont play well/without limitations with mods like RemoteTec,TAC-LS ...

wait over improvements on this mod interaction to install it ...

 

Regards

It should play well alongside most life support mods except in the rare circumstances when those mods try to fight with it over making kerbals into Tourists and back. I personally play with USI-LS and have no issues whatsoever (other than the need to disable USI-LS habitation mechanics).

As to RemoteTech, the only issue is the Connected factor, because RemoteTech currently handles connections in its own way incompatible with stock mechanics. You may simply compensate it by disabling Assigned factor. When RemoteTech 2.0 is released, which is supposed to use stock CommNet, the problem will be solved automatically.

[Fraz86]

@garwel

I just discovered your mod, and I am very excited to try it out! However, I am concerned about a balance issue with respect to recuperation. Currently, there appears to be no limit on the number of Kerbals who benefit from the recuperation bonus provided by cupolas. Every Kerbal on board gains the full 1% HP regeneration, whether it's a crew of 1 or 100. This stands in contrast to parts that reduce crowdedness or microgravity, which appear to have limits on the number of Kerbals allowed to benefit. Furthermore, the recuperation effect is fully additive, with no diminishing returns (two cupolas is fully twice as good as one), whereas crowdedness-reducing parts do not stack (only one reduction of crowdedness applies to each Kerbal, even if there are additional unused crowdedness-reducing parts). With these factors in mind, it will often be mathematically most efficient to use mostly cupolas in place of habitation modules for missions with large crews and/or long durations, and it is especially easy to ignore small effects like microgravity rather than using centrifuges. I would recommend that the recuperation mechanic be carefully reconsidered. Limiting the number of Kerbals who benefit from a given recuperation-providing part (or dividing the recuperation value by the number of crew) would be a start, but I would also suggest that you reduce the magnitude of the effect, and/or introduce diminishing returns (i.e., so that the second cupola provides less benefit than the first), and/or create a maximum ceiling for total recuperation per day. Anyway, I know that I can make adjustments via a MM patch if needed, but I just wanted to raise these concerns for your consideration. Thanks for creating such an interesting mod!

 

Addendum:

After testing some MM patches, it appears that adding "crewCap = 1" to a ModuleKerbalHealth that provides recuperation (such as in the cupola) does not function as expected. Some elements do function as one would expect: the tooltip in the VAB reads "Recuperation: 1%/day for up to 1 Kerbal," and the module only consumes a max of 1 EC/s (rather than 1 EC/s per Kerbal). However, all Kerbals on board still gain the full 1%/day recuperation, with no cap. I would have expected that either (a) only 1 Kerbal would gain recuperation, or (b) the available recuperation would be divided equally among the crew (e.g., with a crew of 5 and a single cupola [1%/day, crewCap = 1], each Kerbal would gain 0.2%/day recuperation).

Edited December 25, 2017 by Fraz86

[garwel]

On 12/25/2017 at 10:04 AM, Fraz86 said:

@garwel

I just discovered your mod, and I am very excited to try it out! However, I am concerned about a balance issue with respect to recuperation. Currently, there appears to be no limit on the number of Kerbals who benefit from the recuperation bonus provided by cupolas. Every Kerbal on board gains the full 1% HP regeneration, whether it's a crew of 1 or 100. This stands in contrast to parts that reduce crowdedness or microgravity, which appear to have limits on the number of Kerbals allowed to benefit. Furthermore, the recuperation effect is fully additive, with no diminishing returns (two cupolas is fully twice as good as one), whereas adding multiple crowdedness-reducing parts becomes less and less efficient the more you add. With these factors in mind, it will often be mathematically most efficient to use mostly cupolas in place of habitation modules for missions with large crews and/or long durations, and it is especially easy to ignore small effects like microgravity rather than using centrifuges. I would recommend that the recuperation mechanic be carefully reconsidered. Limiting the number of Kerbals who benefit from a given recuperation-providing part (or dividing the recuperation value by the number of crew) would be a start, but I would also suggest that you reduce the magnitude of the effect, and/or introduce diminishing returns (i.e., so that the second cupola provides less benefit than the first), and/or create a maximum ceiling for total recuperation per day. Anyway, I know that I can make adjustments via a MM patch if needed, but I just wanted to raise these concerns for your consideration. Thanks for creating such an interesting mod!

I've been thinking of it lately. I may adjust the recuperation system in the next release where I'll change a lots of maths. Recuperation is supposed to be used for long-term habitation, in stations and bases. I don't want to force the player to spam cupolas (or any other part). So for most practical purposes, having a Hitchhiker and 2 Cupolas, or vice versa, and a few extra seats should be enough for a crew of 3. It may not be balanced for very big crews though, but those make little sense in a Career campaign anyway. I guess adding a relatively high cap for recuperation parts should fix it.

PS: Yes, crew cap is not currently implemented for recuperation, regardless of MM settings.

Edited December 26, 2017 by garwel

[Fraz86]

19 hours ago, garwel said:

I've been thinking of it lately. I may adjust the recuperation system in the next release where I'll change a lots of maths. Recuperation is supposed to be used for long-term habitation, in stations and bases. I don't want to force the player to spam cupolas (or any other part). So for most practical purposes, having a Hitchhiker and 2 Cupolas, or vice versa, and a few extra seats should be enough for a crew of 3. It may not be balanced for very big crews though, but those make little sense in a Career campaign anyway. I guess adding a relatively high cap for recuperation parts should fix it.

PS: Yes, crew cap is not currently implemented for recuperation, regardless of MM settings.

Thank you for considering the issue. I believe the problems become apparent when attempting to apply KerbalHealth to mods that add larger/better/more complex habitation modules (as I am currently attempting to do for Nertea's new SSPX pack).

Consider the microgravity penalty. The penalty is appropriately small (-0.5 HP/day), such that it only needs to be addressed for longer missions, which makes good sense. Long missions, in which compensation for microgravity is needed, would be an intuitive use case for centrifuges. Unfortunately, as it stands now, adding one additional Cupola can more than offset the entire microgravity penalty for all Kerbals onboard (1% recuperation will generate +0.5-0.75 HP/day for Kerbals at 50% of their max HP, depending on level). The Cupola presumably has lower mass, lower cost, lower EC use, and lower technology required than any centrifuge. Additionally, the Cupola can apply its effect to any crew size (whereas the centrifuge would presumably be capped at its crew capacity), and its benefit is more versatile (i.e., it continues to provide it's recuperation even when the craft is landed on a planet with full gravity, where a centrifuge would be useless; also, a Cupola can allow HP recovery, whereas a centrifuge can only prevent HP loss). In short, the Cupola works out to be a superior solution to the problem of microgravity.

Your mod provides a variety of potentially interesting problems to solve for long-term missions. What do I do about microgravity? How can I prepare for sickness? How do I offset/eliminate the last bit of crowded penalty (after it's already been reduced by a factor of 0.375 or whatever)? What should I do if it will be difficult to maintain a comms connection back to KSP? Currently, I believe Cupolas are the best solution to all of these problems (Cupolas even provide better mitigation of sickness than labs, on an HP/mass basis), which flattens much of your mod's potential for nuance and complexity. I understand that you face quite a dilemma: you need to make your mod playable using only stock parts, and considering that the stock game doesn't include any centrifuges, long-term hab modules, etc., you need to balance your mod such that Hitchhikers and Cupolas are sufficient for missions of any duration. Unfortunately, this balancing ultimately leaves little purpose for larger/more complex parts introduced by mods. I honestly don't know what to recommend as a solution to this dilemma, other than perhaps scaling certain variables based on the mods a player has installed.

If it's any use to you, below is a draft of my compatibility patch for Nertea's SSPX. The recuperation bonus provided by cupolas/observation modules is reduced by a factor of 10, but the bonus remains ship-wide with no crewCap, and is now alwaysActive with no EC cost, so these modules are useful when you need a small longevity bump for the ship as a whole, but they are no longer efficient as the primary solution to HP loss. Hab modules are given better crowdedness-reduction (with the largest modules completely eliminating the crowded penalty up to their crew capacity), as well as moderate partCrewOnly recuperation bonuses. Centrifuges reduce or eliminate the microgravity penalty. Labs are more effective at mitigating sickness, with a multiplier of 0.25. In summary, I made various parts more effective at accomplishing their specific purposes, while dramatically nerfing ship-wide recuperation as a panacea.

@PART[cupola]:NEEDS[KerbalHealth]:AFTER[KerbalHealth]
{
	@MODULE[ModuleKerbalHealth]:HAS[#recuperation[>0]]
	{
		@recuperation = 0.1
		!resourceConsumptionPerKerbal = DELETE
		%alwaysActive = true
	}
	!MODULE[ModuleKerbalHealth]:HAS[#multiplyFactor[Crowded]] {}
	!RESOURCE[RadiationShielding] {}
}
@PART[crewCabin]:NEEDS[KerbalHealth]:AFTER[KerbalHealth]
{
	@MODULE[ModuleKerbalHealth]
	{
		@resourceConsumptionPerKerbal = 1.5
		@multiplier = 0.3
	}
	MODULE
	{
		name = ModuleKerbalHealth
		recuperation = 0.4
		partCrewOnly = true
		alwaysActive = true
		crewCap = 4
	}
}
@PART[MK1CrewCabin]:NEEDS[KerbalHealth]:AFTER[KerbalHealth]
{
	@MODULE[ModuleKerbalHealth]
	{
		@resourceConsumptionPerKerbal = 1
	}
	MODULE
	{
		name = ModuleKerbalHealth
		recuperation = 0.3
		partCrewOnly = true
		alwaysActive = true
		crewCap = 2
	}
}
@PART[mk2CrewCabin]:NEEDS[KerbalHealth]:AFTER[KerbalHealth]
{
	MODULE
	{
		name = ModuleKerbalHealth
		recuperation = 0.3
		partCrewOnly = true
		alwaysActive = true
		crewCap = 4
	}
}
@PART[mk3CrewCabin]:NEEDS[KerbalHealth]:AFTER[KerbalHealth]
{
	MODULE
	{
		name = ModuleKerbalHealth
		recuperation = 0.3
		partCrewOnly = true
		alwaysActive = true
		crewCap = 16
	}
}
@PART[Large_Crewed_Lab]:NEEDS[KerbalHealth]:AFTER[KerbalHealth]
{
	@MODULE[ModuleKerbalHealth]
	{
		@resourceConsumptionPerKerbal = 2
		@multiplier = 0.25
	}
}
@PART[sspx-lab-375-1]:NEEDS[KerbalHealth]:AFTER[KerbalHealth]
{
	MODULE
	{
		name = ModuleKerbalHealth
		resourceConsumptionPerKerbal = 2.5
		multiplyFactor = Sickness
		multiplier = 0.25
		crewCap = 3
		partCrewOnly = true
	}
}
@PART[sspx-habitation-125-1]:NEEDS[KerbalHealth]:AFTER[KerbalHealth]
{
	MODULE
	{
		name = ModuleKerbalHealth
		multiplyFactor = Crowded
		multiplier = 0.3
		resourceConsumptionPerKerbal = 1.5
		crewCap = 2
	}
	MODULE
	{
		name = ModuleKerbalHealth
		recuperation = 0.4
		partCrewOnly = true
		alwaysActive = true
		crewCap = 2
	}
}
@PART[sspx-utility-125-1]:NEEDS[KerbalHealth]:AFTER[KerbalHealth]
{
	MODULE
	{
		name = ModuleKerbalHealth
		multiplyFactor = Crowded
		multiplier = 0.3
		resourceConsumptionPerKerbal = 1.5
		crewCap = 1
	}
	MODULE
	{
		name = ModuleKerbalHealth
		recuperation = 0.4
		partCrewOnly = true
		alwaysActive = true
		crewCap = 1
	}
}
@PART[sspx-inflatable-hab-125-1]:NEEDS[KerbalHealth]:AFTER[KerbalHealth]
{
	MODULE
	{
		name = ModuleKerbalHealth
		multiplyFactor = Crowded
		multiplier = 0.3
		resourceConsumptionPerKerbal = 1.5
		crewCap = 6
	}
	MODULE
	{
		name = ModuleKerbalHealth
		recuperation = 0.4
		partCrewOnly = true
		alwaysActive = true
		crewCap = 6
	}
}
@PART[sspx-inflatable-hab-125-2]:NEEDS[KerbalHealth]:AFTER[KerbalHealth]
{
	MODULE
	{
		name = ModuleKerbalHealth
		multiplyFactor = Crowded
		multiplier = 0.3
		resourceConsumptionPerKerbal = 1.5
		crewCap = 3
	}
	MODULE
	{
		name = ModuleKerbalHealth
		recuperation = 0.4
		partCrewOnly = true
		alwaysActive = true
		crewCap = 3
	}
}
@PART[sspx-inflatable-hab-125-3]:NEEDS[KerbalHealth]:AFTER[KerbalHealth]
{
	MODULE
	{
		name = ModuleKerbalHealth
		multiplyFactor = Crowded
		multiplier = 0.3
		resourceConsumptionPerKerbal = 1.5
		crewCap = 3
	}
	MODULE
	{
		name = ModuleKerbalHealth
		recuperation = 0.4
		partCrewOnly = true
		alwaysActive = true
		crewCap = 3
	}
}
@PART[sspx-inflatable-centrifuge-125-1]:NEEDS[KerbalHealth]:AFTER[KerbalHealth]
{
	MODULE
	{
		name = ModuleKerbalHealth
		multiplyFactor = Crowded
		multiplier = 0.3
		resourceConsumptionPerKerbal = 1.5
		crewCap = 6
	}
	MODULE
	{
		name = ModuleKerbalHealth
		recuperation = 0.5
		partCrewOnly = true
		alwaysActive = true
		crewCap = 6
	}
	MODULE
	{
		name = ModuleKerbalHealth
		multiplyFactor = Microgravity
		multiplier = 0.25
		resourceConsumption = 6
		crewCap = 6
	}
}
@PART[sspx-inflatable-centrifuge-125-2]:NEEDS[KerbalHealth]:AFTER[KerbalHealth]
{
	MODULE
	{
		name = ModuleKerbalHealth
		multiplyFactor = Crowded
		multiplier = 0.5
		resourceConsumptionPerKerbal = 1
		crewCap = 4
	}
	MODULE
	{
		name = ModuleKerbalHealth
		recuperation = 0.4
		partCrewOnly = true
		alwaysActive = true
		crewCap = 4
	}
	MODULE
	{
		name = ModuleKerbalHealth
		multiplyFactor = Microgravity
		multiplier = 0.5
		resourceConsumption = 4
		crewCap = 4
	}
}
@PART[sspx-habitation-25-1]:NEEDS[KerbalHealth]:AFTER[KerbalHealth]
{
	MODULE
	{
		name = ModuleKerbalHealth
		multiplyFactor = Crowded
		multiplier = 0.1
		resourceConsumptionPerKerbal = 2
		crewCap = 6
	}
	MODULE
	{
		name = ModuleKerbalHealth
		recuperation = 0.5
		partCrewOnly = true
		alwaysActive = true
		crewCap = 6
	}
}
@PART[sspx-observation-25-1]:NEEDS[KerbalHealth]:AFTER[KerbalHealth]
{
	MODULE
	{
		name = ModuleKerbalHealth
		recuperation = 0.2
		alwaysActive = true
	}
	!RESOURCE[RadiationShielding] {}
}
@PART[sspx-inflatable-hab-25-1]:NEEDS[KerbalHealth]:AFTER[KerbalHealth]
{
	MODULE
	{
		name = ModuleKerbalHealth
		multiplyFactor = Crowded
		multiplier = 0.1
		resourceConsumptionPerKerbal = 2
		crewCap = 18
	}
	MODULE
	{
		name = ModuleKerbalHealth
		recuperation = 0.5
		partCrewOnly = true
		alwaysActive = true
		crewCap = 18
	}
}
@PART[sspx-inflatable-hab-25-2]:NEEDS[KerbalHealth]:AFTER[KerbalHealth]
{
	MODULE
	{
		name = ModuleKerbalHealth
		multiplyFactor = Crowded
		multiplier = 0.1
		resourceConsumptionPerKerbal = 2
		crewCap = 9
	}
	MODULE
	{
		name = ModuleKerbalHealth
		recuperation = 0.5
		partCrewOnly = true
		alwaysActive = true
		crewCap = 9
	}
}
@PART[sspx-inflatable-centrifuge-25-1]:NEEDS[KerbalHealth]:AFTER[KerbalHealth]
{
	MODULE
	{
		name = ModuleKerbalHealth
		multiplyFactor = Crowded
		multiplier = 0.1
		resourceConsumptionPerKerbal = 2
		crewCap = 8
	}
	MODULE
	{
		name = ModuleKerbalHealth
		recuperation = 0.6
		partCrewOnly = true
		alwaysActive = true
		crewCap = 8
	}
	MODULE
	{
		name = ModuleKerbalHealth
		multiplyFactor = Microgravity
		multiplier = 0
		resourceConsumption = 8
		crewCap = 8
	}
}
@PART[sspx-habitation-375-1]:NEEDS[KerbalHealth]:AFTER[KerbalHealth]
{
	MODULE
	{
		name = ModuleKerbalHealth
		multiplyFactor = Crowded
		multiplier = 0.05
		resourceConsumptionPerKerbal = 2.5
		crewCap = 12
	}
	MODULE
	{
		name = ModuleKerbalHealth
		recuperation = 0.6
		partCrewOnly = true
		alwaysActive = true
		crewCap = 12
	}
	MODULE
	{
		name = ModuleKerbalHealth
		alwaysActive = true
		shielding = 10
	}
}
@PART[sspx-habitation-375-2]:NEEDS[KerbalHealth]:AFTER[KerbalHealth]
{
	MODULE
	{
		name = ModuleKerbalHealth
		multiplyFactor = Crowded
		multiplier = 0.05
		resourceConsumptionPerKerbal = 2.5
		crewCap = 6
	}
	MODULE
	{
		name = ModuleKerbalHealth
		recuperation = 0.6
		partCrewOnly = true
		alwaysActive = true
		crewCap = 6
	}
	MODULE
	{
		name = ModuleKerbalHealth
		alwaysActive = true
		shielding = 5
	}
}
@PART[sspx-habitation-375-3]:NEEDS[KerbalHealth]:AFTER[KerbalHealth]
{
	MODULE
	{
		name = ModuleKerbalHealth
		multiplyFactor = Crowded
		multiplier = 0.5
		resourceConsumptionPerKerbal = 1
		crewCap = 6
	}
	MODULE
	{
		name = ModuleKerbalHealth
		recuperation = 0.3
		partCrewOnly = true
		alwaysActive = true
		crewCap = 6
	}
	MODULE
	{
		name = ModuleKerbalHealth
		alwaysActive = true
		shielding = 20
	}
}
@PART[sspx-core-375-1]:NEEDS[KerbalHealth]:AFTER[KerbalHealth]
{
	MODULE
	{
		name = ModuleKerbalHealth
		alwaysActive = true
		shielding = 5
	}
}
@PART[sspx-aquaculture-375-1]:NEEDS[KerbalHealth]:AFTER[KerbalHealth]
{
	MODULE
	{
		name = ModuleKerbalHealth
		alwaysActive = true
		shielding = 20
	}
}
@PART[sspx-cupola-375-1]:NEEDS[KerbalHealth]:AFTER[KerbalHealth]
{
	MODULE
	{
		name = ModuleKerbalHealth
		recuperation = 0.1
		alwaysActive = true
	}
	!RESOURCE[RadiationShielding] {}
}
@PART[sspx-expandable-centrifuge-375-1]:NEEDS[KerbalHealth]:AFTER[KerbalHealth]
{
	MODULE
	{
		name = ModuleKerbalHealth
		multiplyFactor = Crowded
		multiplier = 0
		resourceConsumptionPerKerbal = 3
		crewCap = 14
	}
	MODULE
	{
		name = ModuleKerbalHealth
		recuperation = 0.7
		partCrewOnly = true
		alwaysActive = true
		crewCap = 14
	}
	MODULE
	{
		name = ModuleKerbalHealth
		recuperation = 0.3
		alwaysActive = true
	}
	MODULE
	{
		name = ModuleKerbalHealth
		multiplyFactor = Microgravity
		multiplier = 0
		resourceConsumption = 14
		crewCap = 14
	}
}
@PART[sspx-expandable-centrifuge-375-2]:NEEDS[KerbalHealth]:AFTER[KerbalHealth]
{
	MODULE
	{
		name = ModuleKerbalHealth
		multiplyFactor = Crowded
		multiplier = 0
		resourceConsumptionPerKerbal = 3
		crewCap = 10
	}
	MODULE
	{
		name = ModuleKerbalHealth
		recuperation = 0.7
		partCrewOnly = true
		alwaysActive = true
		crewCap = 10
	}
	MODULE
	{
		name = ModuleKerbalHealth
		multiplyFactor = Microgravity
		multiplier = 0
		resourceConsumption = 10
		crewCap = 10
	}
}

Unrelated side note: I noticed that the config you use to give parts RadiationShielding does not successfully exclude Cupolas and Cockpits.

Edited December 27, 2017 by Fraz86

[Fr8monkey]

Haven't checked the possible future updates; but is there plans for a hospital or clinic to put on bases or long distance trips?   Maybe a bonus for having a medic (scientist) onboard?

[garwel]

On 12/27/2017 at 4:53 AM, Fr8monkey said:

Haven't checked the possible future updates; but is there plans for a hospital or clinic to put on bases or long distance trips?   Maybe a bonus for having a medic (scientist) onboard?

I don't plan to add any parts to this mod. It is supposed to work alongside existing part mods as well as in a stock-only setup. Some mods (e.g. MKS) do have a med bay, which is supported by Kerbal Health. Their effect is a dramatic reduction of Sickness effect and provision of a huge Recuperation bonus (currently 8%, but I plan to lower that a bit) to kerbals inside these parts. It should be good for recovering kerbals that had suffered from accidents etc.

Medics and scientists already provide bonus to sickness healing, and a medic counts as two scientists for this purpose. It's a rare occasion though.

@Fraz86 Thanks for your ideas. I think some crew cap is indeed required and maybe lowering Recuperation bonus or adding diminishing returns mechanics. Hold out for a beta of KH 1.1.

[garwel]

Here is the promised beta release of Kerbal Health 1.1.0.

• Added: (Almost) every crewable part now provides Living Space, which is used to calculate Crowded factor instead of seats number. Generally, heavier and more expensive parts tend to provide more space, but factor multipliers and Recuperation are also taken into account.
• Added: Recuperation now has crew cap and can't go higher than the highest Recuperation value among your parts. E.g. a Cupola provides 1% Recuperation for 2 crew => 4 Cupolas give 1% Recup for 8 crew (not 4%!).
• Added: Support patches for Atomic Age, FTmN, FTmn-New, RSCapsuledyne (thanks @linuxgurugamer for these), and DSEV mods
• Added: Recuperation is now shown in Health Report
• Added: Some parts (stocks as well as from mods) now provide bonuses to Loneliness and Connected factors
• Changed: Health modules can only be enabled or disabled if they consume resources (EC). Therefore alwaysActive keyword has been deprecated.
• Changed: All parts' values have been rebalanced
• Significantly improved performance for vessels with a lot of crew

NOTE: As all parts have been rebalanced, be careful when updating a live save file with ongoing missions. Check that your kerbals are ok after updating and change settings accordingly (or rescue them before it's too late).

Download here

Send me your bug reports (be sure to enable Debug Mode and attach the output log) and feedback re new mechanics and balance.

Edited January 2, 2018 by garwel

[Fraz86]

13 hours ago, garwel said:

Here is the promised beta release of Kerbal Health 1.1.0.

• Added: (Almost) every crewable part now provides Living Space, which is used to calculate Crowded factor instead of seats number. Generally, heavier and more expensive parts tend to provide more space, but factor multipliers and Recuperation are also taken into account.
• Added: Recuperation now has crew cap and can't go higher than the highest Recuperation value among your parts. E.g. a Cupola provides 1% Recuperation for 2 crew => 4 Cupolas give 1% Recup for 8 crew (not 4%!).
• Added: Support patches for Atomic Age, FTmN, FTmn-New, RSCapsuledyne (thanks @linuxgurugamer for these), and DSEV mods
• Added: Recuperation is now shown in Health Report
• Added: Some parts (stocks as well as from mods) now provide bonuses to Loneliness and Connected factors
• Changed: Health modules can only be enabled or disabled if they consume resources (EC). Therefore alwaysActive keyword has been deprecated.
• Changed: All parts' values have been rebalanced
• Significantly improved performance for vessels with a lot of crew

NOTE: As all parts have been rebalanced, be careful when updating a live save file with ongoing missions. Check that your kerbals are ok after updating and change settings accordingly (or rescue them before it's too late).

Download here

Send me your bug reports (be sure to enable Debug Mode and attach the output log) and feedback re new mechanics and balance.

Thanks for the update! For the purpose of creating compatibility patches, I was hoping to get additional details regarding any values that are now determined formulaically. For instance, I saw your post from page 11 where you gave the following formula:

Quote

CrowdedFactor = min (100%, 25% * (1 + RecuperationBonus) * sqrt (1000 * EffCrew / Cost) * EffCrew / Mass)

where

EffCrew = CrewCapacity + CommandModule + 5 * SciLab

Does a hab being a centrifuge have a defined impact on the CrowdedFactor (e.g., in terms of modifying EffCrew like CommandModule or SciLab)? How is EC use calculated? What about "space"? Are there formulae for calculation of RecuperationBonus, or connected/loneliness/sickness multipliers multipliers?

EDIT: Upon further review, it appears that some parts don't actually obey the above formula for CrowdedFactor. For example, the calculation for the Mk1 Crew Cabin should be 0.25 * (1 + 0) * sqrt(1000 * 2 / 550) * 2 / 1 = ~0.95, but instead it has a CrowdedFactor of 0.75. Am I missing something, or has it been arbitrarily adjusted?

Edited January 3, 2018 by Fraz86

[cyberKerb]

Thanks for the update!

Phew! I was a little worried my freshly constructed station was going to need a major refit with this update.  My station has two cupolas and a few other crew capacity modules and had (I think) a hover health level of something like 60/70%. With the update it's slightly lower (55%-ish), but still a hover health level, so the station is still viable for long term habitation.

 

Just curious, what's criteria are you using for a part to have a recuperation module? Is it required that a part has to have windows? I ask as I'm looking at my other mods I've got installed and wondering what patches I can create that might be a big enough part to warrant adding that module. I understand I can just add it to any part I see fit in my own game, but I was looking for information on what is more in theme with the your own criteria.

I've created a patch to add Shielding to the extra large structural panel (3x3) & small triangle panel from Vens Stock Revamp. I'm sure there is stack of other stuff to add from this Mod (hence the question above), but this is what I've used so far.

@PART[Angledpanel]:NEEDS[VenStockRevamp&KerbalHealth] 
{ 
	MODULE 
	{ 
		name = ModuleKerbalHealth 
		shielding = 0.375 
	} 
	RESOURCE 
	{ 
		name = RadiationShielding 
		amount = 0 
		maxAmount = 0.375 
	} 
} 


@PART[structuralPanel3]:NEEDS[VenStockRevamp&KerbalHealth] 
{ 
	MODULE 
	{ 
		name = ModuleKerbalHealth 
		shielding = 6.75  
	} 
	RESOURCE 
	{ 
		name = RadiationShielding 
		amount = 0 
		maxAmount = 6.75 
	} 
} 

 

 

6 hours ago, Fraz86 said:

Thanks for the update! For the purpose of creating compatibility patches, I was hoping to get additional details regarding any values that are now determined formulaically. For instance, I saw your post from page 11 where you gave the following formula:

Does a hab being a centrifuge have a defined impact on the CrowdedFactor (e.g., in terms of modifying EffCrew like CommandModule or SciLab? How is EC use calculated? What about "space"? Are there formulae for calculation of RecuperationBonus, or connected/loneliness/sickness multipliers multipliers?

EDIT: Upon further review, it appears that some parts don't actually obey the above formula for CrowdedFactor. For example, the calculation for the Mk1 Crew Cabin should be 0.25 * (1 + 0) * sqrt(1000 * 2 / 550) * 2 / 1 = ~0.95, but instead it has a CrowdedFactor of 0.75. Am I missing something, or has it been arbitrarily adjusted?

For the Mk1 Crew cabin - based on the github, I see that it's been specifically set, so it doesn't use the calculation patch.

https://github.com/GarwelGarwel/KerbalHealth/blob/master/Patches/KHStock.cfg#L84

Edited January 3, 2018 by wile1411

[Fraz86]

8 minutes ago, wile1411 said:

For the Mk1 Crew cabin - based on the github, I see that it's been specifically set, so it doesn't use the calculation patch.

https://github.com/GarwelGarwel/KerbalHealth/blob/master/Patches/KHStock.cfg#L84

I'm not seeing any calculation patch (at least, not as a MM file). It looks like all of the crowded multipliers are specifically set. It's just that the multipliers chosen for other stock parts approximately match the value given by the formula. See below:

	Predicted multiplier	Actual multiplier
Hitchhiker	0.4	0.4
Mk1 Crew Cabin	0.953	0.75
Mk2 Crew Cabin	0.488	0.5
Mk3 Crew Cabin	0.449	0.45

The multipliers for other parts were just rounded to nice even numbers, whereas the multiplier for the Mk1 Crew Cabin got a substantial buff from 0.953 to 0.75. I'm trying to understand if there's some logic I'm missing that explains this discrepancy, so that I can reproduce this logic when I write compatibility patches for Nertea's mods.

[cyberKerb]

3 hours ago, Fraz86 said:

I'm not seeing any calculation patch (at least, not as a MM file). It looks like all of the crowded multipliers are specifically set. It's just that the multipliers chosen for other stock parts approximately match the value given by the formula.

Sorry - by calculation patch I just meant the KH module being added via the MM patch. I assumed the calculation was within the code "somewhere".

Best guess is this area in the code that does it - althought it just as easily be something done outside the mod and hardcoded in. I'll wait for Garwel to reply

https://github.com/GarwelGarwel/KerbalHealth/blob/3b45b16a6651cdbfda718cc8ddd2afbeee22575f/VesselHealthInfo.cs#L82

Edited January 3, 2018 by wile1411

[garwel]

I actually calculate most of these values in a big, 32-column wide Excel spreadsheet and manually copy them into configs. It doesn't make sense to do it in the plugin and the formulas are too complicated to be used in MM patches. The one @Fraz86 cited is not correct any more; I've made a lot of changes. I may upload the spreadsheet to Google Drive for everyone to play with, but it's really complex to use correctly.

With Recuperation, I decide it case-by-case. Basically, if the part is big (something like 1 ton per kerbal or more), is supposed to be used mainly for long-term habitation, and has no other primary use, it should probably have recup. I rarely look at the parts' visual models; in fact I usually grab all the data I need from parts' config files.

I'll look at Ven's Stock Parts Revamp for what can be patched. Your patches look ok to me, @wile1411.

[Fraz86]

12 minutes ago, garwel said:

I actually calculate most of these values in a big, 32-column wide Excel spreadsheet and manually copy them into configs. It doesn't make sense to do it in the plugin and the formulas are too complicated to be used in MM patches. The one @Fraz86 cited is not correct any more; I've made a lot of changes. I may upload the spreadsheet to Google Drive for everyone to play with, but it's really complex to use correctly.

With Recuperation, I decide it case-by-case. Basically, if the part is big (something like 1 ton per kerbal or more), is supposed to be used mainly for long-term habitation, and has no other primary use, it should probably have recup. I rarely look at the parts' visual models; in fact I usually grab all the data I need from parts' config files.

I would love to see your spreadsheet, or even just your most up-to-date formulas. It would be very helpful for writing compatibility patches.

[garwel]

Ok, guys, here is the part balancing spreadsheet. Download it, open in Excel and use the 1.1 tab in it.

A few comments:

• Com? — set to 1 if the part can be used as a command module (with crew or not) and to 2 if it can be used as probe control.
• Lab? — set to 1 if the part has a science lab or some other very specific primary function (e.g. a greenhouse or a power generator or something); for labs with data capacity other than default 750, use formula (0.5 + DataCapacity / 1500).
• Lock? — set to 1 for parts that are not supposed to house kerbals such as airlocks (it zeroes out their Kerbal Health values).
• EffCrew — calculated automatically based on the values above and crew capacity. Basically, it is a measure of how much space crew uses in the part (the higher, the more cramped the part is).
• Recup — like I said, if a part is relatively big (something like 1 ton per kerbal or more), is supposed to be used for long-term habitation, and has no other primary purpose, it can have recuperation. In most cases, Recuperation should be 1%, but it can go higher (say 2%) for very heavy and advanced parts or lower in some other cases.
• Space efficiency (col O), Space, and Crowded multiplier are calculated automatically.
• mG, Lone, Conn, etc. — multipliers for Microgravity, Loneliness, Connected, etc. Set them to appropriate values for relevant parts, use stock parts as reference. Remember that Connected factor is positive unlike the others.
• EC/k is EC usage per kerbal per second. That column provides the total usage, from Recuperation (1 EC/k per 1%) and multipliers. You may have to look at the formula and calculate it manually if you have several health modules.
• Columns Y to AH are for testing purposes: they allow you to see what values the vessel will have with a given set of parts and crew (defined in the lowest rows). Note that it is not 100% accurate in some complex cases. In-game Health Report should give you the real values.

[cyberKerb]

Thank Garwel! I'll have a poke around in the sheet - it's nice an organised so I like it already 

Here's the "PPD 20 Jumbo Kerbal Can" part from Vens Stock Revamp that I was thinking of adding some recup to. I haven't found any pictures of it online, so I've uploaded a quick snap with a mk1 capsule ontop for size comparison. It's 5t with 10 seats, so it's well below your metric of 1t / kerbal, so maybe not. Would this be more of a crowded mitigator?

3 hours ago, garwel said:

With Recuperation, I decide it case-by-case. Basically, if the part is big (something like 1 ton per kerbal or more), is supposed to be used mainly for long-term habitation, and has no other primary use, it should probably have recup. I rarely look at the parts' visual models; in fact I usually grab all the data I need from parts' config files.

I'll look at Ven's Stock Parts Revamp for what can be patched. Your patches look ok to me, @wile1411.

 

Edited January 3, 2018 by wile1411

[Fraz86]

@garwel A few thoughts have come up in the course of playing with your spreadsheet (which is awesome, by the way) and working on a compatibility patch for Nertea's new SSPX mod. The use of "Eff t/k" as the primary determinant of habitation modules' "Crowd" factor yields intuitive results for most parts. However, unintuitive results arise for some large hab modules - clearly intended for much longer habitation than a Hitchhiker - that end up with unimpressive Crowd multipliers due to their very high crew capacities. The problem, in my view, is that the crew capacity for such parts is meant to represent the maximum capacity rather than the intended long-term habitation capacity. For example, Nertea's PFD-A Inflatable Habitation Module has a crew capacity of 18 (Eff t/k = 0.54, Crowd = 0.40), but its part description clearly states it has only 9 beds (the other 9 spots are in common areas with exercise equipment, dining, etc.). It would make much more sense, thematically, it the part provided a 0.10 Crowded multiplier for 9 Kerbals, rather than a 0.40 multiplier for 18 Kerbals. This would also allow the part to be much more interesting and useful in terms of gameplay and craft design, providing a meaningful difference vs just stacking multiple Hitchhikers.

In short, I would love to see the addition of some kind of "long-term habitation capacity" that represents the number of Kerbals for whom the part is equipped to provide its maximal benefit. For stock parts (Hitchhiker, Mk1/2/3 Crew Cabins), this is identical to crew capacity, but I believe there are a number of mod parts that could benefit from such a distinction. Perhaps you could subtract half of the difference between Crew Capacity and "long-term habitation capacity" in calculating EffCrew (in the above example: 18 - 0.5 * [18 - 9] = 13.5) and set the Crowded CrewCap equal to the long-term habitation capacity.

EDIT: I also wish that microgravity modification (i.e., a module being a centrifuge) was factored in to calculation of the Crowded multiplier. Basically, a centrifuge should be less effective at reducing crowdedness than an non-centrifuge habitation module with identical mass, capacity, and cost.

Edited January 4, 2018 by Fraz86

[garwel]

On 1/4/2018 at 8:24 AM, Fraz86 said:

@garwel A few thoughts have come up in the course of playing with your spreadsheet (which is awesome, by the way) and working on a compatibility patch for Nertea's new SSPX mod. The use of "Eff t/k" as the primary determinant of habitation modules' "Crowd" factor yields intuitive results for most parts. However, unintuitive results arise for some large hab modules - clearly intended for much longer habitation than a Hitchhiker - that end up with unimpressive Crowd multipliers due to their very high crew capacities. The problem, in my view, is that the crew capacity for such parts is meant to represent the maximum capacity rather than the intended long-term habitation capacity. For example, Nertea's PFD-A Inflatable Habitation Module has a crew capacity of 18 (Eff t/k = 0.54, Crowd = 0.40), but its part description clearly states it has only 9 beds (the other 9 spots are in common areas with exercise equipment, dining, etc.). It would make much more sense, thematically, it the part provided a 0.10 Crowded multiplier for 9 Kerbals, rather than a 0.40 multiplier for 18 Kerbals. This would also allow the part to be much more interesting and useful in terms of gameplay and craft design, providing a meaningful difference vs just stacking multiple Hitchhikers.

In short, I would love to see the addition of some kind of "long-term habitation capacity" that represents the number of Kerbals for whom the part is equipped to provide its maximal benefit. For stock parts (Hitchhiker, Mk1/2/3 Crew Cabins), this is identical to crew capacity, but I believe there are a number of mod parts that could benefit from such a distinction. Perhaps you could subtract half of the difference between Crew Capacity and "long-term habitation capacity" in calculating EffCrew (in the above example: 18 - 0.5 * [18 - 9] = 13.5) and set the Crowded CrewCap equal to the long-term habitation capacity.

EDIT: I also wish that microgravity modification (i.e., a module being a centrifuge) was factored in to calculation of the Crowded multiplier. Basically, a centrifuge should be less effective at reducing crowdedness than an non-centrifuge habitation module with identical mass, capacity, and cost.

I think in these cases, you can simply assume crew capacity to be less than the actual one. E.g. maybe use 9 or 12 instead of 18. Also, the Recuperation's 1 ton per kerbal rule is not strictly mandatory, of course. E.g., I'm going to add Recup to some mods' parts that don't conform to this rule but make logical sense. Recuperation, as well as the Crowded multiplier, also affects living space, so it will still be somewhat balanced. In general, I try to make sure that every part pack that has lots of "advanced" crew parts has at least one part with Recup (and therefore doesn't force you to use Cupolas or other mods).

As to Microgravity multiplier, it affects Living Space, but doesn't affect Crowded. Multipliers shouldn't influent one another or we can have unintended consequences with loops in formulas.

[Fraz86]

@garwel From General.cfg, the following does not work as intended:

@PART[*]:HAS[#CrewCapacity[>0],!name[*Cockpit*],!name[*cupola*],!RESOURCE[RadiationShielding],!MODULE[KerbalSeat]]:AFTER[KerbalHealth]
{
	RESOURCE
	{
		name = RadiationShielding
		amount = 0
		maxAmount = #$../CrewCapacity$
	}
}

In MM syntax, "*" can't represent nothing. For example, *Cockpit* looks for strings with at least one character before the "C" and after the "t", which happens to exclude all of the cockpits in the game. In order to function as you intended, I suggest the following modification:

@PART[*]:HAS[#CrewCapacity[>0],!name[*ockpi*],!name[*upol*],!RESOURCE[RadiationShielding],!MODULE[KerbalSeat]]:AFTER[KerbalHealth]
{
	RESOURCE
	{
		name = RadiationShielding
		amount = 0
		maxAmount = #$../CrewCapacity$
	}
}

 

[garwel]

@Fraz86, thanks, I'll fix it.

[garwel]

A new pre-release of v1.1.0 is out:

• Added: Living Space and RadShield values for stock cockpits
• Changed: Living Space has been lowered for most parts from pre-release 1
• Changed: Crowded factor default base value is now -3 instead of -5; a message will warn you to change it manually in an ongoing game
• Fixed: Cupola and some cockpits still had RadShield capacity when they shouldn't have (thanks @Fraz86 for pointing out)

Download here

As always, it is recommended that you visit your every crewed vessel after updating to make sure new Kerbal Health values are applied.

I'm going to release KH 1.1 on January 20, one year since publication of the first alpha.

Edited January 11, 2018 by garwel

[Fraz86]

5 hours ago, garwel said:

A new pre-release of v1.1.0 is out:

• Added: Living Space and RadShield values for stock cockpits
• Changed: Living Space has been lowered for most parts from pre-release 1
• Changed: Crowded factor default base value is now -3 instead of -5; a message will warn you to change it manually in an ongoing game
• Fixed: Cupola and some cockpits still had RadShield capacity when they shouldn't have (thanks @Fraz86 for pointing out)

Download here

As always, it is recommended that you visit your every crewed vessel after updating to make sure new Kerbal Health values are applied.

I'm going to release KH 1.1 on January 20, one year since publication of the first alpha.

I look forward to trying out the new release! Might you be able to post the latest version of your spreadsheet?

[garwel]

22 minutes ago, Fraz86 said:

I look forward to trying out the new release! Might you be able to post the latest version of your spreadsheet?

It is already there. In fact, that file is synchronized with my local spreadsheet as I edit it. (It also means that sometimes figures there may be something I'm playing with at the moment.)

[cyberKerb]

9 hours ago, garwel said:

A new pre-release of v1.1.0 is out:

• Changed: Crowded factor default base value is now -3 instead of -5; a message will warn you to change it manually in an ongoing game

I was wondering where the message would be and found it in the stock messaging system. Awesome use of that part of the game to communicate with players!
Checked my stations again and the float HPs gone down this time to a flat 60% for a 1 star Kerbal. Guess I need to work on some interplanetary missions now to get the experience to get closer to 70%.

Thanks for the release!