[1.3.1]TextureReplacerReplaced v0.5.4

[HaArLiNsH]

7 minutes ago, Galileo said:

The dds plugin for photoshop and Gimp do a better job than the dds converter that is constantly brought up in this thread. To convert a large amount of files, Photoshop can do batch conversion, so it would be easier but not necessarily faster. Gimp can do batch conversion but it’s not easy to set up (you have to write up a script). That said, Gimp saves DDS textures much faster than PS when saving manually. 221 textures is a lot though. I wouldnt blame you if you decided to miss out on a little quality for convenience.

Do you have a place where I can find some informations on how to batch convert with photoshop or Gimp ? I'm really interested because I'm searching for this since I'm working on these .dds. (the working time doesn't matter if I don't have to click a thousand time   )

I only advice the DDSconverter because its super easy to use and is free. 

[DoctorDavinci]

1 hour ago, Cetera said:

That actually looks the best out of all of them.  I don't have access to photoshop, though.  How long did it take to convert that file?  How long would it take to convert 221 files?  

Does it also clamp the DDS file?

Get yourself a copy of Fireworks or use photoshop and create all your textures then open them in paint.net, flip them vertically and save as dxt5

I did the Airplane Plus textures for DCK in this manner ... took 10 minutes to do a batch of 42 (number of textures available per part) and there were 11 batches - So a little under 2 hours for 554 textures converted to .dds from .png

[Cetera]

5 minutes ago, DoctorDavinci said:

Get yourself a copy of Fireworks or use photoshop and create all your textures then open them in paint.net, flip them vertically and save as dxt5

I did the Airplane Plus textures for DCK in this manner ... took 10 minutes to do a batch of 42 (number of textures available per part) and there were 11 batches - So a little under 2 hours for 554 textures converted to .dds from .png

Well, I just created my textures in Paint.Net, and then flipped and saved as dxt5, but I get the lighting errors on the textures (screenshots here).  @HaArLiNsH believes it to be a CLAMP issue with the DDS export, which Paint.Net does not have an option for.

Edited November 13, 2017 by Cetera
added post URL for screenshot

[HaArLiNsH]

20 minutes ago, Cetera said:

I tried doing that this weekend, redoing just one start by hand, and was still getting the compression artifacts.  That's why I posted the test file above with a very crappy star, but it was a new file guaranteed to not have any other issues, and guaranteed to be only three colors (gray, black, and dark red).  It had issues all over the place, which is why I gave up.  

From looking at your post above, it looks like this is just a limitation we have to deal with when using DDS in the current KSP engine.  Nothing for it, just have to wait for something better.

I also tried some time ago (I noticed this when using your old texture before making the "rainbow dev" ones and I didn't got any good results too. 

I think we have an engine limitation problem BUT hopefully @Galileo can maybe give us a "not too tedious to use" better tool (I really hope so because its a shame that we loose hard clean work just because of conversion problems) 

17 minutes ago, DoctorDavinci said:

Get yourself a copy of Fireworks or use photoshop and create all your textures then open them in paint.net, flip them vertically and save as dxt5

I did the Airplane Plus textures for DCK in this manner ... took 10 minutes to do a batch of 42 (number of textures available per part) and there were 11 batches - So a little under 2 hours for 554 textures converted to .dds from .png

We CAN'T use DXT5 for simple texture with no alpha of normal map, it weight too much for the number of file needed. And btw, TRR (TR did that too) convert these DXT5 to DXT1 when it can to spare memory.

If a file weight 10,6Mo in DXT1 , it weight 16Mo in DXT5. And the compression method is not in charge of this (DDSconverter use the same method for both)

Better have a DXT1 with a good compression method than a DXT5

Edited November 13, 2017 by HaArLiNsH

[DoctorDavinci]

10 minutes ago, Cetera said:

Well, I just created my textures in Paint.Net, and then flipped and saved as dxt5, but I get the lighting errors on the textures (screenshots above).  @HaArLiNsH believes it to be a CLAMP issue with the DDS export, which Paint.Net does not have an option for.

Don't use Paint.Net to create them, only to convert them

Paint.Net is garbage for 'creating' the textures as whenever there are two connecting colors it wants to blend them together (causing artifacts) ... if you only use it to convert then you shouldnt experience this issue

9 minutes ago, HaArLiNsH said:

I also tried some time ago (I noticed this when using your old texture before making the "rainbow dev" ones and I didn't got any good results too. 

I think we have an engine limitation problem BUT hopefully @Galileo can maybe give us a "not too tedious to use" better tool (I really hope so because its a shame that we loose hard clean work just because of conversion problems) 

We CAN'T use DXT5 for simple texture with no alpha of normal map, it weight too much for the number of file needed.

If a file weight 10,6Mo in DXT1 , it weight 16Mo in DXT5. And the compression method is not in charge of this (DDSconverter use the same method for both)

Better have a DXT1 with a good compression method than a DXT5

Then use DXT1 ... point I was making is to only use paint.net to convert

Edited November 13, 2017 by DoctorDavinci

[HaArLiNsH]

8 minutes ago, Cetera said:

Well, I just created my textures in Paint.Net, and then flipped and saved as dxt5, but I get the lighting errors on the textures (screenshots here).  @HaArLiNsH believes it to be a CLAMP issue with the DDS export, which Paint.Net does not have an option for.

I don't believe, I KNOW there is a problem if you don't clamp the .DDS. I coded it

You have 2 choices : clamp or repeat, and TRR (I got that from TR) use the clamp (I believe the game use it). 

While its not a problem when you make your own model; we don't have acces to the kerbal model , they are in the KSP.assets and we need to do as the dev "hardcoded" it.

3 minutes ago, DoctorDavinci said:

Don't use Paint.Net to create them, only to convert them

Paint.Net is garbage for 'creating' the textures as whenever there are two connecting colors it wants to blend them together (causing artifacts) ... if you only use it to convert then you shouldnt experience this issue

I can't agree more on this.

Make your life easier, get photoshop like everybody that works a little with images   (you are not "really" obliged to pay to use it you know.. )

But , as we are in open source water, we should be able to have a really free solution don't we ?

[Cetera]

16 minutes ago, DoctorDavinci said:

Don't use Paint.Net to create them, only to convert them

Paint.Net is garbage for 'creating' the textures as whenever there are two connecting colors it wants to blend them together (causing artifacts) ... if you only use it to convert then you shouldnt experience this issue

Then use DXT1 ... point I was making is to only use paint.net to convert

You can turn off the anti-aliasing-style color conversion in Paint.Net if you don't like it, or it is messing things up.  Regardless, that isn't the issue.  It doesn't matter whether the textures are DXT1 or DXT5, without any blended colors, on any line that isn't perfectly vertical or horizontal, you get compression artifacts moving to a DDS texture type.

You can see the examples above.  The test image was made in about 30 seconds using Paint.Net, and as you can see, there are no color gradients in it.

Further, my point remains that Paint.Net won't clamp DDS texture files, so they are useless with any kind of directional lighting, if that is what is truly causing it.  I haven't done my new conversion yet to test my next iteration, but I'm confident they'll work this time.

Edited November 13, 2017 by Cetera

[HaArLiNsH]

I tried the dds exporter from GIMP, you can clamp but you don't really have the choice in the compression method and both do pretty much the same crap :

- DXT1 with BC1 compression (682Ko)

- DXT5 with BC3 compression (1,33Mo)

 

Maybe DDSconverter use the same settings and this could be the normal compression method for either DX1 or DX5.

Anyway both don't give you good result like BC7 compression..

 

I think people won't really notice this ingame. And usually modder don't have the problem because they make their own model without the weird thing that is the helmet model and his texture placement. Squad made a "multi facet" model that need to be clamped with a big curving and stretching area in the most visible place

 

Edited November 13, 2017 by HaArLiNsH

[HaArLiNsH]

@Cetera I'm also trying with the nvida plugin in photoshop but I got pretty much the same result, DXT1 and DXT5 give the same lossy result

And in the setting menu , we can see that the compression grid seems to be 5x5, witch is really bad for "low res" textures.

I think this is a limitation of the compression method. Nothing we can change.

I can see 2 solutions for this :

- bigger resolution

- more "noise" in the draw, I mean if you have an image with a lot of "noise" and elements, you would notice less artefact than when you have a clean draw of a basic and clearly identifiable form like the star on a flat grey.

 

This require some test, but maybe you could have better result if you had a noisy background like this (1 sec search, you can do much better) than the flat grey you use ?

EDIT : forget about the noisy solution... it change nothing

Edited November 13, 2017 by HaArLiNsH

[Cetera]

7 hours ago, HaArLiNsH said:

@Cetera I'm also trying with the nvida plugin in photoshop but I got pretty much the same result, DXT1 and DXT5 give the same lossy result

And in the setting menu , we can see that the compression grid seems to be 5x5, witch is really bad for "low res" textures.

I think this is a limitation of the compression method. Nothing we can change.

I can see 2 solutions for this :

- bigger resolution

- more "noise" in the draw, I mean if you have an image with a lot of "noise" and elements, you would notice less artefact than when you have a clean draw of a basic and clearly identifiable form like the star on a flat grey.

 

This require some test, but maybe you could have better result if you had a noisy background like this (1 sec search, you can do much better) than the flat grey you use ?

EDIT : forget about the noisy solution... it change nothing

LOL, good work testing though!  Oh well.

One more time, 'cause I'm a slow learner.  What config option do I need to have in my config file to make TRR use the EVA Space textures for the EVA Surface?

Oh, dang, do the Normal Maps need to be clamped too when converting to DDS?  I forgot to ask.

[Aelfhe1m]

30 minutes ago, Cetera said:

What config option do I need to have in my config file to make TRR use the EVA Space textures for the EVA Surface?

Just add a block like this to your config beneath the folders section for each suit:

// use the name of the suit folder here
PilotRedSuit 
{
    suit_EvaGround_NoAtmo = 2 // default = 1
    helmet_EvaGround_NoAtmo = 2 // default = 1
		
    // optional
    visor_EvaGround_Atmo = 2 // default = 3
}

What the numbers mean: https://github.com/HaArLiNsH/TextureReplacerReplaced/blob/master/GameData/TextureReplacerReplaced/%40Default.cfg#L435-L440 

[Cetera]

3 minutes ago, Aelfhe1m said:

Just add a block like this to your config beneath the folders section for each suit:

// use the name of the suit folder here
PilotRedSuit 
{
    suit_EvaGround_NoAtmo = 2 // default = 1
    helmet_EvaGround_NoAtmo = 2 // default = 1
		
    // optional
    visor_EvaGround_Atmo = 2 // default = 3
}

What the numbers mean: https://github.com/HaArLiNsH/TextureReplacerReplaced/blob/master/GameData/TextureReplacerReplaced/%40Default.cfg#L435-L440 

Which suit number corresponds to which suit state?  Maybe that's a better question, and one I haven't grokked from the documentation.

 

NVM, it is in the config.  I was was right the first time... I'm just a little slow!

            // 0 = IVA,
            // 1 = EVA GROUND,
            // 2 = EVA SPACE 

Edited November 14, 2017 by Cetera

[Wyzard]

10 hours ago, HaArLiNsH said:

I guess its related to the fact that the new compression method need DX11+. Thus even if it worked, this won't do good for Linux KSP

FWIW: OpenGL supports the newer compression formats with an optional extension called BPTC, but because it's optional, not all systems may support it.  My Linux PC with an nVidia card supports BPTC, but my 2016 MacBook Pro with Intel GPU does not.  (The GPU driver matters more than the OS, really.)

[Cetera]

Mwuahahahahahahahahaha!

I say again:

Mwuahahahahahahahahaha!

 

Sometime between the most recent build, and the last build I fully tested in TRR, the auto-conversion from PNG to DDS got a LOT improved.  I can release my suit pack in PNG, let the game convert them when it loads, and get a much, much better conversion than me mucking about with these standalone tools.  It looks a lot like this one, honestly:

 

I'll take it.

I have a folder of 221 PNG files that I have to manually flip right-side-up again, but they are named properly.  (Yes, I know, stupid for me to save over the ones I flipped!  I have the originals still, but they aren't named properly for TRR, and I think it's faster for me to re-flip than to rename.)

[Cetera]

OK, need a rewrite of my config by someone who knows what the heck they are doing.  I'm having no success.  I've had help in the past, but I've clearly messed something up, and no suits are being assigned by class currently.

Here's my config:

https://www.dropbox.com/s/1gtua0c1b9lozlg/CeteraSuits.cfg?dl=0

 

I want all EvaSpace suits to be used for EvaGround suits.  I have folders set up for each class.  I have Space and Ground visor textures, and have specified visor base color and reflection colors specified in the config too.  I want them all the same, so if there is a way to do it universally rather than by each suit folder, that'd be good.

[HaArLiNsH]

9 hours ago, Cetera said:

Mwuahahahahahahahahaha!

I say again:

Mwuahahahahahahahahaha!

 

Sometime between the most recent build, and the last build I fully tested in TRR, the auto-conversion from PNG to DDS got a LOT improved.  I can release my suit pack in PNG, let the game convert them when it loads, and get a much, much better conversion than me mucking about with these standalone tools.  It looks a lot like this one, honestly:

 

I'll take it.

I have a folder of 221 PNG files that I have to manually flip right-side-up again, but they are named properly.  (Yes, I know, stupid for me to save over the ones I flipped!  I have the originals still, but they aren't named properly for TRR, and I think it's faster for me to re-flip than to rename.)

I did NOT changed anything on the conversion side   and what you are showing is the "crappy" DXT1 with BC1 compression that seems to be what TRR/KSP does when converting. Better convert it on your side first, KSP load slower and TRR need to purge nearly 1Go of RAM after it has converted and unloaded (it save RAM yes, but you still need to have have this free space on them so the conversion can be done.. so it wont work well on lower machine)

 

I found the problem of the .cfg file !   I need to change how I look for the cfg when there is more than 1 cfg  (typically when you have multiple texture pack , so TRR + a texture pack = 2 cfg). Right now, it load correctly the cfg but when he read another cfg without the cfg for your suit (so for example the default.cfg) , it change the loaded config with the default one (as it suposed to do when there a no cfg). I'll fix that

EDIT: more search has showed me the real problem (I didn't saw that when testing), TRR loads the cfg file with the same alphabetical order of the folder in gamedata, I  did not noticed that because my test folder is named TRR_Guide and so the .cfg is loaded after the one from TextureReplacerReplaced. With a folder named Cetera, it load before (so it does Cetera -> TextureReplacerReplaced -> TRR_Guide). Off course, I wont oblige you to name your folder with a naming convention , I'll find a solution

Edited November 14, 2017 by HaArLiNsH

[Cetera]

@HaArLiNsH I'm not sure what the difference is then.  Maybe it is the flag in the config turning compression off?  I am pretty sure I had it set before, but there's always the possibility that my config was no good.  I'm not terribly good at writing them.  However, to illustrate the quality differences, here is my level 5 veteran pilot suit, first with using the DDS file as converted by by the nVidia DDS Converter 1.4, and then using PNG unconverted.

nVidia DDS Converter 1.4:

 

PNG unconverted:

 

 

That is a huge difference in quality, and why I've been so grumpy with the DDS files.  There are still some minor compression artifacts in whatever conversion is done loading the PNG files, but it is very minor.  Everything is clearer and cleaner.  Detail differences are wildly apparent on the helmet, but also on the jetpack too.  

At this point, with that level of quality difference, there's absolutely no way I'll be releasing my suit pack with DDS files, unless someone else wants to convert them for me and can achieve the level of quality that occurs when using PNG.  The difference is too much.  The DDS textures look like crap in-game.

 

[HaArLiNsH]

16 minutes ago, Cetera said:

@HaArLiNsH I'm not sure what the difference is then.  Maybe it is the flag in the config turning compression off?  I am pretty sure I had it set before, but there's always the possibility that my config was no good.  I'm not terribly good at writing them.  However, to illustrate the quality differences, here is my level 5 veteran pilot suit, first with using the DDS file as converted by by the nVidia DDS Converter 1.4, and then using PNG unconverted.

nVidia DDS Converter 1.4:

 

PNG unconverted:

 

 

That is a huge difference in quality, and why I've been so grumpy with the DDS files.  There are still some minor compression artifacts in whatever conversion is done loading the PNG files, but it is very minor.  Everything is clearer and cleaner.  Detail differences are wildly apparent on the helmet, but also on the jetpack too.  

At this point, with that level of quality difference, there's absolutely no way I'll be releasing my suit pack with DDS files, unless someone else wants to convert them for me and can achieve the level of quality that occurs when using PNG.  The difference is too much.  The DDS textures look like crap in-game.

 

OMFG , yeah its horrible in .dds

hmm Ok let me figure out a good solution for this. I'm still not familiar with the compression/conversion things in TR/TRR (didn't had the time to look yet). I'll look at that asap because I'm sure I have the same problem with the texture bundled with TRR (and in my future texture pack, I did not noticed it yet because I'm still at the .png/development phase)

Meanwhile, I've fixed the .cfg setting problem and even improved it : you can now also override the DEFAULT_SUIT in your .cfg. (useful for the Tourist class)

I'll now "fix" your texture pack (name, settings) and propose you how I saw the veteran (and even badass) for your suit pack. It should be "trivial" to do  

And also get the new version of TRR released ...

Edited November 14, 2017 by HaArLiNsH

[HaArLiNsH]

@Cetera : I wont have the time to do the TRR's release today, if you want to test it anyway, you can download the 0.5.2 branch on github:

To install it : delete your old TRR folder and copy both folder from the GameData folder you will find in the .zip, respectively "000_TRR_Config" and "TextureReplacerReplaced"

000_TRR_Config/ is the new place for the (renamed now) @Default.cfg

The female badass jetpack is also fixed and some button label have been changed to be more understandable.

 

I will also make a new version fo the TRR_guide, I saw that I forgot to put the informations in the .cfg for the suits (that's why you could only find these in the @Default.cfg)

 

 

[Cetera]

1 hour ago, HaArLiNsH said:

@Cetera : I wont have the time to do the TRR's release today, if you want to test it anyway, you can download the 0.5.2 branch on github:

To install it : delete your old TRR folder and copy both folder from the GameData folder you will find in the .zip, respectively "000_TRR_Config" and "TextureReplacerReplaced"

000_TRR_Config/ is the new place for the (renamed now) @Default.cfg

The female badass jetpack is also fixed and some button label have been changed to be more understandable.

 

I will also make a new version fo the TRR_guide, I saw that I forgot to put the informations in the .cfg for the suits (that's why you could only find these in the @Default.cfg)

No worries, make haste slowly.  I spent a lot of time messing with it last night, letting other things drop.  I won't have much more time to tinker this week.

[HaArLiNsH]

1 hour ago, Cetera said:

No worries, make haste slowly.  I spent a lot of time messing with it last night, letting other things drop.  I won't have much more time to tinker this week.

I looked at the compression & mipmap generation code, and I was wrong and I mixed some old souvenirs together. It was Active Texture Management that converted the .png in .dds. Since KSP 1.XX, it seems that Unity does it by itself. 

I think its time to change some things, since we can (and all should) play in 64bits, I wont bother with that

I tested the pack you PM'd me and I tried different settings :

The helmet in middle is the .dds (DXT5) , the rest are in .png

As we can see, the quality is better better on the .png (the left one on the second picture) AND the colour is different on the .dds ! you can clearly see that on the first picture, the grey is more white, only you can tell us witch one is the closest to your creation  

I seems that KSP still convert and compress the .png but I don't know the compression method

Finally I tried with adding the

generateMipmaps = ^Cetera/

in your .cfg, and I must say this is HORRIBLE for the .png ! The .dds does a better job because it already has them.

All these tests where done with the setting

isCompressionEnabled = never

Well I think its time for the default settings to change, I will disable by default the compression and mipmap generation. I see that there are multiple mods that seems to be using these mipmap generation but I think this is from an old and ugly time where compromise had to be made. For example I see UmbraSpaceIndustries inside by default and I can confirm that it convert a number of texture. In all honestly, I can't let TRR degrade hard works like that just to save a tiny amount of RAM space when we can have so much space now.

So for now, I think I'll suggest to make them in .png compressed. This is the best middle ground. TRR's Unloader can handle the freeing of space needed for the .png  

I tried .tga but the result where poorer than .png.

 

 

 

 

 

@RoverDude  : Maybe you can help us a bit on the question : I see you have your UmbraSpaceIndustries folder that was included with TR for the mipmap generation. I see that some of your textures are in .png and others in .dds. Can you explain me why ? Is it because of time or better results for some textures ?

Also , are the mipmaps really obligatory ? I don't really see the differences when I use them or not on a Kerbal, is there a way to see when/why they are a needed?

Lastly, Do you mind if I remove I disable the mipmap generation for your mod in TRR or do you want to keep it ? I think I will disable it by default and if people need it, they still can put the setting in their config.  (I'm not talking about the unloading, witch need to stay)

Edited November 14, 2017 by HaArLiNsH

[Cetera]

Very nice work, @HaArLiNsH.  I'm glad you're understanding my dilemma now.  I'm not savvy enough to be able to communicate it fully, I think, and have too little experience knowing for certain which item is working or not and which variable is the root cause.  I'm glad you've got it sorted, and I look forward to future releases with the highest quality possible for TRR textures!

[Doxel]

So, I was looking at Cetera's cfg file, and I noticed that it was structured like this:

Spoiler

TextureReplacerReplaced
{
  Folders
  {
    Suits = Cetera/Suits/
  }
  // etc
}
@TextureReplacerReplaced:AFTER[TextureReplacerReplaced]
{
  SuitSettings
  {
    CetPilot
    {
      suit_EvaGround_NoAtmo = 2
    }
  }
  // etc
}

I started wondering why half was done through ModuleManager, since TRR is supposed to pull all the cfg files in alphabetical order, and the default file has an @ so it should come first and get overwritten. Shouldn't it be possible to just write it like this?

Spoiler

TextureReplacerReplaced
{
  Folders
  {
    Suits = Cetera/Suits/
  }
  SuitSettings
  {
    CetPilot
    {
      suit_EvaGround_NoAtmo = 2
    }
  }
  // etc
}

I rewrote Cetera's file like that and did a little experimenting. I quickly discovered that TRR actually DOES use alphabetical order, but it includes the folder names in the ordering. A file named "GameData/Cetera/test.cfg" gets overwritten by TRR's default cfg, but the same file named "GameData/ZZZAfterTextureReplacerReplaced/test.cfg" does not get replaced. The only other way to make Cetera's suit setting work right seems to be ModuleManager, since "Cetera" comes before "TextureReplacerReplaced" alphabetically.

You might want to try and find away around that, so modders don't have to make all their mod names start with Z or use ModuleManager. Or if not, maybe include a mention in the readme that ModuleManager is required if you do not put your file in the TextureReplacerReplaced folder.

[Cetera]

3 minutes ago, Doxel said:

So, I was looking at Cetera's cfg file, and I noticed that it was structured like this:

  Hide contents

TextureReplacerReplaced
{
  Folders
  {
    Suits = Cetera/Suits/
  }
  // etc
}
@TextureReplacerReplaced:AFTER[TextureReplacerReplaced]
{
  SuitSettings
  {
    CetPilot
    {
      suit_EvaGround_NoAtmo = 2
    }
  }
  // etc
}

I started wondering why half was done through ModuleManager, since TRR is supposed to pull all the cfg files in alphabetical order, and the default file has an @ so it should come first and get overwritten. Shouldn't it be possible to just write it like this?

  Hide contents

TextureReplacerReplaced
{
  Folders
  {
    Suits = Cetera/Suits/
  }
  SuitSettings
  {
    CetPilot
    {
      suit_EvaGround_NoAtmo = 2
    }
  }
  // etc
}

I rewrote Cetera's file like that and did a little experimenting. I quickly discovered that TRR actually DOES use alphabetical order, but it includes the folder names in the ordering. A file named "GameData/Cetera/test.cfg" gets overwritten by TRR's default cfg, but the same file named "GameData/ZZZAfterTextureReplacerReplaced/test.cfg" does not get replaced. The only other way to make Cetera's suit setting work right seems to be ModuleManager, since "Cetera" comes before "TextureReplacerReplaced" alphabetically.

You might want to try and find away around that, so modders don't have to make all their mod names start with Z or use ModuleManager. Or if not, maybe include a mention in the readme that ModuleManager is required if you do not put your file in the TextureReplacerReplaced folder.

One thing I was having issues with when writing my config file (and seriously, I have such limited knowledge of how MM actually works I am probably doing something wrong -- half of my current config was written by someone else months ago as an example to show me what I'm doing):

If I named my Mod "CeteraSuits" in the config file, instead of "TexutreReplacerReplaced" nothing I put in the config ever worked.  If instead the first line was "TextureReplacerReplaced" then it worked.  Is this part of what you're talking about?

[Doxel]

2 minutes ago, Cetera said:

If I named my Mod "CeteraSuits" in the config file, instead of "TexutreReplacerReplaced" nothing I put in the config ever worked.  If instead the first line was "TextureReplacerReplaced" then it worked.  Is this part of what you're talking about?

Not exactly. If you are talking about the first line of your config, that does have to be TextureReplacerReplaced. TRR only looks for TextureReplacerReplaced objects in cfg files, not CeteraSuits objects, so it needs to be named right for TRR to find it.

What I was talking about was the order of overwritting. Whoever wrote your cfg file cleverly used ModuleManager to make sure your settings go in last, but they really shouldn't have to have, since TRR is supposed to load Cetera.cfg afterthe default one.

This is easiest to see if you are making a file that overwrites the default suit. I tested this by making a file that sets suit_EvaGround_NoAtmo to two for the default suit, thinking that all of your suits would inherit that behavior and you wouldn't have to specify it for every single one. Again, it only worked if it was in a folder after TextureReplacerReplaced alphabetically. The same file functioned in a folder named ZZZCetera, but not in one named Cetera.