Fairings do not retain settings

[Electrocutor]

When setting a fairing part to any PBR shader along with properties, the visual is shown to have affected the fairing as well. For example, set the fairing part to metallic mirror and the fairing itself also becomes a mirror; but when changing scenes, the fairing loses its visual change.

From my perspective this can only mean that the code firing when switching between texturesets for KSPTextureSwitch is different from the code that fires during scene load, and the latter is missing something that allows the fairings to be included.

[shadowmage45]

This is caused by stock code. The stock code recreates the materials on the fairing at some point after it is loaded / after the texture switch is run.

I'll look into it, but no guarantee I'll be able to solve it for TU.

I have it working in SSTU, but only with a custom module that interacts closely with the fairing module/code... something I don't really want to implement in TU as it very ugly.

This might have to wait until KSP 1.4 and the stock texture switch and fixes to the fairing module. Still might not be possible even then if they are still using the same material re-creation BS in the stock code.

[Electrocutor]

Does it only re-create the material once or at multiple times during flight? If just once, couldn't you just fire off a time-delayed re-paint?

[shadowmage45]

In flight scene -- just once if I remember correctly. Could be accommodated, but would still be a dirty hack that only adds clutter to the code. The current SSTU code re-applies the texture set + colors during the Start() method in the fairing-manipulating PartModule; (what I wouldn't give for some consistency in KSP code, where hacks aren't necessary because there are proper hooks...)

A bigger problem is in the editor. Every time the user adjusts the fairing, the stock code recreates the materials (more than one), and they all need to be re-adjusted.

And the real problem is that the only way I found to consistently adjust the materials on the fairing relies on explicitly messing with data from ModuleProceduralFairing -- obviously that cannot be a general solution as it is not going to work anywhere else or for any other part-modules. https://github.com/shadowmage45/SSTULabs/blob/master/Plugin/SSTUTools/SSTUTools/Module/SSTUResizableFairing.cs#L250-L269

---

So I guess the real problem is that I simply don't want to add stock-fairing-specific texture set handling code. I don't believe it should be necessary, and believe that hard-coding like that is about as 'bad' as you can get in programming.

I'm willing to consider alternate solutions if some are provided, but I do not have time to be developing them myself right now.

[shadowmage45]

Hmmm... there might be an easy way to solve this....

A Fairing-specific texture switch module.

(well... still a ton of work, but easier than trying to work around the stock inconsistencies, and more desirable from a functional perspective)

[shadowmage45]

Looking into this problem more -- at least part of it is likely being caused by an incomplete texture set definition. You need to explicitly specify the transform/mesh names for the fairing panels, and also explicitly specify the transform name for the base mesh. (this is to prevent the bleeding problem you describe above, where changes to one effect the other)

Can I see the configs that you are using to adjust the fairing parts?

The other portion of this, is that yes, some additional code will need to be put in place to update the fairing-panel materials during Start() (or later).

[shadowmage45]

@Electrocutor I think I have a solution in place for this -- do you have a config file that I could use to test the setup and solution?

[Electrocutor]

@REFLECTION_CONFIG[default]:NEEDS[TexturesUnlimited] {
%enabled = true
}

KSP_MODEL_SHADER {
model = Squad/Parts/Aero/fairings/AutoTruss
model = Squad/Parts/Aero/fairings/fairingSize1
model = Squad/Parts/Aero/fairings/fairingSize2
model = Squad/Parts/Aero/fairings/fairingSize3
model = FairingPanel

MATERIAL {
	shader = SSTU/PBR/Metallic

	PROPERTIES {
		name = _Metal
		float = 0.75
	}
	PROPERTIES {
		name = _Smoothness
		float = 0.9
	}
}

}

Also

KSP_TEXTURE_SET {
name = MetalShiny
title = MetalShiny
recolorable = false

MATERIAL {
	shader = SSTU/PBR/Metallic

	PROPERTY {
		name = _Metal
		float = 0.75
	}
	PROPERTY {
		name = _Smoothness
		float = 0.9
	}
}

}

@part[fairingSize1,fairingSize2,fairingSize3] {
MODULE {
name = KSPTextureSwitch
sectionName = Appearance
currentTextureSet = MetalShiny

	textureSet = MetalShiny
}

}

[shadowmage45]

Thanks, will see if I do indeed have this fixed tonight.

[shadowmage45]

Apparently the fairings are now using the stock part-variant setup. This is going to complicate things substantially. One is going to have to decide to use either the stock part-variant system for texture-switching or using TU's TextureSwitch module.

Using the KSP_MODEL_SHADER setup alone it will be impossible to adjust the fairing panels. These do not exist in the database model ('model = FairingPanel' doesn't exist), as they are created at run-time by the stock ModuleProceduralFairing. You can adjust the shaders on the base without problem (this works already), though the textures may be overriden by the stock part-variant system (untested).

Even if using the stock part-variants for texture-switching, some sort of secondary module is going to need to exist on the part in order to (re-)set the properties of the materials after the part-variant has changed and/or the fairing itself is rebuilt. I would suggest that this simply applies the shader to the materials, and allow the stock part-variant system to handle the rest of the texture-switching functions. (IIRC you found a way to set material properties with the stock system, and could patch those into the stock texture sets).

If wanting to use the more advanced features of TUs texture-switching (such as recoloring GUI use), this will require a specially developed texture-switch module that integrates with the stock ModuleProceduralFairings to manipulate the textures properly. It would also require the removal (via patch) of all of the stock part-variant related information from the fairing part configs. As I'll be needing this for SSTU, I'll likely develop this in the near future, probably a few weeks out.

---

Some progress -- I can manually force-assign the material back onto the fairing panels in the flight scene. Doesn't work when you first build the fairing, but after reloading or launching the craft, it properly applies the textures. Kind of opposite of the original problem....

[shadowmage45]

Made a bit more progress last night, and have something in place that allows for setting the shader on the fairing panels. It doesn't set textures, or shader properties, just the shader itself.

Going to do a bit more work on it to see if I can adapt it to also load shader properties. The module will point towards a texture-set, but it will only be able to effectively use the non-texture shader properties (e.g. attempts to use it to set textures will be unsupported; use the stock part-variant system for texture manipulation).

---

Will aim to get these all wrapped up and ready for a release shortly after 1.4.3 is made available. There are a few config-node related fixes coming in stock code with that update that I really need to have in place.

[shadowmage45]

Have updated this to read from a texture set, and use a specific MATERIAL block for the fairing panels. Both the texture-set-name and material-block-index need to be specified in the config file for the new module. This setup allows for TU code to set shader and shader properties (e.g. _Metal), while still allowing the stock code to manipulate the textures.

Will do some further testing and validation on this tonight, and probably call it 'solved'. At some point in the future I'll write the full Fairing-Texture-Switch module, but for now stock-based fairings will have to use the stock system for texture switching.

[shadowmage45]

New module based solution is verified to work in all tested cases.

• Build new fairing in editor.
• Reload existing craft in editor.
• Launch craft from editor
• Revert-to-launch
• Revert-to-editor
• Launch from space center
• Revisit craft in editor (leave to space center and go right back in)
• Visit existing craft from tracking station.
• Visit existing craft from map while in flight.
• Visit existing non-controlled craft by moving into loading range.

It has the following limitations:

• Only uses a single MATERIAL block out of the texture set for the panels, specified by the 'materialIndex' config parameter. This is applied to the the fairing side panels and fairing 'nosecone' piece.
• Should not be used to adjust textures. Use the stock part-variant system for texture swaps. You -may- use it to assign textures to slots that are not used by stock, but any attempts to use it to adjust _MainTex or _BumpMap will be overwritten by the stock system. E.G. you could assign a _MetallicGlossMap or _AOMap to be used by all part-variants.
• Does not allow for 'texture swapping' setups. Use the stock part-variant system to adjust diffuse and/or normal map textures.
• Untested if you can set the textures for the fairing-base, or if those are also controlled by the stock part-variant system. The shaders -are- applied to it, as are the shader properties.

Simple Config example:

KSP_TEXTURE_SET
{
	name = STOCK-Fairings
	title = Default
	recolorable = false
	MATERIAL
	{
		shader = SSTU/PBR/Metallic
		//simply setting properties for metal and gloss
		PROPERTY
		{
			name = _Metal
			float = 0.05
		}
		PROPERTY
		{
			name = _Smoothness
			float = 0.125
		}
	}
}
@PART[fairingSize1,fairingSize2,fairingSize3]
{
	MODULE 
	{
		name = KSPFairingShader
		textureSet = STOCK-Fairings
		materialIndex = 0
	}
}

Complex config example - applies metallics to the base and structure, and non-metallics to the panels.

KSP_TEXTURE_SET
{
	name = STOCK-Fairings
	title = Default
	recolorable = false
	//0'th block is used for the fairing panels, referenced in the module config
	MATERIAL
	{
		shader = SSTU/PBR/Metallic
		//exclude the base and
		excludeMesh = Mesh
		excludeMesh = Cap1
		excludeMesh = Cap2
		excludeMesh = Cap3
		excludeMesh = Cap4
		excludeMesh = Cap5
		excludeMesh = Cap6
		excludeMesh = Truss1
		excludeMesh = Truss2
		excludeMesh = Truss3
		excludeMesh = Truss4
		excludeMesh = Truss5
		excludeMesh = Truss6
		//simply setting properties for metal and gloss
		PROPERTY
		{
			name = _Metal
			float = 0.05
		}
		PROPERTY
		{
			name = _Smoothness
			float = 0.125
		}
		//could alternatively provide a separate _MetallicGlossMap texture
		// PROPERTY
		// {
			// name = _MetallicGlossMap
			// texture = SSTU/Assets/StockFairing-MET
		// }
	}
	//technically you can include the base in the 'main' material block if they will share texture properties
	//but this example applies metal properties to the base and structural bits and uses matte properties for the panels
	MATERIAL
	{
		shader = SSTU/PBR/Metallic
		mesh = Mesh
		mesh = Cap1
		mesh = Cap2
		mesh = Cap3
		mesh = Cap4
		mesh = Cap5
		mesh = Cap6
		mesh = Truss1
		mesh = Truss2
		mesh = Truss3
		mesh = Truss4
		mesh = Truss5
		mesh = Truss6
		PROPERTY
		{
			name = _Metal
			float = 0.95
		}
		PROPERTY
		{
			name = _Smoothness
			float = 0.7
		}
	}
}
@PART[fairingSize1,fairingSize2,fairingSize3]
{
	MODULE 
	{
		name = KSPFairingShader
		//the name of the texture set to use for loading of shader, property, and texture data
		textureSet = STOCK-Fairings
		//this points to the MATERIAL block in the texture set that will adjust the fairing panels and nosecone
		materialIndex = 0
	}
}

Will be available with the next update.

[Electrocutor]

Would it not be a simpler solution to just search for the Material used by the fairing and alter it? The meshes are created on-the-fly, but I believe the material used on it is static, is it not?

It is named "FairingsMat"

[shadowmage45]

I do adjust that material (and the one for the cones as well); only it is not possible to adjust it for an already existing part before the panels are created. The material does not exist in the model itself, so I cannot adjust it as part of the model-database.

Example:
Vessel is loaded in flight with a fairing part. The fairing modules' OnStart() method is run and the fairing panels fully constructed before TU modules OnStart() method is run. Thus I need to adjust the existing panels as well. Any -newly created- panels (e.g. rebuilding the fairing in the editor) will use the already-adjusted material from the fairing module.

Edit:
The material is not static. It is created per-part-module, and each part has its own material instance.