Universal Storage II [1.3.1 and 1.4.5 - 1.7.0]

[Dominiquini]

On 7/7/2021 at 5:32 AM, Daishi said:

Thank you so much! There is only so much I can do as an artist, coding is not my strong suit and errors like those were way out of my reach 

If you're confident, would you mind if this is pushed and included in an official 1.12 release? Full credit to you of course

 

With this bugfix, the mod is working ok? Is not possible to make a release?

Thanks.

[Daishi]

9 hours ago, Tangle said:

Hello, just a minor question- What's the prognosis on making some parts work only for roleplay? Like, the food and waste containers- I see those are only activated by compatible mods, but would anything break if I made them function anyway?

Nah, nothing would break. You'd just have to edit out certain "require mod" fields in the .cfg and replace the resources with something useful

8 hours ago, Dominiquini said:

With this bugfix, the mod is working ok? Is not possible to make a release?

Thanks.

I trust it'll be working fine, though I haven't got KSP installed at the moment to check. Can't really do another update with the patch without the authors permission, though. 

[Dominiquini]

I was testing here and saw that the integration with TAC-LS was a little weird. This mod is using resource like Hydrogen and Methane, that I don't use in any other place!

Thanks.

[Chimichanga]

On 7/6/2021 at 5:53 PM, NicolaSix said:

I like this mod a lot and I'm handy with a compiler, so thus https://github.com/LambdaSix/UniversalStorage2_1.12/releases/tag/1.8.1a which fixes the NRE spam in the console when accessing the PAW, or seems to for me in testing it on my career save. Drop the two new dll's over the original dll's, it's all in the folder structure so you can just drop GameData in directly if you prefer.

I'm not taking this mod up as a maintainer, I'm no linuxgurugamer ty, but here's the recompiled DLL's (compliant with the licensing)  -- recompiled against KSP 1.12.1.

Thank you! Working well.

[jefferyharrell]

@Paul Kingtiger, I don't know if this mod is still alive, but I found a tiny little bug in a config file. In the TAC LS section of ComboLifeSupportWedge.cfg, there's the following resource definition:

RESOURCE
{
name = Water
amount = 60
maxAmount = 60
}

It should be:

@RESOURCE[Water]
{
@name = Water
@amount = 60
@maxAmount = 60
}

 

[Atlas Gaming]

Man I remmeber this mod being one of my favorites... hope Linuxgurugamer upadates it for 12.x at some point.

[OldMold]

The mod works fine in 12.x with the fix from the previous page applied

[Atlas Gaming]

I'm running the fix for 12.x and am not getting any containers showing up... just the scientific wedges, but no containers. Log File https://www.dropbox.com/t/f1P7snVHLjpTXXuB

  

Edited September 26, 2021 by Atlas Gaming

[CreepyShadow]

It seems that there is a problem with the 1.25m to 1.875m tapered fairing. It uses the 5 bay service core, which leads to the wedge brackets clipping through the fairing at the 1.25m side. It should probably be changed to use the 4 bay service core instead. Also, a 1.875m cylindrical fairing would be great, but that's not too important.

[Starseeker]

3 hours ago, CreepyShadow said:

It seems that there is a problem with the 1.25m to 1.875m tapered fairing. It uses the 5 bay service core, which leads to the wedge brackets clipping through the fairing at the 1.25m side. It should probably be changed to use the 4 bay service core instead. Also, a 1.875m cylindrical fairing would be great, but that's not too important.

A 1.875m cylindrical fairing's been on the burner for a while now; however, a hard drive failure & a bunch of other stuff in the lives of the devs have kinda stalled development momentum. I wouldn't call it "dead" per se, but it's definitely on hiatus.
IIRC, the description for the 1.25->1.875m tapered fairing says it should only have low-profile stuff in the "top" slots - though last I remember, the localization files are a bit borked, so it might not show up properly. It'd be nice to have a 4-segment variant, but that's also a lot of re-modeling work and stuff.

[Frostiken]

The 1.875 cylindrical fairing is like literally the only part that was missing from this mod  Without it, the entire 1.875 core stack is borderline pointless.

 

The 1.875m fairing was 'coming soon' literally three years ago. I'd say at this point it's never coming and the mod is dead.

Edited November 6, 2021 by Frostiken

[panarchist]

10 hours ago, Frostiken said:

The 1.875 cylindrical fairing is like literally the only part that was missing from this mod  Without it, the entire 1.875 core stack is borderline pointless.

 

The 1.875m fairing was 'coming soon' literally three years ago. I'd say at this point it's never coming and the mod is dead.

Given that Paul Kingtiger hasn't been on since June and last posted about KSP back in January, I agree it's unlikely. At least the mod works in the final version of KSP. Never say never, though - plenty of modders have returned after months or years away, you never know when someone decides to hop back on. Kingtiger appears consumed by fighting sail era miniatures, and honestly, I totally can understand that. I took a 5 minute look at his Twitter feed and now *I* want to play that game.

Edited November 7, 2021 by panarchist

[610yesnolovely]

On 11/6/2021 at 7:04 PM, panarchist said:

Given that Paul Kingtiger hasn't been on since June and last posted about KSP back in January, I agree it's unlikely. At least the mod works in the final version of KSP. Never say never, though - plenty of modders have returned after months or years away, you never know when someone decides to hop back on. Kingtiger appears consumed by fighting sail era miniatures, and honestly, I totally can understand that. I took a 5 minute look at his Twitter feed and now *I* want to play that game.

@Daishihas recently posted and he's the animation, model and texture artist (according to the first page), so his license/copyright would require his input/help/blessing (however that works). @DMagicis around-ish I think, though the rest of the mod is MIT licensed. I'd hope something could happen to make an official 1.12.2 release at least, US2 is a great mod (esp. if you combine it with DMagic Orbital Science). Hope somehow we can keep it going.

[Starseeker]

On 11/6/2021 at 7:04 PM, panarchist said:

Given that Paul Kingtiger hasn't been on since June and last posted about KSP back in January, I agree it's unlikely. At least the mod works in the final version of KSP. Never say never, though - plenty of modders have returned after months or years away, you never know when someone decides to hop back on. Kingtiger appears consumed by fighting sail era miniatures, and honestly, I totally can understand that. I took a 5 minute look at his Twitter feed and now *I* want to play that game.

And hey, with KSP having a truly stable version and the constant battle against mod-breaking updates a thing of the past, that might encourage all sorts of people to come back to modding, so who knows?

[panarchist]

11 hours ago, 610yesnolovely said:

@Daishihas recently posted and he's the animation, model and texture artist (according to the first page), so his license/copyright would require his input/help/blessing (however that works). @DMagicis around-ish I think, though the rest of the mod is MIT licensed. I'd hope something could happen to make an official 1.12.2 release at least, US2 is a great mod (esp. if you combine it with DMagic Orbital Science). Hope somehow we can keep it going.

Not sure much if anything needs to happen to "keep it going", since it works already with the final version of KSP 1. It's more that there were a few outstanding items that Daishi and Kingtiger originally stated they had planned, and which got back-burnered. I think we're all aware this is 100% volunteer, and I think we're all very appreciative of all the work over the years. I know I am. No one has made a modular storage system to compare to this one, and it's always one of the first mods I install (and keep installed) on any KSP installation I spin up. Modding's a thankless job, and I'm surprised more of the KSP modding community hasn't burned out, or burned out quicker. If they both choose to leave it permanently, I hope they'll be amenable to granting permission for someone to distribute the mod in the event that the current repositories go away.

[Frostiken]

Not that it will get fixed, but I found that the radial resource tanks do NOT save their locked/unlocked status. I was trying to make a reserve fuel supply but every time you load the vessel it unlocks all the tanks, and it's way too much a PITA to remember to re-lock them manually.

[Sandriell]

For anyone using Nertea's Cryo Tanks/Cryo Engines mods- here is a patch that will add Liquid Hydrogen and Liquid Methane to the Fuel Tank wedge, as well as adding a Liquid Fuel only option.

////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
///////////   Expand fuel options and add support to the fuel tank wedge for LqdHydrogen and LqdMethane added by CryoTanks
///////////   Sandriell - https://forum.kerbalspaceprogram.com/index.php?/profile/165509-sandriell/
////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

@PART[USAerozineWedge]:NEEDS[CryoTanks]
{
	@title = Universal Storage: Fuel Tank
	@description = Fuel tank built in wedge format to be mounted to Universal Storage cores. Capable of holding Liquid Fuel as well as cryogenic Liquid Hydrogen and Liquid Methane, all with or without Oxidizer. Cryogenic fuels will require a small amount of electric charge to prevent boil-off. Fuel may be refueled via lines, or the entire wedge can be removed on EVA and replaced with new equipment or storage.  Four size variants are available.

	@MODULE[USFuelSwitch]
	{
		@SwitchID = 0;1
		@resourceNames = LiquidFuel,Oxidizer;LiquidFuel,Oxidizer;LiquidFuel,Oxidizer;LiquidFuel,Oxidizer|LiquidFuel;LiquidFuel;LiquidFuel;LiquidFuel|LqdHydrogen,Oxidizer;LqdHydrogen,Oxidizer;LqdHydrogen,Oxidizer;LqdHydrogen,Oxidizer|LqdHydrogen;LqdHydrogen;LqdHydrogen;LqdHydrogen|LqdMethane,Oxidizer;LqdMethane,Oxidizer;LqdMethane,Oxidizer;LqdMethane,Oxidizer|LqdMethane;LqdMethane;LqdMethane;LqdMethane
		@resourceAmounts = 10,12;20,24;30,36;40,48|22;44;66;88|105,7;225,15;345,23;450,30|165;330;495;660|40,8;90,18;130,26;165,33|110;220;330;440
		@initialResourceAmounts = 10,12;20,24;30,36;40,48|22;44;66;88|105,7;225,15;345,23;450,30|165;330;495;660|40,8;90,18;130,26;165,33|110;220;330;440
		@tankCost = 0;35;70;105|0;35;70;105|0;35;70;105|0;35;70;105|0;35;70;105|0;35;70;105
		@tankMass = 0;0.014;0.028;0.042|0;0.014;0.028;0.042|0;0.014;0.028;0.042|0;0.014;0.028;0.042|0;0.014;0.028;0.042|0;0.014;0.028;0.042
	}

	MODULE
	{
		name = USSwitchControl
		SwitchID = 1
		ButtonName = #autoLOC_US_FuelVariants
		CurrentVariantTitle = #autoLOC_US_FuelVariants
		ShowPreviousButton = False
		ObjectNames = #LOC_CryoTanks_switcher_fuel_lfox;#LOC_CryoTanks_switcher_fuel_lf;#LOC_CryoTanks_switcher_fuel_lh2ox;#LOC_CryoTanks_switcher_fuel_lh2;#LOC_CryoTanks_switcher_fuel_methalox;#LOC_CryoTanks_switcher_fuel_methane
		FuelSwitchModeTwo = True
		ModuleDisplayName = #autoLOC_US_TankOptions
		VariantColors = #bfa760,#3399cc;#bfa760,#bfa760;#99ccff,#3399cc;#99ccff,#99ccff;#00bf8f,#3399cc;#00bf8f,#00bf8f
	}

	MODULE
	{
		name =  ModuleCryoTank
		CoolingEnabled = False
		BOILOFFCONFIG
		{
			FuelName = LqdHydrogen
			// in % per hr
			BoiloffRate = 0.05
			CoolingCost = 0.09
		}
		BOILOFFCONFIG
		{
			FuelName = LqdMethane
			// in % per hr
			BoiloffRate = 0.05
			CoolingCost = 0.09
		}
	}
}

I suggest saving it in a file called "US_CryoTanks.cfg" and putting it in your either "GamaData/CryoTanks/Patches" or "GamaData/UniversalStorage2/Patches" folders. Pick only one.

[Brigadier]

16 minutes ago, Sandriell said:

I suggest saving it in a file called "US_CryoTanks.cfg" and putting it in your either "GamaData/CryoTanks/Patches" or "GamaData/UniversalStorage2/Patches" folders.

Wouldn't putting the patch in a user folder (e.g. zz_my_mods) unrelated to either mod be more resilient since installing or updating that particular mod could wipe out the patch file inadvertently?

[Sandriell]

2 minutes ago, Brigadier said:

Wouldn't putting the patch in a user folder (e.g. zz_my_mods) unrelated to either mod be more resilient since installing or updating that particular mod could wipe out the patch file inadvertently?

Yep, technically you could put it anywhere in the GameData folder and it would work fine. Updating either manually or through CKAN should be safe though, as neither method would overwrite any user created files- as long as you are not deleting the mod folder before updating.

[Brigadier]

6 hours ago, Sandriell said:

Yep, technically you could put it anywhere in the GameData folder and it would work fine. Updating either manually or through CKAN should be safe though, as neither method would overwrite any user created files- as long as you are not deleting the mod folder before updating.

This is a poor practice since not removing a mod entirely before updating leads to problems.  Any files not in the update would remain, potentially conflicting with the mod author's intent.   This is particularly true of manual installs where you're dragging and dropping, and not removing old .dlls and .cfgs.

Best practice is to start a mod update or reinstall with a clean mod directory and thus avoid old, unused files from accumulating.  Putting all of your user cfgs in a separate directory that only you maintain would keep them all in one place if you ever have to remove or update them.  It also makes it easier to copy your user cfgs to another save, which may or may not have all of the same mods.

[Gordon Dry]

9 hours ago, Brigadier said:

This is a poor practice since not removing a mod entirely before updating leads to problems. 

This is the reason why I always use file synchronization, I can see which files are changed, added or removed and what are the differences. I want to be in  control of the rig, not the rig in control of me. I'm not a transhuman from CCP.
I archive all mods, well sorted and categorized by release, dev or test versions. I add text files with infos and hints about dependencies, incompatibilities and companion mods. I place fix patches from the forums into those archives as well.
When I see quirks I try to find the culprit as soon as possible and/or open an issue at the Github - if available. Some mod devs do not provide a way to place issues and/or suggestions besides the forum.

[Gordon Dry]

Why does the part
GameData\UniversalStorage2\Parts\Electrical\GuidanceComputer.cfg
does this? This makes no sense at all:
First

PART:NEEDS[kOS|MechJeb2]

so no matter if MechJeb or kOS

then

            MODULE
            {
                name = kOSProcessor

just add a kOSProcessor - but no MechJebCore.

This whole patching inside parts thing is a bad idea. Patches should be seperate of part configs. In another folder. And they shoud do at least.

The minimum what I can do now to just edit the file to sanity and not add a new file is:
GameData\UniversalStorage2\Parts\Electrical\GuidanceComputer.cfg

Spoiler

// Universal Storage 2 by Paul Kingtiger, Daishi and DMagic.
// See packaged file for license information

// This file is best viewed with notepad++ https://notepad-plus-plus.org/
// Using the KSP Module Manager language file included in the mod.

// name = USGuidanceComputer

PART:NEEDS[kOS|MechJeb2]
{
	// Shared by all parts in the mod
	// Module, Author, Manufacturer, Subcategory
	// These values should never change and are common to all parts.
	/+
		module = Part
		author = Daishi, DMagic, and Paul Kingtiger
		manufacturer = #autoLOC_US_Manufacturer //New Horizons & Nox Industrial
		subcategory = 0
	/-
	// .- -- .- --.. .. -. --. --. ..- -.-- ...



	// Common fields
	// Every part has these core variables
	/+
		// Base attributes
			title = #autoLOC_US_GuidanceComputer_Title //Universal Storage: Guidance Computer
			category = Control
			tags = #autoLOC_US_GuidanceComputer_Tags //Universal Storage Wedge DSKY Guidance Computer
			description = #autoLOC_US_GuidanceComputer_Description //A top of the line, 2MHz digital computer. While best utilized to experience the pinnacle of next-gen gaming; the KSC would rather you use this workhorse to plot your way to the stars. Features pre-woven memory and a convenient carry handle.
			cost = 1200
			mass = 0.12
			maxTemp = 3400
			fuelCrossFeed = True
			bulkheadProfiles = wedge
			crashTolerance = 9

		// Tech Tree
			TechRequired = flightControl
			entryCost = 4200
	/-
	// .- -- .- --.. .. -. --. --. ..- -.-- ...



	// Special
	// Contains any special functionality for this part
	/+
		// kOS
			MODULE:NEEDS[kOS]
			{
				name = kOSProcessor
				diskSpace = 10000
				ECPerBytePerSecond = 0
				ECPerInstruction = 0.000004
			}

			MODULE:NEEDS[MechJeb2]
			{
				name = MechJebCore
				MechJebLocalSettings
				{
					MechJebModuleCustomWindowEditor { unlockTechs = flightControl }
					MechJebModuleSmartASS { unlockTechs = flightControl }
					MechJebModuleManeuverPlanner { unlockTechs = advFlightControl }
					MechJebModuleNodeEditor { unlockTechs = advFlightControl }
					MechJebModuleTranslatron { unlockTechs = advFlightControl }
					MechJebModuleWarpHelper { unlockTechs = advFlightControl }
					MechJebModuleAttitudeAdjustment { unlockTechs = advFlightControl }
					MechJebModuleThrustWindow { unlockTechs = advFlightControl }
					MechJebModuleRCSBalancerWindow { unlockTechs = advFlightControl }
					MechJebModuleRoverWindow { unlockTechs = fieldScience }
					MechJebModuleAscentGuidance { unlockTechs = unmannedTech }
					MechJebModuleLandingGuidance { unlockTechs = unmannedTech }
					MechJebModuleSpaceplaneGuidance { unlockTechs = unmannedTech }
					MechJebModuleDockingGuidance { unlockTechs = advUnmanned }
					MechJebModuleRendezvousAutopilotWindow { unlockTechs = advUnmanned }
					MechJebModuleRendezvousGuidance { unlockTechs = advUnmanned }
				}
			} 

			RESOURCE
			{
				name = ElectricCharge
				amount = 5
				maxAmount = 5
			}

		// KIS
		// Adds KIS functionality when KIS is installed
			MODULE:NEEDS[KIS]
			{
				name = ModuleKISItem
				shortcutKeyAction = drop
				useName = use
				usableFromEva = true
				usableFromContainer = true
				usableFromPod = true
				usableFromEditor = false
				stackable = true
				volumeOverride = 0
				moveSndPath = KIS/Sounds/itemMove
				equipable = true
				equipMode = part
				equipSlot = Back
				equipSkill = <null>
				equipRemoveHelmet = false
				equipMeshName = jetpack_base01
				equipBoneName = aliasJetpack
				equipPos = (0,-0.05,-0.3)
				equipDir = (0,270,0)
				carriable = true
				allowPartAttach = 1
				allowStaticAttach = 0
			}
	/-
	// .- -- .- --.. .. -. --. --. ..- -.-- ...



	// Don't edit anything below this line.Here be dragons!
	// Drag, Model call, US*Switch
	// Changing these values breaks the part, so don't do that!
	/+
			name = USGuidanceComputer
			rescaleFactor = 1
			attachRules = 1,0,1,1,0

		// Drag
			angularDrag = 1
			dragModelType = default
			maximum_drag = 0.2
			minimum_drag = 0.2

			DRAG_CUBE
			{
				cube = A0, 0.3288,0.8916,0.5346, 0.3265,0.8726,0.583, 0.2238,0.9466,0.7513, 0.222,0.9016,0.6095, 0.2912,0.9138,0.5084, 0.2902,0.8752,0.4591, 0.02138,0.03299,0.01759, 0.5252,0.7037,0.5856

			}

		// Model call
			MODEL
			{
			model = UniversalStorage2/Parts/Electrical/GuidanceComputer
			scale = 1, 1, 1
			}

		// Wedge attach node definitions
			NODE
			{
				name = attach
				transform = attach
				size = 0
				method = HINGE_JOINT
			}
	/-
	// .- -- .- --.. .. -. --. --. ..- -.-- ...



}




// Module Manager
// Contains @PART code for Module Manager, things that cannot be placed in within PART{}
/+

//-
// .- -- .- --.. .. -. --. --. ..- -.-- ...



// Notes
/+

/-
// .- -- .- --.. .. -. --. --. ..- -.-- ...

 

 

[Gordon Dry]

Hmm, the life support tank wedges got Mod specific patches in them (again, patches inside part configs...) - also for Kerbalism, and those are not balanced out against each other.

For exampIe, on top of the already existing life support for 1d on my vessel I get 48d food vs. 32d oxygen vs. 82d water when I add same sized wedges.
Adding the combined life support wedge I get 12d food, 8d oxygen and 7d water.

Are those outdated Kerbalism values from back in the days?

 

Edited December 10, 2021 by Gordon Dry

[panarchist]

On 11/26/2021 at 4:40 AM, Gordon Dry said:

Why does the part
GameData\UniversalStorage2\Parts\Electrical\GuidanceComputer.cfg
does this? This makes no sense at all:
First

PART:NEEDS[kOS|MechJeb2]

so no matter if MechJeb or kOS

then

            MODULE
            {
                name = kOSProcessor

just add a kOSProcessor - but no MechJebCore.

This whole patching inside parts thing is a bad idea. Patches should be seperate of part configs. In another folder. And they shoud do at least.

The minimum what I can do now to just edit the file to sanity and not add a new file is:
GameData\UniversalStorage2\Parts\Electrical\GuidanceComputer.cfg

Pretty sure that dates back to the early days of US2 or possibly the original US. This was by design - parts only show in the list if you have a mod which requires them.

2 hours ago, Gordon Dry said:

Hmm, the life support tank wedges got Mod specific patches in them (again, patches inside part configs...) - also for Kerbalism, and those are not balanced out against each other.

For exampIe, on top of the already existing life support for 1d on my vessel I get 48d food vs. 32d oxygen vs. 82d water when I add same sized wedges.
Adding the combined life support wedge I get 12d food, 8d oxygen and 7d water.

Are those outdated Kerbalism values from back in the days?

Parts aren't balanced for any of those mods, and they weren't intended to be. When Paul Kingtiger and Daishi started working on the original Universal Storage, Paul had a lengthy discussion with a number of parties in the mod community about part volumes and life support baseline values. The values in each US part were volume-based, with a presumption that 1 unit = 5L of RL volume. Tank capacities are linked specifically to the volume of the container / tanks within the wedge, and the density of the stored item. For gases, some are stored in liquid form, and others in gaseous form under high pressure.  There was no effort made to balance them out for any of the mods, because they're based on RL physical constants and properties that Kingtiger meticulously calculated and published the math and methodology for. (I don't know if those links are still online)

For US2, they specifically balanced the parts against stock instead of RL physics, so the capacities are in line with similarly-sized parts in the stock game. US/US2 doesn't contain patches for compatibility with other mods, just the ones inside the part.cfg which enable part visibility if a given mod is installed. It's on the other mods if they want to provide config files to change the storage values in US2. I can't speak as to why Kingtiger decided to put the patch in the config file, but I suspect it was done since MM is a dependency for the mod. It's bad practice now, but there weren't any standard on that in 2017 that I can recall.

[Gordon Dry]

Well, here are fixed configs, the archive only contains the changed files, so overwrite yours.
btw even the LF / Ox ratio in the Hex and Octo core parts is not correct, for example 200 LF / 240 Ox (should be 244.44 Ox then, or 196.36 LF the other way around). So I also fixed that.
https://www.dropbox.com/s/6w5pozz437mq47i/Universal Storage II (Kerbalism fixes).zip?dl=1

Edit: darn, there was a copy&paste-typo-error, please redownload

Edited December 17, 2021 by Gordon Dry
Edit: darn, there was a copy&paste-typo-error, please redownload