Manwith Noname

Hehe, yeah, I know. When I say "a while", I'm talking years. It's why i don't currently touch launch clamps, parachutes and...various things I can't really mention right now due them being projects not revealed. Way back in the early days of this thread there should be a discussion about it from memory. I'm sure it's a nut that will get cracked one day. I had revisited a problem with regard to this just recently and I'm gathering more information that might be useful in identifying where things go wrong.

@Agustin I know you want it but it might be best to just wait and see if they give you a link to the download. Essentially someone took the pWings parts and made new ones with different material properties and textures. Kinda like TU does without all the external work but it's worth highlighting, they don't use TU. Can you do something similar with TU? Kinda... That's just a quick hack but TU's translucent shaders are something I have been struggling with for a while now.

Not currently. Well, at least not one that I know of.

@Electrocutor If you're referring to the cabin lights "shining" on to other parts of the pod, it's artistic use of the emissive texture itself.

Heh, not so silly. I'll explain better. Open the configs in a text editor, basic Notepad is fine for this, then use the Find and Replace function (typically CTRL+H). In the find field enter the first block, in the replace field enter one of the following blocks. I suspect, there may be some parts that this doesn't work on for various reasons (mainly those using Part Variants) but manually editing those wouldn't be as much of a pain as doing every single part.

I just noticed something in your screenshots. There's a new button labelled Legacy Textures with the state disabled, you could try enabling them and see what occurs.

We introduced a social distancing policy some time ago. At first, things seemed to be going well but apparently our employees just cannot help but be a bit touchy feely.

@SilverlightPony That appears to be working as intended and is not directly a result of Textures Unlimited. If you want to use the original Procedural Parts textures when Textures Unlimited is installed, you'll need to contact the maintainer of the fork you are using and ask them to integrate them in to their patch which is overriding the original assets. Edit: Or make a patch which brings them back.

If you want to change the default set that appears when you place a part: 1) Open The Standardised Switching config. 2) FInd and replace... currentTextureSet = Stock_Default With either... currentTextureSet = Alternate_Stock_Metallic ...or... currentTextureSet = MWNN_Stock_Paint This should work fine for 90% of the parts. In some cases, I may have drifted away from the naming convention for various reasons and then there's parts set up to use the stock PartVariant module. If a part doesn't work right, you should be able to find the part in the configs and see why just by checking the line where the texture set is applied to the switching module. You'll want to make the currentTextureSet line match the name of the textureSet. For preset colouring, open the Recolour Texture Sets config. Look for the colour block within the MWNN_Stock_Paint setup. Change those to match a preset colour from the Color Presets config in the Textures Unlimited folder or make some of your own presets and apply them. You can also apply colours without presets via directly referencing RGB values I believe but I have never tested this. Note, this is global and these apply to every part when the Stock Paint set is selected. If you want specific colours on specific parts, you would be best writing a patch that modifies the COLOR block within all of the specific sets configured in the main recolour file. Yes, this would take a fair amount of time but having a separate module manager patch that does this would save headaches down the road you would likely run in to by editing the configs themselves. That's not to say the patch will work forever but breakages will most likely only occur when a part is redesigned...hopefully.

@CarnationRED Ok I think I found the issue. @PART[CarnationREDFlexibleFuelTank]:FOR[RealFuels] { MODULE { name = ModuleFuelTanks volume = 2000 type = Default } } @PART[CarnationREDFlexibleFuselage]:FOR[RealFuels] { MODULE { name = ModuleFuelTanks volume = 2000 type = Fuselage } } By using :FOR, you're setting up a situation where module manager thinks a mod called RealFuels exists. Change it to :NEEDS and it should be good.

I see you're aware of an issue in this area but I thought it might be worth mentioning it's not exclusive to just that mod. It appears that this mod will trigger patches looking for Real Fuels more generally. Specifically, I was helping someone resolve an issue with B9 Aerospace HX parts where the fuel switch would cease to function as a result. Edit: To make that clearer. Flexible Parts is triggering module manager patches with NEEDS[RealFuels] Another Edit: Here's a simple patch for reproduction purposes... @PART[*]:NEEDS[RealFuels] { @title = NEEDS RealFuels Test } You can specify a particular part if you want but this saves hunting for it in the editors to check.

@Agustin Ah, ok. While I have never experienced a crash to desktop from anything related to Textures Unlimited, if you manage to track something down in that area that's conclusive it would be appreciated. The fairings do currently have an issue I haven't got round to investigating but it shouldn't cause crashes to my knowledge and so it's on my list of minor problems to look at when more pressing things are sorted.

I looked in to it and it's bad news I'm afraid. The only part that doesn't mirror textures top and bottom (in terms of shuttle replicas) is the cockpit. Saying that, there's the booster plate too I suspect but cargo bays and fuel use the same part of the texture for both top and bottom on the same mesh, which makes it impossible to do any trickery I have done in the past to get round things like this. Basically, whatever paint is applied to the bottom gets applied to the top. There's a way round it but it's not pretty and involves new models with more meshes and new UV data. Edit: I made this for a visual reference of what I'm trying to explain. I put a single green splodge on the paint texture and this is what occurs in game as a result... I have not checked yet but OPT might be possible and it's certainly a use for the blue layer which has yet to be implemented on most parts. Heh, I've considered every mod that exists, it just takes time. This should still work with RSS/RO. They just change the solar system and other behaviour in parts. So long as they don't rename the PART, all the packs should work. I'm unclear whether what remains is a new problem or the issue you no longer have so I'll answer just to be sure. I imagine what you describe here just needs the reflection update mode changed. Every frame offers smooth reflection behaviour, I have not tested with lower options but I imagine they will produce a stutter type behaviour in the look of reflections because that is typically how the rendering of them is altered to reduce computation and improve performance.

@lk00david This was something that bugged me year ago when the MK3 parts first appeared. I wanted to make it so you could pretty much do that but the manner in which some models are unwrapped, the area of the texture used for both top and bottom is the same. This doesn't apply to all parts though from memory. Fuel tanks and wings are the main ones I remember it on. The cockpit can be done but I'm vague on the cargo bays, I'd need to look at them again to be sure either way. Stay at home Sunday report. The Spark, which I had previously made a bit a mess of trying to work around restrictions has received a revamp.

Stay at home Saturday brought with it a LV-909 Revamp to make use of new features... I wonder what stay at home Sunday will bring?

It shouldn't cause any problems, you'll just end up only being able to manipulate recolouring on parts that still exist from the game ReStock doesn't touch. Everything is setup to prevent conflicts with parts altered by ReStock, though there may be things I have not found from brief checks. It's 300 parts and while I do what I can to make things play nice based on what I find in the files, placing everything in the editor and manually checking them takes time. If someone with both installed finds something that conflicts, they can report it and I'll do what I can to fix it but I'm not particularly keen in sitting in front of my computer for 2 hours just placing parts when I could be working on other things that I know need to be done. No new issues thus far. There's the ol' problem we spoke about in the past where multiples of the same part using PartVariants share colour schemes but not sure that is easily solvable from my memory of the conversation. Well, you can paint them differently in the editor but the last colour set applied is used when launched. There's a way to work around it by launching the craft and reverting to hangar, then you can colour one of them in another scheme and the next launch they have independent paint jobs. Is the render quality set to good or higher? KSP apparently disables the reflection probe when set below good which causes things to look very strange indeed due to the loss of reflections data. There is not a way to parse colour sets through the craft tree but there are ways to speed up the manual process. If you configure a part in a scheme you like and want that throughout the craft, make use of the store and load pattern buttons in the GUI. This does still take some time and you may not want every part the same scheme but it helps a lot. At some point, I may go through the parts and assign something so that when selecting the recolour scheme it's not RGB, I just find this preset useful when configuring parts and making it apparent that the recolour scheme is selected. You could of course edit the master COLOR block in the recolouring texture set so it assigns white paint or any combination of preset colours you desire. What you are suggesting can be done from within TU (manipulating material properties on existing textures), in fact, it was essentially how these packs were setup previously and to some extent, still is (it's what the "It's all shiny" set does). The diffuse texture is nearly always the supplied texture by the part (there are a few cases where I have created alternative textures for the diffuse for various reasons) so nothing is really duplicated. What comes extra are due to the nature of PBR and the further texture inputs that make it function correctly. In the past, only specific parts had dedicated metallicglossmaps and the supplied textures be it stock or mod were referenced in place. It "works" but is limited for a few reasons. Mainly, the biggest issue comes down to the meshes of the model in game. The majority of parts are a single mesh which means only one MATERIAL (I'm not shouting,just indicating how these are referenced) can be assigned over it. The metallicglossmap allows for texture input to vary the apparent material properties over the mesh. So, for example, take a cockpit with only a single mesh. Without a metallicglossmap texture you cannot have the window look more glass like while the end plates look like metal and something else looking like rubber. Well, you might be able to come up with ways of manually defining UV coordinates with various metallic and specular values at a config level but...I can't imagine it being an improvement over supplying a texture input. As for OPT, yes, it has some larger textures but I would hasten to add that just looking at a texture size isn't the entire story. There are 4096x4096 textures which on the face of it might seem huge for KSP but they are being used to cover multiple different parts. So, in some ways, it wouldn't be that much different overall if those parts all had their own individual 1024 or 2048 textures. Granted, I don't think any of the 4k textures cover 16 parts but at the same time, there's a reason OPT generally looks nice even when up close and not all smudgy and blurry. While it's not fair to compare apples and oranges, many games these days use 4k dds textures or higher in a much denser area than parts in KSP and at some point, I had considered making the stock pack with double the resolution of the supplied stock textures. See the spoiler below for how that would have looked...sort of. Ultimately, while I understand the concern of resources there are reasons for things being the way they are.

My hunch would be that you don't have the core Stock pack installed. You don't need the entire pack though, just grab the texture sets configs and place them in your install. Yes, anyone can do it. I only use GIMP and Notepad++ alongside features available within TexturesUnlimited and some other mods (ObjectInspector or DebugStuff). Though the need for these debug tools has been significantly reduced due to improvements in TU's own data mining. Hmm, first of all, double check your graphics options in game. There's one particular setting that is very important, "Reflection Refresh Mode", which needs to be set to anything other than None.

That's fair enough. I don't have a github account so it's unlikely I'll be making any pull requests but if I do make some headway with a more standardised setup that can be built off and patched on to I'll let you know. What I wanted to do didn't work right (though it did strangely look quite cool, even though clearly broken) but I'll probably investigate in the future.

As was mentioned, it's "compatible" in the sense they should work together without causing issues. What happens is where there are conflicts due to redesigned parts from ReStock, my patches (should) disable themselves and textures for those parts do not load. Might be worth mentioning, I've found a couple of errors with this, meaning I found one part unintentionally being blocked and some typos in the blacklist which meant unused textures would be loaded. These will be fixed when I have the last of the 1.9 stock parts sorted but they're also not critical. I would to some extent forget all my ramblings about PartVariants and B9 Part Switch. It was just a bit of fun for me to test something that at the time I was unable to achieve with TU alone and had been kicking around the idea for quite a while. I've always preferred the standard texture switch module but now, where appropriate, PartVariants can be split in to multiple sections to get more material control in the GUI, which was what it was all about really. As you're interested, the implementation of the new TUPartVariant functionality ended up something like this... To some extent, this is also not entirely necessary. I fiddled with different structures partly to try and break it but also to see where I could reduce the config length. You can essentially mix and match how much you break down the texture sets but I settled on this for a number of reasons. 1) It keeps the various configs very similar. So when someone reads the stock texture sets, they closely match the recolour texture sets. 2) My heavy use of copying from a base texture set applies things I sometimes forget to apply within nested MATERIAL blocks. Things like remembering to specify the shader or keywords and so on. Naturally, they get added when I realise after loading the game and things are broken but this significantly reduces my level of brainfarts and reloads. 3) The general idea of the Standardised Switching is to set everything up initially and becomes an easier way to just keep adding on to. If I had stuck with one of the other configs I had tried, I kept the stock stuff with just 2 texture sets from memory, there was only one TUPartVariant MODULE and everything else was added later in the recolour config. It's ultimately about trying to keep the various configs consistent and hopefully logical so people trying to learn from them can piece the puzzle together. Additionally, yes, I know ReStock doesn't currently replace this part....but it will. I believe their next update will replace all these new stock parts and all the wheels from posts I have seen in their release thread.

@Acvila Indeed, you can find the a collection of packs which add TU shaders to Stock and some mods (including the original pWings) here... Edit: Oh also, @jrodriguez, in the spoiler below is an adjusted version of your supplied config. This is to show how the setup should occur to maintain functionality of the leading and trailing edge mesh switching.

This is really good to see, so thumbs up for getting that working but I have some observations and suggestions. 1) If TU isn't installed, the B9 colour system doesn't function. I assume this is a side effect of having to disable them to get TU functioning. Is it not possible, like I suggested in the PM months ago, to enable a switch system so default behaviour is to continue using the B9 system and if a flag is set by a config that wants to apply TU, the old system is disabled? Hmm, scrub this, I have it working now. 2) Remove the transform specified in the texture switch module. Right now, due to this, everything breaks when you try to switch the mesh for the leading and trailing edges. If you write the configs differently and make appropriate texture sets, then apply them in the right switcher, this edge mesh switch still functions... 3) Don't force a hard dependency on Procedural Parts. By all means, supply a patch that creates a set using textures from there if they are present (using the NEEDS field) but it would be preferable if a standalone B9 Proc Wings could exist. 4) Following on from 3, as can be seen in the pictures, make a set of default patches that look like B9 and can be added to easily through using FOR patching by others. I know what this involves, I've spent a bit of time looking through the default art assets and can see where the problems lie but it's achievable with a bit of time. I can help with this if you're interested, obviously I've fixed some things myself and half setup a means of having B9 alike recolour in these shaders. Though, I have other projects which should be the primary focus right now. It is already done...

@Shadowmage

@Shadowmage I'll get on it as soon as I can and report back.

@Shadowmage Maybe? It's late, I'm a bit brain dead. I must admit, I butchered the part massively but I do quite like how it functions. Everything works independently so B9 handles just the model changes and the standard TU texture switch module deals with the usual texture set side of things. This is essentially how I would like things to work, switching models keeps texture sets applied, switching texture sets has no effect on the meshes being displayed. I fixed one issue, that was straight forward, I just forgot to add the fairing transforms to the B9 switcher. I'm reasonably sure I've seen posts in the past about engine plumes in the editors but I'm not entirely sure what caused them. There could also potentially be issues with using a 1.8 plugin on 1.9. I just want to test the concept and see how it functioned. This is the config, obviously you won't be able to use it due to missing textures and what not but it might give more of an idea of how I set it up. Edit: I think I understand your suggestion. Essentially the extra info block and part variant modules would allow for the material control to display in the GUI but it would all be tied to a particular variant? This would of course work, I just like the ability to switch between texture sets on specific meshes so you can mix and match say, a straight metallic set on some meshes with recolour on others. Basically, I like that flexibility but to some extent it's not essential. What bothers me the most is being limited to 3 user definable colours / materials when a part could be broken down to allow more. Another edit: Haha, might need to switch out colliders too...

The Solution!...well, maybe? Every time I think of variants, I think of Aliens. We should nuke the thing from orbit, it's the only way to be sure. I've tried manipulating the module in cunning ways but all I managed to do was break the editor. So, the idea that's been kicking around my head for a long time is to completely replace the stock part variant system with something else that I know plays nice with TU. Ladies and gentlemen, I present to you, the "variants begone" part switcher...sponsored by B9 Part Switch. *drumroll* So, the proof of concept works it seems. Sadly, it comes with one or two issues right now. I feel like this should work with a bit more time digging out how to set up the B9 part switch module. Then again, I might find that this is also an area that B9 just will not solve. Another drawback if I can get it all to work is it becomes a dependency but I kinda feel that a lot of people will have it installed anyway due to other mods incorporating it. I might see how Firespitter mesh switch functions in this area too but not tonight I suspect. Thoughts and suggestions on this are welcome. I've had my fun for the evening goofing around. Normal business may resume.