Manwith Noname

@DeliriumTrigger Confirmed. Just downloaded everything and tested it. Aside from launching you can also save and reload the craft in the editor to fix the rendering issue. It seems like something weird with material changes and render layers causing it that gets fixed with a full refresh / reload.

@DeliriumTrigger Putting my money on Depth Mask. I had that in the back of my head in the earlier post as I can recall experiencing issues with it in the past. My recollection was that it broke recolouring though but it kinda fits with what you see. Edit: Actually the more I think about it, it did what you kinda see. Certain viewing angles of where the depth mask was would make the rest of the part invisible. This was back in 2019 though and I may not have had mesh targets on everything...but this is still broken for some reason.

@Akagi You don't necessarily need to open the .mu file. You can often just go by what the textures show you in photoshop or GIMP coupled with the mesh export function of TU. If you want to work in 3D, like Blender, you need to get the KSP blender tool plugin. @DeliriumTrigger I don't mind looking through the module manager cache, even if it's huge (CTRL+F for the win) I am mainly curious to see if we can find anything because even if it cannot be resolved, assuming we find the problem, at least we then know what the problem is.

Yes. Probably the simplest thing to do is install the stock recolour, copy the Recolour_Texture_Sets.cfg and Colour_Presets.cfg files and move them up one level out of the TU_Stock_Recolour folder. Do the same with the Metal_Texture_Sets.cfg file inside TU_Extras. You can now delete both those folders. Then in the TU_Standardised_Switching folder keep the standardised texture sets config but delete the other two configs. You basically want to end up with all the Texture Sets config files, the colour presets (though these are not overly critical) and the placeholder textures. The textures need to remain in the folder path they come in or you need to edit all the file paths in the configs to match wherever you put them. Alright, that's a bit weird and I suspect a conflict of some kind. First thing that comes to mind is another TU config set, typically those that apply a metallic look to a bunch of stuff just through text files and not with textures. It used to be the case that the Texture Switch module would simply override MODEL_SHADER configs but maybe something is amiss. Perhaps the best thing to do is paste the contents of you module manager cache file to somewhere like pastebin and drop a link here and I'll see what I can see with regard to how the part ends up. Procedural Parts should come with its own set of TU configs but you need a specific fork, like this one.

Yes, you just need to insert the line... crew = #autoLOC_20827 ...in to the Mk1-3 Pod PART module of the g_docking.sfs tutorial save state and start it again. Something like this... PART { name = mk1-3pod cid = 4294634394 uid = 3817944765 mid = 4004293368 persistentId = 643397188 launchID = 1 parent = 0 position = 0,0,0 rotation = 0,0,0,1 mirror = 1,1,1 symMethod = Radial istg = -1 resPri = 0 dstg = 0 sqor = 0 sepI = -1 sidx = 0 attm = 0 sameVesselCollision = False srfN = , -1 attN = bottom, 4 attN = top, 1 mass = 2.31799984 shielded = False temp = 304.62609337808368 tempExt = 305.11675208761795 tempExtUnexp = 305.11673133775491 staticPressureAtm = 0.98840547378581445 expt = 0.5 state = 0 attached = True autostrutMode = Off rigidAttachment = False flag = Squad/Flags/default rTrf = _default modCost = 0 modMass = 0 moduleVariantName = moduleCargoStackableQuantity = 1 crew = #autoLOC_20827 EVENTS { } ..... You could also edit the persistent.sfs the game created when you tried to play the tutorial and continue but I would suggest starting the tutorial again.

As a result of a discussion elsewhere I performed some checking of files and the replacement docking tutorial save appears to have omitted the crew from the "Kerbal Rescuer" ship. In the original file, Valentina is the assigned crew member. crew = #autoLOC_20827

A brief report from an initial install and run... https://github.com/meirumeiru/InfernalRobotics/blob/develop/Resources/GameData/MagicSmokeIndustries/Parts/Rework_Utility/Probe/Misc/IR_DockingPort/part.cfg MODEL { model = Squad/Parts/Utility/dockingPortJr/model } ...needs changing to... MODEL { model = Squad/Parts/Utility/dockingPortJr/dockingPortJr } Also of note, a few errors and exceptions on the large and small suspension. Looks like all the module indexes need to be incremented by 1 or move the IR Variants module to the end of the file. Edit: Just to say I haven't used anything in anger yet. Noticed the update, installed and ran. Spotted some errors and exceptions as I have them log to screen. Briefly glanced at what they were.

Batteries Not Now Included - An Electrical Overhaul The Stock Recolour pack has been updated to bring an overhaul and completeness to electrical components. Of note, the "new" shrouded solar panels on any existing craft may need to be checked (and will probably be broken) due to renaming of a texture set for surprise reasons. People may or may not notice the changes but kinda needed to be done to correctly implement...something. Also many of the older parts probably want checking on existing craft as they were previously only "placeholder" configured. Oh, and batteries can now be messed with. Still some things I want to tweak some time in the future but everything "should" be very close to whatever those changes may bring. As always, probably best to delete the existing stock recolour folders before extracting this one. Depending on exactly what the problem is, perhaps. First things first, make sure you are using the supplied version of Textures Unlimited. This has specific features that are not present in the stable public release relating to handling Part Variants. However it does sound potentially like an issue I am aware of with part variant behaviour. If it is this, there is a workaround, or there used to be. When painting a craft with multiple of the same part that uses part variants as opposed to the Textures Unlimited texture switch module, only one set of parameters can be "live". You will notice that if you place a part and paint it, placing a new piece of the same part will contain the same colour scheme for the same variant. Adjusting either one so they are now different but then launching the craft will result in them both displaying the most recently set scheme. At least I think this is how it worked, it's been a long time since I found this behaviour and worked it out. In any case, reverting back to the hangar and then correcting the variant that had been adjusted to a scheme you want, then launching again would result in both parts having independent schemes. I also seem to recall that painting, saving, reloading and painting works too. Essentially you need to get the colour scheme data saved in to the part of the craft file before you can adjust another part that has the same variant data. Again though, long time ago I discovered this and I'm just going from memory. I'll investigate a bit more when I have the time and report if it's anything different from what I've described. Gonna be honest, unlikely. I've got my hands full with getting the packs I've already created finished alongside a couple of other projects.

Alright, first things first... UPDATE It is advisable to delete the pre existing Stock Recolour installation The Stock recolour pack has been updated. Notable additions are things that were new in 1.12 but never got their lick of paint. So, new docking ports along with Swivel and Reliant engines. As I type this I just remembered an issue I spotted but can't recall if I fixed...such is life. Also of note, many parts have been tweaked or added among various other areas of the game. Forewarning, if you have recoloured and saved a structural beam or girder it will likely look weird now but only because the previous existing config was incomplete. In general, any craft that uses parts residing in the structural folder of the game files (not the in editer menu) may want a repaint. For visual reference... This likely also applies to many parts in the Utility folder (again, game files, not the editor menu). There's still many things I want to tweak / finish / add but now seems like a good point to upload what is done. While I've been busy stuff... Any discussion that is about creating configs is welcome to be added to the thread. I appreciate some cards may want to be held close to ones chest (like don't tell everyone your working on ReStock if you haven't even started it) but general "how do I do this?" and guidance for workflow is fine. We can all share and learn from each other. In all the zip files you should find a GameData folder. You can either extract that to the root install of your game or extract the contents of that GameData folder to the existing GameData folder of your install. The main thing to be aware of is not to create GameDataception by dropping the GameData folder inside the existing GameData folder. I think I need to type GameData one more time, so...GameData. To explain this, the included pack contains a dll file from the development branch of Textures Unlimited. This has added functionality specific to allowing increased configuration flexibility with the Stock ModulePartVariant. This is present on fairings among other things which is why using the dll that doesn't include this feature spits the error. There is a post somewhere in the earlier days of this thread I think that describes this but it's fairly simple to do so I'll type it here. Open the file 112x_Standardised_Switching.cfg in a text editor of your choice. Use the find and replace function to find... currentTextureSet = Stock_Default ...and replace all instances with... currentTextureSet = Alternate_Stock_Metallic This will for the most part do what you want. It will not work for parts which utilise the stock part variant module though. I did at one point start naming themes that would allow you to use the in game function but it got a bit messy so I mostly shelved it and planned on thinking about how best to do it. Some parts of that might remain if I didn't comment them out in the configs. Bye, have a beautiful time!

They can but I'm 99.99% sure they have some sort of conflict in their mod collection or they didn't install the pack correctly so it cannot find the placeholder normal map.

KSP should convert png files to the appropriate format but that might explain why your normal maps failed. A plain albedo / diffuse texture if it is only using the RGB layer can be DXT1. Anything that uses the alpha layer (like metal / gloss maps) should be DXT5. Normal maps want to be DXT5nm or BC7 BC5. If you export to BC7 BC5 you need to add the appropriate keyword in the config so TU knows.

Any part these configs alter already have a flat placeholder normal map applied. That has been the case since the project began. When the problem you are referring to appeared, the place holder normal maps were not affected by the issue. I would perhaps suggest if they are using the latest TU or recolour pack with KSP 1.9 then they should source something from that time but as far as tracking down conflicts with other mods that might be causing it...unfortunately they'll need to apply their own investigative methods amongst their 100+ mods. Edit: I would also suggest checking that the install is correct. If the texture is not found then this problem would likely return.

In a word, no. (EDIT: See edit below) I just downloaded the latest Scatterer and plonked it in my install, loaded up a basic craft painted with variations of the platinum metal all over (basically different levels of reflection) and it all behaves normally for me. Even tried different levels of reflection refresh thinking it might be that and got a whole load of nope in terms of recreating the effect from your video. So it's not directly scatterer per se from my experience but possibly a setting I haven't altered or something to do with scatterer and E.V.E combo. EDIT: Ok, I had some time to muck about a bit more and have managed to recreate the issue by adding E.V.E Redux in to the mix. I would also point out that it happens with just E.V.E Redux and no Scatterer. Why? Don't know. Something flickers / strobes in the reflection probe that isn't immediately obvious in the main scene. Possibly shadow related or perhaps the noise swirl thing that is going on. Can perhaps narrow it down with some config tweaking. Another edit: Yeah, if you make a part completely smooth you can see stroboscopic clouds.

It is supplied with Kerbalism. Edit: I will add, if you are thinking of creating recolour sets you can proceed without concern. Setting up recolour will override the KSP_MODEL_SHADER config.

@jonathan_92 The data for how a craft is coloured is stored inside the craft file and subsequently as part of the craft data within a save (persistence.sfs). This update should only cause issues on craft with the various docking ports if they used a recolour texture set. If it uses the blanket shine set it should be exactly as it was. If a file remains unchanged, it will also recall the correct settings when I finish the colour masks, provided I don't rename the texture set. Which I shouldn't. Also might be worth mentioning, if a texture set is missing and cannot be recalled, the part will just fall back to the stock look.

Heh, yeah and the MK1 Inline and the... Coming Soon™

@DasSkelett Thank you for the information. Heh, obviously I didn't check the report myself but I have previously seen a repo by someone that looks like it was intended to become files CKAN could access. To clarify my comment, I don't have an issue with CKAN or the repo I saw. It was just a response to say, other than knowing they exist I have no connection with what is available there, which it turns out is nothing from your comment. For everyone else, the stock recolour link has been updated. Hopefully, everything should be functional and correctly calling textures on all parts that were changed / new in 1.12. Basically docking ports should be fixed but missing recolour and the new solar panels are covered. Looking to the future, now Squad are finished with the game I do plan on revisiting parts I had expected they might remodel / retexture. I've also got some unfinished mod packs that I want to get through.

A brief but important notice covering some recently raised issues: Airplane Plus The change in behaviour with the prop blur is intentional due to lack of a shader that gave me the result I wanted so I altered the behaviour. If you want prop blur back, just delete the FSProp_Reconfig.cfg file in the TU_APP_Recolour folder. CKAN I have nothing to do with this. Somebody went out of their way to create their own repo and link it. I don't know what else if anything they have done. I don't use CKAN therefore I cannot support things download from it. Life got a bit crazy so I have not progressed much on making colour masks. I'll try to put together the package as is on the stock front so at least the switch is in place pointing to correct textures and meshes along with the "shiny" metal. From memory this is done I just need to pack it in a form that people can easily download and use.

Yep. These and new parts are already reconfigured. Things are currently making their way through the spray booths...

@Dominiquini Looking at your mod list, the swivel problem might be a weird conflict with decoupler shroud perhaps? At least, the swivel is connected to a decoupler if my eyes do not deceive me? Could you also try creating a completely clean install of KSP (separate from this install, not necessarily deleting what you have) and only install TU, the stock recolour pack and module manager?

@Dominiquini I can't reproduce it... Like is also said though, I think there are underlying issues with the game that might be contributing to this problem. Although right now I can't reproduce either issue, I have randomly noticed things stop working when once they worked fine and the next day the problem goes away again. This is certainly not related to the configs themselves. For the swivel, the glitchy horrible look is due to the low resolution normal map Squad supply with it but you also appear to have some sort of UV mapping issue. Can you post a list of the mods you have installed?

@DominiquiniI've had a similar report some time ago and it turned out that user had not installed the supplied version of Textures Unlimited. I've just rerun the test I did back then and have the same result, things are working for me. So, can you ensure you use the version of the TU plugin supplied with the pack and not one you may have downloaded from CKAN or elsewhere. If you are interested in a more complete explanation, you can read the original response here. If this is not your issue, please report back with some more detail (steps to reproduce perhaps, potentially conflicting mods and so on) because as I said, I've checked a bunch of engines with shrouds and they're functioning as expected here. Edit: Also, the problem I mention with the 909, I'm pretty sure is related to a stock bug.

Any parts Squad have updated (solar panels come to mind) or added will either behave strangely or not work at all. I haven't got round to checking things as yet but it will happen.

Great news! Strictly speaking, that line shouldn't be required and TU will default to that mode if no mode is set. I just put it there for completeness as when checking logs, you can end up with lots of messages about it being missing. Yes, it can be very helpful. You can basically see how the entire part config ends up after all module manager patches. Also, a note on your allred test texture. There is already a red texture available in the placeholder textures folder named Paint. Can be handy sometimes ;D

@OnlyLightMatters You may have tried this but this is where I would start... @PART[DeployedSatDish]:FOR[000_Standardised_Switching]:NEEDS[TexturesUnlimited] { MODULE { name = KSPTextureSwitch sectionName = Appearance currentTextureSet = Stock_Default_DeployedSatDish textureSet = Stock_Default_DeployedSatDish } } +KSP_TEXTURE_SET[Stock_Default]:NEEDS[TexturesUnlimited] { @name = Stock_Default_DeployedSatDish @MATERIAL { @shader = KSP/Specular mesh = Base mesh = MountBase mesh = PanelMount mesh = DishCore mesh = Antenna mesh = LeafBot mesh = LeafLeft mesh = LeafRight mesh = LeafTop texture = _MainTex,SquadExpansion/Serenity/Parts/DeployedScience/Assets/satDish_diffuse texture = _BumpMap,TURD/TU_Standardised_Switching/000_PlaceholderTextures/Bump texture = _Emissive,TURD/TU_Standardised_Switching/000_PlaceholderTextures/Emis } MATERIAL { mode = create shader = KSP/Alpha/Translucent Additive mesh = Screen (1) texture = _MainTex,SquadExpansion/Serenity/Parts/DeployedScience/Assets/Grid texture = _BumpMap,TURD/TU_Standardised_Switching/000_PlaceholderTextures/Bump texture = _Emissive,TURD/TU_Standardised_Switching/000_PlaceholderTextures/Emis } MATERIAL { mode = create shader = KSP/Emissive/Specular mesh = marcoPantalla mesh = polySurface116 mesh = Switch1 mesh = Switch2 mesh = Switch3 mesh = Switch4 mesh = BaseGenericParts mesh = squareButton1 mesh = squareButton2 mesh = squareButton3 mesh = squareButton4 mesh = squareButton5 mesh = squareButton6 mesh = squareButton7 mesh = squareButton8 mesh = squareButton9 //texture = _MainTex,SquadExpansion/Serenity/Parts/DeployedScience/Assets/GenericParts_diffuse texture = _MainTex,TURD/TU_BG_AllInOne/allred texture = _BumpMap,TURD/TU_Standardised_Switching/000_PlaceholderTextures/Bump texture = _Emissive,SquadExpansion/Serenity/Parts/DeployedScience/Assets/GenericParts_emissive } } If that doesn't work, my main suspicion would be the Screen mesh with (1) in the name might be causing a severe breakage. Also, if it doesn't work, can you paste the contents of the ModelData.txt file from a TU export, if you ran that, or expand the mesh hierarchy in the Object Inspector window and grab a screenshot. Something else that might be useful, enable verbose logging, also log errors and exceptions to screen in game so you'll get a heads up when things break. Check in the TU options accessed through the game difficulty menu to enable some extra logging (if I remember correctly where that is now). You can upload a paste to somewhere like pastebin.com or PM a copy of the entire KSP.log if you want me to scan through that for ideas. To keep it clean, load the game, go straight to the editor, add the parts in and try to alter them through TU controls, then exit out. The thing I will say, although I covered some objects that Kerbals grab out of storage containers, they're not very nice to work with in game. Though I suspect you may have found that already. Edit: Oh, another useful thing to check when debugging, the module manager cache.