[1.8-1.12] TextureReplacer 4.5.3 (8.2.2022)

[Hotaru]

Hotaru's are nice, but they eyelashes blow it for me. One sideways look in IVA and you'll see what I mean - I much prefer Val's circa 1960 liquid eyeliner look, and the textures Cosmic Farmer derived from Diverse Kerbal heads has nearly that same look.

The eyelashes were an experiment, as was the freckle/blush effect TaintedLion commented on. I'll change them back to something more stock-like for the next update.

Experimenting with different hairstyles too. Harder than it looks, might take a while.

[Proot]

Hey Guys I need your help here.

The visor reflection seems to vary depending on the commandpod. Sometimes the helmet is disabled and sometimes the reflection on the helmet is different.

I made a testcraft and loaded it with kerbals to show you what I mean.

My KSP 1.0.2 is modded and from all the pods available only those ones have a helmet enabled after the craft is off the ground:

mk2 landercan, mk1 commandpod, mk1 landercan, mk1-2commandpod and the ppd12 cupola module

http://i.imgur.com/VNOZK5W.png

Now my question:

Where and what do I have to edit to select that? I would prefer to have the helmets disabled while the kerbal is inside a commandpod.

But I really would love a more detailed explanation about how texturereplacer works in this regard.

I searched the web and this forum but couldn't find a solution to this or maybe I couldn't reproduce it properly.

And the reflection on the main menu looks terrible too!

http://i.imgur.com/JPOrKa3.png

Maybe you are smarter than me and help me figure it out (^^)

That is not a TR issue. It's a KSPRC "feature" for cabin visors, done before the new TR reflections. Please use KSPRC's thread for this type of complains.

About the reflection in the main menu: it's the stock one, so its not related to TR (or KSPRC).

[million_lights]

Oh ok. Thank you Proot. that explains why I couldn't find any answered here!

[Whirligig Girl]

I'm having problems with TR and normal maps. Might be due to ATM.

They all share the same normal map texture (copy-pasted), but only the yellow command uniform is actually showing the proper normal map (The one without the KSP logo engraved in it.) What is wrong?

Another question here: If normal maps are in the default folder for suits, and no other normal map is specified, will all the suits use the normal map?

EDIT: And now it won't even always load the helmet.

Could someone make a head texture for a male Kerbal that has the sharp Star Trek sideburns?

EDIT: I've found the problem seems to be related to Active Texture Management

Edited May 28, 2015 by GregroxMun

[shaw]

Hey Guys I need your help here.

The visor reflection seems to vary depending on the commandpod. Sometimes the helmet is disabled and sometimes the reflection on the helmet is different.

I made a testcraft and loaded it with kerbals to show you what I mean.

My KSP 1.0.2 is modded and from all the pods available only those ones have a helmet enabled after the craft is off the ground:

mk2 landercan, mk1 commandpod, mk1 landercan, mk1-2commandpod and the ppd12 cupola module

http://i.imgur.com/VNOZK5W.png

Now my question:

Where and what do I have to edit to select that? I would prefer to have the helmets disabled while the kerbal is inside a commandpod.

But I really would love a more detailed explanation about how texturereplacer works in this regard.

I searched the web and this forum but couldn't find a solution to this or maybe I couldn't reproduce it properly.

And the reflection on the main menu looks terrible too!

http://i.imgur.com/JPOrKa3.png

Maybe you are smarter than me and help me figure it out (^^)

1. There are no visor reflections in IVA. The "reflections" you see are baked into KSPRC visor texture and they "vary" a little because of different internal illumination between command pods.

2. You can edit config files of pod internals and set "allowHelmet = false" for all seats to disable all helmets in IVA. TR disables IVA helmets when a vessel is in "safe" situation, i.e. in (stable) orbit or landed. The latter is explained in the @Default.cfg.

3. Real reflections don't work in the main menu, because visor reflection and shader replacement are managed via part module on Kerbal EVAs. However, part modules are disabled during the main menu. I don't think this is worth fixing, because there is no (especially) simple fix and you usually only see the main menu scene for a few seconds.

- - - Updated - - -

I'm having problems with TR and normal maps. Might be due to ATM.

http://i.imgur.com/nsxM8BX.jpg

They all share the same normal map texture (copy-pasted), but only the yellow command uniform is actually showing the proper normal map (The one without the KSP logo engraved in it.) What is wrong?

Another question here: If normal maps are in the default folder for suits, and no other normal map is specified, will all the suits use the normal map?

EDIT: And now it won't even always load the helmet.

Could someone make a head texture for a male Kerbal that has the sharp Star Trek sideburns?

http://i.imgur.com/zs7wR.jpg

1. I don't know, maybe ATM texture caching. Try without it.

2. Yes, missing textures are not personalised, so the ones from the prototype model are used, i.e. the ones from Default/.

- - - Updated - - -

I'm discovering that the TR reflection plugin seems to ignore normal maps on parts if the "window" portion of the piece isn't defined as a separate mesh from the base part. I'll have to live with that for WindowShine.

What if you manually assign a shader, e.g. "Reflective/Bumped Diffuse"?

- - - Updated - - -

I suppose I was mainly thinking along the lines of something brand new that KSP wouldn't, obviously, be doing already. Otherwise we'd have stock reflective windows. Take the old mod "KerbPaint" which, before we even had alternative asset loader capabilities (which lead to the DDS loader mod), used texture masks (which were not actually loaded into the game) to define the color replacement regions. I believe it also used custom shaders to accomplish all this. If something similar could be developed to work with the reflection part of TR it would allow much more freedom of texture modification without the need for nearly-completely transparent regions of the texture in the areas where you don't want it to reflect. Either way, this line of thought isn't even a "request" at this point. Just something to look into when you're up to it. If texture-mask usage could be done before, surely it can be done again. Otherwise, we'll never be able to have freely-retextured parts with reflections.

Another way of going might be if we could simply invert the behavior of the "reflection plugin" part of TR in that instead of non reflecting in the transparent areas of the texture, it would treat the transparent areas as the reflective areas. Granted, you'd have to cross some wires somewhere between the texture load and the reflection rendering, and current mod authors would have to invert all their alpha levels to match it, but it would sure do the trick.

I don't really know much about all this though, just thinking out loud, so to speak. With some research and fiddling, all of this might be possible sometime.

I think it's only possible to invert alpha by rewriting the shader.

- - - Updated - - -

Are vessels supposed to be reflected? I can't see them on the helmets.

I can see planets though.

Vessels are reflected. Probably you must only come closer. Visor is convex and objects are much smaller in it.

- - - Updated - - -

For some reason the little pictures of the Kerbals in the bottom right hand corner was just showing black and grey.

Log?

[Whirligig Girl]

Star Trek: The Original Series colored space suits pack

Version 1.2: Now with Medical Blue, Cadet Grey, and Command Green; along with slightly revamped EVA Suits.

 

Command Gold: Pilot

Engineer/Security/Comms Red: Engineer

Command Green (Kirk sometimes wore this color): Alternate Pilot

Science Blue: Science

Medical Blue: Alternate Science

Cadet Grey: Tourist/Other

Download

Edited April 29, 2016 by GregroxMun

[Proot]

I've read this just now in the OP:

"disabled texture compression, mipmap generation and unloading by default, these functions will be removed in the next major release"

May I know why? may I request to keep this features inside TR?

With the DDS textures I'm not using ATM since time ago thanks to TR. But.. many plugins -even using DDS now- still needs PNG textures. Like EVE, for the main clouds textures. And mipmaps are truly useful to those PNG remain textures.

Some textures looks way better in PNG than in DDS. One example: the kerbals helmets, where the PNG bump textures looks perfectly, but DDS normals (stock alike) makes a very odd lighting at the texture edges.

[Whirligig Girl]

I am still in need of ATM, but the problem is that for some reason I'm having big problems with ATM. It compresses things wrong and the helmets and normal maps for my suits are all reverted to stock for some reason. Is it possible to disable ATM just for TextureReplacer?

[KerbMav]

I am still in need of ATM, but the problem is that for some reason I'm having big problems with ATM. It compresses things wrong and the helmets and normal maps for my suits are all reverted to stock for some reason. Is it possible to disable ATM just for TextureReplacer?

The Renaissance Pack has configs for ATM including for TR - but I still get some black kerbal textures here and there.

[shaw]

I've read this just now in the OP:

"disabled texture compression, mipmap generation and unloading by default, these functions will be removed in the next major release"

May I know why? may I request to keep this features inside TR?

With the DDS textures I'm not using ATM since time ago thanks to TR. But.. many plugins -even using DDS now- still needs PNG textures. Like EVE, for the main clouds textures. And mipmaps are truly useful to those PNG remain textures.

Some textures looks way better in PNG than in DDS. One example: the kerbals helmets, where the PNG bump textures looks perfectly, but DDS normals (stock alike) makes a very odd lighting at the texture edges.

Probably you don't convert normal maps correctly, DDS normal maps shouldn't be any worse quality (actually, PNG normal maps get mipmaps generated, and converted to DXT5nm and unloaded from RAM -- that's done by the stock loader without TR involvement -- , so in the end it's the same as using DDS normal maps, it just takes longer to load). DDS normal maps use RGB -> GGGR encoding to lessen DXT5 compression artefacts (Z component of normal vectors is calculated in fragment shader on the fly).

EVE should generate mipmaps for PNG by itself. Actually, that's where I learnt how to implement mipmap generation.

Now with DDS textures I don't see much need for the mentioned features. First, model textures will probably all use DDS format in all mods, so modders will have control over texture compression and mipmaps, hence no need for TR intervention unless a modder f*cks something up. And even if he does, TR can't do anything about it. DDSes are unloaded from RAM by the stock loader and hence cannot be touched by TR.

Secondly, UI textures can also be converted to DDS as long as loaded via GameDatabase. Some UI icons that are loaded manually (that's not a good idea!) need to stay in PNG format. Unity already compresses them, mipmaps are not desired for UI textures anyway since they make them blurry if you don't use the full texture quality. The only drawback is that they remain loaded, but that's not a big issue since icons are usually very small. If you think that's an issue, ask modders to load those textures via GameDatabase and convert them to DDS.

So, only some "special" textures, like EVE clouds and Kopernicus maps remain. These textures are usually directly loaded by their mods, so mipmap generation, compression and unloading is best fixed there, not in TR. Anyway, these textures are mostly blacklisted in TR configuration.

[Proot]

Probably you don't convert normal maps correctly, DDS normal maps shouldn't be any worse quality (actually, PNG normal maps get mipmaps generated, and converted to DXT5nm and unloaded from RAM -- that's done by the stock loader without TR involvement -- , so in the end it's the same as using DDS normal maps, it just takes longer to load). DDS normal maps use RGB -> GGGR encoding to lessen DXT5 compression artefacts (Z component of normal vectors is calculated in fragment shader on the fly).

EVE should generate mipmaps for PNG by itself. Actually, that's where I learnt how to implement mipmap generation.

Now with DDS textures I don't see much need for the mentioned features. First, model textures will probably all use DDS format in all mods, so modders will have control over texture compression and mipmaps, hence no need for TR intervention unless a modder f*cks something up. And even if he does, TR can't do anything about it. DDSes are unloaded from RAM by the stock loader and hence cannot be touched by TR.

Secondly, UI textures can also be converted to DDS as long as loaded via GameDatabase. Some UI icons that are loaded manually (that's not a good idea!) need to stay in PNG format. Unity already compresses them, mipmaps are not desired for UI textures anyway since they make them blurry if you don't use the full texture quality. The only drawback is that they remain loaded, but that's not a big issue since icons are usually very small. If you think that's an issue, ask modders to load those textures via GameDatabase and convert them to DDS.

So, only some "special" textures, like EVE clouds and Kopernicus maps remain. These textures are usually directly loaded by their mods, so mipmap generation, compression and unloading is best fixed there, not in TR. Anyway, these textures are mostly blacklisted in TR configuration.

I'm using a Nvidia Photoshop DDS plugin now. I convert all normals automatically from there. All the converted DXT5nm textures works perfectly, except for the helmet, where with DDS textures you can see the edges of the normalmap overlapping in the helmet.

Since it's the same texture (PNG & and DDS conversion), there must be some difference in the process. TR does it right. If TR converts the PNG all looks perfect. If I do the conversion automatically from PS, it looks odd.

Is quite weird... all the rest of DDS nomals are working perfectly.

EDIT: I'll try to post a few pics to explain the difference ASAP

[shaw]

Again: TR doesn't touch normal maps. Could you upload both the original PNG and your final DDS?

[veryinky]

Don't suppose someone could comment on the suit pack I made, kinda curious as to what others thought of it.

[Whirligig Girl]

The Renaissance Pack has configs for ATM including for TR - but I still get some black kerbal textures here and there.

They did not fix the texture problem. I have to just be able to completely disable ATM just for Texture Replacer.

[Mister Dilsby]

Outstanding! And thanks for making the alternate 'command' lime, it really looks great. I think I like the EVA suits with the helmet marks and leg/sleeve bands the best.

Not sure if I will load these in for my current save (the crew in my comic would have to explain the continuity error somehow, after all ) but will definitely play with it and maybe wear them for the next mission.

[Proot]

This is the thing:

Both are good, well iluminated and so on but, did you see the border in the middle of the DDS version?

Is where the texture have its "cut" for the other pieces. But is not visible at all in the PNG version.

Here you have the textures. Both are the same, in fact, the DDS one has been generated from the PNG. I can't see where is the problem. This is the only texture where I have this issue.

[Bentley]

@Proot

I kept having that problem with various parts and particularly the helmet when I made normals, I figured it had to do with the alpha channel not using the correct background transparency (according to how paint.net works with the files). I ended up just trying the KSP4DDS tool and it seemed to work although everything went pink. The in game result looks fine though. Maybe try adjusting the channel level ? or try the KSP4DDS tool and see if the result is the same.

[Eleven]

Don't suppose someone could comment on the suit pack I made, kinda curious as to what others thought of it.

I checked it out briefly. at first glance it looked like the color coded collars were a bit hard to discern in the little flight window. Also it looked like maybe the colors weren't matching up like they should. I put Bill, Bob and Jeb in a capsule and they came out in 2 red collars and 1 yellow in EVA. I'll check it out again tomorrow when I have more time...but so far, I absolutely dig the idea of telling which class they are just by the color!

[DaniDE]

Hi there. I recently reinstalled everything and I use Js Suits Pack with Texture Replacer. Everything works except the Helmets of the Kerbals are always the standard red striped ones, not the custom colored ones from the pack. It works fine with the suits themselves tho. I remember I had an additional texture pack installed too before (before the big cleanup), but I cant figure out which one it was, however the helmets worked then. Now with only Js Suits installed this problem occured. If anyone knows how to fix this, please let me know. I suspect its probably a filename or a cfg edit or such (I *hope*).

Thanks

[KerbMav]

Looking at the textured model ... and looking at what the texture file looks like ... what are you using to paint the new heads? Do you just have perfect 3D visualization abilities in your brains?

[altrue]

Hi there, I have an issue with Texture Replacer. Browsing the in-game options to assign suits by role (pilot, engineer, etc...) made the affected Kerbals return into the astronaut training, while keeping their level.

[Cosmic_Farmer]

Okay, I've updated my pack. It now includes low-res versions, and the directory structure is fixed.

Here's the link:

https://mega.nz/#!4t5DHBaa!t4nQzADq6H3wvx3ts6hGmzG_MzbP9g6j5G9iSPj0H4k

mitchz95: I didn't use the original pack names, in case the original was re-released.

KerbMav: Texture mapping seems to be all trial and error for me.

[Overland]

Star Trek: The Original Series colored space suits pack

Version 1.2: Now with Medical Blue, Cadet Grey, and Command Green; along with slightly revamped EVA Suits.

Known to maybe not be that great with Active Texture Management.

http://imgur.com/a/C9fJ2

Command Gold: Pilot

Engineer/Security/Comms Red: Engineer

Command Green (Kirk sometimes wore this color): Alternate Pilot

Science Blue: Science

Medical Blue: Alternate Science

Cadet Grey: Tourist/Other

Download

Great uniform pack mate.. as much as I love star trek though.. my recent adventures in KSP have been more train-based..

any chance you could modify the orange suit to be high visibility reflective vest and suchlike.. as what railway crew would wear in current day?

I did a passable attempt myself seen here in my latest update..

but i'd sure like something more official than simply a half transparent high vis vest pasted ontop of your great artwork... its only for personal use but it feels like a disservice of some kind..

(my train isnt hype related)

Edited May 29, 2015 by Overland

[Proot]

@Proot

I kept having that problem with various parts and particularly the helmet when I made normals, I figured it had to do with the alpha channel not using the correct background transparency (according to how paint.net works with the files). I ended up just trying the KSP4DDS tool and it seemed to work although everything went pink. The in game result looks fine though. Maybe try adjusting the channel level ? or try the KSP4DDS tool and see if the result is the same.

That solves the issue! Many, many thanks!

I guess that nvidia's DDS plugin for photoshop is not so accurate after all...

Truth is that for things like mipmaps, Gimp works better to save the files.

Works perfectly Bentley, so thanks again.

I guess now I can't argue at all against the changes announced by Shaw.

Shaw, you was completely right, from the beginning. As always. Sorry for being such a pain in your ass.

[veryinky]

I checked it out briefly. at first glance it looked like the color coded collars were a bit hard to discern in the little flight window. Also it looked like maybe the colors weren't matching up like they should. I put Bill, Bob and Jeb in a capsule and they came out in 2 red collars and 1 yellow in EVA. I'll check it out again tomorrow when I have more time...but so far, I absolutely dig the idea of telling which class they are just by the color!

I'll try to replicate. I've been trying different solutions (arm bands, jacket tops, full recolours), it's hard to make the suits different but still visible in the IVA window without completely recolouring the suits. Wish I could give them baseball caps or something.