Jump to content

[1.12.x] Textures Unlimited Recolour Depot

Manwith Noname

By Manwith Noname
in KSP1 Mod Development

 Share

Recommended Posts

  • 3 weeks later...
OnlyLightMatters

OnlyLightMatters

Posted
Posted (edited)
On 4/3/2021 at 11:35 PM, DanDucky said:

In the future/is it possible to create configs or something along those lines to make restock parts work?

To make Restock parts work with TURD, you need to make additionnal textures and add some updated config rules for stock parts to tell TU how to recolor them. I am a big fan of Restock/+ but in my very humble opinion of KSP player, enabling TURD on MH and BG parts is a higher priority.

Edited by OnlyLightMatters
Link to comment
Share on other sites
OnlyLightMatters

OnlyLightMatters

Posted
Posted

Okay I managed to make some configurations on MH parts which share their textures with stock ones (Nose cone Mk16A, 1.85m Heatshield). I understood most of the work to be done except on specific textures (Normal, specular) and I need to make a first configuration on a part with variants to validate my ability to do the whole work. The only thing which really annoys me is the mesh statement such as here: 

+KSP_TEXTURE_SET[MWNN_Stock_Paint]:NEEDS[TexturesUnlimited&!Restock]
{
    @name = MWNN_Stock_Paint_HeatShields_Fairing
    @MATERIAL
    {
        mesh = fairing
        
        texture = _MainTex,Squad/Parts/Aero/HeatShield/Fairing

[...]

Not sure to identify nor retrieve the appropriate meshes for each part.

As the mod's maintainer is MIA from the 12th of March, I am asking you guys: who here is interested to get a MH & BG support?

 

Link to comment
Share on other sites
Manwith Noname

Manwith Noname

Posted
  • Author
Posted
22 hours ago, OnlyLightMatters said:

Not sure to identify nor retrieve the appropriate meshes for each part.

Look in the 000_TexturesUnlimited folder and find the general configuration file. Under the UV_EXPORT section set exportUVs = true. Load the game, it will seem to hang but leave it be and once it reaches the main menu close it. Go back to the file and set exportUVs = false.

Now, inside your KSP install you'll have a folder named exportedUVMaps. Browse through there for the part you want to work with and you'll have a bunch of svg file which are the UVmaps and a text file which lists all the mesh names, texture paths and material properties.

It's best to do this with no mods installed.

Other useful tools, Kerbal Object Inspector or Debug Stuff. These can be used in game to visualise meshes when things get complicated.

I'm going away for the weekend so good luck but you seem to be doing alright so far.

Link to comment
Share on other sites
OnlyLightMatters

OnlyLightMatters

Posted
Posted (edited)

@Manwith Noname, I've had an issue which was impacting the RCS s1p5 fuel tank which also applies to another stock part.

Symptoms
A part with variants displays correctly with its standard default variant . Changing the variant works. THEN when changing back to the first default variant, the part is not modified.
The other part having this issue if the Rockomax X200 16.

Investigation
The same error displays in the KSP.log: 

ERROR: TUPartVariant could not locate default or stored texture set data

Looking inside Squad's files, both parts do not have a baseVariant = XXXXX statement.

 

To me there are two solutions.

1/ kill the variants in 1110_Variant_Removal.cfg and build the switching feature with KSPTextureSwitch.

2/ kill the variants in the 1110_Standardised_Switching.cfg as soon as possible then redefine the variants. I tried this way on my RCS fuel tank part, it works like a charm. 

@PART[Size1p5_Monoprop]:FOR[000_Standardised_Switching]:NEEDS[TexturesUnlimited&!Restock]
{
    !MODULE[ModulePartVariants],*{}
	MODULE
	{
	    name = ModulePartVariants
	    baseVariant = YellowAndWhite

		VARIANT
		{
			name = YellowAndWhite
			primaryColor = #ffffff
			secondaryColor = #ffdd00
			//baseDisplayName = #autoLOC_8003114            
			useMultipleDragCubes = false

			EXTRA_INFO
			{
			    textureSet = Stock_Default_Size1p5_Monoprop_YW
			}
		}
		VARIANT
		{
			name = White
			//displayName = #autoLOC_8007116 	//#autoLOC_8007116 = White
			themeName = White
			primaryColor = #ffffff
			secondaryColor = #ffffff

			EXTRA_INFO
			{
				textureSet = Stock_Default_Size1p5_Monoprop_W
			}
		}
	}
	%MODULE[TUPartVariant]
	{
		%name = TUPartVariant
	}
	%MODULE[SSTURecolorGUI]
	{
		%name = SSTURecolorGUI
	}
}
+KSP_TEXTURE_SET[Stock_Default]:NEEDS[TexturesUnlimited&!Restock]
{
	@name = Stock_Default_Size1p5_Monoprop_YW
	@title = Stock Default Size1p5 Monoprop YW
	@MATERIAL
	{
		mesh = Size1p5_Mono
		
		texture = _MainTex,SquadExpansion/MakingHistory/Parts/FuelTank/Assets/Size1p5_mono
		texture = _BumpMap,SquadExpansion/MakingHistory/Parts/FuelTank/Assets/Size1p5_mono_N
		texture = _Emissive,TURD/TU_Standardised_Switching/000_PlaceholderTextures/Emis
	}
}
+KSP_TEXTURE_SET[Stock_Default]:NEEDS[TexturesUnlimited&!Restock]
{
	@name = Stock_Default_Size1p5_Monoprop_W
	@title = Stock Default Size1p5 Monoprop W
	@MATERIAL
	{
		mesh = Size1p5_Mono
		
		texture = _MainTex,SquadExpansion/MakingHistory/Parts/FuelTank/Assets/Size1p5_mono_2
		texture = _BumpMap,SquadExpansion/MakingHistory/Parts/FuelTank/Assets/Size1p5_mono_N
		texture = _Emissive,TURD/TU_Standardised_Switching/000_PlaceholderTextures/Emis
	}
}

 

 

What do you think about that?
Are there more elegant ways to handle this issue?

 

 

Work done so far from the previous screen capture : the 3 Service Modules, the Rover Wheels, the 2 RCS tanks, the inflatable airlock.

 

Edited by OnlyLightMatters
Link to comment
Share on other sites
Manwith Noname

Manwith Noname

Posted
  • Author
Posted (edited)
On 5/3/2021 at 11:35 PM, OnlyLightMatters said:

@Manwith Noname, I've had an issue which was impacting the RCS s1p5 fuel tank which also applies to another stock part.

Symptoms
A part with variants displays correctly with its standard default variant . Changing the variant works. THEN when changing back to the first default variant, the part is not modified.
The other part having this issue if the Rockomax X200 16.

Investigation
The same error displays in the KSP.log: 



ERROR: TUPartVariant could not locate default or stored texture set data

Looking inside Squad's files, both parts do not have a baseVariant = XXXXX statement.

 

This sounds similar to an issue I was having that I previously posted about. At least, I'm fairly sure I found the same error in the log when I looked. I didn't get very far with debugging it because it seemed pretty random. I had an issue with Terrier not switching correctly, at the time I had removed large parts of my install to help with loading times. When I put everything back, the Terrier worked but later I found that the Spark did the same thing.

I meant to get around to checking if this related to how I split the meshes up but didn't always call the texturesetX for certain variants but this isn't applicable to you looking at the config. Looking at the Squad parts they both have base variants defined too. I'm fairly sure this worked perfectly well previously so part of me suspects some changes in KSP may have caused this issue to occur and perhaps the TU plugin needs some changes but I have nothing concrete on that, just that I don't recall ever experiencing this issue back in 1.8 or 1.9. Correlation is not causation though.

As for which method you should use to fix the problem, totally up to you. Initially I aimed to move everything over to the TU texture switch because the part variant selector in the PAW is crap by comparison (it doesn't scroll or give any indication how many variants exist once you fill the window). Then certain parts don't play nice with removing part variants and using the TU switcher due to how they turn on and off meshes, so I also considered converting everything to use Part Variants exclusively but along with my personal distaste for how the menu behaves, this also comes with limitations and would result in not being able to mix and match materials across a single parts meshes (like with landing gear, wheels, inflatable heatshield...).

On top of all this, I would also consider compatibility with other mods. If a part has Part Variants by default, other mods might expect them to still be there but I've ignored this a few times because of the previous points.

 

Edit:

 

Ok...I just fired up my install and checked a few things. I'm not so sure the problem I encounter is related. Both the Terrier and Spark behave strangely but they're not alone, the Juno also had issues which I can categorically say didn't exist before. Something very strange going on because I'm pretty sure this is now a different error, it's occurring on part variants and the TU switcher. Things seem to work but the part disappears when hovering over the PAW.

Edited by Manwith Noname
Link to comment
Share on other sites
Arco123

Arco123

Posted
Posted
4 minutes ago, OnlyLightMatters said:

Progress status : all MH  parts done except structural ones.
Engines plates and Structural tubes were not a straightforward work.

210506045039950852.jpg

 

To be done : all panels and triangles.
Then I will release a beta with It's all Shiny patches for MH.

Start the engines :)

Link to comment
Share on other sites
Opus

Opus

Posted
Posted

Hello, I am running KSP 1.10.1 with RSS RO RP1. I am having an issue in which B9 procedural wings revert to a default texture when the vehicle is loaded to launch. I skimmed the thread but did not find any relevant discussion at a glance. Sorry if this has been addressed. Is anyone aware of a fix to this issue? Thank you 

Link to comment
Share on other sites
Manwith Noname

Manwith Noname

Posted
  • Author
Posted (edited)

@Opus I seem to recall this happens with some builds of pWings. You'll need one that specifically supports Textures Unlimited as the transition from hangar to game world on versions that don't allow pWings own material handling to override TU. Try one of these if you are not already...

https://github.com/tetraflon/B9-PWings-Modified/releases

Edited by Manwith Noname
Link to comment
Share on other sites
OnlyLightMatters

OnlyLightMatters

Posted
Posted (edited)

https://github.com/OnlyLightMatters/TURD-MH/releases/tag/prealpha

Pre-release: It's all Shiny is available on Making History parts. 
I strongly advise you to use a disposable KSP installation to test it.
Do not hesitate to raise issues if you find bugs, any feedback is appreciated!

Edited by OnlyLightMatters
Link to comment
Share on other sites
Manwith Noname

Manwith Noname

Posted
  • Author
Posted

I did at one point consider mucking around with flags but there are a couple issues.

1) They are user defined. I prefer to have texture sets be very specific and define all the textures. TU has an "inherit texture" ability but I prefer not to use it as it can cause weirdness when switching.

2) Some flags use transparency. When you apply the main TU shaders to those the transparency is lost and what should be transparent displays the RGB layer content of the texture you aren't supposed to see. TU does have transparent shaders but these have their own issues which can cause rendering to behave strangely (you'll see through the entire part behind where a transparent shader is applied).

These two combined just make dealing with flags messy, so I focused on other things. It had been on my "revisit this" list but it really needs an alpha cutoff shader in TU before I'd seriously look at it.

Link to comment
Share on other sites

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.

×
 Share
Go to topic listing
×
×
  • Create New...