[1.3.1]TextureReplacerReplaced v0.5.4

[Sigma88]

2 hours ago, HaArLiNsH said:

You can now replace a texture with a MM cfg as you can see in the sample provided in this release.

now that I know MM and TRR can work together I'd like to propose a new syntax for TRR

with this new syntax it will be possible to allow much better levels of customization, at at the little cost that old packs will need to add very minor changes to be compatible:

THE FOLLOWING IS NOT IMPLEMENTED, IT'S JUST AN IDEA I AM CONSIDERING

The config structure I have in mind looks something like this:

TextureReplacerReplaced
{
	Folders
	{
		Default = 
		EnvMap = 
		Heads = 
		Suits = 
	}
	ReplaceByName
	{
		Texture
		{
			name = 
			newTexture = 
		}
	}
}

 

the idea is that, the "Folders" node will contains a list of folders from which TRR loads the textures.

so if your mod used to put head textures in the "TextureReplacer/Heads" folder, now you just need to move them into a custom folder (let's say KSPINSTALL/GameData/MyMod/MyTextures)

and add a cfg with the following content:

TextureReplacerReplaced
{
	Folders
	{
		Heads = MyMod/MyTextures
	}
}

 

all the folders included into "MyTextures" will be loaded like they were put into the old "KSPINSTALL/GameData/TextureReplacer/Heads"

 

if anyone has ideas please feel free to share them here so I can get a feel of what most TR(R) users might need

Edited June 13, 2017 by Sigma88

[John FX]

Glad to see this continuing, well done guys (and any gals)

[HaArLiNsH]

2 hours ago, Ger_space said:

I think there are two ways to solve your problem: 

1. use a transparent texture and change the shader to one with alpha support  for that part ("KSP/Alpha/Translucent")

Something like that:

collarObject.GetComponent<MeshRenderer>().material.shader = Shader.Find("KSP/Alpha/Translucent");

2. set the gameobject to inactive 

collarObject.SetActive(false); to make is dissapiar and collarObject.SetActive(true); to make it visible.

 

I have not tried this, but either one should work. 

1. : Never though of this as I don't understand the shader system yet. But anyway I like less this solution because, as I understand, it need a custom texture and it could lead to increase of weight for the textures packs and a new shader (witch seems to not be an easy thing)

2 : This is the kind of things I'm looking for. No mess to do with textures and so on , just to hide the mesh a bit like how the helmet is working now.

 

1 hour ago, Sigma88 said:

now that I know MM and TRR can work together I'd like to propose a new syntax for TRR

with this new syntax it will be possible to allow much better levels of customization, at at the little cost that old packs will need to add very minor changes to be compatible:

THE FOLLOWING IS NOT IMPLEMENTED, IT'S JUST AN IDEA I AM CONSIDERING

The config structure I have in mind looks something like this:

TextureReplacerReplaced
{
	Folders
	{
		Default = 
		EnvMap = 
		Heads = 
		Suits = 
	}
	ReplaceByName
	{
		Texture
		{
			name = 
			newTexture = 
		}
	}
}

 

the idea is that, the "Folders" node will contains a list of folders from which TRR loads the textures.

so if your mod used to put head textures in the "TextureReplacer/Heads" folder, now you just need to move them into a custom folder (let's say KSPINSTALL/GameData/MyMod/MyTextures)

and add a cfg with the following content:

TextureReplacerReplaced
{
	Folders
	{
		Heads = MyMod/MyTextures
	}
}

 

all the folders included into "MyTextures" will be loaded like they were put into the old "KSPINSTALL/GameData/TextureReplacer/Heads"

 

if anyone has ideas please feel free to share them here so I can get a feel of what most TR(R) users might need

Ooooh this start to looks like I wanted. The ultimate goal would be that people use a structure like this and get rid of these in TRR itself:

Gamedata
{
	MySuperCoolMod
		{
			Folders & stuff for the mod
			Texture
				{
					Default folder
						{
							with your default textures and the MM.cfg needed
						}
					EnvMap folder
						{
							with your EnvMap textures and the MM.cfg needed
						}
					Heads folder
						{
							with your Heads textures and the MM.cfg needed
						}
					Suits folder
						{
							with your Suits textures and the MM.cfg needed
						}
					CustomTextures folder
						{
							with your CustomTextures textures and the MM.cfg needed
						}					
					
				}
		}
}

here's a screenshot of what I mean :

 

As you all seems to be much much more familiar with the MM stuff, I let you decide for the structure of the MM config. I don't have a preference as long as it it simple and can be applied easily on older mods/textures packs.

 

TR(R)  looks nice too instead of TRR...  Guys what do you think of it?  witch one do you prefer ?  

TRR  vs TR(R)        round one  :    fight !

Edited June 13, 2017 by HaArLiNsH

[smotheredrun]

I have 2 votes:

1.  Sigma's syntax is so simple, I could even use it, so Sigma88 for the win!

2.  TRR is good

[Ger_space]

17 minutes ago, HaArLiNsH said:

1. : Never though of this as I don't understand the shader system yet. But anyway I like less this solution because, as I understand, it need a custom texture and it could lead to increase of weight for the textures packs and a new shader (witch seems to not be an easy thing)

2 : This is the kind of things I'm looking for. No mess to do with textures and so on , just to hide the mesh a bit like how the helmet is working now.

 

You only need one simple transparent texture (all black and alpha channel set to 1) for all parts you want want to vanish. You set the texture for the parts and set the right shader (one that supports transparency) and the part is gone. 
On the good side the parts gameobject is still active and does his thing, instead of going out of business, but you will need to keep track of the original textures to switch them back and reassign the KSP/Diffuse shader) 

Explaination:
Unity assigns each 3d model a thing they call material. a material consists of the assigned texture maps and a shader, which defines how the textures are redered on the 3d model. You can use the same material on different objects (for example the brown walls of the KSC buildings are all the same material with a tiled maintexture). That way you can save uge amounts of memory, but for the costs of more work for the grafic card, because each building consists of multiple 3d objects, which are rendered indypendent.

Setting a gameobject inactive will stop all scripts assigned to the object. which might be problematic if its transforms are not updated, but might also be good, as its collider is also disabled. 

 

[HaArLiNsH]

15 minutes ago, Ger_space said:

You only need one simple transparent texture (all black and alpha channel set to 1) for all parts you want want to vanish. You set the texture for the parts and set the right shader (one that supports transparency) and the part is gone. 
On the good side the parts gameobject is still active and does his thing, instead of going out of business, but you will need to keep track of the original textures to switch them back and reassign the KSP/Diffuse shader) 

 

So this way we only need to add a simple general texture file but do we need to make a special shader for each suit pack or could we also make a general one ?

If we only had to make these 2 files, we could share in the TRR guide pack.

 

Oh yeah, I did not talked about this yet

I will share the guide textures I made to make my suit pack and make a mod that I will distribute along TRR called something like TRR_reference or TRR_tutorial where you can find all you need to start with TRR (so the structures folders, the guides as an example for the heads,skybox, suit and so on and also a sample like we have now for the MM compatibilty) This way you can download this and have a reference. I soo wanted something like that when I started my suit pack.

[Cetera]

4 minutes ago, HaArLiNsH said:

I will share the guide textures I made to make my suit pack and make a mod that I will distribute along TRR called something like TRR_reference or TRR_tutorial where you can find all you need to start with TRR (so the structures folders, the guides as an example for the heads,skybox, suit and so on and also a sample like we have now for the MM compatibilty) This way you can download this and have a reference. I soo wanted something like that when I started my suit pack.

Very good, thank you!  This will be super helpful.

[evileye.x]

Will it work for changing navball texture and stock parts textures?

Anyway, great news, thanks. Additional point for name.

Edited June 13, 2017 by evileye.x

[HaArLiNsH]

Just now, evileye.x said:

Will it work for changing navball texture and stock parts textures?

Normally it should already be able to change the navball texture just like before (if the last version of TextureReplacer had it working). I don't have looked at this one yet. Could you try one and say if it works ?

For the stock part texture, what we call here the "MM compatibility" feature allow it. If you look at the sample provided, there is a green and a red image. The red replace the logo in the main menu (it simulate a custom texture in a mod or a stock texture) and the green one replace the red with the new MM cfg file called TR_Patch.cfg   (the other cfg is to setup the red in the first place).   At the end you see the green image instead of the KSP logo in the main menu.

Expect more detail on this soon

[Sigma88]

9 minutes ago, evileye.x said:

Will it work for changing navball texture and stock parts textures?

Anyway, great news, thanks. Additional point for name.

As long as you know the name of the texture you want to replace there should be no problem in doing so

[evileye.x]

3 minutes ago, HaArLiNsH said:

Normally it should already be able to change the navball texture just like before (if the last version of TextureReplacer had it working).

I remember the time when it did worked (AFAIR on version 1.0.5 of KSP) 

After that - nope

O'k I guess I'll try nd report (unfortunately it my happen week later or more... as I'm on biz trip)

Still excited as TR (R) needs some love.

Edited June 13, 2017 by evileye.x

[HaArLiNsH]

oh yeah, even if the old technique don't work anymore, you can now change it by MM cfg ! 

3 minutes ago, evileye.x said:

I remember the time when it did worked (AFAIR on version 1.0.5 of KSP) 

After that - nope

O'k I guess I'll try nd report (unfortunately it my happen week later or more... as I'm on biz trip)

Still excited as TR (R) needs some love.

I'll surely try it too soon or later so don't worry

 

edit: hmm I could even put an example for this in the guide pack... I loved the custom navballs

Edited June 13, 2017 by HaArLiNsH

[Ger_space]

55 minutes ago, HaArLiNsH said:

So this way we only need to add a simple general texture file but do we need to make a special shader for each suit pack or could we also make a general one ?

If we only had to make these 2 files, we could share in the TRR guide pack.

 

You only need the texture map, the shader is a Stock KSP Shader, so you can use it anytime. 

[HaArLiNsH]

1 minute ago, Ger_space said:

You only need the texture map, the shader is a Stock KSP Shader, so you can use it anytime. 

Oh nice, you make me dreaming of this again now.. 

Alright, I'll get back to you for this feature after we fix the reflections, this could make a lot of happiness 

And Thx for the help

[Cetera]

51 minutes ago, HaArLiNsH said:

oh yeah, even if the old technique don't work anymore, you can now change it by MM cfg ! 

I'll surely try it too soon or later so don't worry

 

edit: hmm I could even put an example for this in the guide pack... I loved the custom navballs

 

@xEvilReeperx made a custom mod to replace the navball texture after it stopped working in TR.  Dragging him into the discussion, in case he's still around and interested in contributing.

 

[HaArLiNsH]

5 minutes ago, Cetera said:

 

@xEvilReeperx made a custom mod to replace the navball texture after it stopped working in TR.  Dragging him into the discussion, in case he's still around and interested in contributing.

 

nice thx

[Cetera]

While I've only just recently become active again in the KSP community, and started playing again, I did try to keep up on everything I was interested in for future reference when I came back...  LOL.  

[Gordon Dry]

Can I use the TR_Reflective_Emissive_Alpha.ksp from
https://github.com/GER-Space/TextureReplacer/releases (1.3b) with this one?

[Ger_space]

25 minutes ago, Gordon Dry said:

Can I use the TR_Reflective_Emissive_Alpha.ksp from
https://github.com/GER-Space/TextureReplacer/releases (1.3b) with this one?

 not in the current release, as the shader load algorithm is not yet merged. (some other changes changed the same parts) so it requires some rewriting. 

nothing impossible, perhaps in a week.

[Aerospacer]

On 13.06.2017 at 3:46 PM, Ger_space said:

I think there are two ways to solve your problem: 

1. use a transparent texture and change the shader to one with alpha support  for that part ("KSP/Alpha/Translucent")

Something like that:

collarObject.GetComponent<MeshRenderer>().material.shader = Shader.Find("KSP/Alpha/Translucent");

2. set the gameobject to inactive 

collarObject.SetActive(false); to make is dissapiar and collarObject.SetActive(true); to make it visible.

 

I have not tried this, but either one should work. 

 

On 13.06.2017 at 5:19 PM, HaArLiNsH said:

1. : Never though of this as I don't understand the shader system yet. But anyway I like less this solution because, as I understand, it need a custom texture and it could lead to increase of weight for the textures packs and a new shader (witch seems to not be an easy thing)

2 : This is the kind of things I'm looking for. No mess to do with textures and so on , just to hide the mesh a bit like how the helmet is working now.

May be, you talking about something like this?

 

Edited June 14, 2017 by Aerospacer
forum engine's glitch

[Gordon Dry]

I just let Bob leave a rover-like vehicle that I launched with on KSC runway.

As soon as on EVA the log got spammed with:

NullReferenceException: Object reference not set to an instance of an object
  at TextureReplacer.Personaliser.isUnderSubOrbit (.Kerbal kerbal) [0x00000] in <filename unknown>:0 
  at TextureReplacer.Personaliser+TREvaModule.Update () [0x00000] in <filename unknown>:0 

This happened while I tried out Kerbal Konstructs but that also doesn't like my install and massively spammed.

So I'm not sure if "normally" TRR would not spam the log when doing EVA on earth.

I will try it again tomorrow without several problematic mods.

(Mods are usually always problematic as soon as more than a dozen are installed. Unity doesn't like mods. IMHO.)

[Ger_space]

6 hours ago, Gordon Dry said:

I just let Bob leave a rover-like vehicle that I launched with on KSC runway.

As soon as on EVA the log got spammed with:

NullReferenceException: Object reference not set to an instance of an object
  at TextureReplacer.Personaliser.isUnderSubOrbit (.Kerbal kerbal) [0x00000] in <filename unknown>:0 
  at TextureReplacer.Personaliser+TREvaModule.Update () [0x00000] in <filename unknown>:0 

This happened while I tried out Kerbal Konstructs but that also doesn't like my install and massively spammed.

So I'm not sure if "normally" TRR would not spam the log when doing EVA on earth.

I will try it again tomorrow without several problematic mods.

(Mods are usually always problematic as soon as more than a dozen are installed. Unity doesn't like mods. IMHO.)

could you please upload the logfile to some place. That it something I would like to see why KK failes. 

[klgraham1013]

On 6/13/2017 at 9:19 AM, HaArLiNsH said:

TR(R)  looks nice too instead of TRR...  Guys what do you think of it?  witch one do you prefer ?  

TRR  vs TR(R)        round one  :    fight !

I'd wager the community will just use TRR because it's faster to type.  You can try to encourage TR(R), but it might be an exercise in futility. 

[Gordon Dry]

8 hours ago, Ger_space said:

could you please upload the logfile to some place. That it something I would like to see why KK failes.

I will do - as I mentioned I wanted to remove some problematic mods - and last night it became too late to do more tests.

It seems that with the help of @LemonSkin I already could pinpoint just another problematic mod to remove for the next run that will start in a few minutes.

Either if the issue is still there or not I will edit this post then. Stay tuned.
(btw the problematic mod is Smart Actuators)

Edit:

So, I removed Smart Actuators* and that issue is gone, but the spamming on EVA regarding TRR is still there.
This session is without KK btw ...

Full log:
https://www.dropbox.com/s/4nnkrihekwmzvra/2017-06-15-1 KSP.log.zip?dl=1

*already fixed meanwhile, see https://github.com/theRagingIrishman/SmartActuation/releases/tag/1.1.0.2

Edited June 15, 2017 by Gordon Dry

[lajoswinkler]

Now that this has been continued, why don't you put it on Spacedock, too?

 

BTW, Texture Replacer works fine with me on v1.3, although I've only used it for a custom skybox.