Jump to content

PartVariant Guide


Recommended Posts

23 hours ago, linuxgurugamer said:

Ok, so it seems that the material name is, in most cases, the name of the transform.

Given the data below, what are the materialNames?  This part has three textures defined in the MODEL stanza,   only one of which has a corresponding line below


	MODEL
	{
		model = RetroFuture/Command/2m1xCockpit/rectCkPit
		texture = rectCkPit_DIF, RetroFuture/Textures/rectCkPit_DIF
		texture = rectCkPit_NRM, RetroFuture/Textures/rectCkPit_NRM
		texture = rectCkPit_EMI, RetroFuture/Textures/rectCkPit_EMI
	}

I dumped the data using DebugStuff for this part:

  Reveal hidden contents



[DebugStuff] +med2mPodA T:Untagged L:0 (Default)
|   Transform - med2mPodA
|   Part - med2mPodA
|   Highlighter - med2mPodA
|   ModuleScienceContainer - med2mPodA
|   ModuleCommand - med2mPodA
|   ModuleScienceExperiment - med2mPodA
|   ModuleSAS - med2mPodA
|   ModuleReactionWheel - med2mPodA
|   ModuleColorChanger - med2mPodA
|   ModuleTripLogger - med2mPodA
|   ModuleKISInventory - med2mPodA
|   ModuleKISInventory - med2mPodA
|   AudioSource - med2mPodA
|   AudioSource - med2mPodA
|   AudioSource - med2mPodA
|   Rigidbody - med2mPodA
| 
|--+model T:Untagged L:0 (Default)
|  |   Transform - model
|  | 
|  |--+RetroFuture/Command/med2mPodA/med2mPodA(Clone) T:Untagged L:0 (Default)
|  |  |   Transform - RetroFuture/Command/med2mPodA/med2mPodA(Clone)
|  |  | 
|  |   --+med2mPodA T:Untagged L:0 (Default)
|  |     |   Transform - med2mPodA
|  |     | 
|  |      --+med2mPod_Exterior T:Untagged L:0 (Default)
|  |        |   Transform - med2mPod_Exterior
|  |        |   MeshFilter - med2mPod_Exterior
|  |        |   MeshRenderer - med2mPod (Instance) - KSP/Emissive/Bumped Specular
|  |        | 
|  |        |--+Airlock T:Airlock L:21 (Part Triggers)
|  |        |  |   Transform - Airlock
|  |        |  |   CapsuleCollider - Airlock
|  |        |  | 
|  |        |   ---Ladder T:Ladder L:21 (Part Triggers)
|  |        |         Transform - Ladder
|  |        |         CapsuleCollider - Ladder
|  |        |       
|  |        |--+Airlock T:Airlock L:21 (Part Triggers)
|  |        |  |   Transform - Airlock
|  |        |  |   CapsuleCollider - Airlock
|  |        |  | 
|  |        |   ---Ladder T:Ladder L:21 (Part Triggers)
|  |        |         Transform - Ladder
|  |        |         CapsuleCollider - Ladder
|  |        |       
|  |        |--+Airlock T:Airlock L:21 (Part Triggers)
|  |        |  |   Transform - Airlock
|  |        |  |   CapsuleCollider - Airlock
|  |        |  | 
|  |        |   ---Ladder T:Ladder L:21 (Part Triggers)
|  |        |         Transform - Ladder
|  |        |         CapsuleCollider - Ladder
|  |        |       
|  |        |---bulkHead T:Untagged L:0 (Default)
|  |        |      Transform - bulkHead
|  |        |      MeshFilter - bulkHead
|  |        |      MeshRenderer - rectFuselage_EMI (Instance) - KSP/Emissive/Bumped Specular
|  |        |    
|  |        |---extWindow T:Untagged L:0 (Default)
|  |        |      Transform - extWindow
|  |        |      MeshFilter - extWindow
|  |        |      MeshRenderer - med2mPod_EMI (Instance) - KSP/Emissive/Specular
|  |        |    
|  |        |--+podEyeCover T:Untagged L:0 (Default)
|  |        |  |   Transform - podEyeCover
|  |        |  |   MeshFilter - podEyeCover
|  |        |  |   MeshRenderer - med2mPod_ALPHA (Instance) - KSP/Alpha/Translucent
|  |        |  | 
|  |        |   ---fwdLowCam T:Untagged L:0 (Default)
|  |        |         Transform - fwdLowCam
|  |        |       
|  |        |---COL_med2mPodA_collider T:Untagged L:0 (Default)
|  |        |      Transform - COL_med2mPodA_collider
|  |        |      MeshCollider - COL_med2mPodA_collider
|  |        |      MeshFilter - COL_med2mPodA_collider
|  |        |    
|  |        |---COL_med2mPodA3_collider T:Untagged L:0 (Default)
|  |        |      Transform - COL_med2mPodA3_collider
|  |        |      MeshCollider - COL_med2mPodA3_collider
|  |        |      MeshFilter - COL_med2mPodA3_collider
|  |        |    
|  |         ---COL_med2mPodWindow_collider T:Untagged L:0 (Default)
|  |               Transform - COL_med2mPodWindow_collider
|  |               MeshCollider - COL_med2mPodWindow_collider
|  |               MeshFilter - COL_med2mPodWindow_collider
|  |             
|   ---Surface Attach Collider T:Untagged L:0 (Default)
|         Transform - Surface Attach Collider
|         SphereCollider - Surface Attach Collider
|       
 ---_default T:Untagged L:0 (Default)
       Transform - _default
     

 

so would this be correct:

This is not working:


VARIANT
		{
			name = Stock
			displayName = Stock
			themeName = Stock
			primaryColor = #ffffff
			secondaryColor = #dddddd
			TEXTURE
			{
				materialName = rectCkPit_DIF
				_MainTex = RetroFuture/StockScheme/rectCkPit_DIF
			}
			TEXTURE
			{
				materialName = rectCkPit_NRM
				_MainTex = RetroFuture/StockScheme/rectCkPit_NRM 
			}
		}

 

rectCkPit_DIF and similar are just the names of the actual textures.

med2mPod and the like that shows next to MeshRenderer are the material names.

 

so something like:

TEXTURE {
	materialName = med2mPod
	_MainTex = RetroFuture/StockScheme/rectCkPit_DIF
	_BumpMap = RetroFuture/StockScheme/rectCkPit_NRM
	_Emissive = RetroFuture/StockScheme/rectCkPit_EMI
}

 

Edited by Electrocutor
Link to comment
Share on other sites

1 hour ago, COL.R.Neville said:

dont you have use the EXTRA_INFO to list the bump maps etc?

TEXTURE

{

materialName = med2mPod

_MainTex = RetroFuture/StockScheme/rectCkPit_DIF
EXTRA_INFO

_BumpMap = RetroFuture/StockScheme/rectCkPit_NRM

_Emissive = RetroFuture/StockScheme/rectCkPit_EMI

}

No. EXTRA_INFO is used if you have other addons or partmodules that interface with variants. For example, the shell textures with ModuleProceduralFairing (in stock).

Link to comment
Share on other sites

I've made progress, but still have one more issue.

The following works, kind of.  It correctly puts the retro in, but when I go to stock, the part turns a greyish white.  I'm missing something with the second texture, I think, but I don't know what to set the materialName to.



	MODULE
	{
		name = ModulePartVariants
		primaryColor = #484D54
		secondaryColor = #484D54
		baseDisplayName = Retro
		baseThemeName = Retro
		VARIANT
		{
			name = Stock
			displayName = Stock
			themeName = Stock
			primaryColor = #ffffff
			secondaryColor = #dddddd
			TEXTURE 
			{
				materialName = med2mPod
				_MainTex = RetroFuture/StockScheme/med2mPod_EMI
				_BumpMap = RetroFuture/StockScheme/med2mPod_DIF
				_Emissive = RetroFuture/StockScheme/med2mPod_NRM
			}
			TEXTURE 
			{
				materialName = rectFuselage
				_MainTex = RetroFuture/StockScheme/rectFuselage_DIF
				_BumpMap = RetroFuture/StockScheme/rectFuselage_NRM
				_Emissive = RetroFuture/StockScheme/rectFuselage_EMI
			}
		}
	}

 

Link to comment
Share on other sites

1 hour ago, COL.R.Neville said:

dont all the bump maps end with _nrm? and the emissives _EMI? that might be where its going wrong at. 

I have no idea, but you gave me an idea and it's working now.

I think that the original part has more textures listed for the model than are actually used.  Once I realized that, I redid the textures using the materials which were actually there, and it's now working.

For anyone interested, the working code is here:

	MODULE
	{
		name = ModulePartVariants
		primaryColor = #484D54
		secondaryColor = #484D54
		baseDisplayName = Retro
		baseThemeName = Retro
		VARIANT
		{
			name = Stock
			displayName = Stock
			themeName = Stock
			primaryColor = #ffffff
			secondaryColor = #dddddd
			TEXTURE
			{
				materialName = med2mPod_EMI
				_MainTex = RetroFuture/StockScheme/med2mPod_EMI
			}
			TEXTURE 
			{
				materialName = med2mPod
				_MainTex = RetroFuture/StockScheme/med2mPod_DIF
			}
			TEXTURE 
			{
				materialName = rectFuselage_EMI
				_MainTex = RetroFuture/StockScheme/rectFuselage_EMI
			}
		}

 

Edited by linuxgurugamer
Link to comment
Share on other sites

@linuxgurugamer

For your example, you have 4 materials (med2mPod, rectFuselage_EMI, med2mPod_EMI, med2mPod_ALPHA). Each of these could have a diffuse, normal, and emission map. The fact that you are setting a _MainTex on two of these materials as an _EMI, which I would assume to be emission textures, and it looks right; makes me think that these meshes were very strangely setup. As can be seen in probeRoverBody_v2 from stock, that is not the usual way you use materials.

Link to comment
Share on other sites

51 minutes ago, Electrocutor said:

@linuxgurugamer

For your example, you have 4 materials (med2mPod, rectFuselage_EMI, med2mPod_EMI, med2mPod_ALPHA). Each of these could have a diffuse, normal, and emission map. The fact that you are setting a _MainTex on two of these materials as an _EMI, which I would assume to be emission textures, and it looks right; makes me think that these meshes were very strangely setup. As can be seen in probeRoverBody_v2 from stock, that is not the usual way you use materials.

They were.  It's an old mod which I'm updating.

Link to comment
Share on other sites

that what i like doing too making stuff from .2 work now 

but having to learn blender and unity  since some of these old models are using shaders and stuff that wont work anymore

and are baked into the mu object which is probably more accurate instead of saying model hehe.  

 

Link to comment
Share on other sites

20 hours ago, Electrocutor said:

@linuxgurugamer

For your example, you have 4 materials (med2mPod, rectFuselage_EMI, med2mPod_EMI, med2mPod_ALPHA). Each of these could have a diffuse, normal, and emission map. The fact that you are setting a _MainTex on two of these materials as an _EMI, which I would assume to be emission textures, and it looks right; makes me think that these meshes were very strangely setup. As can be seen in probeRoverBody_v2 from stock, that is not the usual way you use materials.

As it turns out, my configs were wrong.  They do follow the naming convention, and I am now making good progress with it

Link to comment
Share on other sites

  • 3 weeks later...
On 6/16/2019 at 3:28 PM, smartdummies said:

Is it possible for KSPF to change values for the effects? I am specifically looking at the localPosotion so that I can adjust the plume positions to match the different models

KSPF can change any property value on any PartModule as well as resources and the IVA model. It is only the base properties of the part that won't work currently because those are read in before any PartModule event is fired in the API (and I haven't found a way to make KSP re-read the values).

Link to comment
Share on other sites

6 hours ago, Electrocutor said:

It is only the base properties of the part that won't work currently because those are read in before any PartModule event is fired in the API (and I haven't found a way to make KSP re-read the values).

Speaking from an almost total absence of knowledge on the subject: couldn't the API part upgrade mechanism be (ab)used to trigger KSP to re-read/adapt base values?

Link to comment
Share on other sites

18 hours ago, swjr-swis said:

Speaking from an almost total absence of knowledge on the subject: couldn't the API part upgrade mechanism be (ab)used to trigger KSP to re-read/adapt base values?

I haven't tinkered with them extensively yet; it is on my to-do list. Upgrades serve a different purpose though, allowing improvement via the tech tree; so I'd honestly like it better the other way around where an upgrade would unlock a more advanced variant instead.

Edited by Electrocutor
Link to comment
Share on other sites

On 7/2/2019 at 8:08 AM, Electrocutor said:

KSPF can change any property value on any PartModule as well as resources and the IVA model. It is only the base properties of the part that won't work currently because those are read in before any PartModule event is fired in the API (and I haven't found a way to make KSP re-read the values).

If I am reading this correctly then I would assume that since the EFFECTS node is not a module you are not able to make changes to it via KSPF

Link to comment
Share on other sites

On 7/7/2019 at 10:48 AM, smartdummies said:

If I am reading this correctly then I would assume that since the EFFECTS node is not a module you are not able to make changes to it via KSPF

I would have to code for it specifically, like I did with changing the IVA and resources; then test if it reads the changes or not. I thought EFFECTS was no longer used though since they created PartModules for different types of effects?

Link to comment
Share on other sites

Hmm. I might have to look. I have been trying to see if I could use the part variants to remove the duplicated parts in Realism Overhaul, mostly engines, and my last issue has been the plumes. RO uses RealPlumes and Smokescreen which uses the EFFECTS node. If there is an alternate to that then maybe I can get that to work.

Link to comment
Share on other sites

  • 4 weeks later...

As I go through all the items I need changed for what I want to do I think that I might just need to write my own code as there are a number of config nodes I will need to touch that are not modules and I will need a way to change child nodes and specify which nodes to be changed. I appreciate you help and thoughts. 

Link to comment
Share on other sites

  • 2 months later...

@Electrocutor

I have some additional information you can add to the guide.  This arose when the costs were not making sense in a new mod I'm working on.

Upon initial instantiation, the cost of the part will be the sum of the base cost plus the cost of the baseVariant.  The base cost includes the cost of all resources in the base part as defined in any/all RESOURCE stanzas as is normal with parts

Upon changing variants, the cost is equal to the base cost plus the cost of the new variant plus the cost of any resources which may have been changed in a part module.

This is important when dealing with (among other things) fuel tanks.  If the amount of one or more resources has been changed, that's going to affect the final cost.  If a partmodule changes the amount of resources, it has to have an IPartCostModifier which accounts for the changed resources.

Edited by linuxgurugamer
Link to comment
Share on other sites

  • 2 months later...

First, I apologize, as I'm sure its just something dumb I'm missing, but i am trying to add a part variant (just to texture switch), to a Procedural Fairings part. It already has an existing part variant module, with 4 variants set up. I just want to add this additional one.

I cant seem to get this patch to work. My MM syntax feng-shui is rusty, so i dont know if its that, or I'm missing something with how the stock variant system works... vOv

Anyone have a clue?
 

@PART[KzProcFairingSide1]:NEEDS[ProceduralFairings]
{
    @MODULE
    {
        @name = ModulePartVariants

		%VARIANT
		{
			%name = 3SL
			%themeName = 3SL
			%displayName = 3SL Generic
			%primaryColor = #0D1C32
			%secondaryColor = #935209

			%TEXTURE
			{
				%materialName = fairing1
				%_MainTex = HorizonAeronautics/Assets/Aero/HA_3SL_PayloadFairing_D
				%_BumpMap = HorizonAeronautics/Assets/Aero/HA_3SL_PayloadFairing_N
			}
			
//			EXTRA_INFO
//			{
//				<info name> = <info value>
//
//				// Known Examples (ModuleProceduralFairing)
//				FairingsTextureURL = HorizonAeronautics/Assets/Aero/HA_3SL_PayloadFairing_D
//				FairingsNormalURL = HorizonAeronautics/Assets/Aero/HA_3SL_PayloadFairing_N
//			}
		}
	}
	
}

The part doesnt use the stock ModuleProceduralFairing module, but i copy/pasta'd that from the example in the OP, just incase, and for reference for myself.

Edited by Stone Blue
Link to comment
Share on other sites

  • 1 month later...
  • 3 weeks later...
  • 1 month later...

Okay, I got this far:

@PART[Panel0|Panel1|Panel1p5|Panel2|Triangle0|Triangle1|Triangle1p5|Triangle2|EquiTriangle0|EquiTriangle1|EquiTriangle1p5|EquiTriangle2]
{
  @MODULE[ModulePartVariants]
  {
    +VARIANT
    {
      name = Duna
      displayName = Duna
      themeName = Duna
      primaryColor = #cc0000
      TEXTURE
      {
          shader=KSP/Bumped Specular (Mapped)
          mainTextureURL = PATCH_LIB/duna_temple/red
          color = #943828
          _BumpMap=SquadExpansion/MakingHistory/Parts/Structural/Assets/Panels_Gold_NRM
          _SpecMap=SquadExpansion/MakingHistory/Parts/Structural/Assets/Panels_Gold_S
      }
    }
  }
}

The panels do show up in the VAB in red but the variant in the slider is still called Dark. As I launch the craft it reverts back to dark grey.... Not sure where I make a mistake. Anyone that can help?

I checked the .craft file there it also lists the selectedVariant as Dark. So why isn't the name of the variant "Duna"

@Electrocutor do you have an idea?

Edited by MacLuky
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.

×
×
  • Create New...