[1.3.1]TextureReplacerReplaced v0.5.4

Cetera · November 5, 2017

Huh, having an interesting issue with the helmet lighting too. It looks like the light map is applied backwards on the rear portion of the helmet when using my texture pack. It doesn't look like this is happening with the TRR Default textures.

Also, do you know what might be causing the texture degradation on the emblem and stars? It is pretty apparent in-game. I tried my texture in 1.2.2 under the old TR, and it is there, but not quite as bad. In 1.2.2 TR it seems that if you zoom in closer, the detail level gets better, and further out it is using a lower-resolution texture. I'm guessing this is in the DDS compression using mipmaps, which I did save when I converted from .png files. I have disabled mipmaps in my TRR config. I'm not sure TRR is still making new mipmaps or not. It is easier to see in this shot:

Here's a link to the helmet used in this shot, but they are all basically the same, and all having the same issue:

https://www.dropbox.com/s/rp1blgv71sgmadt/Helmet_EvaSpace_Veteran_Male5.dds?dl=0

klgraham1013 · November 5, 2017

Diverse Kerbal Heads is now available for TRR.

Spoiler

Doxel · November 5, 2017

Quick question: what is the order of fallback if TRR cannot find a texture? For example, if there is no veteran jetpack texture provided, will it try to use the standard jetpack texture instead? If I am not making both male and female versions of a EVA spacesuit, should I call it "Suit_EvaSpace_Standard_Male0" or "Suit_EvaSpace_Standard_Female0" so that it will default correctly? Same question if I am making one texture for both ground and space EVAs.

Basically I just want to know which are the default choices if not all are provided. The docs were clear on how ranked textures fell back to the next lowest number when they weren't found, but it didn't mention how it behaved when other things are missing.

HaArLiNsH · November 6, 2017

17 hours ago, Cetera said:

@HaArLiNsH OK, I have my suits in-game and working, and my module manager patch even seems to be assigning suits correctly! Woohoo!  However, I'm still having some issues.

I have IVA helmets and suits, and EVA Space suits, and an EVA visor. I do not intend on making an EVA Ground set of suits, and just want the Space to double for those. However, with the defaults included in TRR, only the defaults show when on ground, even when suits are selected properly by class.

1. Is there any way to ignore ground EVA suits via a MM config?

2. If not, is there any way to have EvaSpace and EvaGround pull from the same file, rather than me duplicating all textures again?

3. What is the "Exclusive" option in the TRR Suits Menu for? What does it do? When I select it, I'm not seeing any changes anywhere.

4. No matter the selections, even manually configuring in the TRR menu, there is a bug with texture selection for Female Badasses and JetPacks.   EVA Space Jetpacks for Female Badasses are always selected to the TRR default. I can't test if it happens with Ground EVA Jetpacks, as I don't have a texture for that, and didn't muck about with it any further tonight.

* * *

I'm going to need some volunteers to test my suit pack, and make sure all is working well. I've done quite a bit of testing, but there's only so long one person can look at the same things over and over and actually notice details that aren't right. I see what I think should be there, regardless of whether it really is or not. Once my suit pack is 100% complete, then I'll create a separate thread for it on the forums, per HaArLiNsH's suggestion.

1: YES, I made the configuration for this, you can found this in the Default.cfg (or in the in-game menu)

look at the DEFAULT_SUIT to find all the infos on the configurations :

SuitSettings
	{
		// The settings for the suit sets		
		//
		//   enter the name of your directory from Suits/
		//
		// if you want to change the default setting of your custom suit set, 
		// Just enter the ones you want to change
		// If you put no settings, your custom suit will have the settings from the DEFAULT_SUIT
		// when you reset your suit set ingame, it goes back to these values
		//
		// *********************************************************************************
		// I don't recommend changing the DEFAULT_SUIT setting here, you can change these settings ingame.
		// they are used when you reset it to the setting you find here
		// *********************************************************************************
		// Example:
		//
		//   MyPilotSuit     
		//	 {
		//		helmet_EvaGround_Atmo = 0
		//		visor_EvaGround_Atmo = 0
		//		visor_EvaSpace_BaseColor[0] = 0,0,0,255
		//		visor_EvaSpace_BaseColor[1] = 50,0,0,255
		//		visor_EvaSpace_BaseColor[2] = 100,0,0,255
		//		visor_EvaSpace_BaseColor[3] = 150,0,0,255
		//		visor_EvaSpace_BaseColor[4] = 200,0,0,255
		//		visor_EvaSpace_BaseColor[5] = 255,0,0,255
		//   }
		//
		// THESE SETTINGS ARE OVERRIDDEN BY PER-GAME SETTINGS SET IN THE GUI!
		//

		DEFAULT_SUIT
		{			
			//	Is the suit exclusive to one kerbal ?         
			isExclusive = false
				
			// The suit when in vehicle and safe
			// 0 = IVA,
			// 1 = EVA GROUND,
			// 2 = EVA SPACE        
			suit_Iva_Safe = 0
				
			// The suit when in vehicle and unsafe
			// 0 = IVA,
			// 1 = EVA GROUND,
			// 2 = EVA SPACE        
			suit_Iva_Unsafe = 0
		
			// The suit when out of the vehicle, on the ground and with atmosphere
			// 0 = IVA,
			// 1 = EVA GROUND,
			// 2 = EVA SPACE        
			suit_EvaGround_Atmo = 0
				
			// The suit when out of the vehicle, on the ground and without atmosphere
			// 0 = IVA,
			// 1 = EVA GROUND,
			// 2 = EVA SPACE        
			suit_EvaGround_NoAtmo = 1
				
			// The suit when out of the vehicle, in space
			// 0 = IVA,
			// 1 = EVA GROUND,
			// 2 = EVA SPACE        
			suit_EvaSpace = 2
				
			// The helmet when in vehicle and safe
			// 0 = IVA,
			// 1 = EVA GROUND,
			// 2 = EVA SPACE
			// 3 = NONE        
			helmet_Iva_Safe = 3
				
			// The helmet when in vehicle and unsafe
			// 0 = IVA,
			// 1 = EVA GROUND,
			// 2 = EVA SPACE
			// 3 = NONE        
			helmet_Iva_Unsafe = 0
				
			// The helmet when out of the vehicle, on the ground and with atmosphere
			// 0 = IVA,
			// 1 = EVA GROUND,
			// 2 = EVA SPACE
			// 3 = NONE        
			helmet_EvaGround_Atmo = 3
		
			// The helmet when out of the vehicle, on the ground and without atmosphere
			// 0 = IVA,
			// 1 = EVA GROUND,
			// 2 = EVA SPACE
			// 3 = NONE        
			helmet_EvaGround_NoAtmo = 1
				
			// The helmet when out of the vehicle, in space
			// 0 = IVA,
			// 1 = EVA GROUND,
			// 2 = EVA SPACE
			// 3 = NONE        
			helmet_EvaSpace = 2
				
			// The visor when in vehicle and safe
			// 0 = IVA,
			// 1 = EVA GROUND,
			// 2 = EVA SPACE
			// 3 = NONE        
			visor_Iva_Safe = 3
				
			// The visor when in vehicle and unsafe
			// 0 = IVA,
			// 1 = EVA GROUND,
			// 2 = EVA SPACE
			// 3 = NONE        
			visor_Iva_Unsafe = 0
		
			// The visor when out of the vehicle, on the ground and with atmosphere
			// 0 = IVA,
			// 1 = EVA GROUND,
			// 2 = EVA SPACE
			// 3 = NONE        
			visor_EvaGround_Atmo = 3
		
			// The visor when out of the vehicle, on the ground and without atmosphere
			// 0 = IVA,
			// 1 = EVA GROUND,
			// 2 = EVA SPACE
			// 3 = NONE        
			visor_EvaGround_NoAtmo = 1
		
			// The visor when out of the vehicle, in space
			// 0 = IVA,
			// 1 = EVA GROUND,
			// 2 = EVA SPACE
			// 3 = NONE        
			visor_EvaSpace = 2
		
			// The jetpack when out of the vehicle, on the ground and with atmosphere
			// 0 = EVA GROUND,
			// 1 = EVA SPACE
			// 2 = NONE,        
			jetpack_EvaGround_Atmo = 2
				
			// The jetpack when out of the vehicle, on the ground and without atmosphere
			// 0 = EVA GROUND,
			// 1 = EVA SPACE
			// 2 = NONE,        
			jetpack_EvaGround_NoAtmo = 0
				
			// The jetpack when out of the vehicle, in space
			// 0 = EVA GROUND, 
			// 1 = EVA SPACE
			// 2 = NONE,        
			jetpack_EvaSpace = 1

			// the color of the base mesh of the Iva visor at each level
			// change this to alter the base color (like the yellow of the Eva space visor)
			// enter in format RGBA 
			// numbers must be between 0 and 255
			// the last one must be 255 (the alpha channel)
			visor_Iva_BaseColor[0] = 255,255,255,255
			visor_Iva_BaseColor[1] = 255,255,255,255
			visor_Iva_BaseColor[2] = 255,255,255,255
			visor_Iva_BaseColor[3] = 255,255,255,255
			visor_Iva_BaseColor[4] = 255,255,255,255
			visor_Iva_BaseColor[5] = 255,255,255,255			
			
			// the color of the base mesh of the Eva Ground visor at each level
			// change this to alter the base color (like the yellow of the Eva space visor)
			// enter in format RGBA 
			// numbers must be between 0 and 255
			// the last one must be 255 (the alpha channel)
			visor_EvaGround_BaseColor[0] = 255,255,255,255
			visor_EvaGround_BaseColor[1] = 255,255,255,255
			visor_EvaGround_BaseColor[2] = 255,255,255,255
			visor_EvaGround_BaseColor[3] = 255,255,255,255
			visor_EvaGround_BaseColor[4] = 255,255,255,255
			visor_EvaGround_BaseColor[5] = 255,255,255,255			
			
			// the color of the base mesh of the Eva Space visor at each level
			// change this to alter the base color (like the yellow of the Eva space visor)
			// enter in format RGBA 
			// numbers must be between 0 and 255
			// the last one must be 255 (the alpha channel)
			visor_EvaSpace_BaseColor[0] = 200,150,0,255
			visor_EvaSpace_BaseColor[1] = 200,150,0,255
			visor_EvaSpace_BaseColor[2] = 200,150,0,255
			visor_EvaSpace_BaseColor[3] = 200,150,0,255
			visor_EvaSpace_BaseColor[4] = 200,150,0,255
			visor_EvaSpace_BaseColor[5] = 200,150,0,255


			// the color of the reflection in your Iva visor at each level
			// enter between 0 and 255
			// enter in format RGBA 
			// numbers must be between 0 and 255
			// the last one must be 255 (the alpha channel)
			visor_Iva_ReflectionColor[0] = 128,128,128,255
			visor_Iva_ReflectionColor[1] = 128,128,128,255
			visor_Iva_ReflectionColor[2] = 128,128,128,255
			visor_Iva_ReflectionColor[3] = 128,128,128,255
			visor_Iva_ReflectionColor[4] = 128,128,128,255
			visor_Iva_ReflectionColor[5] = 128,128,128,255			
			
			// the color of the reflection in your Eva Ground visor at each level
			// enter between 0 and 255
			// enter in format RGBA 
			// numbers must be between 0 and 255
			// the last one must be 255 (the alpha channel)
			visor_EvaGround_ReflectionColor[0] = 128,128,128,255
			visor_EvaGround_ReflectionColor[1] = 128,128,128,255
			visor_EvaGround_ReflectionColor[2] = 128,128,128,255
			visor_EvaGround_ReflectionColor[3] = 128,128,128,255
			visor_EvaGround_ReflectionColor[4] = 128,128,128,255
			visor_EvaGround_ReflectionColor[5] = 128,128,128,255			
			
			// the color of the reflection in your Eva Space visor at each level
			// enter between 0 and 255
			// enter in format RGBA 
			// numbers must be between 0 and 255
			// the last one must be 255 (the alpha channel)
			visor_EvaSpace_ReflectionColor[0] = 128,128,128,255
			visor_EvaSpace_ReflectionColor[1] = 128,128,128,255
			visor_EvaSpace_ReflectionColor[2] = 128,128,128,255
			visor_EvaSpace_ReflectionColor[3] = 128,128,128,255
			visor_EvaSpace_ReflectionColor[4] = 128,128,128,255
			visor_EvaSpace_ReflectionColor[5] = 128,128,128,255

			
		}
	}

You need to add this in the .cfg of your custom folder for each of your suits set (folders) if you want to use the EVA Space suit instead of the EVA ground suit.

SuitSettings
	{
		MyPilotSuit
		{	
			// The suit when out of the vehicle, on the ground and without atmosphere
			// 0 = IVA,
			// 1 = EVA GROUND,
			// 2 = EVA SPACE        
			suit_EvaGround_NoAtmo = 2
			
			// The helmet when out of the vehicle, on the ground and without atmosphere
			// 0 = IVA,
			// 1 = EVA GROUND,
			// 2 = EVA SPACE
			// 3 = NONE        
			helmet_EvaGround_NoAtmo = 2
					
			// The visor when out of the vehicle, on the ground and without atmosphere
			// 0 = IVA,
			// 1 = EVA GROUND,
			// 2 = EVA SPACE
			// 3 = NONE        
			visor_EvaGround_NoAtmo = 2
				
			// The jetpack when out of the vehicle, on the ground and without atmosphere
			// 0 = EVA GROUND,
			// 1 = EVA SPACE
			// 2 = NONE,        
			jetpack_EvaGround_NoAtmo = 1
		}
	}

2 : You can't pull from the same file but as I said in 1, you can choose witch element (suit,jetpack,..) you want to use in different state (inside the vehicle, outside , with atmo, without atmo, in space..). You can do this with the in game menu too.

3: I tough getting rid of it for the suit. Iit prevent the suit from being randomly selected. But this case only happen when you kerbal did not had a suit set selected (like after a reset or when he is new) AND you don't have allocated a suit to a class. This come from the Heads. If you want a special suit set (or head set) for a kerbal, you manually select it for him (with the arrow in the menu or with the .cfg), you hit "exclusive" and the others wont randomly have it. Its useful for the heads when you want a head for Jeb and you want this only for him but less for the suits since you select a class suit normally.

4: I'll look into this bug, its really possible I missed/misspelled a combination

16 hours ago, Cetera said:

Huh, having an interesting issue with the helmet lighting too. It looks like the light map is applied backwards on the rear portion of the helmet when using my texture pack. It doesn't look like this is happening with the TRR Default textures.

Also, do you know what might be causing the texture degradation on the emblem and stars? It is pretty apparent in-game. I tried my texture in 1.2.2 under the old TR, and it is there, but not quite as bad. In 1.2.2 TR it seems that if you zoom in closer, the detail level gets better, and further out it is using a lower-resolution texture. I'm guessing this is in the DDS compression using mipmaps, which I did save when I converted from .png files. I have disabled mipmaps in my TRR config. I'm not sure TRR is still making new mipmaps or not. It is easier to see in this shot:

Here's a link to the helmet used in this shot, but they are all basically the same, and all having the same issue:

https://www.dropbox.com/s/rp1blgv71sgmadt/Helmet_EvaSpace_Veteran_Male5.dds?dl=0

I don't think TRR still does mipmap generation on .dds with mipmap (this is still a part a did not look too much)

I got this degradation too and I think I found the solution and this solve also your other problem. first you need to have a really clean NRM, the online converter compress the image, so forget it I use the addon for GIMP to make them. and then the ddsconverter to convert them but here come the subtlety :

You need to select the option "CLAMP" in the .dds convertion. You need to do that for all of your .dds (suit,jetpack, helmet..) this will solve the weird problem you have with the helmet (and it solve it also for the other part, even if you don't see it as much as the helmet does)

@klgraham1013 : You also need to "CLAMP" your .dds for the heads. If you don't you will have strange things at the edge of the meshes (like in the mid of the back of the head or the ponytail)

7 hours ago, klgraham1013 said:

Diverse Kerbal Heads is now available for TRR.

Reveal hidden contents

Nice ! Thanks

2 hours ago, Doxel said:

Quick question: what is the order of fallback if TRR cannot find a texture? For example, if there is no veteran jetpack texture provided, will it try to use the standard jetpack texture instead? If I am not making both male and female versions of a EVA spacesuit, should I call it "Suit_EvaSpace_Standard_Male0" or "Suit_EvaSpace_Standard_Female0" so that it will default correctly? Same question if I am making one texture for both ground and space EVAs.

Basically I just want to know which are the default choices if not all are provided. The docs were clear on how ranked textures fell back to the next lowest number when they weren't found, but it didn't mention how it behaved when other things are missing.

You can see the order in the in game menu. Basically it goes like :

Female vet badass -> female vet ->female badass -> female standard -> male vet badass-> male vet -> male badass -> male standard.

The male standard is always the last (and mandatory) texture chosen if the others don't exist. So you don't have to a make female version, it will pick the right choice.

klgraham1013 · November 6, 2017

8 minutes ago, HaArLiNsH said:

@klgraham1013 : You also need to "CLAMP" your .dds for the heads. If you don't you will have strange things at the edge of the meshes (like in the mid of the back of the head or the ponytail)

I have no option for this when I export as DDS. Perhaps my DDS converter is different? I am using GIMP.

When I updated this mod, I merely flipped the PNGs and saved as DDS using DXT1 compression and generating mipmaps.

Edited November 6, 2017 by klgraham1013

Doxel · November 6, 2017

9 minutes ago, HaArLiNsH said:

Female vet badass -> female vet ->female badass -> female standard -> male vet badass-> male vet -> male badass -> male standard.

Thanks so much for the speedy reply! That really helps. Now I can start converting over all the old textures.

9 minutes ago, HaArLiNsH said:

You can see the order in the in game menu.

...so you can. Well, I feel stupid.

Thanks again.

Doxel · November 6, 2017

Just a heads up about an interesting quirk of TRR that you might be interested in, but I found an repeatable error for an unusual folder setup which causes it to select textures for the wrong gender. I had my Kerbal head textures named in the pattern of "modauthor_description" and ended up with a folder named "scart_blonde" in both the male and female head subdirectories. This caused TRR to give male Kerbals the female head texture of the same name by mistake.

Fixing it was as easy as appending a "_f" or "_m" to the end of each folder, but I just thought you might want to know that there was an unusual condition in which the mod gets a bit confused and forgets which folder is which.

Otherwise it runs beautifully and has twice the functionality of the original TR. Keep up the great work.

Cetera · November 6, 2017

@HaArLiNsH thanks, that's a lot for me to wade through. I somehow missed the new config file in the updated mod, and was working off my MM patch from version .4, I think. I'll see if I can get that functional again. I may need some additional assistance with the TRR menu, or some additional documentation. I can see the previews of the suits, but not how to select which one for which level.

Regarding the DDS conversions, egads. Paint.Net doesn't seem to have a Clamp option, so that means I'm going to have to use a different too. You mentioned you had a way to convert with better quality. Do you mind sharing that?

It looks like my pack is a bit further behind than I thought. I renamed every file after I converted to DDS, so I have a lot of make-work to do one of these days, lol.

RealGecko · November 6, 2017

On 11/5/2017 at 12:32 PM, Cetera said:

Also, do you know what might be causing the texture degradation on the emblem and stars?

Hey, man! Glad to see you're working on porting your suit pack to TRR. I love it a lot, I still use original TR with my KSP 1.3.1 and I used ImageMagick to convert textures from your pack to DDS. Looks like this degradation is caused by DDS compression:

original:

versus compressed:

I think not much can be done with it, as TR (and TRR) will convert original PNG to DDS anyway.

Edit: it's not that noticable in the game however

Edited November 6, 2017 by RealGecko

HaArLiNsH · November 6, 2017

10 hours ago, klgraham1013 said:

I have no option for this when I export as DDS. Perhaps my DDS converter is different? I am using GIMP.

When I updated this mod, I merely flipped the PNGs and saved as DDS using DXT1 compression and generating mipmaps.

5 hours ago, Cetera said:

@HaArLiNsH thanks, that's a lot for me to wade through. I somehow missed the new config file in the updated mod, and was working off my MM patch from version .4, I think. I'll see if I can get that functional again. I may need some additional assistance with the TRR menu, or some additional documentation. I can see the previews of the suits, but not how to select which one for which level.

Regarding the DDS conversions, egads. Paint.Net doesn't seem to have a Clamp option, so that means I'm going to have to use a different too. You mentioned you had a way to convert with better quality. Do you mind sharing that?

It looks like my pack is a bit further behind than I thought. I renamed every file after I converted to DDS, so I have a lot of make-work to do one of these days, lol.

I use DDSConverter with these settings :

Heads, Suit, Jetpack, helmet : DXT1 + Mipmaps + Clamp

Visor : DXT5 + MipMaps + Alpha + Clamp

NRM : DXT5NormalMap + MipMaps + Normal + ToNormalMap + Clamp (don't worry about the new brown colour of your NRM)

This converter works in batch , so it means you have to regroup your files to be converted in 3 folders (one for the DXT1, one for DXT5 and one for DXT5NormalMap)

Don't forget to invert vertically your png before converting (this is the only thing that this converter don't do ..)

You should have better compression result as this converter use the official Nvidia tools.

The degradation is really visible on the helmet because its a big flat surface. You have 3 ways to improve the results :

- Have a good NRM, because it accentuate the "errors".

- Remove all the "noise" in your texture. You need better transitions between your colours. Your stars for example, the pixels between the red and the black aren't regular, some are more red, some are more black and when the compression goes, it take the middle value between these and if this is not regular, you will have artefacts. You can have "between black and red" pixels, but they need to be regular.

- Raise the resolution, I tried with a helmet in 4096x4096 and it was gorgeous. You can find a middle in this and make them in 2048. This is what I'll use in my suit pack.

Also, @Cetera , Look at the new visor configurations. I provided 3 basic grey visors (clear, middle, nearly opaque) and you can assign the one you prefer and colourise it in the .cfg (and in the menu). Off course, you can still provide your own visors textures (and colourise them too ingame)

6 hours ago, Doxel said:

Just a heads up about an interesting quirk of TRR that you might be interested in, but I found an repeatable error for an unusual folder setup which causes it to select textures for the wrong gender. I had my Kerbal head textures named in the pattern of "modauthor_description" and ended up with a folder named "scart_blonde" in both the male and female head subdirectories. This caused TRR to give male Kerbals the female head texture of the same name by mistake.

Fixing it was as easy as appending a "_f" or "_m" to the end of each folder, but I just thought you might want to know that there was an unusual condition in which the mod gets a bit confused and forgets which folder is which.

Otherwise it runs beautifully and has twice the functionality of the original TR. Keep up the great work.

Yeah I should notice this somewhere, its better to name your heads(so the folder) MyHeadMod_Male1, MyHeadMod_Male2, ... and MyHeadMod_Female1 than Male1_MyHeadMod and female1_MyHeadMod.

klgraham1013 · November 6, 2017

2 hours ago, HaArLiNsH said:

I use DDSConverter with these settings :

Heads, Suit, Jetpack, helmet : DXT1 + Mipmaps + Clamp

Thanks. Worked like a charm.

klgraham1013 · November 6, 2017

I'm updating a skybox. I went ahead and flipped and converted in the same manner as the heads. As the authors have long since left the forum (I did message them), is there any harm in maintaining them as mods? What is the most open license I could use? As of now, I'll probably just throw CC BY 4.0 on everything.

I might actually go a little nutty today and update a number of texture packs...

We'll see.

Electrocutor · November 6, 2017

15 minutes ago, klgraham1013 said:

I'm updating a skybox. I went ahead and flipped and converted in the same manner as the heads. As the authors have long since left the forum (I did message them), is there any harm in maintaining them as mods? What is the most open license I could use? As of now, I'll probably just throw CC BY 4.0 on everything.

I might actually go a little nutty today and update a number of texture packs...

We'll see.

Have a look here:

It's not an especially easy thing to take over a previous project. Depending on the license that they used and what the licenses were of any content that they also pulled from someone else, it can get very sticky. What's more these are actual legal licenses, so if you breach them, the original author can seek legal action; though usually that doesn't happen as most modders are understanding about ignorance.

Edited November 6, 2017 by Electrocutor

klgraham1013 · November 6, 2017

3 minutes ago, Electrocutor said:

snip

My trouble is that some of the skybox's were just posted in the Texture Replacer thread with a link to a download site. As far as I can tell, no real license is stated. It'd be a shame if all these texture packs just died because of legal issues.

Electrocutor · November 6, 2017

Just now, klgraham1013 said:

My trouble is that some of the skybox's were just posted in the Texture Replacer thread with a link to a download site. As far as I can tell, no real license is stated. It'd be a shame if all these texture packs just died because of legal issues.

You could provide the link and instructions or a .bat file or something to download and put them into the right place with the right name. This is similar to how other mods, like Astronomer's Visual Pack has a link to KSPRC then gives instructions about how to pull out only part of KSPRC's textures.

klgraham1013 · November 6, 2017

Just now, Electrocutor said:

You could provide the link and instructions or a .bat file or something to download and put them into the right place with the right name. This is similar to how other mods, like Astronomer's Visual Pack has a link to KSPRC then gives instructions about how to pull out only part of KSPRC's textures.

If the original content has no listed license, you can consider it as 'all rights reserved' unless you get the original author to state otherwise.

So, basically, unless it has a license that directly states I can modify and redistribute, I'm not touching it. Preservation of such things could be lost simply because of unknown legal ramifications.

Electrocutor · November 6, 2017

8 minutes ago, klgraham1013 said:

So, basically, unless it has a license that directly states I can modify and redistribute, I'm not touching it. Preservation of such things could be lost simply because of unknown legal ramifications.

Have a look here: https://choosealicense.com/no-license/

There could be some content that you are able to repackage just because of terms and conditions of where they put it up for download and such.

John Nowak · November 6, 2017

On 10/30/2017 at 1:17 AM, sardia said:

Does anyone have example pics of old favorites that got adapted to 1.31? I

I won't pretend to be an expert, but I have been able to use old suits and heads from my previous game. It just takes some work with file names and directories. I'll be happy to walk you through this if you're still interested.

klgraham1013 · November 7, 2017

It is definitely possible to use old textures with TRR. The issue is, it's much easier for the average user to drop a mod folder into GameData than to learn how to get old packs to work with TRR. I'm not saying it's hard. It's just a matter of convenience. TRR seems to have been designed with this in mind.

maja · November 7, 2017

13 minutes ago, klgraham1013 said:

It is definitely possible to use old textures with TRR. The issue is, it's much easier for the average user to drop a mod folder into GameData than to learn how to get old packs to work with TRR. I'm not saying it's hard. It's just a matter of convenience. TRR seems to have been designed with this in mind.

Even for experienced user it's convenient just to drop folder into GameData than search why heads weren't loaded even with propper folder structure.

Poodmund · November 7, 2017

As someone who is offering a "Texture" mod at the moment, I am currently packaging it in a way that supports the directory structure requirements of 'TextureReplacer' whilst also including a config file in that directory that patches in compatibility for 'TextureReplacerReplaced'. Hopefully that way it covers most ground for the end users.

HaArLiNsH · November 8, 2017

6 hours ago, Poodmund said:

As someone who is offering a "Texture" mod at the moment, I am currently packaging it in a way that supports the directory structure requirements of 'TextureReplacer' whilst also including a config file in that directory that patches in compatibility for 'TextureReplacerReplaced'. Hopefully that way it covers most ground for the end users.

Heu.. I don't see how you can do that properly.

As far as I know, the only way to use TR's textures is to put them in TR's folder and while you can still do this in TRR, I strongly encourage people not to.

And you really don't need compatibility between them because TR is "finished" since a long time now.

11 hours ago, klgraham1013 said:

It is definitely possible to use old textures with TRR. The issue is, it's much easier for the average user to drop a mod folder into GameData than to learn how to get old packs to work with TRR. I'm not saying it's hard. It's just a matter of convenience. TRR seems to have been designed with this in mind.

I made TRR with TR legacy system in mind

I don't understand what is the difficulty to use the old TR textures with TRR. Maybe I need some explanation of the real problem?

I tried to made it simple, you just make a custom that has nearly the same structure that TR got and the little .cfg and then you put your textures in it just like you did with TR. you just don't use the old .cfg file that went with the old texture pack.

You can make one TRR's custom folder for each of your texture (in case where you have a head pack from one and a suit pack from another modder, so there wont be any lost or conflict when they update) or you can put them all in the same place.

Also, its better to save the old texture pack then see if there are any legal problem than just letting them disappear. I wanted to convert some of the most famous but time is not on my side.

Edited November 8, 2017 by HaArLiNsH

CodyCoyote · November 8, 2017

On 6/10/2017 at 10:49 AM, HaArLiNsH said:

EVAspace : grey 85% (nearly not clear , you can still see the head)

how do I make this totally not clear (100% grey) ?

HaArLiNsH · November 8, 2017

8 hours ago, CodyCoyote said:

EVAspace : grey 85% (nearly not clear , you can still see the head)

how do I make this totally not clear (100% grey) ?

You have to make your own texture

This is simple :

- make a png sized 1024x1024 (non compressed) with a grey color (I used 125,125,125)

- convert it in .DDS with DDSConverter with these settings : DXT5 + MipMaps + Alpha + Clamp

- name it like the visor you want to replace (KerbalVisor, EVAgroundVisor or EVAvisor ) , the space one is the EVAvisor

- put your new texture in the Default/ folder of your custom folder

Enjoy !

jlcarneiro · November 9, 2017

This is getting better and better, thanks!

I'd like to know if, compared to TR, TRR uses more or less system resources (RAM, CPU, etc.) for those (like me) who use potato-like machines... :wink:

[1.3.1]TextureReplacerReplaced v0.5.4

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Join the conversation