Jump to content

[1.11.2] B9PartSwitch v2.18.0 (March 17)


blowfish

Recommended Posts

1 minute ago, blowfish said:

Pretty much anything you can display to the user can be localized via the usual methods.  Does that answer your question?

Sorry for wording my question vaguely. Does it support localization of the strings it provides itself? I.E. the "switch able parts" and "x subtypes"? Strings provided by mods providing configs for this mod seem to work fine, indeed.

Link to comment
Share on other sites

6 hours ago, Three_Pounds said:

Sorry for wording my question vaguely. Does it support localization of the strings it provides itself? I.E. the "switch able parts" and "x subtypes"? Strings provided by mods providing configs for this mod seem to work fine, indeed.

An yeah, those aren’t localized.  But any mod can override those strings with localized versions

Link to comment
Share on other sites

  • 2 weeks later...

B9PartSwitch v1.10.0 for KSP 1.3.1 is now available

  • Add new GUI that allows selecting subtype from a list
  • Allow switching in flight via switchInFlight parameter (uses new GUI)

More details on switchInFlight - this is a parameter on ModuleB9PartSwitch which defaults to false but can be set to true for a particular module.  If enabled, it will show the GUI button to select a new subtype (the slider is not visible in flight).  If resources are present on the part that would be removed, it warns you first.

I highly recommend that if you intend to use this, you create a unique set of subtypes for it.  They should have zero mass and cost and have the tanks empty by default.

Link to comment
Share on other sites

Hello! 

Have an issue lately after migrating to 1.3.1, updating modes and installing new ones. But it doesn't seem related to other modes afaik. Any ideas?

Output:

 
(Filename:  Line: -1)

InvalidOperationException: Cannot get volume before parent has been linked!
  at B9PartSwitch.PartSubtype.get_TotalVolume () [0x00000] in <filename unknown>:0 
  at B9PartSwitch.PartSubtype.get_TotalCost () [0x00000] in <filename unknown>:0 
  at B9PartSwitch.ModuleB9PartSwitch.GetModuleCost (Single baseCost, ModifierStagingSituation situation) [0x00000] in <filename unknown>:0 
  at Part.GetModuleCosts (Single defaultCost, ModifierStagingSituation sit) [0x00000] in <filename unknown>:0 
  at KSP.UI.Screens.Editor.PartListTooltip.Setup (.AvailablePart availablePart, .Callback`1 onPurchase, UnityEngine.RenderTexture texture) [0x00000] in <filename unknown>:0 
  at KSP.UI.Screens.Editor.PartListTooltipController.CreateTooltip (KSP.UI.Screens.Editor.PartListTooltip tooltip, KSP.UI.Screens.EditorPartIcon partIcon) [0x00000] in <filename unknown>:0 
  at KSP.UI.Screens.Editor.PartListTooltipController.OnTooltipSpawned (KSP.UI.Tooltip tooltip) [0x00000] in <filename unknown>:0 
  at KSP.UI.UIMasterController.SpawnTooltip (ITooltipController tooltipController) [0x00000] in <filename unknown>:0 
  at KSP.UI.PinnableTooltipController.OnPointerEnter (UnityEngine.EventSystems.PointerEventData eventData) [0x00000] in <filename unknown>:0 
  at UnityEngine.EventSystems.ExecuteEvents.Execute (IPointerEnterHandler handler, UnityEngine.EventSystems.BaseEventData eventData) [0x00000] in <filename unknown>:0 
  at UnityEngine.EventSystems.ExecuteEvents.Execute[IPointerEnterHandler] (UnityEngine.GameObject target, UnityEngine.EventSystems.BaseEventData eventData, UnityEngine.EventSystems.EventFunction`1 functor) [0x00000] in <filename unknown>:0 
UnityEngine.DebugLogHandler:Internal_LogException(Exception, Object)
UnityEngine.DebugLogHandler:LogException(Exception, Object)
UnityEngine.Logger:LogException(Exception, Object)
UnityEngine.Debug:LogException(Exception)
UnityEngine.EventSystems.ExecuteEvents:Execute(GameObject, BaseEventData, EventFunction`1)
UnityEngine.EventSystems.BaseInputModule:HandlePointerExitAndEnter(PointerEventData, GameObject)
UnityEngine.EventSystems.PointerInputModule:ProcessMove(PointerEventData)
UnityEngine.EventSystems.StandaloneInputModule:ProcessMouseEvent(Int32)
UnityEngine.EventSystems.StandaloneInputModule:ProcessMouseEvent()
UnityEngine.EventSystems.StandaloneInputModule:Process()
UnityEngine.EventSystems.EventSystem:Update()

.cfg

PART
{
	name = kube_test
	title = Kube Test
	author = Katten
	manufacturer = m3tech
	description = Take a moment to appreciate this elegant shape! By using advanced technologies, we have been able to construct a part whose every side is the same form as all the other sides! Remarkable, yes. But beware - if you drop it on the floor, you might not know what side is up anymore!
	MODEL
	{
		model = Kube/Parts/kube_test
	}
	rescaleFactor = 2.5
	node_stack_top 		= 0.0, 0.5, 0.0, 0.0, 1.0, 0.0, 2
	node_stack_bottom 	= 0.0, -0.5, 0.0, 0.0, -1.0, 0.0, 2
	node_stack_left 	= 0.0, 0.0, 0.5, 0.0, 0.0, 1.0, 2
	node_stack_right 	= 0.0, 0.0, -0.5, 0.0, 0.0, -1.0, 2
	node_stack_front	= -0.5, 0.0, 0.0, -1.0, 0.0, 0.0, 2
	node_stack_back 	= 0.5, 0.0, 0.0, 1.0, 0.0, 0.0, 2
	node_stack_cargotop	= 0,0.48, 0.0, 0.0, -1.0, 0.0,1
	node_stack_cargobottom = 0,-0.48, 0.0, 0.0, 1.0, 0.0,1

	mass = 0.1
	module = Part
	category = Electrical
	heatConductivity = 0.12 
	skinInternalConductionMult = 4.0
	emissiveConstant = 0.4 
	dragModelType = default
	maximum_drag = 0.2
	minimum_drag = 0.2
	angularDrag = 2
	breakingForce = 70
	breakingTorque = 70
	crashTolerance = 20
	maxTemp = 1200 
	TechRequired = start
	entryCost = 10000
	cost = 1000
	subcategory = 0
	attachRules = 1,0,1,1,0
	bulkheadProfiles = size3

	tags = 
	baseVolume = 2000
	

	MODULE
	{
		name = ModuleB9PartSwitch
		moduleID = core
		title = Core
		switcherDescription = Core
		SUBTYPE
		{
			name = Solid
			node = left
			node = right
			transform = core_solid
			transform = node_collider_solid
		}
		SUBTYPE
		{
			name = Truss
			node = cargotop
			node = cargobottom
			transform = truss_hollow
			transform = node_collider_hollow
		}
		SUBTYPE
		{
			name = Closed truss
			node = left
			node = right
			transform = truss_hollow
			transform = truss_solid
			transform = node_collider_solid
		}
		SUBTYPE
		{
			name = Tank
			node = left
			node = right
			transform = core_tank
			transform = truss_hollow
			transform = truss_solid
			transform = node_collider_solid
		}
	}

	MODULE
	{
		name = ModuleB9PartSwitch
		moduleID = tanks
		switcherDescription = Tank
		baseVolume = 1000
		
		SUBTYPE
		{
			name = None
		}
		SUBTYPE
		{
			name = LFO
			tankType = LFOX
			addedCost = 1
			addedMass = 1
			crashTolerance = 50
			transform = tank_lfo
		}		
		
		SUBTYPE
		{
			name = Liquid Fuel
			tankType = LF
			addedCost = 1
			addedMass = 1
			crashTolerance = 50
			transform = tank_lf
		}		
		
		SUBTYPE
		{
			name = Monopropellant
			tankType = MonoPropellant
			addedCost = 1
			addedMass = 1
			crashTolerance = 50
			transform = tank_monopropellant
		}
	}	
}

 

Link to comment
Share on other sites

1 hour ago, Katten said:

Hello! 

Have an issue lately after migrating to 1.3.1, updating modes and installing new ones. But it doesn't seem related to other modes afaik. Any ideas?

*snip*

Already answered this via another channel but for others' sake - this is usually the result of referencing a tank type that doesn't exist.  If that's the case there will also be a KeyNotFoundException higher up in the log.  I've opened an issue to try and handle the errors more smoothly.

Edited by blowfish
Link to comment
Share on other sites

@blowfish  not sure if you wanna consider this normal, or a minor issue... The GUI/switchInFlight buttons show up in the editor, along with the sliders... Dont know if its supposed to show both in editor...

Otherwise it all seems to work as advertised... Thanx for adding the in-flight functionality... :)

81WybIy.jpg

Edited by Stone Blue
Link to comment
Share on other sites

  • 4 weeks later...

PSA - I plan to release version 2.0 soon, which will contain a potentially breaking change.  Currently, if you specify node = xxx on a subtype, B9 Part Switch will find all nodes that contain xxx.  This has caused some issues, and I plan to change it so that it will only find nodes that exactly match xxx.  So for example node = top will currently match node_stack_top, node_stack_top01, node_stack_top02, etc, but with this change it would only match node_stack_top (the node_stack_ part is stripped out by KSP in either case).  Please let me know if there are any concerns about this.

Link to comment
Share on other sites

KSP 1.3.1, B9 Part Switch 1.10.0

Early on in the log file (line 3269) I'm getting this error:

Quote

KSP-AVC -> Version file contains errors: D:\Programs\Games\Steam\steamapps\common\KSP v1.3.1\GameData\B9PartSwitch\B9PartSwitch.version

In the next line, I'm getting the following but I don't know if they're related:

Quote

 

(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 42)

KSP-AVC -> System.InvalidCastException: Cannot cast from source type to destination type.
  at KSP_AVC.AddonInfo.ParseVersion (System.Collections.Generic.Dictionary`2 data) [0x00000] in <filename unknown>:0
  at KSP_AVC.AddonInfo.GetVersion (System.Object obj) [0x00000] in <filename unknown>:0
  at KSP_AVC.AddonInfo.ParseAvc (System.String json) [0x00000] in <filename unknown>:0
  at KSP_AVC.AddonInfo..ctor (System.String path, System.String json, RemoteType remoteType) [0x00000] in <filename unknown>:0

 

It doesn't seem to be having any negative effect (but what do I know), so this is FYI.

Link to comment
Share on other sites

5 minutes ago, Brigadier said:

KSP 1.3.1, B9 Part Switch 1.10.0

Early on in the log file (line 3269) I'm getting this error:

In the next line, I'm getting the following but I don't know if they're related:

It doesn't seem to be having any negative effect (but what do I know), so this is FYI.

Yeah, the .version file had the version numbers as strings instead of numbers.  CKAN seems to digest this fine, but apparently AVC doesn't like it.  It's already been fixed, just haven't released a new version since then.

Link to comment
Share on other sites

  • 2 weeks later...

B9 Part Switch v2.0.0 for KSP 1.3.1

Major version change as this contains a potentially breaking change (probably not though)

  • Only match on exact attach node id (this is the potentially breaking change, see below)
  • When switching in flight, resources should always start empty
  • Allow individual subtypes to not allow switching in flight via allowSwitchInFlight field
  • Allow ModuleB9PartSwitch to have its GUI hidden if it has advancedTweakablesOnly = true and advanced tweakables are disabled
  • Better error handling if resource of tank type does not exist (show error dialog in game and force the user to quit)
  • Fix .version file not being able to be parsed by KSP-AVC
  • Move remote .avc file from bintray to s3
  • Add back assembly guid (accidentally removed a while ago)

More info on only matching exact node IDs: Previously if you had node = top, that would match node_stack_top, node_stack_top01, etc.  Now it will only match node_stack_top.

Edited by blowfish
Link to comment
Share on other sites

Got a development build with working texture switch if anyone wants to play around with it:

https://s3.amazonaws.com/blowfish-ksp-b9partswitch-dev-builds/TextureSwitch/B9PartSwitch_TextureSwitch_325_v2.0.0-4-ge3bf962.zip

How to use it:

Each subtype can now have TEXTURE nodes which take the following fields:

  • texture (required) - path to the texture you want to use, e.g. MyMod/Parts/SomePart/texture
  • currentTexture (optional) - name of the current texture (just the filename excluding the extension, not the full path).  Anything that does not have this as the current texture will be ignored.
  • isNormalMap (optional, default false) - whether the texture is a normal map or not (necessary due to KSP treating normal maps differently when they are loaded)
  • shaderProperty (optional) - name of the shader property that the texture sits on.  Default is _MainTex if isNormalMap = false or _BumpMap if isNormalMap = true.  For an emissive texture you would want _Emissive
  • transform (optional, can appear more than once) - names of transforms to apply the texture switch to
  • baseTransform (optional, can appear more than once) - names of transforms where the texture switch should be applied to them and all of their children

If no transform or baseTransform values are specified, the texture switch will apply to the entire part.  All the textures will be reverted to their originals once another subtype is selected (or that subtype's textures will be switched, if it has any).

For reference, here is an example minimal setup:

SUBTYPE
{
	name = originalTexture
	title = Original Texture
{

SUBTYPE
{
	name = newTexture
	title = New Texture

	TEXTURE
	{
		texture = MyMod/SomeFolder/SomeTexture
	}
}

In this example, the "Original Texture" subtype would have the original textures, and the "New Texture" subtype would have the texture SomeTexture applied to the entire part.

Definitely looking for feedback about this, including the process of setting it up (in addition to any bugs that might show up of course).  Don't hesitate to ask if you have questions or concerns!

Edited by blowfish
Link to comment
Share on other sites

Hi,

I am trying to as b9 parts switch to a cargo pod that switches between ore and snacks.  Does anyone happen to have an example that adds fuel switching.  I think I am not populating a needed field.

I would post my try, but I am on a business trip and do not have it.

Link to comment
Share on other sites

Hiya,

I'm sure this isn't the feedback you're looking for, @blowfish, so I'll apologize in advance.
I've once more tried updating to 1.3.1.
With the last released version of B9PartSwitch, and also with that development build from that November 21 post, I keep getting the following error message:
ErrorMessage.png

This is because of one or more other mods not playing nice, of that much I am certain.
However, I cannot figure out which one it could be. I am utterly incompetent at reading the output log.
I would greatly appreciate any help in figuring out what I have to kick so as to get to the next fatal error that inevitably waits beyond this one.

Output log: https://drive.google.com/open?id=1SbNYRh47YkGpkfLZgrIc62qB50-a3Qc9
List of presently installed Addons: https://drive.google.com/open?id=1UfTnNKv7ZYYIlSN-0fOo3-IgWkQJyxJZ

Link to comment
Share on other sites

3 hours ago, DerGolgo said:

Hiya,

I'm sure this isn't the feedback you're looking for, @blowfish, so I'll apologize in advance.
I've once more tried updating to 1.3.1.
With the last released version of B9PartSwitch, and also with that development build from that November 21 post, I keep getting the following error message:
*snip*

This is because of one or more other mods not playing nice, of that much I am certain.
However, I cannot figure out which one it could be. I am utterly incompetent at reading the output log.
I would greatly appreciate any help in figuring out what I have to kick so as to get to the next fatal error that inevitably waits beyond this one.

Output log: https://drive.google.com/open?id=1SbNYRh47YkGpkfLZgrIc62qB50-a3Qc9
List of presently installed Addons: https://drive.google.com/open?id=1UfTnNKv7ZYYIlSN-0fOo3-IgWkQJyxJZ

Hey, thanks for providing the screenshot and log!  It looks very much to me like your GameData/Squad folder is corrupt - you're missing all of the stock resources (looks like this is causing some other issues as well)

Link to comment
Share on other sites

3 hours ago, blowfish said:

Hey, thanks for providing the screenshot and log!  It looks very much to me like your GameData/Squad folder is corrupt - you're missing all of the stock resources (looks like this is causing some other issues as well)

Wheeee!!
That solved it, game started right up!! THANK YOU!

Seriously, with the sheer number of Mods I use. I seriously expected it would take a few more days of finagling to get to the main menu!
In case you are still looking for feedback regarding the developmental version of the mod, here's the output log of the successful startup:
https://drive.google.com/open?id=16fOGF_gMinERL3X1KJWpZc2PHtEtdDh3

Link to comment
Share on other sites

B9PartSwitch v2.1.0 for KSP 1.3.1

  • Add texture switching
    • Each subtype can now have TEXTURE nodes which take the following fields:
      • texture (required) - path to the texture you want to use, e.g. MyMod/Parts/SomePart/texture
      • currentTexture (optional) - name of the current texture (just the filename excluding the extension, not the full path).  Anything that does not have this as the current texture will be ignored.
      • isNormalMap (optional, default false) - whether the texture is a normal map or not (necessary due to KSP treating normal maps differently when they are loaded)
      • shaderProperty (optional) - name of the shader property that the texture sits on.  Default is _MainTex if isNormalMap = false or _BumpMap if isNormalMap = true.  For an emissive texture you would want _Emissive
      • transform (optional, can appear more than once) - names of transforms to apply the texture switch to
      • baseTransform (optional, can appear more than once) - names of transforms where the texture switch should be applied to them and all of their children
    • If no transform or baseTransform is specified, it will look for textures to switch on the entire part
Edited by blowfish
Link to comment
Share on other sites

On 11/30/2017 at 3:14 PM, blowfish said:

This update seems to have caused a conflict with @Angel-125's Wild Blue Tools part switcher thingy.  Prior to this update, both B9PS and WBT co-existed peacefully, but now weird stuff is happening.  Is this something I can fix on my end or do you and/or Angel-125 need to resolve this?

Here are some examples:

This ship has fuel tanks from Angel-125's DSEV mod that were set to be LF-only to run LVN engines.  The decals on the side of the tank indicate it was set to be LF-only.  The ship was in BARIS integration when the B9PS update happened.  Upon launch after the update, the tanks had reverted back to their default configuration of having LFO, even though the decal was still showing LF-only.  The oxidizer tanks were full on launch---I dumped them manually once in orbit.

25018878568_99ba7281ef_z.jpg

 

Even weirder example:  This ship had the DSEV tanks left in their default LFO configuration (as shown by the decals).  It was also in BARIS integration when B9PS updated.  Upon launch, the oxidizer tanks were present but empty.  Despite this, the LFO-burning engines worked fine and the ship reached orbit, without using any of the LF, either.  This pic shows the tanks as they reached orbit---I have not messed with the fuel levels in them.  Bizarre...

25018878318_5c423f7023_b.jpg

Link to comment
Share on other sites

I think the problem comes from both a change in WildBlueTools and the way that B9 part switch adds its resource switcher. I'm not familiar with how B9 part switch works, but if it adds its resource switcher to all fuel tanks that have resources, then it will affect Wild Blue tanks as well (I created my own tanks in an attempt to avoid switcher conflicts, heh). Anyway, all my custom tanks use WBIConfigurableStorage part modules to switch their resources, and if the B9 MM patch could exclude parts with that module, then the conflict could be avoided.

Link to comment
Share on other sites

6 hours ago, Geschosskopf said:

This update seems to have caused a conflict with @Angel-125's Wild Blue Tools part switcher thingy.  Prior to this update, both B9PS and WBT co-existed peacefully, but now weird stuff is happening.  Is this something I can fix on my end or do you and/or Angel-125 need to resolve this?

Here are some examples:

This ship has fuel tanks from Angel-125's DSEV mod that were set to be LF-only to run LVN engines.  The decals on the side of the tank indicate it was set to be LF-only.  The ship was in BARIS integration when the B9PS update happened.  Upon launch after the update, the tanks had reverted back to their default configuration of having LFO, even though the decal was still showing LF-only.  The oxidizer tanks were full on launch---I dumped them manually once in orbit.

 

 

Even weirder example:  This ship had the DSEV tanks left in their default LFO configuration (as shown by the decals).  It was also in BARIS integration when B9PS updated.  Upon launch, the oxidizer tanks were present but empty.  Despite this, the LFO-burning engines worked fine and the ship reached orbit, without using any of the LF, either.  This pic shows the tanks as they reached orbit---I have not messed with the fuel levels in them.  Bizarre...

 

 

10 minutes ago, Angel-125 said:

I think the problem comes from both a change in WildBlueTools and the way that B9 part switch adds its resource switcher. I'm not familiar with how B9 part switch works, but if it adds its resource switcher to all fuel tanks that have resources, then it will affect Wild Blue tanks as well (I created my own tanks in an attempt to avoid switcher conflicts, heh). Anyway, all my custom tanks use WBIConfigurableStorage part modules to switch their resources, and if the B9 MM patch could exclude parts with that module, then the conflict could be avoided.

B9 Part Switch doesn't do anything to anything to any tank by default.  If there is a B9 Part Switch module on these parts, then some other mod is adding it.  Do you perhaps have CryoTanks installed?

Link to comment
Share on other sites

19 hours ago, blowfish said:

B9 Part Switch doesn't do anything to anything to any tank by default.  If there is a B9 Part Switch module on these parts, then some other mod is adding it.  Do you perhaps have CryoTanks installed?

No I do not.  BUT, that sounds like something Near Future might get involved with.  I have several of the Near Future family of mods as well as the Wild Blue ones, and recent updates of some NFT mods mentioned they included the new version of B9PS.  Hmm, so maybe NFT is doing something blanket to all tanks here, having to do with CryoTanks.

Guess we'll have to ask @Nertea about this.  And I'll look into it myself when I get home.

Link to comment
Share on other sites

Small note re: the Default Tank Types config. The Battery tank type has two extra zeroes in the unitsPerVolume entry for ElectricCharge. The tank type produces batteries that are 100(ish) times more energy dense than stock stuff per unit of volume.

B9_TANK_TYPE
{
    name = Battery
    tankMass = 0.0009
    tankCost = 15.0
    
    RESOURCE
    {
        name = ElectricCharge
        unitsPerVolume = 2000 <-- should be 20.
    }
}

Setting this to 20 would mean that an FLT-100 fuel tank converted to include batteries would have 2,000 charge - equal to two Z-1k batteries, which together are (vaguely) the same size as the FLT-100 tank.

Link to comment
Share on other sites

3 hours ago, AccidentalDisassembly said:

Small note re: the Default Tank Types config. The Battery tank type has two extra zeroes in the unitsPerVolume entry for ElectricCharge. The tank type produces batteries that are 100(ish) times more energy dense than stock stuff per unit of volume.

B9_TANK_TYPE
{
    name = Battery
    tankMass = 0.0009
    tankCost = 15.0
    
    RESOURCE
    {
        name = ElectricCharge
        unitsPerVolume = 2000 <-- should be 20.
    }
}

Setting this to 20 would mean that an FLT-100 fuel tank converted to include batteries would have 2,000 charge - equal to two Z-1k batteries, which together are (vaguely) the same size as the FLT-100 tank.

Thanks for finding that!  Would you mind reporting on Github so I remember to fix it?

Link to comment
Share on other sites

  • 1 month later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...