Jump to content

PartVariant Guide

Electrocutor
 Share

Recommended Posts

Electrocutor

Electrocutor

Posted
Posted (edited)

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 by Electrocutor
Link to comment
Share on other sites
Psycho_zs

Psycho_zs

Posted
Posted

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?)

Link to comment
Share on other sites
Electrocutor

Electrocutor

Posted
  • Author
Posted (edited)
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 by Electrocutor
Link to comment
Share on other sites
Psycho_zs

Psycho_zs

Posted
Posted
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.

Link to comment
Share on other sites
Electrocutor

Electrocutor

Posted
  • Author
Posted
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.

Link to comment
Share on other sites
sebi.zzr

sebi.zzr

Posted
Posted
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.

Link to comment
Share on other sites
  • 2 weeks later...
cakepie

cakepie

Posted
Posted (edited)

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 by cakepie
Link to comment
Share on other sites
Electrocutor

Electrocutor

Posted
  • Author
Posted
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.

Link to comment
Share on other sites
cakepie

cakepie

Posted
Posted
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.

 

Link to comment
Share on other sites
Electrocutor

Electrocutor

Posted
  • Author
Posted
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.

Link to comment
Share on other sites
cakepie

cakepie

Posted
Posted
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.

Link to comment
Share on other sites
  • 5 months later...
Electrocutor

Electrocutor

Posted
  • Author
Posted (edited)

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 by Electrocutor
Link to comment
Share on other sites
Electrocutor

Electrocutor

Posted
  • Author
Posted
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.

Link to comment
Share on other sites
  • 2 months later...
Electrocutor

Electrocutor

Posted
  • Author
Posted (edited)

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 by Electrocutor
Link to comment
Share on other sites
  • 4 months later...
smartdummies

smartdummies

Posted
Posted
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?

Link to comment
Share on other sites
Electrocutor

Electrocutor

Posted
  • Author
Posted
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.

Link to comment
Share on other sites
This thread is quite old. Please consider starting a new thread rather than reviving this one.

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.

×
 Share
Go to topic listing
×
×
  • Create New...