Jump to content

[1.3.1]TextureReplacerReplaced v0.5.4


HaArLiNsH

Recommended Posts

3 minutes ago, Doxel said:

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.

I think I'm beginning to understand.

So would my config file linked above have worked if I had put it in a ZCetera folder?  'Cause the only thing that config ever did was assign suit folders to class.  Nothing else in it ever worked for me, and I wasn't sure if I had naming conventions incorrect, or if I didn't have the proper nodes, or something.

Link to comment
Share on other sites

1 hour ago, Cetera said:

I think I'm beginning to understand.

So would my config file linked above have worked if I had put it in a ZCetera folder?  'Cause the only thing that config ever did was assign suit folders to class.  Nothing else in it ever worked for me, and I wasn't sure if I had naming conventions incorrect, or if I didn't have the proper nodes, or something.

Yeah, in fact I tested pretty much exactly that. I made a file that looked pretty much just like this:

TextureReplacerReplaced
{
	Folders
	{
		Default = Cetera/Default/
		Suits = Cetera/Suits/
	}
	ClassSuits
	{
		Pilot		= CetPilot
		Engineer	= CetEngineer
		Scientist	= CetScientist
		Kolonist	= CetKolonist
		Miner		= CetMiner
		Technician	= CetTechnician
		Mechanic	= CetMechanic
		Biologist	= CetBiologist
		Geologist	= CetGeologist
		Farmer		= CetFarmer
		Medic		= CetMedic
		Quartermaster	= CetQuartermaster
		Scout		= CetScout
		Tourist		= DEFAULT
	}
	SuitSettings
	{
		DEFAULT_SUIT
		{	      
			suit_EvaGround_NoAtmo = 2       
			helmet_EvaGround_NoAtmo = 2      
			visor_EvaGround_NoAtmo = 2    
			jetpack_EvaGround_NoAtmo = 1
		}
	}
}

No need for all the individual suit settings, since they inherit from default. The only caveat is that this file has to get loaded after the default one, so it has to either go into a folder named ZCetera in GameData, or the TextureReplacerReplaced folder itself.

EDIT: Okay, confirmed. The above cfg file works to get what you want. If you make a new save file (or go into the suits menu and hit "Reset All To Defaults" on an already existing save) then you will get deep space suits in place of the non-atmospheric ground suits. You just have to move the file out of the Cetera folder and into the TextureReplacerReplaced folder (or any folder after that). As soon as TRR gets patched to ignore folder names when deciding what order to look at the cfgs, you should be able to move the cfg back into the Cetera folder, but until then moving the file seems a better solution that forcing things in with ModuleManager. I should have done this way earlier, since I always use your suits anyway and I was starting to miss them.

Oh, and the reason your original cfg file didn't work was a mismatched bracket.

Edited by Doxel
Adding the results of additional testing.
Link to comment
Share on other sites

1 hour ago, Doxel said:

Yeah, in fact I tested pretty much exactly that. I made a file that looked pretty much just like this:


TextureReplacerReplaced
{
	Folders
	{
		Default = Cetera/Default/
		Suits = Cetera/Suits/
	}
	ClassSuits
	{
		Pilot		= CetPilot
		Engineer	= CetEngineer
		Scientist	= CetScientist
		Kolonist	= CetKolonist
		Miner		= CetMiner
		Technician	= CetTechnician
		Mechanic	= CetMechanic
		Biologist	= CetBiologist
		Geologist	= CetGeologist
		Farmer		= CetFarmer
		Medic		= CetMedic
		Quartermaster	= CetQuartermaster
		Scout		= CetScout
		Tourist		= DEFAULT
	}
	SuitSettings
	{
		DEFAULT_SUIT
		{	      
			suit_EvaGround_NoAtmo = 2       
			helmet_EvaGround_NoAtmo = 2      
			visor_EvaGround_NoAtmo = 2    
			jetpack_EvaGround_NoAtmo = 1
		}
	}
}

No need for all the individual suit settings, since they inherit from default. The only caveat is that this file has to get loaded after the default one, so it has to either go into a folder named ZCetera in GameData, or the TextureReplacerReplaced folder itself.

One of the things I was trying to do with my pack was prevent conflicts if anyone installs any other suit pack in the future.  I put copies of the normal maps in each suit folder, for example.  Is there a config code that can apply to all of my suits, but not alter the universal TRR default?  That's why I listed each one of my suits with all the same config info.

Also, would I just put the visor color settings in that same section you have the suit/helmet/visor/jetpack listed in now?

Link to comment
Share on other sites

2 minutes ago, Cetera said:

One of the things I was trying to do with my pack was prevent conflicts if anyone installs any other suit pack in the future.  I put copies of the normal maps in each suit folder, for example.  Is there a config code that can apply to all of my suits, but not alter the universal TRR default?  That's why I listed each one of my suits with all the same config info.

Also, would I just put the visor color settings in that same section you have the suit/helmet/visor/jetpack listed in now?

Yes, if you wanted to avoid any conflicts then you would need to specify for each suit. Just use the structure I put above, duplicating it under the name of each suit instead of using DEFAULT_SUIT. You do not need to include settings that are not changed, so just add entries for the four EvaGround_NoAtmo entries and the visor entries. No ModuleManager needed, as long as you move your cfg to load after the default cfg.

Link to comment
Share on other sites

@Cetera and @Doxel  : I've noticed the alphabetical problem yesterday, don't worry about it, I fixed the problem for the TRR 0.5.2, I've added a 000_TRR folder with the old @Defaul.cfg moved inside. No more problem with any name modder could use (well .. dont use something that goes before 000_)  

Also Cetera, your cfg file is indeed totally broken, but don't worry, I make it right  and I'll send it back to you tomorrow if all goes well and I can PM your Suit pack back :)

Edited by HaArLiNsH
Link to comment
Share on other sites

30 minutes ago, Doxel said:

Clever Solution. Although, come to think of it, why not just rename TRR's main folder? If you just added an @ and called it @TextureReplacerReplaced, then you wouldn't need two folders for the mod.

Hmm, well I didn't though about this one :) 

I'll try this, one folder is indeed better for me.

 

EDIT : forget that idea, I noticed the problem of this too, TRR MUST be named after the SQUAD folder, otherwise, it can't replace the texture that are loaded in the Squad's folder .. :)

Edited by HaArLiNsH
Link to comment
Share on other sites

Here with latest KSP 1.3.1. and latest CKAN, CKAN will not update (button keeps grey) by telling not found a "TextureReplacer.dll"
in the "Updating Repositories" tab. Sure, the new one is "TextureReplacerReplaced.dll".

My work around is to keep the old dll in, renamend to ".dll_", and if i need to update i renamed it back to .dll, after updating back "dll_".
Think i could rename the new one and edit the config files... ;-) But i keep it to avoid possible future inconsistency.

Sorry, if somewhere back in this thread this behavior is already posted.

And of course, thousends thanks to keep this mod alive and maintainanced!

Edited by Jansn67
Link to comment
Share on other sites

3 hours ago, Jansn67 said:

Here with latest KSP 1.3.1. and latest CKAN, CKAN will not update (button keeps grey) by telling not found a "TextureReplacer.dll"
in the "Updating Repositories" tab. Sure, the new one is "TextureReplacerReplaced.dll".

My work around is to keep the old dll in, renamend to ".dll_", and if i need to update i renamed it back to .dll, after updating back "dll_".
Think i could rename the new one and edit the config files... ;-) But i keep it to avoid possible future inconsistency.

Sorry, if somewhere back in this thread this behavior is already posted.

And of course, thousends thanks to keep this mod alive and maintainanced!

You can't update TextureReplacer (TR) by TextureReplacerReplaced (TRR) , they are different beasts :)

Uninstal TR and simply instal TRR .

Link to comment
Share on other sites

New Release of TRR : V0.5.2 :

Quote

I've found bugs with the new folder system and some naming choice for your custom folder. I made some structural change to TRR to resolve this :

  • added a second folder named 000_TRR_Config that is the new place for the default .cfg of TRR. DON'T TOUCH THAT FOLDER

I've also found a loading order bug that can happen if you name your folder with a name that goes before TextureReplacerReplaced (it happen too with the squad folder). As KSP load the mods in gamedata by an alphabetical order, if you name your custom folder in a way that it load before the Squad folder (or TRR), like if you name it "MyCustomFolder", the engine load the squad (and TRR) folder after your custom one and thus, override your custom texture (if you changed a squad texture or a default suit texture in TRR).

SOLUTION : I Strongly encourage you to name your custom folder with the prefix "TRR_ "
Like "TRR_MyCustomFolder". (Or with a name that goes alphabetically after TextureReplacerReplaced). I suggest "TRR_" so people will be able to find them easily in CKAN as they will go next to each others.

I fixed the jetpack_EvaSpace_Badass_Female choice that selected the default one instead.

Lastly, I changed the setting for the visors so the reflections seems less white
(reflections colors from 255,255,255,255 to 128,128,128,255)
You can still off course change them to you liking.

I STRONGLY RECOMMEND YOU TO RESET TRR !
either by

  • pushing the "reset TRR button" and the "reset all" in the head,suit and visor menu
  • deleting your "TRR_Scenario" in your persistant.sfs file.

Installation :

  • if you update from CKAN, check if the file "@TRR_Default.cfg" has not stayed in the "TextureReplacerReplaced" folder.
  • If you update manually, delete the old "TextureReplacerReplaced" folder and paste BOTH folder from the .zip

 

Link to comment
Share on other sites

13 hours ago, HaArLiNsH said:

New Release of TRR : V0.5.2 :

I've found bugs with the new folder system and some naming choice for your custom folder. I made some structural change to TRR to resolve this :

  • added a second folder named 000_TRR_Config that is the new place for the default .cfg of TRR. DON'T TOUCH THAT FOLDER
2

I see the new folder is included in the download from Github, but when I updated through CKAN it doesn't appear to have updated correctly. Just a heads up for you.

Link to comment
Share on other sites

12 minutes ago, IntoSpaceAgain said:

I see the new folder is included in the download from Github, but when I updated through CKAN it doesn't appear to have updated correctly. Just a heads up for you.

Thank you for the report, I was wondering if CKAN updated correctly

Link to comment
Share on other sites

My suit pack is undergoing the last finishing touches and testing.  It should be available by no later than this weekend.  I'll have a separate release thread for it that I'll link here.

I will need volunteers to make a CKAN profile or whatever for it, so it can be updated that way.  

If I update my existing SpaceDock profile mod (https://spacedock.info/mod/282/Cetera's Suit Mod) will it break things for current users on previous versions in CKAN, or mess things up for the future since TRR instead of TextureReplacer is required?

 

Here's an album of suit pics for those who are interested:  

https://imgur.com/a/TZdy4

 

Edited by Cetera
Imgur links still don't seem to work properly.
Link to comment
Share on other sites

New version of TRR released V0.5.3

This one should solve the last CKAN installation problem.

No update on the reflections yet.

 

@Cetera  : I think the safest way to allow people to still use your old version for TR is to make another mod release on space dock. You could call it "Cetera's Suit Mod for TRR"  or something that indicate that this is the TRR's version. It will differentiate it from the TR 's version and will preserve it.

I can make your netkan pull request if you want (I just made 3 of them so its fresh for me). Or you can gently ask @linuxgurugamer :)  (I will ask him to check the PR if I make it anyway).

edit : ps: if the imgur album don't work natively, Link one image (the best one) that should appear normally on the page, and give another link with the album. This way, even if the system don't goes well, people see at least one good picture.

 

Edited by HaArLiNsH
Link to comment
Share on other sites

37 minutes ago, Poodmund said:

@Cetera if you want to make your texture mod compatible with TR and TRR, check out my Skybox listings on Spacedock. They are set up to work with TR but have the necessary MM config to allow TRR to recognise them and get them to function. It's pretty simple.

Your idea of using TextureReplacer as custom folder is good but you should NOT do that.

I'm pretty sure you WILL have problem with updates on CKAN. If another modder use that name and push an update, it will screw yours (or you could screw his). The custom folder was made to allow you to have your OWN folder that you can update SAFELY as you want independently of the others textures mods, with the only (newly discovered) limitation that it should load after TextureReplacerReplaced to avoid any conflict in texture loading order (that's why I suggest the folder name "TRR_TheNameYouWant", you could use "TRR_PoodMund").

You didn't noticed this problem probably because you are, as far as I know,  the only one using TextureReplacer as custom folder :)

I strongly advice you to change that.

I don't want to impose you a brand "TRR" or something, you can name it "ZPoodmund" it will work, it just has to load after TextureReplacerReplaced  and have a name different from the others mods. The "TRR_" is just here to help the unknowing user to know the relation between your mod and TRR and help regroup the differents texture pack.

 

Edit : I though of an example, WindowShine replace the default pod textures, if it was named aWindowShine, the default textures in the Squad folder would load after his and thus replace them. Same rules for everyone make the system safe, name it alphabetically  AFTER TextureReplacerReplaced with a unique name :)

Edited by HaArLiNsH
Link to comment
Share on other sites

9 minutes ago, linuxgurugamer said:

An FYI, the CKAN names cannot have an underscore:


#   Failed test 'TRR_Guide: CKAN identifiers must consist only of letters, numbers, and dashes, and must start with a letter or number.'
#   at t/metadata.t line 27.
#                   'TRR_Guide'
#     doesn't match '(?^:^[A-Za-z0-9-]+$)'

OMFG :o

http://nooooooooooooooo.com/

 

The folder can still be named TRR_ but not the identifier if I understand that well?  TRR-Guide as identifier will work ?

So does people can use the identifier with the name they want (Cetera, PoodMund, Etc) and still use a folder named "TRR_TheNameyouWant" ?

Or the "TRR_" prefix idea is just a bad idea ?  I don't want to impose anything , people can use the name they want but this is really safer (and sometimes critical) that the name goes after TextureReplacerReplaced. This is not by me, this is how Unity load the folders in GameData. Or do you know a trick to use the folder name you want and impose a loading order to unity ?

 

 

Edited by HaArLiNsH
Link to comment
Share on other sites

4 hours ago, HaArLiNsH said:

Your idea of using TextureReplacer as custom folder is good but you should NOT do that.

I'm pretty sure you WILL have problem with updates on CKAN. If another modder use that name and push an update, it will screw yours (or you could screw his).

You didn't noticed this problem probably because you are, as far as I know,  the only one using TextureReplacer as custom folder :)

I strongly advice you to change that.

CKAN has no issues with any mods using the same folders or folder structure as long as they don't try to replace/change files with the same filenames. Therefore, using the TextureReplacer folder a way to make mods cross compatible between TR and TRR should be fine as long as all included files are uniquely named (depending on what texture mods are used... in this case, Skybox mods should be unique as only 1 can be installed).

I'd suggest you understand how CKAN manages its file handling before misinforming others as to how to structure their add-ons. :wink: 

Link to comment
Share on other sites

1 minute ago, Poodmund said:

CKAN has no issues with any mods using the same folders or folder structure as long as they don't try to replace/change files with the same filenames. Therefore, using the TextureReplacer folder a way to make mods cross compatible between TR and TRR should be fine as long as all included files are uniquely named (depending on what texture mods are used... in this case, Skybox mods should be unique as only 1 can be installed).

I'd suggest you understand how CKAN manages its file handling before misinforming others as to how to structure their add-ons. :wink: 

The problem comes from the fact that they use the same name. In the past I have lost several time different textures when updating TR by CKAN. I totally agree with that for the experienced user, but the non experienced could have problems when trying things. Off course this can even be avoided if you put "conflicts" settings to avoid multiple skyboxes. I still believe its easier to see what mod you have if you name them properly in the Gamedata folder.

If it was my skyboxes, I would make one custom folder for each, just for human readability. And wouldn't be better for your pride to have your own named folder ? :wink:

I don't think TR will ever be updated, you don't really need cross compatibility.

I just suggest, nothing is imposed as I tried made TRR as open as possible. The custom folder system is great but you need to know that there are some problem that can occur if you make some configurations and folder name choice. 

After that, you can do what you want and I really appreciate the feedback, never stop learning things.  :)

 

Link to comment
Share on other sites

Your link to an example folder of a sample texture mod outside of TRR is broken. I really need you to fix it so I can figure out how I am supposed to make a folder outside of TRR that has the textures I want to use, that it can read. I did not understand the readme at all.

Edited by Pavel ☭
Link to comment
Share on other sites

Hey, I'm getting some weird behavior with this mod. When I launch a new vessel all the male Kerbals have the helmets on in the capsule but the females don't. When I reach space all of them have helmets, and when I land they all take them off. But when I go on EVA right after launching the vessel only the males wear it. It's not causing trouble but it's definitely funky behavior that should get fixed.

Link to comment
Share on other sites

This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...