USI support patch

[Grimmas]

A patch to add support for MKS and USI-LS.

I did some basic testing by throwing Jeb against the habitat walls. MM reports that all is peachy. But more testing is required, and definitely a balance pass. I basically looked at the nearest MKS equivalent modules in terms of mass to get a clue for how to configure this.

The hydroponics module has two configurations - a simple one for when only USI-LS is installed without MKS, and a more hardcore one for when MKS is installed.

The configurations are largely based on how MKS configures itself so credit and props to RoverDude for his work.

[gamepeller]

I've been playing around with this and some of these are definitely broken and fixable. I'm no expert on how MKS does things but I think the issue is the part has to have storage for the resources that it uses. For example:

@PART[Benjee10_MMSEV_baseHabShort]:FOR[PlanetsideExplorationTechnologies]:NEEDS[USILifeSupport]
{
	MODULE
	{
		name = USI_SwapController 
		ResourceCosts = SpecializedParts,61,MaterialKits,305,ElectricCharge,305
	}
	MODULE
	{
		name = USI_SwappableBay 
		bayName = Bay 1
		moduleIndex = 0
	}
	MODULE
	{
		name = USI_Converter
		UseSpecialistBonus = false
	}
	MODULE
	{
		name = USILS_HabitationSwapOption
		ConverterName = Hab-Common
		StartActionName = Start Hab-Common
		StopActionName = Stop Hab-Common		

		BaseKerbalMonths = 16.8
		CrewCapacity = 4
		BaseHabMultiplier = 5.2

		INPUT_RESOURCE
		{
			ResourceName = ElectricCharge
			Ratio = 0.94
		}
		INPUT_RESOURCE
		{
			ResourceName = Machinery
			Ratio = 0.000004
		}
		OUTPUT_RESOURCE
		{
			ResourceName = Recyclables
			Ratio = 0.000004
			DumpExcess = true
		}
		REQUIRED_RESOURCE
		{
			ResourceName = Machinery
			Ratio = 200
		}		
	}
	MODULE
	{
		name = USILS_HabitationSwapOption
		ConverterName = Hab-Quarters
		StartActionName = Start Hab-Quarters
		StopActionName = Stop Hab-Quarters		

		BaseKerbalMonths = 80
		CrewCapacity = 0
		BaseHabMultiplier = 0

		INPUT_RESOURCE
		{
			ResourceName = ElectricCharge
			Ratio = 2.09
		}
		INPUT_RESOURCE
		{
			ResourceName = Machinery
			Ratio = 0.000004
		}
		OUTPUT_RESOURCE
		{
			ResourceName = Recyclables
			Ratio = 0.000004
			DumpExcess = true
		}
		REQUIRED_RESOURCE
		{
			ResourceName = Machinery
			Ratio = 200
		}
	}
}

does not work and spams the log with errors, but if I add

	RESOURCE
	{
		name = Machinery
		amount = 200
		maxAmount = 200
	}
	RESOURCE
	{
		name = Recyclables
		amount = 0
		maxAmount = 200
	}

it works as expected and the spamming stops.

[GHrynk]

I tried out sac-winged-bat's additions for Resources, and they appear to work to make hab parts functional. They're likely going to be needed on every habitable part.

I'm going to take a crack at hab time balance, as there are some inconsistencies (same values for different sized parts) and contradictions (smaller parts having more time than larger parts) on Grimmas' first pass. I was hoping RoverDude had a hab scaling calculation tool, but I haven't been able to find it. Nertea might, for his StationPartsExpansion mod, but I haven't picked through that repository yet. I've started compiling the Grimmas stats on the Benjee10 parts, with a USI-LS modded PPD-10 Hitchhiker for basic comparison. I'll probably look at the existing USI/MKS parts, and maybe Nertea's as well, to see if I can derive some scaling trends. My initial thoughts are to base it on part volume, and err on the conservative side for at least the 1.875m parts, with the assumption that 2.5m and 3.75m, parts are progressively more efficient.

I haven't looked at a fix for the Hydroponics Module yet but, as I noted on the Forum (as KSPrynk), it doesn't seem to be switching modes for different types of agriculture (ex., use Fertilizer + Mulch to get Supplies). The MKS and USI-LS GH Wikis do contain pages defining the parameters, if anyone wants to take a crack at that in the meantime.

UPDATE: I think I found a copy of RoverDude's scaling calculation spreadsheet, via this discussion.

[GHrynk]

I've just spent the past few days trying to understand the "Balance Guidelines for MKS_USI-LS.xlsx" spreadsheet calculator tool and I think I've learned enough to be dangerous. Before I go into proposed changes, here are some learning points:

1. The MKS tool accounts for just about every component of mass, including onboard electric charge, and structural fraction. This latter one is important because Benjee10's parts have a crash tolerance of 45m/s and most of the relevant MKS modules have a tolerance of 8m/s. The MKS tool adds to the mass fraction for structure when you increase the crash tolerance.
2. The starting mass is based on Crew-Capacity; Hab bonuses in Kerbal Months add mass, but not as much as Hab Multipliers do. MKS/USI-LS also automatically provides 1 Kerbal month of Hab time for every 1 Kerbal of Crew-Capacity. Keep that in mind when you're wondering why the displayed values in-game are higher than what you put in the .cfg file.
3. Part volume is the other constraint. There's a simple geometry tool sheet for calculating volume, and a field for Target Volume, to compare to calculated component volume. I added under that a Target Mass field, just because my working assumption going in was that I should be constrained to the part masses that Benjee10 assigned. That became a big constraint later.
4. Adding machinery increases the mass of the part, and it's automatically calculated and applied in-game. I applied sac-winged-bat's code at the end of each relevant part, and the mass went up from the part's originally set mass. With full Machinery resources (and 0 starting Recyclables) on the relevant part, I used that part mass as my Target Mass.
5. Because Benjee10's parts are relatively light, despite the 45m/s crash tolerance, this was usually the biggest constraint on Hab time bonuses. In rare cases, volume was, but there's an Extra KM Bonus field that allows more Kerbal Months to be added, which contributes to volume but not mass.
6. The Expandable Hab is kind of an outlier, because it's not using the USIAnimation module to consume Material Kits and EC and turn that into a new, higher, mass after the part is inflated (which would represent "moving in the furniture"). It's using ModuleAnimateGeneric, so when it inflates, it's not consuming resources, but it's also not gaining mass. I'm not sure there's a way to fudge in the resource MatlKit consuming/mass adding portion but I haven't tried yet. The easiest thing to do may be to arbitrarily add more mass to the part (when MKS/USI-LS is installed), but it may be alright as is.
7. Continuous use of resources (ex., EC utilized during operation) and Swappable Bay consumption (MatlKits, SpParts, EC) get calculated once you're done messing with all the other variables.

[GHrynk]

SO, here's what I came up with so far for re-balancing. Note, this is just for FOUR of the dedicated Hab parts. I still need to work out the command modules, log parts, and science modules, but that should go faster, now that I've gotten into a groove on using the MKS calc tool.
My general working methodology was to:

1. Make sure Crew Capacity, crash tolerance, and onboard EC are set properly for the relevant part. This includes adding machinery, if utilized. This is an easy step to forget, in between parts.
2. Scale down the bonuses in proportion to similarly-sized MKS Kerbitat parts, the way I think Grimmas sort-of did. For the 3.75m parts, it's just a scaling by height difference from MKS Tundra 3.75m parts. For 1.875m, I scaled from 2.5m Tundras (linearly; in retrospect, I should have scaled by volume, because circles aren't squares - I may redo this).
3. For parts/operating modes with Hab Multipliers, Crew Affected immediately became the biggest limitation. Benjee10's parts are both light in general and relatively high in Crew Capacity on the 1.875m parts. I blew the mass budget when attempting to Affect the entire crew, so that was the first variable that would get scaled down. Note: Crew Affected appears to be relevant specifically when Hab Multipliers are in play.
4. Added to Kerbal Months until I hit either the Mass or Volume Targets. If I hit mass first, I would throw in the "Extra KM bonus" to then max out the volume.

Allegedly, there's a video on YT or Twitch that explains how to use the spreadsheet. I'm curious how far off base my methodology was. Here are the end results for just four parts, as Grimmas' original value --> new value:

PT-3B Habitation Module (3.75m rigid hab):
Hab-Common - Crew Affected: 4 (no change), Kerb Mos: 16.8 --> 6.7 (reminder: 6 mos get added due to crew capacity), Multiplier: 5.2 --> 1.8, Power: 0.94 --> 0.35
Hab-Quarters - Crew Affected: 0 (no change), Kerb Mos: 80 --> 26, Power: 2.09 --> 0.65

PT-3H Expandable Hab (3.75m)
Hab-Common - Crew Affected: 4 --> 2, Kerb Mos: 8 --> 9.1 (note: un-inflated hab gets no initial mos), Multiplier: 5.2 --> 1.8, Power: 0.94 --> 0.12
Hab-Quarters - Crew Affected: 0 (no change), Kerb Mos: 40 --> 17, Power: 2.09 --> 0.43
Note: The expandable hab actually produces more hab time than the rigid, but only for a relatively small occupying crew. The rigid hab wins out when the occupying crew is maxxed out.

PT-M50H Habitation Module (short 1.875m)
Hab-Common - Crew Affected: 4 --> 2, Kerb Mos: 16.8 --> 1.4. Multiplier: 5.2 --> 0.6, Power: 0.94 --> 0.07
Hab-Quarters - Crew Affected: 0 (no change), Kerb Mos: 80 --> 3.8, Power: 2.09 --> 0.10
USISwapController - SpecializedParts: 61 --> 5, MaterialKits: 305 --> 25, EC: 305 --> 25

PT-M100H Habitation Module (long 1.875m)
Hab-Common - Crew Affected: 4 --> 3, Kerb Mos: 16.8 --> 1.3. Multiplier: 5.2 --> 1.1, Power: 0.94 --> 0.12 (note: not double values over short, because Crew Affected is 50% more.)
Hab-Quarters - Crew Affected: 0 (no change), Kerb Mos: 80 --> 7.9, Power: 2.09 --> 0.20 (note: this is, correctly, twice as mush as the short part.)
USISwapController - SpecializedParts: 61 --> 14, MaterialKits: 305 --> 70, EC: 305 --> 70

Give it a try and let me know if this sounds good enough or way off base. Keep in mind, again, Benjee10's parts are light, so just doing scaling by size alone would make them over-powered, as a player could use that mass-savings to stuff the craft with these modules, at the expense of the presumably more advanced, and properly balanced, MKS parts. I'd also rather err on the side of low hab time, only because tweaking the values higher doesn't impact a craft in flight (at least on mass, but it would on power), but dropping them lower could kill a mission in progress.

I can format this a little better next time, or just drop a new .cfg file, once I've sorted out the rest. Which begs the question, what's the etiquette for tweaking a PR? Should I post a new .cfg here, or start an alternate PR?

ADDENDUM: Just to clarify, it's not so much that BenJee10's parts are unnaturally light, so much as how much crew capacity they have for their size. In the context of MKS/USI-LS, more life support equipment would be needed to support the full crew. One could argue they're fine for a smaller, more "MKS normal"-sized crew for a long mission, or also fine for a short-duration, packed-house, party.

[johnabsher]

@GHrynk as a self-interested observer who is both very interested in using this compatibility patch and also reviews PRs for a living, you could consider creating a new PR based off this branch.

If @Grimmas doesn't mind, you could also just push a commit on this same branch - multiple people contribute to a single PR all the time.

[kaa253]

@GHrynk re-balancing for the four dedicated Hab parts looks to be very good, not just good enough. I have edited the .cfg for myself and I am actually testing in Real Solar System mod. I would be pleased to see work @GHrynk on the command modules, log parts, and science modules. I am also not familiar with the etiquette on Git but new .cfg file/s would be very convenient.

[Grimmas]

@johnabsher You guys can totally contribute to this PR or make your own with the proposed fixes, I completely don't mind. I haven't had much time for KSP lately, sadly.

@sac-winged-bat I don't remember it exactly since it's been a while but I think you are correct in that you need to add resource storage for any resources used.

[BostonBlack]

I have gone through and balanced everything as best I can based off the spreadsheet and video and also changed the cfg files.

However I cannot seem to push my commit.
I'm not really familiar with contributing to other people's projects so not sure if I'm doing something wrong.

[Poodmund]

@BostonBlack do you still have these balance changes? Are they worth uploading elsewhere so somebody can assist with the PR merge?

[BostonBlack]

@Poodmund Yes! I still have them. If you can point me towards somewhere to upload them that would be great.

[Poodmund]

@Poodmund Yes! I still have them. If you can point me towards somewhere to upload them that would be great.

You could use something like https://pastebin.com/ and then post the links to all the configs you have.

[BostonBlack]

MKS:
https://pastebin.com/CKvbPgCc
https://pastebin.com/VdN3eZwM
https://pastebin.com/2AHaHXFV
https://pastebin.com/WvHa4Ji0
https://pastebin.com/whSEiFUU

USI-LS:
https://pastebin.com/raBgfwMS
https://pastebin.com/1vTeECRT
https://pastebin.com/UPpNSqY0
https://pastebin.com/DGwUdWdJ

[Poodmund]

@Grimmas I have raised a PR with @BostonBlack's balance changes against the usi-patches branch of your repo. If you upstream them they should filter into the PR, I presume. 😄

[Grimmas]

@Poodmund @BostonBlack Cheers. I merged your changes, should show up here now. I briefly went over the changes but to cover my behind I will note that I did not test these new changes in-game :-p

[iLikeGothMommys]

MKS: https://pastebin.com/CKvbPgCc https://pastebin.com/VdN3eZwM https://pastebin.com/2AHaHXFV https://pastebin.com/WvHa4Ji0 https://pastebin.com/whSEiFUU

USI-LS: https://pastebin.com/raBgfwMS https://pastebin.com/1vTeECRT https://pastebin.com/UPpNSqY0 https://pastebin.com/DGwUdWdJ

@BostonBlack @Grimmas For USI LS your converters are not balanced properly, you forgot to add a 0 for the fertilizer input. With this config it requires an outrageous amount of fertilizer per day to produce supplies when compared to the stock USI greenhouses, it also makes it impossible to have a fully self sufficient surface base with just USI LS due to the balance issue your config has. I have fixed this by adding the additional 0 that was missing, it is now on par with the balancing of stock USI LS.

For example with the config you have it costs 45 fertilizer per day to run a greenhouse, which stock USI LS greenhouse modules only requires 4.5.

Here is the updated config.
https://pastebin.com/D0jr0kXx