[1.11.2] B9PartSwitch v2.18.0 (March 17)

[Bonus Eventus]

 

3 minutes ago, mbartelsm said:

Hello, is there a way to hide parts only if this mod is installed? What I want is for part A, B and C to be available in the part catalog by default, but when this mod is installed then B and C would disappear as they are now accessible as a subtype of A

I believe you would do this with module manager, right?

8 minutes ago, blowfish said:

There's no way to do this currently.  I don't think it would be hard to implement, but it would require new code.  I think there are really two features here:

• Ability to only partially fill tanks.  You are not the first person to request this, so I'm somewhat more inclined to look into this now.
• Ability to override the resource's tweakable option

In both cases I think it would be defined on the tank type.  Something like this

  Reveal hidden contents

B9_TANK_TYPE
{
	name = MyMod_LFO_Inflatable
	tankMass = 0.00005
	tankCost = 0.5
	
	RESOURCE
	{
		name = LiquidFuel
		unitsPerVolume = 0.45

		filled = 0
		tweakable = false
	}
	RESOURCE
	{
		name = Oxidizer
		unitsPerVolume = 0.55

		filled = 0
		tweakable = false
	}
}

 

(note for anyone reading this in the future, this is a prototype and not necessarily how the feature would look)

I'd definitely like to hear some feedback on how you would expect this to work, also from @komodo who also requested the ability to partially fill tanks (and anyone else who is interested in these features, of course).  Specifically, a couple of questions still remain in my mind:

• In both cases, would you prefer the setting to be per resource or per tank type?
• For partially filled/empty tanks, how would you like it to be defined.  It could be a proportion (0-1), a percentage (0-100), or the number of "units per volume" that would be filled (so if unitsPerVolume = 0.45, the range would be 0.0-0.45)?

 

For my purposes it would be nice if if followed the PartResource convention.

RESOURCE
	{
		name = LiquidFuel
		amount = 0
		maxAmount = 4000
		isTweakable = false
	}

 

Edited November 28, 2016 by Bonus Eventus

[mbartelsm]

3 hours ago, Bonus Eventus said:

I believe you would do this with module manager, right?

 

I don't know? I guess I should ask in the MM thread then

[blowfish]

1 hour ago, mbartelsm said:

Hello, is there a way to hide parts only if this mod is installed? What I want is for part A, B and C to be available in the part catalog by default, but when this mod is installed then B and C would disappear as they are now accessible as a subtype of A

ModuleManager would be the way.  Nothing specific to B9PartSwitch there.  I can provide an example when I get home if you want.

1 hour ago, Bonus Eventus said:

For my purposes it would be nice if if followed the PartResource convention.

Spoiler

RESOURCE
	{
		name = LiquidFuel
		amount = 0
		maxAmount = 4000
		isTweakable = false
	}

 

Have you taken a look at some of the existing tank definitions?  There's not really a concept of a fixed amount of a resource in B9PartSwitch - the amount that you end up with is essentially ( (base volume on the module) + (added volume on the subtype) ) * (units per volume on the tank) .  So what I'm trying to figure out is how to defined how much should be filled in relation to the units per volume.

[Bonus Eventus]

16 minutes ago, blowfish said:

ModuleManager would be the way.  Nothing specific to B9PartSwitch there.  I can provide an example when I get home if you want.

Have you taken a look at some of the existing tank definitions?  There's not really a concept of a fixed amount of a resource in B9PartSwitch - the amount that you end up with is essentially ( (base volume on the module) + (added volume on the subtype) ) * (units per volume on the tank) .  So what I'm trying to figure out is how to defined how much should be filled in relation to the units per volume.

Well, that being the case, percentages, sound good to me. Simple to think about, not much ambiguity. Although, I think more people need to weigh in besides me

[komodo]

8 hours ago, blowfish said:

I'd definitely like to hear some feedback on how you would expect this to work, also from @komodo who also requested the ability to partially fill tanks (and anyone else who is interested in these features, of course).  Specifically, a couple of questions still remain in my mind:

• In both cases, would you prefer the setting to be per resource or per tank type?
• For partially filled/empty tanks, how would you like it to be defined.  It could be a proportion (0-1), a percentage (0-100), or the number of "units per volume" that would be filled (so if unitsPerVolume = 0.45, the range would be 0.0-0.45)?

I think in my case, per tank type would be the choice here. In which case, either proportion 0-1 or percentage 0-100% would work well, although any of them could be made to work.

The use case I was after was exactly that of the Apollo service module, where the default could/should be a partial fill, but that the option exists for a full fuel load for certain mission profiles.

Staring at a part config, it would make sense to me to configure it in the SUBTYPE block, as an optional percentage in that case. I don't know how feasible that is though.

Pinging @Jsoas well, as I can't conceptualize the "number of units per volume to be filled" option, and that might turn out to be just the ticket.

Edited November 29, 2016 by komodo
forum software = bonkers

[Jso]

14 hours ago, blowfish said:

There's no way to do this currently.  I don't think it would be hard to implement, but it would require new code.  I think there are really two features here:

• Ability to only partially fill tanks.  You are not the first person to request this, so I'm somewhat more inclined to look into this now.
• Ability to override the resource's tweakable option

In both cases I think it would be defined on the tank type.  Something like this

Actually partially filling tanks does work, we were just missing the obvious. If you leave the resources from the default tank type defined in the part.cfg rather than deleting them as is customary the amount you have in there will be left alone. Apparently this is unintentional so perhaps care should be taken not to break it.

I would definitely not use a "filled = X" parameter on the tank type since I can't think of a scenario where I would want that on all tanks of a type. On second thought, ore tanks and life support waste products are generally empty by default, so maybe that would be useful.

This works for a half full tank when placed in the vab, at least initially. Once you switch types it goes to full, but I would call that expected behavior.

Spoiler

		RESOURCE
		{
			name = LiquidFuel
			amount = 90
			maxAmount = 180
		}
		RESOURCE
		{
			name = Oxidizer
			amount = 110
			maxAmount = 220
		}
		MODULE
		{
			name = ModuleB9PartSwitch
			moduleID = fuelSwitch
			switcherDescription = Fuel
			baseVolume = 400
			SUBTYPE
			{
				name = LF/O
				tankType = bdbLFOX
				addedMass = -0.25
				addedCost = -91.8
			}
			SUBTYPE
			{
				name = LH2/O
				tankType = bdbLH2O
				addedMass = -0.25
				addedCost = -91.8
			}
		}

 

 

[blowfish]

@Bonus Eventus @komodo Feel like testing out those new features?  I've got a dev build for you to try.

The new features are these:

• percentFilled can be defined on the subtype, resource, or tank type (in that order of priority, defaulting to 100%).  If set, the tanks will be (by default) filled by that amount.
• resourcesTweakable can be defined on the subtype or tank type (with that priority, defaulting to whatever the default for that resource is).  If set, it will determine whether the resource amounts can be tweaked in the editor.

https://drive.google.com/file/d/0BwOUWbxCxiu_SlVLcXJxQW95OVE/view?usp=sharing

This is a test build, so I can still change anything about how this works.  So definitely provide feedback if you have any!

[Jso]

Haven't tried to break it but percentFilled on a SUBTYPE at least works great!

This might be messy, but one more thing to cover the bases. Could we define it per resource under a subtype? An example would be a service module tank that can hold either LFO+MP or all MP. The small amount of MP in the LFO+MP tank would be percentFilled separately from the fuel:

Spoiler

@PART[whatever]:HAS[stuff]
{
	%tank_volume = #$RESOURCE[LiquidFuel]/maxAmount$
	@tank_volume += #$RESOURCE[Oxidizer]/maxAmount$
	@tank_volume += #$RESOURCE[MonoPropellant]/maxAmount$
	
	fuelPctFill = #$RESOURCE[Oxidizer]/amount$
	@fuelPctFill /= #$RESOURCE[Oxidizer]/maxAmount$
	@fuelPctFill *= 100
	
	mpPctFill = #$RESOURCE[MonoPropellant]/amount$
	@mpPctFill /= #$RESOURCE[MonoPropellant]/maxAmount$
	@mpPctFill *= 100
	
	!RESOURCE[LiquidFuel] {}
	!RESOURCE[Oxidizer] {}
	!RESOURCE[MonoPropellant] {}
	
	MODULE
	{
		name = ModuleB9PartSwitch
		moduleID = fuelSwitch
		switcherDescription = Fuel
		baseVolume = #$../tank_volume$
		SUBTYPE
		{
			name = LF/O
			tankType = SmLFO
			percentFilled = #$../../fuelPctFill$
			RESOURCE[MonoPropellant]
			{
				percentFilled = #$../../../mpPctFill$
			}
		}
		SUBTYPE
		{
			name = MonoProp
			tankType = SmMP
			percentFilled = #$../../fuelPctFill$
		}
	}
}

 

 

[blowfish]

5 hours ago, Jso said:

Could we define it per resource under a subtype? An example would be a service module tank that can hold either LFO+MP or all MP. The small amount of MP in the LFO+MP tank would be percentFilled separately from the fuel:

 

On 12/6/2016 at 0:39 AM, blowfish said:

percentFilled can be defined on the subtype, resource, or tank type (in that order of priority, defaulting to 100%).

Having different resources with different fill amounts works, I tested it.  You would define it on the tank definition though, not on the module itself.

Edited December 7, 2016 by blowfish

[Jso]

5 hours ago, blowfish said:

Having different resources with different fill amounts works, I tested it.  You would define it on the tank definition though, not on the module itself.

Got that. I'm looking to set the individual resource fill amounts at the part level, to avoid making part specific tank definitions. Right now it's (parent object added for clarity - correct me if I'm wrong) PartModule.subtype, Definition.resource, Definition.tanktype. I'm looking for PartModule.subtype.resource, PartModule.subtype, Definition.resource, Definition.tanktype.

Edited December 7, 2016 by Jso

[blowfish]

1 hour ago, Jso said:

Got that. I'm looking to set the individual resource fill amounts at the part level, to avoid making part specific tank definitions. Right now it's (parent object added for clarity - correct me if I'm wrong) PartModule.subtype, Definition.resource, Definition.tanktype. I'm looking for PartModule.resource, PartModule.subtype, Definition.resource, Definition.tanktype.

Makes sense.  I'm going to have to do a bit more coding to get this to work, but it should be doable.

[blowfish]

B9PartSwitch v1.5.3 for KSP 1.2.2 has been released!

Just wanted to get a quick recompile out before I start working on more complicated features so no other mod author is waiting.  This build also removes a debug message that was creating some spam in the logs.

[blowfish]

B9PartSwitch v1.6.0 for KSP 1.2.2 is now available

• Allow tanks to be partially filled - percentFilled can be defined on the subtype, resource, or tank type (in decreasing order of priority), defaulting to completely full
• Allow toggling resource tweakability in the editor - resourcesTweakable can be defined on the subtype or tank type (subtype takes priority), default is whatever the standard is for that resource
• Allow RESOURCE nodes directly on the subtype
  • If the resource already exists on the tank, values defined here will override what is already on the tank (won't affect other subtypes using the same tank)
  • If it isn't already on the tank, it will be added (won't affect other subtypes using the same tank)
• Add ModuleB9DisableTransform to remove unused transforms on models
• Major internal changes

 

I did a fair bit of testing on the internal changes, but it's possible something slipped through the cracks so be sure to report any possible issues if you see them!  But the changes should hopefully make adding new features much easier in the future (some of the features in this release couldn't have been done before).

@Jso I believe what you wanted to do is now possible.  Let me know if something more is needed.

[Jso]

1 hour ago, blowfish said:

@Jso I believe what you wanted to do is now possible.

It sure does. Thank you!

1 hour ago, blowfish said:

Allow RESOURCE nodes directly on the subtype

I'm going to have to play with this.

 

[blowfish]

Question: is anyone actually using the included tank types?  It seems that most modders who bundle this made their own tank types and I moved B9 off of the included ones recently because I will need to change the B9 dry/wet ratios at some point soon.  So if no one is using the included tank types I might remove them.

@Jiraiyah Also I haven't forgotten about your request, just need to think about the implementation details a bit more.  In fact, it works well with some stuff I wanted to change in B9 so expect support for this soonish.

[Jso]

On 1/25/2017 at 5:14 AM, blowfish said:

Allow RESOURCE nodes directly on the subtype

• If the resource already exists on the tank, values defined here will override what is already on the tank (won't affect other subtypes using the same tank)
• If it isn't already on the tank, it will be added (won't affect other subtypes using the same tank)

 

I don't know what you had in mind for this but it's working out really well for service modules, aka LFO+MP tanks. I can get rid of all the extra tank types and I'm not tied down to predefined proportions. I found one minor glitch though. If percentFilled is defined on the SUBTYPE, it overrides percentFilled on the RESOURCE added to the SUBTYPE.

Snippet:

Spoiler

MODULE
{
	name = ModuleB9PartSwitch
	moduleID = fuelSwitch
	switcherDescription = Fuel
	baseVolume = 1000
	SUBTYPE
	{
		name = LF/O
		tankType = bdbLFOX
		addedMass = -0.625
		addedCost = -1279
		percentFilled = 100        // When this is present...
		RESOURCE
		{
			name = MonoPropellant
			unitsPerVolume = 0.25
			percentFilled = 40    // This is overridden
		}
	}
}

 

 

 

[blowfish]

17 minutes ago, Jso said:

I don't know what you had in mind for this but it's working out really well for service modules, aka LFO+MP tanks. I can get rid of all the extra tank types and I'm not tied down to predefined proportions. I found one minor glitch though. If percentFilled is defined on the SUBTYPE, it overrides percentFilled on the RESOURCE added to the SUBTYPE.

Yeah I think this made sense when you couldn't override individual resources at the subtype level but now that you can the individual resource should probably be the first thing considered.  Should have a fix out shortly.

E: very shortly, apparently

Edited January 27, 2017 by blowfish

[blowfish]

B9PartSwitch v1.6.1 for KSP 1.2.2 has been released!

• Switch percentFilled priority to resource -> subtype -> tank type -> 100% since resources can be overridden on individual subtypes now

[blowfish]

B9PartSwitch v1.7.0 for KSP 1.2.2 has been released!

• Allow "child" part switch modules to modify volume of "parent" module
• Allow multiple modules to manage the same transform or node, only enable it if they all agree

More details on the child/parent feature:

MODULE
{
    name = ModuleB9PartSwitch
    moduleID = fuelSwitch
    baseVolume = 800
    
    SUBTYPE
    {
        name = Structural
    }
    
    SUBTYPE
    {
        name = LiquidFuel
        tankType = LF
    }
}

MODULE
{
    name = ModuleB9PartSwitch
    moduleID = meshSwitch
    parentID = fuelSwitch
    
    SUBTYPE
    {
        name = Standard
        transform = standard_mesh
    }
    
    SUBTYPE
    {
        name = Big
        transform = big_mesh
        mass = 0.2
        cost = 200
        volumeAddedToParent = 200
    }
}

Things to notice here:

• The meshSwitch module has parentID = fuelSwitch.  This identifies the other module as its parent
• The "Big" subtype on this module has a new volumeAddedToParent field.  When this subtype is selected, the parent will gain this much volume, so instead of 800 units of LiquidFuel it would have 1000

Feel free to ask questions if this isn't clear

Edited February 2, 2017 by blowfish

[blowfish]

B9PartSwitch v1.7.1 for KSP 1.2.2 has been released!

• Fix an occasional NRE when building part info.  I believe this only happened in the case that something was wrong to begin with, but it's better to clean up regardless.

[AccidentalDisassembly]

I'm attempting to write a catch-all B9 Tank Switch patch. I'm running into a problem, however - I want to be able to control which tank type is selected by default when placing a part in the editor. With the patch I've created, however, it's ALWAYS the "Structural" type that's selected when placing the part, no matter what I do to the order of SUBTYPEs within the ModuleB9PartSwitch.

However, changing the order of the SUBTYPEs does have one effect: when the Structural SUBTYPE is first in the list, the selector in the editor displays "Structural" and the selector's background (the bit that fills up with green as you cycle through subtypes) is empty.

When the Structural subtype is last in the list of SUBTYPEs, the selector still displays "Structural," but the green bar is full instead.

Am I setting up the config wrong, or is there no way to control the order of tanks, e.g. make it so that an LFO tank defaults to the LFO subtype, and LF defaults to LF, and so forth?

Here's my patch:

Spoiler

B9_TANK_TYPE
{
    name = Oxidizer
    tankMass = 0.0001
    tankCost = 0.375
    RESOURCE
    {
        name = Oxidizer
        unitsPerVolume = 1
    }
}

@PART[*]:HAS[@RESOURCE[LiquidFuel],@RESOURCE[Oxidizer],!RESOURCE[MonoPropellant],!MODULE[ModuleTankManager],!MODULE[InterstellarFuelSwitch],!MODULE[FSfuelSwitch],!MODULE[ModuleB9PartSwitch],!MODULE[ModuleEnginesFX],!MODULE[ModuleEngines]]:NEEDS[B9PartSwitch]:FOR[B9PartSwitch]
{
    %totalCap = #$RESOURCE[LiquidFuel]/maxAmount$
    @totalCap += #$RESOURCE[Oxidizer]/maxAmount$
    
    MODULE
    {
        name = ModuleB9PartSwitch
        moduleID = fuelSwitch
        switcherDescription = Tank Type
        baseVolume = #$../totalCap$

        SUBTYPE
        {
            name = LFO
            tankType = LFO
        }
        SUBTYPE
        {
            name = LiquidFuel
            tankType = LiquidFuel
        }
        SUBTYPE
        {
            name = Oxidizer
            tankType = Oxidizer
        }
        SUBTYPE
        {
            name = MonoProp
            tankType = MonoPropellant
        }
        SUBTYPE
        {
            name = Structural
            tankType = Structural
        }            
    }
    !RESOURCE[LiquidFuel] {}
    !RESOURCE[Oxidizer] {}
}

 

[blowfish]

@AccidentalDisassembly I think your best bet is to add the resources on that particular subtype to the part.

This may seem like odd behavior, but it turns out that this is actually a "feature" working correctly.  Basically if there is no subtype set B9PartSwitch will automatically try to find the correct subtype based on the part's resources.  I built this mainly to support converting from other switchers or none to B9PartSwitch without breaking any craft.  I will have to think about how to handle this in a way that makes it easier to specify a default subtype.

[Jso]

17 hours ago, blowfish said:

@AccidentalDisassembly I think your best bet is to add the resources on that particular subtype to the part.

This may seem like odd behavior, but it turns out that this is actually a "feature" working correctly.  Basically if there is no subtype set B9PartSwitch will automatically try to find the correct subtype based on the part's resources.  I built this mainly to support converting from other switchers or none to B9PartSwitch without breaking any craft.  I will have to think about how to handle this in a way that makes it easier to specify a default subtype.

I would use a default = Subtype Name parameter.

[AccidentalDisassembly]

17 hours ago, blowfish said:

@AccidentalDisassembly I think your best bet is to add the resources on that particular subtype to the part.

This may seem like odd behavior, but it turns out that this is actually a "feature" working correctly.  Basically if there is no subtype set B9PartSwitch will automatically try to find the correct subtype based on the part's resources.  I built this mainly to support converting from other switchers or none to B9PartSwitch without breaking any craft.  I will have to think about how to handle this in a way that makes it easier to specify a default subtype.

Huh, ok - so if I simply don't remove the original resources from the tank (don't remove LF from one of the Stock LF tanks, for example), it won't duplicate resources? E.g. have a tank of LF, then also an equal-volume switchable B9Tank?

[blowfish]

40 minutes ago, Jso said:

I would use a default = Subtype Name parameter.

Sure, specifying a default is easy, the question is how to decide when to use this and when to try to determine the subtype automatically based on resources.  One option would be to always use the default if it is specified, but that would effectively break the feature for anything having a default.  Another option would be to only use it if there are no resources currently on the part.

18 minutes ago, AccidentalDisassembly said:

Huh, ok - so if I simply don't remove the original resources from the tank (don't remove LF from one of the Stock LF tanks, for example), it won't duplicate resources? E.g. have a tank of LF, then also an equal-volume switchable B9Tank?

Yup.  It will detect that the resources are there already and use them rather than creating new ones.  You don't even have to match up the amounts, but if you didn't then you might end up with partially filled tanks and it would display the wrong amounts to the user in the part info window.