PartVariant Guide

sumghai · May 16, 2019

Thanks for documenting this, very useful.

Based on recent correspondence with JPLRepo, parts should only have one ModulePartVariants containing definitions for all possible variants and permutations, due to the aforementioned issue regarding nodes overriding one another - in fact, no stock parts have multiple ModulePartVariants.

This is why I have instead opted to use B9PartSwitch for enabling/disabling meshes, independently of a separate ModulePartVariants for changing part textures/skins.

zer0Kerbal · May 17, 2019

is there a way to have different attachment nodes for different variants? Say like the mk2lander?

linuxgurugamer · May 18, 2019

Is there any way to change the size of the part using Variants? Nothing else to change, but to provide 2 different sizes of the same part.

If I have to use B9PartSwitch, I will, looking for the best answer. I'm trying to avoid requiring Tweakscale, and only allowing specific sizes of these parts.

Thanks in advance

Edit: Thought occurred to me, I could include the same model multiple times, with difference scale values for each. Would this work?

Edited May 18, 2019 by linuxgurugamer

Tonka Crash · May 18, 2019

23 minutes ago, linuxgurugamer said:

Is there any way to change the size of the part using Variants? Nothing else to change, but to provide 2 different sizes of the same part.

If I have to use B9PartSwitch, I will, looking for the best answer. I'm trying to avoid requiring Tweakscale, and only allowing specific sizes of these parts.

Thanks in advance

Edit: Thought occurred to me, I could include the same model multiple times, with difference scale values for each. Would this work?

Take a look at the Making History Tubes. It looks like it they could be used as a template for this.

linuxgurugamer · May 18, 2019

3 hours ago, Tonka Crash said:

Take a look at the Making History Tubes. It looks like it they could be used as a template for this.

It could, except I would have to make a new model for each size in order to give the transform name inside each one a different name. I tried it, and after learning more about the VARIANTS than I ever wanted to know, finally realized that 5 copies of the same part will all have the same transform name.

Given the number of parts I want to apply this to, I'll pass on that. Now looking into the B9PartSwitch

Electrocutor · May 24, 2019

On 5/18/2019 at 1:10 PM, linuxgurugamer said:

Is there any way to change the size of the part using Variants? Nothing else to change, but to provide 2 different sizes of the same part.

If I have to use B9PartSwitch, I will, looking for the best answer. I'm trying to avoid requiring Tweakscale, and only allowing specific sizes of these parts.

Thanks in advance

Edit: Thought occurred to me, I could include the same model multiple times, with difference scale values for each. Would this work?

Unfortunately, scale is not one of the built-in components of variants. You could still create a mod that changes scale and uses EXTRA_INFO from PartVariants to set what scale it should use, but you would still have to create that mod. Basically, PartVariants can be extended via 3rd party mods if they choose instead of having their own gui mechanism, but I've not seen any except TexturesUnlimited do this.

On 5/17/2019 at 6:42 PM, zer0Kerbal said:

is there a way to have different attachment nodes for different variants? Say like the mk2lander?

Kind of... you cannot add or remove attach nodes, but you can hide them by moving their location. So, you could for example, have a clump of optional nodes at the center of the part that get moved where you want them depending on the variant.

linuxgurugamer · May 24, 2019

Ok, thx.

wasml · June 1, 2019

@Electrocutor Have you been able to move node_attach nodes? I've made a series of truss segments of various lengths and used variants to combine them into one part in the menu (using you example - thanks) - the stack nodes work correctly but the surface attach node doesn't change. Not sure if I'm doing something wrong or if variants can't change node_attach points.

Electrocutor · June 1, 2019

11 hours ago, wasml said:

@Electrocutor Have you been able to move node_attach nodes? I've made a series of truss segments of various lengths and used variants to combine them into one part in the menu (using you example - thanks) - the stack nodes work correctly but the surface attach node doesn't change. Not sure if I'm doing something wrong or if variants can't change node_attach points.

I've not messed with surface ones; if you can fully reproduce it, be sure to add that as a bug to the ksp bugtracker (bugs.kerbalspaceprogram.com).

wasml · June 2, 2019

Added this to the bug tracker (22749) and updated a similar bug report (22073 - stack node orientation is ignored in variants)

linuxgurugamer · June 5, 2019

@Electrocutor

How can this be used if a part has multiple textures? For example:

	
	MODEL
	{
		model = RetroFuture/Command/2m1xCockpit/rectCkPit
		texture = rectCkPit_DIF, RetroFuture/Textures/rectCkPit_DIF
		texture = rectCkPit_NRM, RetroFuture/Textures/rectCkPit_NRM
		texture = rectCkPit_EMI, RetroFuture/Textures/rectCkPit_EMI
	}

I tried this, and while it didn't have any errors, and did have the variants on the PAW, changing varients didn't do anything:


	MODULE
	{
		name = ModulePartVariants
		primaryColor = #484D54
		secondaryColor = #484D54
		baseDisplayName = Retro
		baseThemeName = Retro
		VARIANT
		{
			name = Stock
			displayName = Stock
			themeName = Stock
			primaryColor = #ffffff
			secondaryColor = #dddddd
			TEXTURE
			{
				rectCkPit_DIF = RetroFuture/StockScheme/rectCkPit_DIF
				rectCkPit_NRM = RetroFuture/StockScheme/rectCkPit_NRM 
			}
		}
	}

I'm pretty sure something is off, when I look at stock parts, they all have a mainTextureURL and _BumpMap, and all of them only seemed to have a single texture for the part

Edited June 5, 2019 by linuxgurugamer

Electrocutor · June 5, 2019

11 hours ago, linuxgurugamer said:
@Electrocutor

How can this be used if a part has multiple textures? For example:
	
	MODEL
	{
		model = RetroFuture/Command/2m1xCockpit/rectCkPit
		texture = rectCkPit_DIF, RetroFuture/Textures/rectCkPit_DIF
		texture = rectCkPit_NRM, RetroFuture/Textures/rectCkPit_NRM
		texture = rectCkPit_EMI, RetroFuture/Textures/rectCkPit_EMI
	}
I tried this, and while it didn't have any errors, and did have the variants on the PAW, changing varients didn't do anything:
	MODULE
	{
		name = ModulePartVariants
		primaryColor = #484D54
		secondaryColor = #484D54
		baseDisplayName = Retro
		baseThemeName = Retro
		VARIANT
		{
			name = Stock
			displayName = Stock
			themeName = Stock
			primaryColor = #ffffff
			secondaryColor = #dddddd
			TEXTURE
			{
				rectCkPit_DIF = RetroFuture/StockScheme/rectCkPit_DIF
				rectCkPit_NRM = RetroFuture/StockScheme/rectCkPit_NRM 
			}
		}
	}
I'm pretty sure something is off, when I look at stock parts, they all have a mainTextureURL and _BumpMap, and all of them only seemed to have a single texture for the part

In the OP, notice that TEXTURE allows a materialName property. You can use the latest version of DebugStuff (https://ksp.sarbian.com/jenkins/job/DebugStuff) to see the name of the different materials on models. When setting the actual texture, you would always use _MainTex= and _BumpMap=.

mainTextureURL is another property some of the KSP shaders has in them that map to _MainTex. I looked into this once a long time ago, but cannot remember why they had it, but figured out it is the same as setting _MainTex anyway. I think it had to do with resource unloading or something that is no longer used.

Edited June 5, 2019 by Electrocutor

Jognt · June 5, 2019

I'm noticing LLG not defining a baseVariant by name nor does he have a variant defined for the baseDisplayName. Would that be a problem?

Edited June 5, 2019 by Jognt
Reworded

Electrocutor · June 5, 2019

34 minutes ago, Jognt said:

I'm noticing LLG not defining a baseVariant by name nor does he have a variant defined for the baseDisplayName. Would that be a problem?

A lot of the various properties of PartVariants can be left out during debug as they will work fine, but leave a warning in the log. Not setting a name for the base variant I believe gives it the name 'basic'. Also, if you have nothing set in your base variant, there is no need to explicitly define it.

Edited June 5, 2019 by Electrocutor

Jognt · June 5, 2019

7 minutes ago, Electrocutor said:

If you have nothing set in your base variant, there is no need to explicitly define it.

What do you mean by 'nothing set'? Since he defined a variant called Stock, wouldn't the default state (the regular definition of the part) be 'set' for the basevariant?
I thought you either had to define a baseVariant so there was an internal name for the 'regular PART' variant or that you had to define at least two VARIANTs to get switching to work. Or is the baseDisplayName already enough for the internals to work with?

Edited June 5, 2019 by Jognt

Electrocutor · June 5, 2019

7 minutes ago, Jognt said:

What do you mean by 'nothing set'? Since he defined a variant called Stock, wouldn't the default state (the regular definition of the part) be 'set' for the basevariant?

Each VARIANT you define is in addition to the base variant. Now, if you wanted the base variant to say set some value in EXTRA_INFO, then you would need to define an explicit variant for the base, and set it via baseVariant=.

For Example:

// optional battery
MODULE {
	name = ModulePartVariants
	baseVariant = Basic

	VARIANT {
		name = Basic
		cost = 100
		mass = 0.01
		EXTRA_INFO {
			Resource/ElectricCharge = none
		}
	}
	VARIANT {
		name = BatteryIncluded
		cost = 1100
		mass = 0.06
		EXTRA_INFO {
			Resource/ElectricCharge = 1000
		}
	}
}

This uses my ModulePartVariantsEx to allow EXTRA_INFO to set any other module property, but since the changes need to be removed when switching back to the original variant, I must explicitly define the base variant.

Edited June 5, 2019 by Electrocutor

Jognt · June 5, 2019

8 minutes ago, Electrocutor said:

Each VARIANT you define is in addition to the base variant. Now, if you wanted the base variant to say set some value in EXTRA_INFO, then you would need to define an explicit variant for the base, and set it via baseVariant=.

Okay, so which variable is used to reference that 'base variant'? baseVariant or baseDisplayName? Because the OP mentions that the baseDisplayName is set to Basic by default, yet does not mention the same for baseVariant.

I think what it comes down to for me is: How do baseVariant and baseDisplayname differ from eachother? I assume there's a reason they are seperate variables.

Also, I made a small personal patch that makes the 'foil' version of the MH Structural Plates lighter (10x) and tried to lower their torque/crash/impact values by a similar amount, but noticed what the OP confirmed that I can only touch cost/mass at this moment.
is there any way to add new variable interactions to partvariants? (in this case crashTolerance, breakingForce, and breakingTorque)

Edited June 5, 2019 by Jognt

Electrocutor · June 5, 2019

4 minutes ago, Jognt said:

Okay, so which variable is used to reference that 'base variant'? baseVariant or baseDisplayName? Because the OP mentions that the baseDisplayName is set to Basic by default, yet does not mention the same for baseVariant.

I think what it comes down to for me is: How do baseVariant and baseDisplayname differ from eachother? I assume there's a reason they are seperate variables.

Also, I made a small personal patch that makes the 'foil' version of the MH Structural Plates lighter (10x) and tried to lower their torque/crash/impact values by a similar amount, but noticed what the OP confirmed that I can only touch cost/mass at this moment.
is there any way to add new variable interactions to partvariants? (in this case crashTolerance, breakingForce, and breakingTorque)

baseDisplayName changes the visual name of the implicit base variant.
baseVariant sets the name of which explicit variant to use as base.

My Addon called KSPF has a component named ModulePartVariantsEx which extends the functionality of variants to set any property of any PartModule. https://github.com/Electrocutor/KSPF/wiki/ModulePartVariantsEx

Edited June 5, 2019 by Electrocutor

linuxgurugamer · June 5, 2019

57 minutes ago, Jognt said:

I'm noticing LLG not defining a baseVariant by name nor does he have a variant defined for the baseDisplayName. Would that be a problem?

I left that out because it wasn't relevant to the problem. I do have the variants defined in a different file

1 hour ago, Electrocutor said:

In the OP, notice that TEXTURE allows a materialName property. You can use the latest version of DebugStuff (https://ksp.sarbian.com/jenkins/job/DebugStuff) to see the name of the different materials on models. When setting the actual texture, you would always use _MainTex= and _BumpMap=.

mainTextureURL is another property some of the KSP shaders has in them that map to _MainTex. I looked into this once a long time ago, but cannot remember why they had it, but figured out it is the same as setting _MainTex anyway. I think it had to do with resource unloading or something that is no longer used.

Thank you

Jognt · June 5, 2019

9 minutes ago, Electrocutor said:

baseDisplayName changes the visual name of the implicit base variant.
baseVariant sets the name of which explicit variant to use as base.

My Addon called KSPF has a component named ModulePartVariantsEx which extends the functionality of variants to set any property of any PartModule. https://github.com/Electrocutor/KSPF/wiki/ModulePartVariantsEx

Clear and concise, thank you very much!

Edit: KSPF looks like a goldmine, I'm going to have a lot of fun with that!

Edited June 5, 2019 by Jognt

Electrocutor · June 5, 2019

6 minutes ago, Jognt said:

Clear and concise, thank you very much!

Edit: KSPF looks like a goldmine, I'm going to have a lot of fun with that!

After checking the code, it seems I inadvertently removed the bit to set base part values (like mass or breakingForce) while messing with other stuff. Sorry about that. Will add them back in when I get a chance.

Jognt · June 5, 2019

1 minute ago, Electrocutor said:

After checking the code, it seems I inadvertently removed the bit to set base part values (like mass or breakingForce) while messing with other stuff. Sorry about that. Will add them back in when I get a chance.

lol. Thanks for letting me know. Saved me a lot of headscratching!

Electrocutor · June 5, 2019

1 hour ago, Jognt said:

lol. Thanks for letting me know. Saved me a lot of headscratching!

There is no generic place to get/set the base part values, so I need to add them each. Which ones did you need? Just crashTolerance, breakingTorque, and breakingForce?

[Update]
Further testing has revealed that tolerances and breakings are the same as scale, rescalefactor, and many other part-level properties. Their values are read by the system before PartModules are loaded, so even if you change the value in a PartModule, the new values are not used. As yet, I have not found a way to make the game re-read these values after a PartModule loads.

I know that I can set these during PartModule's OnAwake and it works, but during OnAwake the game has not loaded the PartModule fields yet, so you don't know what to set things to.

Edited June 5, 2019 by Electrocutor

Jognt · June 5, 2019

53 minutes ago, Electrocutor said:

There is no generic place to get/set the base part values, so I need to add them each. Which ones did you need? Just crashTolerance, breakingTorque, and breakingForce?

[Update]
Further testing has revealed that tolerances and breakings are the same as scale, rescalefactor, and many other part-level properties. Their values are read by the system before PartModules are loaded, so even if you change the value in a PartModule, the new values are not used. As yet, I have not found a way to make the game re-read these values after a PartModule loads.

I know that I can set these during PartModule's OnAwake and it works, but during OnAwake the game has not loaded the PartModule fields yet, so you don't know what to set things to.

Bummer. That change is mostly just a personal preference change, so don't feel like you 'need' to make it happen. If it's not possible at this moment, I'll just drop the idea or split them into two differing parts. Thanks a lot for checking!

linuxgurugamer · June 6, 2019

On 6/5/2019 at 8:27 AM, Electrocutor said:

In the OP, notice that TEXTURE allows a materialName property. You can use the latest version of DebugStuff (https://ksp.sarbian.com/jenkins/job/DebugStuff) to see the name of the different materials on models. When setting the actual texture, you would always use _MainTex= and _BumpMap=.

~~Ok, so it seems that the material name is, in most cases, the name of the transform.~~

Given the data below, what are the materialNames? This part has three textures defined in the MODEL stanza, only one of which has a corresponding line below

	MODEL
	{
		model = RetroFuture/Command/2m1xCockpit/rectCkPit
		texture = rectCkPit_DIF, RetroFuture/Textures/rectCkPit_DIF
		texture = rectCkPit_NRM, RetroFuture/Textures/rectCkPit_NRM
		texture = rectCkPit_EMI, RetroFuture/Textures/rectCkPit_EMI
	}

I dumped the data using DebugStuff for this part:

Spoiler



[DebugStuff] +med2mPodA T:Untagged L:0 (Default)
|   Transform - med2mPodA
|   Part - med2mPodA
|   Highlighter - med2mPodA
|   ModuleScienceContainer - med2mPodA
|   ModuleCommand - med2mPodA
|   ModuleScienceExperiment - med2mPodA
|   ModuleSAS - med2mPodA
|   ModuleReactionWheel - med2mPodA
|   ModuleColorChanger - med2mPodA
|   ModuleTripLogger - med2mPodA
|   ModuleKISInventory - med2mPodA
|   ModuleKISInventory - med2mPodA
|   AudioSource - med2mPodA
|   AudioSource - med2mPodA
|   AudioSource - med2mPodA
|   Rigidbody - med2mPodA
| 
|--+model T:Untagged L:0 (Default)
|  |   Transform - model
|  | 
|  |--+RetroFuture/Command/med2mPodA/med2mPodA(Clone) T:Untagged L:0 (Default)
|  |  |   Transform - RetroFuture/Command/med2mPodA/med2mPodA(Clone)
|  |  | 
|  |   --+med2mPodA T:Untagged L:0 (Default)
|  |     |   Transform - med2mPodA
|  |     | 
|  |      --+med2mPod_Exterior T:Untagged L:0 (Default)
|  |        |   Transform - med2mPod_Exterior
|  |        |   MeshFilter - med2mPod_Exterior
|  |        |   MeshRenderer - med2mPod (Instance) - KSP/Emissive/Bumped Specular
|  |        | 
|  |        |--+Airlock T:Airlock L:21 (Part Triggers)
|  |        |  |   Transform - Airlock
|  |        |  |   CapsuleCollider - Airlock
|  |        |  | 
|  |        |   ---Ladder T:Ladder L:21 (Part Triggers)
|  |        |         Transform - Ladder
|  |        |         CapsuleCollider - Ladder
|  |        |       
|  |        |--+Airlock T:Airlock L:21 (Part Triggers)
|  |        |  |   Transform - Airlock
|  |        |  |   CapsuleCollider - Airlock
|  |        |  | 
|  |        |   ---Ladder T:Ladder L:21 (Part Triggers)
|  |        |         Transform - Ladder
|  |        |         CapsuleCollider - Ladder
|  |        |       
|  |        |--+Airlock T:Airlock L:21 (Part Triggers)
|  |        |  |   Transform - Airlock
|  |        |  |   CapsuleCollider - Airlock
|  |        |  | 
|  |        |   ---Ladder T:Ladder L:21 (Part Triggers)
|  |        |         Transform - Ladder
|  |        |         CapsuleCollider - Ladder
|  |        |       
|  |        |---bulkHead T:Untagged L:0 (Default)
|  |        |      Transform - bulkHead
|  |        |      MeshFilter - bulkHead
|  |        |      MeshRenderer - rectFuselage_EMI (Instance) - KSP/Emissive/Bumped Specular
|  |        |    
|  |        |---extWindow T:Untagged L:0 (Default)
|  |        |      Transform - extWindow
|  |        |      MeshFilter - extWindow
|  |        |      MeshRenderer - med2mPod_EMI (Instance) - KSP/Emissive/Specular
|  |        |    
|  |        |--+podEyeCover T:Untagged L:0 (Default)
|  |        |  |   Transform - podEyeCover
|  |        |  |   MeshFilter - podEyeCover
|  |        |  |   MeshRenderer - med2mPod_ALPHA (Instance) - KSP/Alpha/Translucent
|  |        |  | 
|  |        |   ---fwdLowCam T:Untagged L:0 (Default)
|  |        |         Transform - fwdLowCam
|  |        |       
|  |        |---COL_med2mPodA_collider T:Untagged L:0 (Default)
|  |        |      Transform - COL_med2mPodA_collider
|  |        |      MeshCollider - COL_med2mPodA_collider
|  |        |      MeshFilter - COL_med2mPodA_collider
|  |        |    
|  |        |---COL_med2mPodA3_collider T:Untagged L:0 (Default)
|  |        |      Transform - COL_med2mPodA3_collider
|  |        |      MeshCollider - COL_med2mPodA3_collider
|  |        |      MeshFilter - COL_med2mPodA3_collider
|  |        |    
|  |         ---COL_med2mPodWindow_collider T:Untagged L:0 (Default)
|  |               Transform - COL_med2mPodWindow_collider
|  |               MeshCollider - COL_med2mPodWindow_collider
|  |               MeshFilter - COL_med2mPodWindow_collider
|  |             
|   ---Surface Attach Collider T:Untagged L:0 (Default)
|         Transform - Surface Attach Collider
|         SphereCollider - Surface Attach Collider
|       
 ---_default T:Untagged L:0 (Default)
       Transform - _default

~~so would this be correct:~~

This is not working:

VARIANT
		{
			name = Stock
			displayName = Stock
			themeName = Stock
			primaryColor = #ffffff
			secondaryColor = #dddddd
			TEXTURE
			{
				materialName = rectCkPit_DIF
				_MainTex = RetroFuture/StockScheme/rectCkPit_DIF
			}
			TEXTURE
			{
				materialName = rectCkPit_NRM
				_MainTex = RetroFuture/StockScheme/rectCkPit_NRM 
			}
		}

Edited June 7, 2019 by linuxgurugamer

PartVariant Guide

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Join the conversation