Converting FS fuel switch tanks to use WBI storage templates.

[KspNoobUsernameTaken]

Like in the title, I want to replace all FS fuel switch modules with WBI omnistorage/convertible storage modules of equivalent capacity. The problem is that WBI uses a single storage volume variable, and FS has a different capacity/resource.

Edited March 8 by KspNoobUsernameTaken
Also, can you do math inside config nodes? Specifically, would this work: (#&ModuleB9PartSwitch/baseVolume&)/1801

[JadeOfMaar]

@KspNoobUsernameTaken There are some parts in Buffalo 2 that have height variants and capacity variants to go with that. I learned from it and used it in parts I've made. Here's a config. In them you will notice the presence of the following:

• In each VARIANT{} which is a mesh switch option (using the stock variants system):

  EXTRA_INFO
  {
  	packedVolumeLimit = 100 // some value. This is the storage amount
  }

• Outside of the variants configs and next to the OmniStorage module:

  MODULE
  {
  	name = ModuleResourceVariants
  }

Math can be done inside config nodes. My mods tend to give MM plenty to do.

Here's roughly what a complete config should look like:

@PART[ThisTank]
{
	// Declare height-volume keys for the number of volume options.
	// In computing we like to count from zero but it's not mandatory.
	// Declare all keys with the same value at first.
	vol0 = #$/MODULE[FSfuelSwitch]/resourceAmounts[0, ]$ // get first number in the named array
	@vol0 *= 5 // rescale from stock fuel densities. WBI and stock cargo containers need this
	
	vol1 = #$vol0$
	vol2 = #$vol0$
	vol3 = #$vol0$
	
	// Multiple the values per the height or otherwise size increments of the part
	@vol1 *= 2
	@vol2 *= 4
	@vol3 *= 8
	
	// The stock mesh switch config. Everything omitted must be fileld in manually.
	// You will need the names of the GameObjects within the model in order to populate the mesh switch.
	MODULE
	{
		name = ModulePartVariants
		...

		VARIANT
		{
			name = Short
			...
			EXTRA_INFO
			{
				packedVolumeLimit = #$/vol0$
			}
		}
		VARIANT
		{
			name = Long
			...
			EXTRA_INFO
			{
				packedVolumeLimit = #$/vol1$
			}
		}
		// more variants
	}
	
	MODULE
	{
		name = ModuleResourceVariants
	}
	
	MODULE
	{
		name = WBIOmniStorage
		storageVolume = #$/vol0$
		...
	}
}

Be sure to include the commands for deleting the Firespitter modules when everything is done.

// Remove Firespitter modules
!MODULE[FSfuelSwitch] {}
!MODULE[FStextureSwitch2],* {} // USI tanks sometimes have more than one of this module

There are other FS switch modules but I don't remember their names so do pay attention to that too.

Edited April 30 by JadeOfMaar

[KspNoobUsernameTaken]

@JadeOfMaar   

My use case is to add omnistorage/wbi convertible storage to USI parts. I don't see how this helps, because wbi parts already have convertible storage.

 

 

[JadeOfMaar]

@KspNoobUsernameTaken Pardon me. I had confused myself with IFS tanks. Your config should look something like this:

@PART[TankA*|TankB*] // these tanks, these other tanks
{
	// Declare key using first FS resource amount	
	FSvolume = #$/MODULE[FSfuelSwitch]/resourceAmounts[0, ]$ // get first number in the named array
	@FSvolume *= 5 // rescale from stock fuel densities. WBI and stock cargo containers need this
	
	// WBI module
	MODULE
	{
		name = WBIOmniStorage
		storageVolume = #$/FSvolume$ // import volume value to here
		... // other stuff
	}
	
	// Edit and remove Firespitter modules
	!MODULE[FSfuelSwitch] {}
	
	@MODULE[FStextureSwitch2],*
	{
		@useFuelSwitchModule = false
		@moduleID -= 1
	}
}

 

[KspNoobUsernameTaken]

The problem here is that each firespitter module can have a different first resource, eg, you could have lf = 10000 or oxidizer = 10000 for the first keys. What I really need is to fetch a specific resource and it's associated key. 

 

I made a mostly working patch for the same thing with B9 Part Switch, but that has a single base volume, so it's different.

[JadeOfMaar]

@KspNoobUsernameTaken I see that. Unfortunately, I'm not sure it's within MM's power to get the array position of an item based on an expected value. The closest thing I can suggest is to sort the parts based on their own naming filter like below, get the first number and then scale that number with respect to what that resource is. I personally don't see the need to fetch a specific resource (at least not in my test case here).

// USI Core's tanks
// Use ? as the placeholder for a single character at this location. 
// Using * at the end can be a bad idea as some parts may have suffixes 
// but have different roles that you don't want to catch such as 
// wanting the C3_Kontainer* which holds MetallicOre 
// but not C3_Kontainer_INV* which is inventory space.

@PART[C3_FlatRnd_??|C3_RTank_??|C3_LqdTrussTank] // holds Karborundum

@PART[C3_FlatTank_??|RadialSupPack|MountableSupPack|C3_Kontainer_??] // holds MetallicOre

@PART[RadialLqdTank|MountableLqdTank] // holds LF+OX

@PART[C3_NukeFuelTank|C3_NukeFuelTank_Lg] // holds EnrichedUranium

@PART[C3_Kontainer_INV_??] // KIS space

From what I understand, resource values are scaled like this in USI's tanks. Exceptions (such as Hydrogen and Argon) occur but can be ignored as they're never the first resource. LFO needs care as it's two numbers.

• Stock = 1x
• All CRP resources = 5x
  • Hydrogen = 50x
  • Argon = 1600x

Ultimately, I just need to get the first number (and maybe don't multiply it by 5? I leave that for you to feel it out) and I'm all set.

Edited May 4 by JadeOfMaar

[KspNoobUsernameTaken]

That would probably work, it's just that ideally a single patch would be enough. It feels a lot clunkier to make separate patches for different types of patch, and being unable to use OR in a :HAS listing makes it way worse.

The ultimate goal is to have a set of patches that converts every fuel switch to be WBI convertible storage.

 

I have some ideas with MM_PATCH_LOOP, but I need to run some experiments

 

[Lisias]

7 hours ago, KspNoobUsernameTaken said:

and being unable to use OR in a :HAS listing makes it way worse.

Did you tried the | operator inside the :HAS? It's supposed to be the OR.

[KspNoobUsernameTaken]

12 hours ago, Lisias said:

Did you tried the | operator inside the :HAS? It's supposed to be the OR.

I haven't actually tried it, but I recall the MM wiki stating it doesn't work.

On 5/5/2024 at 1:00 AM, JadeOfMaar said:

@KspNoobUsernameTaken I see that. Unfortunately, I'm not sure it's within MM's power to get the array position of an item based on an expected value. The closest thing I can suggest is to sort the parts based on their own naming filter like below, get the first number and then scale that number with respect to what that resource is. I personally don't see the need to fetch a specific resource (at least not in my test case here).

// USI Core's tanks
// Use ? as the placeholder for a single character at this location. 
// Using * at the end can be a bad idea as some parts may have suffixes 
// but have different roles that you don't want to catch such as 
// wanting the C3_Kontainer* which holds MetallicOre 
// but not C3_Kontainer_INV* which is inventory space.

@PART[C3_FlatRnd_??|C3_RTank_??|C3_LqdTrussTank] // holds Karborundum

@PART[C3_FlatTank_??|RadialSupPack|MountableSupPack|C3_Kontainer_??] // holds MetallicOre

@PART[RadialLqdTank|MountableLqdTank] // holds LF+OX

@PART[C3_NukeFuelTank|C3_NukeFuelTank_Lg] // holds EnrichedUranium

@PART[C3_Kontainer_INV_??] // KIS space

From what I understand, resource values are scaled like this in USI's tanks. Exceptions (such as Hydrogen and Argon) occur but can be ignored as they're never the first resource. LFO needs care as it's two numbers.

• Stock = 1x
• All CRP resources = 5x
  • Hydrogen = 50x
  • Argon = 1600x

Ultimately, I just need to get the first number (and maybe don't multiply it by 5? I leave that for you to feel it out) and I'm all set.

I could try @PART[]:HAS[@MODULE[FSfuelswitch]:HAS[#resourceValue,1

1. ]]

{

DO STUFF HERE 

}

 

and then the same thing for stock resources here.

[JadeOfMaar]

3 hours ago, KspNoobUsernameTaken said:

I could try

You definitely could. But I don't think that's how that works. I wish you well in minimizing how much you have to write to get the job done.

[KspNoobUsernameTaken]

1 hour ago, JadeOfMaar said:

You definitely could. But I don't think that's how that works. I wish you well in minimizing how much you have to write to get the job done.

@JadeOfMaar

I noticed FSFuelSwitch uses semicolon separated lists. How would I select the first value in such a list? MM looks for commas by default, IIRC.