Mod Manager Variant Livery

[XLjedi]

I've been working on custom liveries for use with the new Variant construct introduced with 1.4.  I'm aware of certain issues regarding the command modules and how they break the flags and so forth.  However, assuming those issues get sorted...  I have the following Mod Manager script that seems to work quite well for adding my custom livery files as a Variant for each part that I want.

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

This works fine, and if you notice, the first thing it does is adds a ModulePartVariants module to the part, but only if the module does not exist.  Then, it adds the new Variant for the custom livery.  

Couple questions for you all...

1) given that this is the syntax for a single part, and it's rather lengthy...  Do you see any way it could be streamlined and maintain functionality? 

2) the "name", "displayName", and "themeName" seem a bit redundant... but it seems to work like this?  Am I misnaming something here?  ...or should they be different for some reason?

Edited April 7, 2018 by XLjedi

[Electrocutor]

@XLjedi Check out my PartVariant Guide thread. That will tell you the difference between name, displayName, and themeName.

As for large cfg patches, it depends what you are applying it to. If you built models using pbr flow, such that each material type was its own mesh and standardized naming schema, then you could share a handful of textures across all parts, and just create a small program or script to copy/paste everything, only changing the [partname]. The downside to doing this is that we don't have detail diff or bump, so any major structure has to be modeled instead of bumped.

 

As far as your example above goes, it would work fine so long as your mod was the only one installed that made variants, but it would not work with other variant mods.

[XLjedi]

3 hours ago, Electrocutor said:

As far as your example above goes, it would work fine so long as your mod was the only one installed that made variants, but it would not work with other variant mods.

Thanks for the feedback...  interesting comment

Assuming that I'm just adding variants to stock parts...  The code seems to work fine when applied consecutively.  Currently, I have two different livery mods, both using the same code and they seem to stack fine; both variants get applied to the same stock parts, and I plan to stack a few more like this. 

Why do you think it wouldn't work with other variant mods?  Granted, if the other variant mods did not properly account for the possibility of another variant mod already adding ModulePartVariants, then those mods might cause something to fail; but I don't think this code would have any issues.    ...possibly stepping on the same names for the Variants? 

Thus far, this code happily drops another Variant into the mix of whatever has already been done by any other variant mod.  ...or at least that's how it seems to work in my testing so far?

I'll look around for the Part Variant Guide thread, I may have scanned that one already, but will look again.

 

 

 

 

 

Edited April 8, 2018 by XLjedi

[Electrocutor]

4 hours ago, XLjedi said:

Thanks for the feedback...  interesting comment

Assuming that I'm just adding variants to stock parts...  The code seems to work fine when applied consecutively.  Currently, I have two different livery mods, both using the same code and they seem to stack fine; both variants get applied to the same stock parts, and I plan to stack a few more like this. 

Why do you think it wouldn't work with other variant mods?  Granted, if the other variant mods did not properly account for the possibility of another variant mod already adding ModulePartVariants, then those mods might cause something to fail; but I don't think this code would have any issues.    ...possibly stepping on the same names for the Variants? 

Thus far, this code happily drops another Variant into the mix of whatever has already been done by any other variant mod.  ...or at least that's how it seems to work in my testing so far?

I'll look around for the Part Variant Guide thread, I may have scanned that one already, but will look again.

As per my guide... if you have multiple ModulePartVariants, you cannot have the same nodes set in more than one of them. In your example, TEXTURE of the second partmodule would override TEXTURE of the first.

You can, of course, have a single ModulePartVariants with many VARIANT within, but that would require a different MM patch than what you have listed.

[XLjedi]

1 hour ago, Electrocutor said:

As per my guide... if you have multiple ModulePartVariants, you cannot have the same nodes set in more than one of them. In your example, TEXTURE of the second partmodule would override TEXTURE of the first.

You can, of course, have a single ModulePartVariants with many VARIANT within, but that would require a different MM patch than what you have listed.

I thought what I have listed only adds a ModulePartVariants if the module does NOT already exist?  ...did I miscode it?   I think it works.  I read the "!" prequalifier as a logical NOT, correct?  Otherwise, the point of the post was to get different opinions on how to do it more efficiently if you have a different idea.

Edit:  I just took a look at your guide, I think my only critique/suggestion would be...  I don't think there's a need to ever write multiple (or overwrite previous) instances of ModulePartsVariants. 

I think the structure I have laid out here, should be the suggested form for Variant mods, as it only adds the modpartvariant module if it's needed.  Otherwise, it skips the addition of a new instance, and just adds another Variant to the list.  

As for the internal names... I think the only risk might be stepping on someone else's names accidentally... possibly?  Maybe good policy to put a unique prequalifier on them to minimize the risk.

 

Edited April 8, 2018 by XLjedi

[Electrocutor]

4 hours ago, XLjedi said:

Edit:  I just took a look at your guide, I think my only critique/suggestion would be...  I don't think there's a need to ever write multiple (or overwrite previous) instances of ModulePartsVariants. 

If all you were doing is changing textures, then it would be ok, but in the case where you need to show and hide different models or meshes, you need a bunch more syntax. For each new model variant, you must hide that model in all other variants.

Also, my bad on incorrectly assessing: having the 'only add if not exist' would indeed work if you are only making a texture variant.

Scenario:
Mod 1 adds a model variant
Mod 2 adds a model variant
Mod 3 (yours) adds a texture variant

Since yours happens to be processed last and does not maintain the existing baseVariant hidden model properties, that means that your variant would show 3 models simultaneously and then change the main texture on all their meshes. If instead, yours were loaded first, then MM patch such as I posted in the guide would maintain and add hidden model properties into your variant so it would work properly.

[XLjedi]

@Electrocutor  Ah, I see...  thank you for these helpful comments once again!  I hadn't really thought about or tested how it might function when dealing with multiple models.  Good news is, I think most of those multi-model variants are related to engines and rocket parts that I'm probably less inclined to add skins for. 

Also, on your recommendation, I picked up @sarbian's DebugStuff mod and have since been able to identify the individual meshes that I am reskinning.  This has been particularly helpful in dealing with parts (like ladders) where I only want to apply paint to the "Bay" and leave the default skin for the ladder alone.  I will have to test now, but I think I 'might' be able to avoid the model variant pitfall if I add the specific materialName to the TEXTURE. 

 

Edited April 9, 2018 by XLjedi