Electrocutor 651 Posted April 3, 2018 Share Posted April 3, 2018 (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 October 31, 2019 by Electrocutor Quote Link to post Share on other sites
Electrocutor 651 Posted April 4, 2018 Author Share Posted 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. Quote Link to post Share on other sites
sebi.zzr 294 Posted April 4, 2018 Share Posted 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. Quote Link to post Share on other sites
Psycho_zs 246 Posted April 4, 2018 Share Posted 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?) Quote Link to post Share on other sites
Electrocutor 651 Posted April 4, 2018 Author Share Posted April 4, 2018 (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 April 4, 2018 by Electrocutor Quote Link to post Share on other sites
Psycho_zs 246 Posted April 4, 2018 Share Posted 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. Quote Link to post Share on other sites
Electrocutor 651 Posted April 4, 2018 Author Share Posted 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. Quote Link to post Share on other sites
Psycho_zs 246 Posted April 4, 2018 Share Posted April 4, 2018 Is it possible to enable/disable attachment node? Quote Link to post Share on other sites
Electrocutor 651 Posted April 4, 2018 Author Share Posted 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. Quote Link to post Share on other sites
sebi.zzr 294 Posted April 4, 2018 Share Posted 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. Quote Link to post Share on other sites
Bonus Eventus 1,000 Posted April 9, 2018 Share Posted April 9, 2018 This should be stickied, at least until the modder's notes are out. Quote Link to post Share on other sites
cakepie 329 Posted April 22, 2018 Share Posted April 22, 2018 (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 April 23, 2018 by cakepie Quote Link to post Share on other sites
Electrocutor 651 Posted April 23, 2018 Author Share Posted 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. Quote Link to post Share on other sites
cakepie 329 Posted April 24, 2018 Share Posted 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. Quote Link to post Share on other sites
Electrocutor 651 Posted April 24, 2018 Author Share Posted 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. Quote Link to post Share on other sites
cakepie 329 Posted April 30, 2018 Share Posted 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. Quote Link to post Share on other sites
Electrocutor 651 Posted October 16, 2018 Author Share Posted October 16, 2018 Updated working example to reflect 1.5.0 changes. Quote Link to post Share on other sites
Electrocutor 651 Posted October 16, 2018 Author Share Posted October 16, 2018 (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 October 16, 2018 by Electrocutor Quote Link to post Share on other sites
Burning Kan 237 Posted October 16, 2018 Share Posted 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. Quote Link to post Share on other sites
Electrocutor 651 Posted October 16, 2018 Author Share Posted 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. Quote Link to post Share on other sites
Burning Kan 237 Posted October 16, 2018 Share Posted 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. Quote Link to post Share on other sites
Electrocutor 651 Posted October 19, 2018 Author Share Posted October 19, 2018 Updated guide to include cost and mass modifiers Quote Link to post Share on other sites
Electrocutor 651 Posted December 27, 2018 Author Share Posted December 27, 2018 (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 December 27, 2018 by Electrocutor Quote Link to post Share on other sites
smartdummies 12 Posted May 5, 2019 Share Posted 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? Quote Link to post Share on other sites
Electrocutor 651 Posted May 9, 2019 Author Share Posted 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. Quote Link to post Share on other sites
Recommended Posts
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.