Manwith Noname

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.

@OnlyLightMatters Assuming you haven't published this problem config on GitHub, can you post the complete code for a part you are trying as you imagine it should work. If it is on GitHub, some direction to find it in amongst everything else would be good.

@OnlyLightMatters I'm not entirely sure I follow but something that stands out to me... ...you probably want to drop the @ on the second and third MATERIAL blocks. This is module manager syntax related. + is copy, @ is edit. So, what's going on here is you copy the Stock_Default KSP_TEXTURE_SET which only has one MATERIAL defined. Then, you're editing that material block, then again, then again. If you want to add further MATERIAL definitions for specific meshes, as previously mentioned, just drop the @ symbol on block 2 and 3, so it looks like this... +KSP_TEXTURE_SET[Stock_Default]:NEEDS[TexturesUnlimited] { @name = Stock_Default_KAL-1000 @MATERIAL { // BLOCK1 } MATERIAL { // BLOCK2 } MATERIAL { // BLOCK3 } } This will create new MATERIAL nodes within that new KSP_TEXTURE_SET. Further to this, when it comes to editing multiple previously defined MATERIAL blocks, module manager will accept indexes from 0. So, to edit previously defined MATERIAL blocks later you'll want something like... @MATERIAL, 0 { Edit stuff in MATERIAL block "1" } @MATERIAL, 1 { Edit stuff in MATERIAL block "2" } @MATERIAL, 2 { Edit stuff in MATERIAL block "3" } If this doesn't answer the question, let me know.

@linuxgurugamer It just occurred to me that it would perhaps be best to slightly modify the B9 Pwings files so they work stand alone. Right now they require that the stock recolour pack be installed. If it isn't there will be some strange errors due to missing texture set configuration and the configs don't make specific checks to ensure this doesn't happen. As far as CKAN goes, there's another hurdle as some packs rely on a dev build of Textures Unlimited that was not fully released and doesn't appear on CKAN either to my knowledge.

Ok, in a technical sense this is a luminance value. For "Porkjet white", I established this a long time ago as 0.74 for diffuse and 0.5 for spec and metal just by looking at the colour values of the pixels and fiddling around a bit to get the effect I wanted. I don't know what texture editor you use but I use GIMP but I imagine if you use Photoshop the same or similar and more is available. Simply opening up the colour palette window and using the colour picking tool to get values from the diffuse texture will give me reasonably close values for anything that is essentially greyscale. For colours, I typically desaturate based on luminance values. Gimp now also gives colour values in numerous formats, so whereas previously I divided 190 by 255 to get 0.74, I can view values on a scale of 0-100 so this calculation is essentially done already and Porkjet white reads as 74. This isn't the be all and end all value but I'll get to that in a moment. Right, I start with my metal and spec maps being identical to the diffuse but converted to luminance greyscale via the desaturation tool in GIMP. I'll put this in exactly as that until I'm settled on my colour mask. During the creation of the colour mask I will have created numerous paths that allow me to select the same area repeatedly and consistently. This will ultimately include areas of the texture that I'm not going to paint. Sometimes, for very simple parts I don't do this but, I digress. When I'm settled on what parts of the texture I'm not painting I have a couple of level adjustment presets for converting areas to metal and spec values that I settled on through trial and error then universally apply to try and be consistent. Now, to come back to the be all and end all. These are things that get me to the ball park of what I want in an artistic sense. Depending on who the original artists was, things will invariably be slightly different and results will be slightly off from what I personally want. I'll load up the game, I'll put my baseline parts down which are things by Porkjet like the MK1 and MK2 cockpits. I'll put the newly covered part next to them and start applying the same colours and comparing the results. Based on what I see, I tweak values slightly. My main aim is to get things so they aren't noticeably different. Setting the detail slider to 500 can be particularly helpful in highlighting out of range diffuse values. If your norm value is too low the colour will over saturate, if it's too high everything goes black or too dark. Again, the original artwork impacts this massively. There are some parts I have that oversaturate in places which leads to... Sometimes the original artwork contains areas that don't suit what I'm trying to achieve and when I can be bothered, I modify the original texture to eliminate things I find offensive, typically those horrendous highlights that are blobbed all around newer parts. Porkjet did this but they weren't blobby and they were within a colour range that meant they didn't look terrible (at least to me). There's plenty of parts I kind of want to revisit in this regard. In the case of the mk2 lander can, there was two thing I wanted to do. One was remove the ghastly highlights around the panels and increase the darkness of the recesses between them. The other was a fix to the rover roof because Squad somehow balls'd that up. I don't know if that mistake is still there today but it's largely irrelevant to me because of the other modifications I performed. There's things like black and white fuel tanks where I manipulated the black area to allow better colour blending through the GUI that just wasn't working when using normalise values alone. And so on, essentially if I have the motivation when I'm covering the part to fix things I dislike, then it will typically start with a modified diffuse texture because everything else is formed from that. You can but are you just including the patches or the textures too? I don't know how other people feel but because TU and recolouring always seemed a bit niche I've made packs in a way that those who want it can add them if they want. It also meant that if and when I wanted to improve things I just change my download rather than bothering others to update their mod. Edit: @OnlyLightMatters If you use GIMP I think I can extract my level adjustment presets and send them to you.

@OnlyLightMatters From what you have shown here it was hard to understand what wasn't working as you expected. I noticed your post in the main TU thread though and I think I can perhaps shed some light on what is missing. The black area of the colour mask takes metallic and specular values from another texture. This can be defined in a number of ways but I highly suspect that the texture being used for this contains no alpha layer. Or perhaps more importantly, the alpha layer has a value of 1 in the areas where you are seeing reflections you don't want. If you're following the texture sets I have defined using the TU/Metallic shader then the metal value is read from the red channel of the RGB layer and the shininess value is read from the alpha channel.

@Weak Player I don't know if you're getting things mixed up but reflection resolution doesn't matter, in fact I would recommend not putting it above 256. The two settings in the graphics options that are important are the rendering quality, which needs to be good or higher and the reflection refresh rate, which needs to be low or higher. If either of these is not met, then things will appear to work in the VAB / SPH but will fail when loading in to the game world. Your second screenshot suggest that the configs are being applied so I would double check the two graphics options if things don't look right.