PartVariant Guide

Electrocutor · April 3, 2018

Guide:

// optional: In Advanced mode in the VAB/SPH, themes change the default theme of all available parts, and allow you to apply the theme en masse to the current craft
VARIANTTHEME
{
	// required: name of theme
	name = <theme name>

	// required: name of theme as displayed in GUI, can be constant or a #localized reference
	displayName = <localized name>

	// optional: description of theme, can be constant or a #localized reference
	description = <localized description>

	// required: colors to use in GUI, alpha not supported
	primaryColor = #rrggbb
	secondaryColor = #rrggbb
}

// all <path>'s should not include extension (f.e. MyMod/MyModel.mu would be MyMod/MyModel, MyMod/MyTexture_d.dds would be MyMod/MyTexture_d)
PART {
	// all possible variant models must be added
	MODEL {
		model = <variant model>
	}

	// multiple ModulePartVariants allowed; lower variants will override node settings from previous ones if they are the same; for example you cannot change TEXTURE.shader in one and TEXTURE._Color in another, but can change GAMEOBJECTS.transform in one and TEXTURE._Color in another. JPLRepo has stated that while it is possible to have multiple ModulePartVariants, it is not recommended or intended.
	MODULE {
		name = ModulePartVariants

		// optional: name of VARIANT to use as default
		baseVariant = <variant name>

		// optional: name of default variant to display in GUI, can be constant or a #localized reference
		// default is 'Basic', only use if not specified a baseVariant
		baseDisplayName = <localized name>

		// optional: theme to which the default variant belongs
		baseThemeName = <theme name>
      
		// optional: whether to create multiple procedural drag cubes
		// default is true
		useMultipleDragCubes = <true/false>

		VARIANT {
			// required: default variant name is Basic, must be unique per part
			name = <variant name>

			// required: name of variant to display in GUI, can be constant or a #localized reference
			displayName = <localized name>

			// optional: name of theme to which this variant belongs; variants may only belong to one
			themeName = <theme name>

			// required: colors to use in right-click GUI, alpha not supported
			primaryColor = #rrggbb
			secondaryColor = #rrggbb

			// optional: allows grouping of like-variants. mostly used to disallow changing a variant to a non-like group while parts attached to surface.
			// GroupA, GroupB, GroupC
			sizeGroup = <group name>

			// optional: may be negative
			cost = <additional cost>
			mass = <additional mass>
      
			// optional: lists should be comma-delimited (but I haven't tested)
			disabledAnimations = <list of animations>
			disabledEvents = <list of module events> // format: <module name>.<event name>

			// optional: only one GAMEOBJECTS node per VARIANT
			GAMEOBJECTS {
				// set which transforms are visible/hidden
				<transform name> = <true/false>
			}

			// optional: arbitrary key,value pairs for use in PartModules/mods
			EXTRA_INFO {
				<info name> = <info value>

				// Known Examples (ModuleProceduralFairing)
				FairingsTextureURL = <path to _d>
				FairingsNormalURL = <path to _n>
			}

			// optional: only one NODES node per VARIANT, assumes scale=1.0, rescaleFactor=1.0
			NODES {
				// all optional: node adjustments per variant
				node_attach = x, y, z, angx, angy, angz, size
				node_stack_top = x, y, z, angx, angy, angz, size
				node_stack_bottom = x, y, z, angx, angy, angz, size
				node_stack_bottomXX = x, y, z, angx, angy, angz, size
				node_stack_connectXX = x, y, z, angx, angy, angz, size
			}

			// optional: multiple TEXTURE nodes allowed (for different materialName)
			TEXTURE {
				// optional: used to restrict this TEXTURE change to the named material within this part, otherwise all materials in this part
				// material names are usually the same as the mesh name to which they belong, but not always
                // note that this parameter automatically includes wildcards, so MyMat and MyMat2 would both change if set to MyMat; this can be worked around by adding an additional TEXTURE
				materialName = <name of material>

				// optional: change the existing material shader, only able to find built-in KSP shaders
				// shader short-list:
				// KSP/Alpha/Cutoff
				// KSP/Alpha/Cutoff Bumped
				// KSP/Alpha/Translucent
				// KSP/Alpha/Translucent Additive
				// KSP/Alpha/Translucent Specular
				// KSP/Alpha/Unlit Transparent
				// KSP/Bumped
				// KSP/Bumped Specular
				// KSP/Bumped Specular (Mapped)
				// KSP/Diffuse
				// KSP/Emissive/Bumped Specular
				// KSP/Emissive/Bumped Specular (Mapped)
				// KSP/Emissive/Diffuse
				// KSP/Emissive/Specular
				// KSP/Specular
				// KSP/Specular (Transparent)
				shader = <shader>

				<texture property> = <path>
				<color property> = #rrggbb // alpha not supported
				<float property> = 0.0

				// Known Examples
				_MainTex = <path to _d>
				_BumpMap = <path to _n>
				_Color = #rrggbb
				_SpecColor = #rrggbb
				_SpecMap = <path to _s>
				_Shininess = 1.0
				_EmissiveColor = #rrggbb
				_Emissive = <path to _e>
				_Opacity = 1.0
				_RimFalloff = 0.0
				_RimColor = #rrggbb
				_TemperatureColor = #rrggbb
				_BurnColor = #rrggbb
				_AmbientMultiplier = 0.2
			}
		}
	}
}

*Note: The two (Mapped) shaders are the quasi-pbr shaders available in newer versions of KSP.

*Note: If you have multiple models on the same part, and show or hide them for variants, keep in mind that any stock PartModules that affect the visibility of transforms will only apply to the first transform of the given name. For example, if you have two engine models, and both have a fairing mesh named 'fairing', then ModuleJettison will only show or hide the first one it finds. ModuleJettison supports multiple transform names though, so if you named the fairing on model2 as fairing2, then it would work fine so long as you specified both transforms within ModuleJettison.

*Note: @linuxgurugamer figured out some specifics of how the cost property affects the overall part cost here.

Edited October 31, 2019 by Electrocutor

Electrocutor · April 4, 2018

If anyone can figure out what use there is in themes and sizegroups, please let me know and I'll update it.

sebi.zzr · April 4, 2018

From KSP-API:The sizegroup of this variant, they are used to filter out other variants that don't match in dimensions and there are things surface attached.

Psycho_zs · April 4, 2018

Variants can be associated with common themes. A theme can then be selected in VAB's advanced categories and applied to all parts that have variants marked with such theme.

Also, multiple ModulePartVariants instances per part give multiple selectors (or has something changed in 1.4.2?)

Electrocutor · April 4, 2018

1 hour ago, Psycho_zs said:

Variants can be associated with common themes. A theme can then be selected in VAB's advanced categories and applied to all parts that have variants marked with such theme.

Also, multiple ModulePartVariants instances per part give multiple selectors (or has something changed in 1.4.2?)

I know you can add more than one, but it's been my experience that after you launch, it will only use the lowest one in the list. I'll do a more controlled test to verify that this is true and not just some other factors that affected my result.

[Edit]
Confirmed that multiple PartModules can stack, merely you need to be aware of which properties are being overridden.

[Edit]
After testing, themes do not apply to any parts of your craft. Instead it changes the baseTheme of all parts so that they default to that theme when added to the craft.

6 hours ago, sebi.zzr said:

From KSP-API:The sizegroup of this variant, they are used to filter out other variants that don't match in dimensions and there are things surface attached.

I do not see this behavior on any of the stock parts with sizeGroup specified or if I add it myself. Do you know the specifics of how to make this do something?

Edited April 4, 2018 by Electrocutor

Psycho_zs · April 4, 2018

25 minutes ago, Electrocutor said:

After some testing, I see the list of VariantThemes in advanced mode, but click them does not change anything. Can you confirm?

To apply a theme you have to click on a tiny icon inside a theme item.

Electrocutor · April 4, 2018

1 minute ago, Psycho_zs said:

To apply a theme you have to click on a tiny icon inside a theme item.

Thank you.

Psycho_zs · April 4, 2018

Is it possible to enable/disable attachment node?

Electrocutor · April 4, 2018

53 minutes ago, Psycho_zs said:

Is it possible to enable/disable attachment node?

Not that I or blowfish have found. If you can find a way, let me know. The fact that the Engine Plates have their own additional PartModule for adding/removing nodes makes me think that it isn't possible.

sebi.zzr · April 4, 2018

1 hour ago, Electrocutor said:

I do not see this behavior on any of the stock parts with sizeGroup specified or if I add it myself. Do you know the specifics of how to make this do something?

Because of lack of documentation this is merely a guess.
All the engines in making history expansion have "sizeGroup",it could be related to calculating of drag cubes?And since the author of all the parts is @RoverDude i suspect he is also involved in code itself.I was hoping we would get explanation on "variants" in "moders notes",like it was for "upgrades",but apparently we're out of luck.

Bonus Eventus · April 9, 2018

This should be stickied, at least until the modder's notes are out.

cakepie · April 22, 2018

I've been trying to wrangle the structural tubes as part of figuring things out, and running into various issues.

1. This works, but things will start getting ridiculous once you go on to add many more colors.

@PART[Tube4] {
	@MODULE[ModulePartVariants] {
		+VARIANT,* {
			%name = #$name$ (black)
			%displayName = #$displayName$ (black)

			%primaryColor = #2d2e2d
			%secondaryColor = #2d2e2d

			%TEXTURE {
				%_Color = #2d2e2d
			}
		}
	}
}

2. This wouldn't work because the last (lowest in PAW) ModulePartVariant will always be the one that takes effect after a save/load

@PART[Tube3] {
	@MODULE[ModulePartVariants],0 {
		%tag = original
	}
	+MODULE[ModulePartVariants]:HAS[#tag[original]] {
		%tag = black
		@baseVariant = #$baseVariant$-black
		@VARIANT,* {
			%name = #$name$-black
			%displayName = #$displayName$-black

			%primaryColor = #2d2e2d
			%secondaryColor = #2d2e2d

			%TEXTURE {
				%_Color = #2d2e2d
			}
		}
	}
}

3. I had high hopes for this one, but no joy.

@PART[Tube2] {
	@MODULE[ModulePartVariants] {
		tag = model
		@VARIANT,* {
			!TEXTURE
		}
	}
	MODULE {
		name = ModulePartVariants
		tag = color
		@VARIANT[Basic] {
			!GAMEOBJECTS
			!NODES
		}
		VARIANT {
			name = KSP_Black
			displayName = Black

			primaryColor = #2d2e2d
			secondaryColor = #2d2e2d

			TEXTURE {
				_Color = #2d2e2d
			}
		}
	}
}

Any better ideas?

- - -

Edit: basically, trying to figure out how to get the bolded below to work in the context of MM patching

On 4/4/2018 at 2:55 AM, Electrocutor said:

// multiple ModulePartVariants allowed; lower variants will override node settings from previous ones if they are the same; for example you cannot change TEXTURE.shader in one and TEXTURE._Color in another, but can change GAMEOBJECTS.transform in one and TEXTURE._Color in another.

Edited April 23, 2018 by cakepie

Electrocutor · April 23, 2018

15 hours ago, cakepie said:

I've been trying to wrangle the structural tubes as part of figuring things out, and running into various issues.

1. This works, but things will start getting ridiculous once you go on to add many more colors.

2. This wouldn't work because the last (lowest in PAW) ModulePartVariant will always be the one that takes effect after a save/load

3. I had high hopes for this one, but no joy.

Any better ideas?- - -

Edit: basically, trying to figure out how to get the bolded below to work in the context of MM patching

The caveat with having 2 ModulePartVariants is that you'll make yourself unable to be compatible with other mods.

MODULE {
	name = ModulePartVariants

	VARIANT {
		name = Model1

		GAMEOBJECTS {
			transform1 = true
			transform2 = false
		}
	}
	VARIANT {
		name = Model2

		GAMEOBJECTS {
			transform1 = false
			transform2 = true
		}
	}
}
MODULE {
	name = ModulePartVariants

	VARIANT {
		name = Tex1

		TEXTURE {
			materialName = Model1Mat
			_MainTex = path1
		}
		TEXTURE {
			materialName = Model2Mat
			_MainTex = path2
		}
	}
	VARIANT {
		name = Tex2

		TEXTURE {
			materialName = Model1Mat
			_MainTex = path3
		}
		TEXTURE {
			materialName = Model2Mat
			_MainTex = path4
		}
	}
}

I'm trying to figure out why you are attempting to use MM value lookups; are you trying to add color tints to pre-existing variants that were made from another mod?

If so, then you would either have to use option1, or else standardize that every part would have 2 ModulePartVariants and index0 is always model-only and index1 is always texture only.

cakepie · April 24, 2018

14 hours ago, Electrocutor said:

I'm trying to figure out why you are attempting to use MM value lookups; are you trying to add color tints to pre-existing variants that were made from another mod?

That's one of the use case here -- I'm trying to see if we can patch texture variants (color and/or texture map) onto pre-existing model varants, whether that be from another mod, or already specified in the original part cfg.

I'm basically exploring the space of what's possible vs impossible in the space of different mods being able to interoperate.

14 hours ago, Electrocutor said:

standardize that every part would have 2 ModulePartVariants and index0 is always model-only and index1 is always texture only.

That's something that we could try to achieve community consensus.
However, option3 didn't seem to work, so I'm wondering if a) I didn't do that correctly, or b) even with such standardization, it's not guaranteed to work.

Electrocutor · April 24, 2018

9 hours ago, cakepie said:

That's something that we could try to achieve community consensus.
However, option3 didn't seem to work, so I'm wondering if a) I didn't do that correctly, or b) even with such standardization, it's not guaranteed to work.

Well, some stock variants change both model and texture. It is better to have a single module, but as you stated above, this leads to a quickly out of control number of permutations if you want to tint across all possible texture and model variants.

cakepie · April 30, 2018

On 4/24/2018 at 8:56 PM, Electrocutor said:

Well, some stock variants change both model and texture.

True that, but structural tubes appears to only change model, so I was a bit puzzled that I wasn't able to create a separate module to handle texture/color changes.

All in all it's a an ongoing process finding the limits of what can be done with part variants, and where the bugs / gotchas are.

Electrocutor · October 16, 2018

Updated working example to reflect 1.5.0 changes.

Electrocutor · October 16, 2018

Here is an example to create a new variant based on the new shiny shader:
(please note that the shiny shader has a bug in 1.5.0 that only lets it work inside the VAB/SPH and not while in flight)

@PART[mk1pod_v2] {
	@MODULE[ModulePartVariants] {
		+VARIANT[White] {
			@name = Shiny
			@displayName = Shiny
			@themeName = Shiny
			@TEXTURE {
				%materialName = Mk1_Dark
				%shader = KSP/Bumped Specular (Mapped)
				%_SpecMap = Squad/Parts/Command/mk1pod_v2/Mk1_v2_W
			}
		}
	}
}

Edited October 16, 2018 by Electrocutor

Burning Kan · October 16, 2018

27 minutes ago, Electrocutor said:

(please note that the shiny shader has a bug in 1.5.0 that only lets it work inside the VAB/SPH and not while in flight)

is this bug adressed by squad?. otherwise i dont see the sens in useing it only in VAB.

btw thx for the fast update.

Electrocutor · October 16, 2018

Just now, Burning Kan said:

is this bug adressed by squad?. otherwise i dont see the sens in useing it only in VAB.

btw thx for the fast update.

Well, 1.5 was only released yesterday and TakeTwo doesn't usually say what they are working on especially. They have http://bugs.kerbalspaceprogram.com , but I've not logged into it for a while.

I should certainly hope it is something they will fix because they are using that shader for things like the rover, foil plates, and stay-put-nik.

Burning Kan · October 16, 2018

1 minute ago, Electrocutor said:

something they will fix because they are using that shader for things like the rover, foil plates, and stay-put-nik

make sens,lets hope for. thanks for the fast answer and this helpful thread.

Electrocutor · October 19, 2018

Updated guide to include cost and mass modifiers

Electrocutor · December 27, 2018

New in 1.6:

VARIANT -> disabledAnimations = comma? delimited list of animations to disable for a given variant
VARIANT -> disabledEvents = <module name>.<event name> (should also be comma? delimited)

I'll add these to the OP once I figure out exactly how they work.

Edited December 27, 2018 by Electrocutor

smartdummies · May 5, 2019

On 4/3/2018 at 2:55 PM, Electrocutor said:

// optional: arbitrary key,value pairs for use in PartModules/mods EXTRA_INFO { <info name> = <info value> // Known Examples (ModuleProceduralFairing) FairingsTextureURL = <path to _d> FairingsNormalURL = <path to _n> }

In you r example, how do you specify that FairingsTextureURL and FairingsNormalURL are to be applied to ModuleProcedurealFairings?

Electrocutor · May 9, 2019

On 5/5/2019 at 10:22 AM, smartdummies said:

In you r example, how do you specify that FairingsTextureURL and FairingsNormalURL are to be applied to ModuleProcedurealFairings?

You don't have to specify anything else; that module looks for the specific variable names and uses the values.

PartVariant Guide

Recommended Posts

Electrocutor 651

Link to post

Share on other sites

Electrocutor 651

Link to post

Share on other sites

sebi.zzr 294

Link to post

Share on other sites

Psycho_zs 246

Link to post

Share on other sites

Electrocutor 651

Link to post

Share on other sites

Psycho_zs 246

Link to post

Share on other sites

Electrocutor 651

Link to post

Share on other sites

Psycho_zs 246

Link to post

Share on other sites

Electrocutor 651

Link to post

Share on other sites

sebi.zzr 294

Link to post

Share on other sites

Bonus Eventus 1,000

Link to post

Share on other sites

cakepie 329

Link to post

Share on other sites

Electrocutor 651

Link to post

Share on other sites

cakepie 329

Link to post

Share on other sites

Electrocutor 651

Link to post

Share on other sites

cakepie 329

Link to post

Share on other sites

Electrocutor 651

Link to post

Share on other sites

Electrocutor 651

Link to post

Share on other sites

Burning Kan 237

Link to post

Share on other sites

Electrocutor 651

Link to post

Share on other sites

Burning Kan 237

Link to post

Share on other sites

Electrocutor 651

Link to post

Share on other sites

Electrocutor 651

Link to post

Share on other sites

smartdummies 12

Link to post

Share on other sites

Electrocutor 651

Link to post

Share on other sites

Join the conversation