Discussion: community curated variant themes

[cakepie]

I'd like to gauge if there is interest in creating a community curated list of VARIANTTHEMEs, which would serve a function similar to Community Tech Tree, Comm. Resource Pack, Comm. Category Kit.

The aims would be to prevent redundancy, avoid name collisions, ensure that different mods play well together, and present an overall consistent, well-organized categorization of modded variant themes to players, to achieve a better user experience.

 

What are variant themes?

With 1.4+ KSP has gained texture switching as part of the stock game, and the new VARIANTTHEME config node to go with that. Variant themes serve to group together the part variants of different parts, that have the same design theme (i.e. "look-and-feel"). This makes it convenient and user friendly for players to switch multiple parts at the same time, to achieve a particular look-and-feel for the craft they are building. With one click in the "Variant Themes" tab in advanced mode in the editor, the player can apply a theme to all applicable parts on the craft currently being edited, or to set that theme as the default for applicable parts when picked out from in the part palette -- rather than have to adjust each part one by one.

These are variant themes. They can be accessed in advanced mode in the editor.
The variant themes that are built-into stock KSP are defined in GameData/Squad/Parts/VariantThemes.cfg

As an example: these panel parts from the Making History expansion each have three part variants.
The part variants are defined in ModulePartVariants of the respective part's cfg files.

Using the part action window in the editor, you can switch a part between its variants, but doing it this way only works for one individual part at a time.

But each of the available part variants are also associated with a variant theme -- this is themeName or baseThemeName value in ModulePartVariants in the part cfg.

Being associated with variant themes allows you to click on these icons:

And it will "apply" the selected theme -- all the parts on the craft that have such a variant will be switched to that variant.

It is optional to associate a part variant with a variant theme. But doing so is useful and user friendly when multiple parts have variants of the same "theme" (hence the name).

 

Why should I care?

If you reskin existing parts from stock or other mods.
e.g. Back In Black

You would obviously like to have a VARIANTTHEME that corresponds to the look-and-feel that you are creating in your mod. So, you set that up. Great!
But wait, you're not done yet! What about the original look of the parts that you have modified?

When you added your version, a "base" part variant was also automatically created for the original version of the part.
You could just leave that as-is , but then the player won't have an easy way to revert multiple parts en masse to their original design.

Okay, so let's create a VARIANTTHEME for that... what should it be called? Reasonable choices might include: "stock", "default", "original", etc.
If different mods use different names/themes for the same purpose, it could result in a clutter of redundant themes in the UI, messy and potentially confusing.
We should standardize.

Furthermore, due to a technical limitation of Module Manager we cannot use a clever MM patch that will "add the 'default'  VARIANTTHEME if it doesn't already exist".
So, for multiple mods to be able to use the same "default" VARIANTTHEME for resetting parts to the original version, we need that to be defined in a community standardized config that gets included by the various mods as a dependency.

Additionally, from a technical standpoint, how to ensure that your mod plays well with other mods? In particular, what if someone else also makes a reskin mod that touches the same parts?
How can we prevent "Back In Black" and "Racy Red" from stomping on one another's MM patches? We should explore and develop best practices for how to do this.
Electrocutor's guide is a good starting point.

 

If you make (a) part(s) that have different textures to choose from.
e.g. Hawkspeed Airstairs

You might have different textures that are designed to fit in with stock parts, or various other mods.
What should you name the different variants?

For starters, do we say "stockalike", "stock-alike", or "stock-like"?
Standardizing on a common set of VARIANTTHEMEs would avoid redundancy and confusion.

Even if your mod has just one part -- since you don't have a natural "collection" of multiple parts to group together, it might seem pointless to set up your part config to use themes.
But that's not true -- it is useful to be part of a standard set of themes, that groups different parts from different mods together if they offer the same "look" -- it enables easy texture switching by the player.

And when it comes to textures for matching with other mods, there are further considerations. Consider my airstair part -- in addition to stockalike option, it comes with an alternate texture that matches the unique look of Firespitter bomber parts. Those parts aren't shipped with any variants, so okay, I go ahead and label my texture "Firespitter". ... but what if a reskin mod comes along and adds a new variant on top of the original Firespitter parts? They can call their new variant whatever they want, but if they file the original Firespitter look under "default", then we have one theme (the "look") split into two different themes (VARIANTTHEME) -- a player would have to pick "default" to reset the Firespitter parts back from the reskinned version, whereas for the airstair it is the "Firespitter" option. Not very intuitive.

 

If you make parts that don't have alternative textures, but come "in a set"
-- stockalike, or your own unique design.

You might think this is none of your business, but hang on.
If other modders create additional textures to reskin your parts, wouldn't you like to have a say over what the original look of your parts should be filed under?

For instance, stockalike mods (e.g. Airplane Plus) may prefer to be grouped with other mods' parts under "stockalike" rather than a meaningless, generic "default".

Whereas in the case of a mod whose parts have a unique aesthetic (e.g. keptin's original KAX textures) it may be appropriate to specify its own VARIANTTHEME.
Although the mod itself doesn't ship with any variants, and thus doesn't initially have any use for the theme, it provides:
a) a target theme for other mods to group their "compatible" variants under, and
b) if someone else makes a reskin, then the original look can be placed under this theme, along with those from (a).

 

- * - * - * -

To kick things off, pinging a few people that this might be relevant or interesting to (based on threads/conversations I've seen elsewhere in the forum)
@Electrocutor  @XLjedi  @Rodger

 

Please discuss, etc etc.

Edited May 4, 2018 by cakepie
add more explanatory content

[Electrocutor]

You can refer to my PartVariant Guide for an example in the OP that shows what is needed for VARIANT to not step on each other.

As for naming of VARIANT's to not step on each other, perhaps something like author_name would make sense because each author would be sure to not use names that conflicted with their own patches.

VARIANTTHEME is trickier due to limitations of ModuleManager. The only viable solution I can think would be to adopt a standardized theme set such as has been done for CommunityResourcePack.

For what to call the default variant, the game automatically uses the name "Basic", but parts that use variants in stock usually use a color scheme name instead.

[XLjedi]

I've been calling the default colors "Default" and I'll probably use the "XL" prequalifier on my theme names to avoid mis-steps.  I might hold off on pushing too far into it until they fix the bug that causes parts with flags to break.  You've probably already seen my relatively simple Mod Manager script for only adding the ModPartVar node if needed.

 

Edited April 22, 2018 by XLjedi

[DoctorDavinci]

So you mean something like the Paintshop in DCK? ... already done

Video is from an early version ... somewhere around 20 part mods are supported now and the textures all work nicely with each other ... also almost all of the stock parts are covered

Edited April 22, 2018 by DoctorDavinci

[cakepie]

10 minutes ago, DoctorDavinci said:

So you mean something like the Paintshop in DCK? ... already done

No. We are talking about new features in stock KSP 1.4+ and how best for modders to coordinate with one another when using these new features, so that different mods play nicely together.

I am well aware that there are preexisting mods for switching part textures or repainting parts/craft -- but that's not what is being discussed here.

[XLjedi]

@DoctorDavinci  That mod just swaps out the individual part texture files correct?  If I can scrap the textures it comes with and load my own, I might have to check that one out.    

[DoctorDavinci]

14 minutes ago, XLjedi said:

@DoctorDavinci  That mod just swaps out the individual part texture files correct?  If I can scrap the textures it comes with and load my own, I might have to check that one out.    

This is totally possible .... look in the DCKinc/Camo directory and go from there ... you could change the textures with your own although it might take a bit of playing around to get them to look right

Take a look at DCK and if you want to take a shot at it PM me and I'll do what I can to help ... it really wouldn't be all that hard, just take a bit of time to learn how I put DCK together (hint: the code is based off of Firespitter Texture Switching and uses the same config layout)

[cakepie]

So, to get back on topic.

Sorry I didn't have time to delve into the substantial stuff earlier.
Here are my responses:

 

On 4/22/2018 at 5:45 AM, Electrocutor said:

You can refer to my PartVariant Guide for an example in the OP that shows what is needed for VARIANT to not step on each other.

That's indeed very helpful. But from some testing, seems there are gotchas when there is a mix of variants that want to manipulate model/node, and variants that are texture switch.
Patch order may become a factor in the interaction between multiple mods patching variants into the same part.

 

On 4/22/2018 at 5:45 AM, Electrocutor said:

As for naming of VARIANT's to not step on each other, perhaps something like author_name would make sense because each author would be sure to not use names that conflicted with their own patches.

VARIANT names aren't the main issue; as you pointed out, avoiding collisions here is easy.
The original part author can use whatever they want, and other modders patching the part would use prefixes, so two patches by different people for the same part can avoid any conflict.

 

On 4/22/2018 at 5:45 AM, Electrocutor said:

VARIANTTHEME is trickier due to limitations of ModuleManager. The only viable solution I can think would be to adopt a standardized theme set such as has been done for CommunityResourcePack.

Yes, I've already noted the MM limitation discussed in the MM thread .

A quick elaboration for other readers:

Suppose modder A makes a mod that reskins parts in black, whereas modder B makes a mod that provides red textures. Both define their own VARIANTTHEME for their respective variants. They also agree that it makes sense to provide a VARIANTTHEME that lets the player easily reset their parts to the original (no-reskin) look -- we'll name that "default" by consensus.

A player could have either one of the reskins installed, or even both. So, if the modders are responsible for including the "default" VARIANTTHEME as part of their patch, they would need to do it in a way that "check if it already exists, then create it if not." But because VARIANTTHEME is a root node, we run into a technical limitation: MM is not able to do what we want -- it might cause other stuff to break.

Thus, the only solution for us is to have the "default" VARIANTTHEME defined in a common community consensus patch, and for both the black/red reskin mods to include that as a dependency.

 

On 4/22/2018 at 5:45 AM, Electrocutor said:

For what to call the default variant, the game automatically uses the name "Basic", but parts that use variants in stock usually use a color scheme name instead.

I'm pretty sure you know your stuff, but for the benefit of others, let's be careful not to conflate different things together.

What you're saying is:
When a default variant is not specified from among the available VARIANTS, the original state of the part is automatically treated as the "Base" variant.
If no display name is explicitly defined for the Base variant, it will show up as "Basic". In stock parts, a display name is usually provided, which coincides with the name of the VARIANTTHEME ("color scheme") that it is associated with.

Lengthier explanation with examples in the spoiler

Spoiler

The variant name, display name and the theme name (or "color scheme name") are all different things.

When setting up a ModulePartVariants MODULE with a bunch of VARIANTs, you have the option of specifying one of those as the "base" variant. e.g. T-12 Structural Tube (Tube1.cfg) sets up 5 variants that have their own respective displayName, then choose one of them as the default baseVariant. None of these have a theme name -- so they are not associated with a VARIANTTHEME

If you don't explicitly specify the baseVariant, then an automatic "Base" Variant is made, this variant will reset the part to its original state.  e.g. this MM patch (borrowed from here) will result in automatic creation of a "base" variant with the displayName "Basic" for the original, along with the "Black" that is explicitly defined here. Again, neither of these are associated with any VARIANTTHEME

@PART[Mk1FuselageStructural] {
	%MODULE[ModulePartVariants] {
		VARIANT {
			name = KSP_Black
			displayName = Black

			primaryColor = #2d2e2d
			secondaryColor = #2d2e2d

			TEXTURE {
				_Color = #2d2e2d
			}
		}
	}
}

And then we can also look at the SP-T06 Structural Panel (EquiTriangle0.cfg) -- this has two explicitly defined variants that specify their displayName as well as give a themeName that associates each one to a VARIANTTHEME.
There is no baseVariant specified, so the original state of the part is automatically created as "Base" variant -- and it is explicitly assigned with displayName #autoLOC_8007116 and associated to the "White" VARIANTTHEME.

Note: the display name for the VARIANT does not necessarily have to correspond to the display name for its associated VARIANTTHEME. (The "White" VARIANTTHEME has displayName = #autoLOC_8007119 -- it can be a different string)
But it is probably best to use the same name to avoid confusing the user.

 

 

-*-*-*-

On 4/22/2018 at 9:56 AM, XLjedi said:

I've been calling the default colors "Default" and I'll probably use the "XL" prequalifier on my theme names to avoid mis-steps.  I might hold off on pushing too far into it until they fix the bug that causes parts with flags to break.  You've probably already seen my relatively simple Mod Manager script for only adding the ModPartVar node if needed.

 

I've seen your tentative MM patch code here. Is there something elsewhere that I've missed?

Using prefix for names is a wise step. If I understand correctly, you're adding a "Default" VARIANTTHEME and setting the parts' original ("basic") variant to that theme?

The flag bug is indeed a deterrent. But I like to consider it as buying some time to figure things out too. =)

 

 

Edited April 23, 2018 by cakepie

[XLjedi]

15 hours ago, cakepie said:

I've seen your tentative MM patch code here. Is there something elsewhere that I've missed?

Using prefix for names is a wise step. If I understand correctly, you're adding a "Default" VARIANTTHEME and setting the parts' original ("basic") variant to that theme?

The flag bug is indeed a deterrent. But I like to consider it as buying some time to figure things out too. =)

In the sample code below, I just call "base" parts "Default".  If I add another Variant and specify that it's the Default, it might step on someone else's code that would do the same thing.  Also, the code has to be repeated so many times, I was trying to make it as short as possible.  Since the Default reference is embedded in the module that is only created if ModPartVar does NOT exist...  I modified the code below; it seems pretty benign.

//////////  avionicsNoseCone  \\\\\\\\\\
@PART[avionicsNoseCone]:HAS[!MODULE[ModulePartVariants]]
{
	MODULE
	{
		name = ModulePartVariants
		primaryColor = #ffffff
		secondaryColor = #4c4f47
		baseDisplayName = Default
		baseThemeName = Default
	}
}
@PART[avionicsNoseCone]
{
	@MODULE[ModulePartVariants]
	{
		VARIANT
		{
			name = XL_Stealth
			displayName = Stealth
			themeName = XL_Stealth
			primaryColor = #2c2c2c //dark gray
			secondaryColor = #000000 //black
			TEXTURE
			{
				mainTextureURL = Livery/Stealth/Skins/Airbrake
			}
		}
	}
}

My original post that contained the outline for the above code was asking for opinions on efficiency and/or structure improvements, so the thread is certainly welcomed... and I will stay tuned to see what may develop.

Edited April 23, 2018 by XLjedi

[XLjedi]

Follow-up note...

I have noticed, that using my code to apply multiple variants has resulted in a rather strange bug in the game that actually impacts craft aerodynamics???

I will be trying to isolate the offending code this weekend, but what I see happening is...  My spaceplanes absolutely stall out at about 350 m/s and can no longer punch through the sound barrier.  Very odd!

I also noticed that I ABSOLUTELY HAVE TO name each specific mesh object that I am going to apply the variant skin to.  A new skin for the landing gear for instance that does not specify which mesh it intends to reskin would have the unwanted affect of also applying the new skin to the glow effect of the landing gear lights, which is a subtle enough glitch that it could easily go unnoticed if play testing never contemplated a nighttime landing scenario.  Same for ladders, or parts with flags, or deployable equipment, etc.  I'm just going to say for all parts, with variants the specific mesh must be referenced.

I'm a bit curious now if somehow the skin plays into the aerodynamics calculations in some way?  For instance, the glow effect is ignored, but writing over it somehow caused it to be factored into drag calculations?  Seems unlikely...

 

 

 

 

  

 

 

Edited April 27, 2018 by XLjedi

[cakepie]

@XLjedi The aerodynamics impact is odd; unfortunately I don't have any insight into that.

As for having to name the meshes to reskin, that's less surprising, but a good catch and a gotcha worth taking note of.
(If I recall correctly, firespitter's texture switch also provided for targeting specific meshes only.)

Meanwhile, I've been experimenting, and also running into limitations of what part variants can do.

 

But putting aside issues with ModulePartVariants, I'm thinking maybe we can make some progress on VARIANTTHEME configs.
E.g.: your config baseThemeName = Default doesn't do much good if there is no corresponding "Default" variant theme.

 

For a start, how does this look for your needs?

VARIANTTHEME
{
	name = CCVT_default
	displayName = #CCVT_default_displayName
	description = #CCVT_default_description
	primaryColor = #ffffff
	secondaryColor = #4c4f47
}

Localization
{
en-us
{
	#CCVT_default_displayName = Default
	#CCVT_default_description = The original version of parts that have variants added by mods
}
}

 

You can do:

@PART[partName]:HAS[!MODULE[ModulePartVariants]]
{
	MODULE
	{
		name = ModulePartVariants
		baseThemeName = CCVT_default
		baseDisplayName = #CCVT_default_displayName
		primaryColor = #ffffff
		secondaryColor = #4c4f47
	}
}

 

[XLjedi]

@cakepie  So the VARIANTTHEME patch is a singular MM script?  ...as opposed to being associated with every part.  Correct? 

And I'd be fine using your suggested "CCVT_" prefix and localization structure.

Also, I did verify the issue that I am having with the aerodynamics being impacted.  I have narrowed it down to just one part and it's the Shock Cone Intake.  For some reason adding a variant skin to the CircularIntakes mesh of this part has a negative impact on the flight dynamics and my spaceplanes with this part will not exceed about 355 m/s as a result.

This is particularly strange as the problem only cropped up recently, possibly the 1.4.2 or 1.4.3 update?  I will try it again this weekend on a vanilla install just to make sure it's not the result of some other mod, but right now...  I can add/remove that one MM script to apply a variant skin to the Shock Cone and it triggers the bug.

  
 

[cakepie]

On 5/4/2018 at 9:36 PM, XLjedi said:

So the VARIANTTHEME patch is a singular MM script?  ...as opposed to being associated with every part.  Correct? 

 

Um, no, not quite.

1. You do want every part that has a relevant part variant to be associated with the VARIANTTHEME.
2. The set of standard VARIANTTHEMEs is put in a standalone config -- no MM syntax, so not considered a patch.
3. The standard VARIANTTHEMEs are then shared by multiple mods. We have to do it this way, because we cannot use a MM patch to do "add this VARIANTTHEME if it doesn't already exist"

Don't you have a VARIANTTHEME named "XL_Stealth"?
(This is different from having VARIANTs on each part that you're reskinning, also named "XL_Stealth".)

Do let me know if I've lost you / what you didn't understand and I'll try to explain better.

 

On 5/4/2018 at 9:36 PM, XLjedi said:

Also, I did verify the issue that I am having with the aerodynamics being impacted.  I have narrowed it down to just one part and it's the Shock Cone Intake.  For some reason adding a variant skin to the CircularIntakes mesh

You sure it's just that one and not all air intakes? All air intakes have a transform used for intakeTransformName in ModuleResourceIntake; texturing that could be the cause -- similar to the issue you had with landing gear / lights, you might not want to disturb that transform.

 

 

 

 

Edited May 6, 2018 by cakepie

[XLjedi]

12 minutes ago, cakepie said:

You sure it's just that one and not all air intakes? All air intakes have a transform used for intakeTransformName in ModuleResourceIntake; texturing that could be the cause -- similar to the issue you had with landing gear / lights, you might not want to disturb that transform.

So far it's only the Shock Cone...   not a problem on the little Juno sized intake, or the F-15 style slanted intake, or the wheesley sized circular intake.  And I also specifically applied the skin to the CircularIntakes mesh.  Which seems to be same reference for both the shock cone and the round wheesley one.   But then again, I haven't tried flying any of those into orbit, so I should correct myself and try testing those to see.

Think I'm clear now on the rest.  ...but I guess we'd be doing what then to wrap all this in a mod?  just have the VARIANTTHEME config as a separate file in the mod folder?  Could we have issues with overlap there if everyone includes one?

I do have a variant XL_Stealth theme, but haven't bothered to try to register it in the config file you mention.  ...and it seemed to be fine.

Edited May 4, 2018 by XLjedi

[cakepie]

35 minutes ago, XLjedi said:

 ...but I guess we'd be doing what then to wrap all this in a mod?  just have the VARIANTTHEME config as a separate file in the mod folder?

Yeah, we'd put CCVT_default and other such standardized VARIANTTHEMEs in their own config file.
Localization for each language are better off in their own respective files.
All of this packed as a mod, with its own mod folder.

 

46 minutes ago, XLjedi said:

Could we have issues with overlap there if everyone includes one? 

Similar mods like Community Resource Pack, Community Tech Tree, etc have been doing it this way for a while, should be workable.
I think we should be okay as long as mods that bundle it make sure to keep updated with new versions. (i.e. avoid users overwriting existing copy with an older one.)

 

[XLjedi]

@cakepie  hmmm...  seems odd that an existing new part with a variant would not have already contemplated this and specified a default theme?  Makes me question a bit whether it's the right approach?

[cakepie]

2 minutes ago, XLjedi said:

@cakepie  hmmm...  seems odd that an existing new part with a variant would not have already contemplated this and specified a default theme?  Makes me question a bit whether it's the right approach?

I don't understand the situation you're trying to describe. What do you mean by "existing new part" ?

 

In your particular use case, you are using MM patch to add ModulePartVariants to existing -- not new -- parts that don't already have variants.
These parts didn't have variants originally, so it's not possible for them to be associated to any theme to begin with.

 

 

 

 

[XLjedi]

1 hour ago, cakepie said:

I don't understand the situation you're trying to describe. What do you mean by "existing new part" ?

Forget mod manager patches for a moment...  Just sayin, there were new parts introduced in 1.4 that have Variants, and I'm curious now as to how they might go about referencing a "Default".  ...and whether or not we are following suit here.

[cakepie]

Ah, you mean "existing" as in "stock" and "new" as in "KSP 1.4+".

Okay.

Strictly speaking, part variants don't have to be associated with a variant theme -- it is technically optional.
This is because part variants are used for different purposes, and it doesn't always make sense to tie-in a variant with a visual theme.

For instance, the MH structural tubes come in 5 variants (Short, Medium-Short, Medium, Medium-Long, Long). But this is a size change, so it isn't meaningful to specify themes for these variants.

On the other hand, for stock parts that use variants for alternate textures, each and every variant is associated with a theme. E.g. MH structural panels use {White, Dark, Gold} themes, and Rockomax tanks use {Black and White, Orange}
These stock parts don't need to reference a "default" theme, since their alternate texture variants were specifically designed according to the stock variant themes in  GameData/Squad/Parts/VariantThemes.cfg (and vice versa)
Thus, every single pre-existing stock variant already maps to a named theme.

So, following this precedent, when we add alternate texture variant(s) to a existing parts that did not previously have variants, we want each variant to be associated with a theme -- i.e. your "XL_Stealth" theme on the variants that you added, so that the player can switch all relevant parts to that design with one click; but also "default" theme for the original design of the parts, so that they player can revert to the original / stock look with one click.

Does that make sense?
 

[XLjedi]

Makes sense... was just pondering if there was a way to disregard a "Default" VariantTheme and have it all still work.  Which is kinda what I've done up to now; admittedly, by accident.

But I guess it loses the extra functionality of converting the whole craft.  Which, at the moment, doesn't really matter to me because some of the parts (like cockpits with flags on them) can't use variants anyway.  If they fix that bug eventually, it might make a difference for me then.  

[cakepie]

5 hours ago, XLjedi said:

Which, at the moment, doesn't really matter to me because some of the parts (like cockpits with flags on them) can't use variants anyway.  If they fix that bug eventually, it might make a difference for me then.   

No reason to let perfect be the enemy of the good:
- The parts with flags do work, they're just unsightly thanks to the flag glitch.
- It's still useful to be able to convert all the parts that you do have variants for with one click

Or do you mean that it's not a pressing concern, because you're not planning to release your texture/livery pack until that bug is fixed?

[XLjedi]

2 minutes ago, cakepie said:

No reason to let perfect be the enemy of the good:
- The parts with flags do work, they're just unsightly thanks to the flag glitch.
- It's still useful to be able to convert all the parts that you do have variants for with one click

Or do you mean that it's not a pressing concern, because you're not planning to release your texture/livery pack until that bug is fixed?

The later...  If I released a livery, the way I have them now, they would also include a separate part for each cockpit with a different skin.  This was my old non-variant approach.  And if you clicked the button to change the theme; everything would change except the cockpit.  So it kinda renders the theme switching feature a bit useless at the moment.  Better than my previous method of having a separate part for every piece; so a lot less clutter in the SPH part window, but still not quite there.

[cakepie]

Fair enough. Give a holler whenever you're ready.