Zelda

Very late reply, but I just learned how to do this following these guides: TU Wiki: https://github.com/shadowmage45/TexturesUnlimited/wiki/Feature---Recoloring RO Discord: https://discord.com/channels/319857228905447436/840034852261593109/1009697620467388436 In particular, I'm guessing that you may have missed the normalization step as that's what tripped me up too with similar results: https://github.com/shadowmage45/TexturesUnlimited/wiki/Feature---Recoloring#normalization-parameter-generation

Okay, I need to make a correction because @ballisticfox0 was right on: In grabbing a fresh repro, I tried toggling Depth of Field again, and this time it did resolve the blur issue. Playing with it a bit more, I discovered the issue is only when HDR and Depth of Field is enabled. Disable either one and the issue goes away. I also confirmed that the profile does not matter; it can be an entirely empty profile, and enabling HDR and DoF (even with no other parameters enabled) triggers it. @JonnyOThan, issue created, let me know if you need anything else: https://github.com/shadowmage45/TUFX/issues/41

Okay, will do after work! It does, but I tried disabling DoF with no change. I tried disabling all of the modules and the only one that had any effect was HDR, and the same profile on the previous version doesn't have this issue. I have run into random blurring rarely, and it was due to DoF - toggling that off temporarily or going to map view typically resolved the issue. I will remove DoF from the profile entirely and try again just to rule that out. If it's helpful, this is the profile I'm using (not sure how it will look to others, but looks pretty nice on my setup at least!): TUFX_PROFILE { name = CREI-FreshHDR hdr = True antialiasing = SubpixelMorphologicalAntialiasing EFFECT { name = AutoExposure Filtering = 40,115 MinLuminance = -1.125 MaxLuminance = 0.75 KeyValue = 0.4775 EyeAdaption = Progressive SpeedUp = 2.0 SpeedDown = 1.0 } EFFECT { name = AmbientOcclusion Mode = MultiScaleVolumetricObscurance Intensity = 0.775 AmbientOnly = True NoiseFilterTolerance = -6.25 UpsampleTolerance = -9.78616333 ThicknessModifier = 2.5 } EFFECT { name = Bloom Intensity = 1.325 Threshold = 0.875 SoftKnee = 0.575 DirtTexture = TUFX/Textures/LensDirt03 DirtIntensity = 0.25 } EFFECT { name = ChromaticAberration SpectralLut = TUFX/Textures/SpectralLut_BlueRed Intensity = 0.0324999988 FastMode = True } EFFECT { name = ColorGrading GradingMode = HighDefinitionRange Tonemapper = ACES Temperature = 1.25 Tint = -1.25 HueShift = 3.25 Saturation = 27 PostExposure = 0.5 Contrast = 12.5 MixerRedOutBlueIn = 1 MixerGreenOutRedIn = -0.75 MixerGreenOutGreenIn = 101.25 MixerGreenOutBlueIn = 0 MixerBlueOutRedIn = -1.75 MixerBlueOutGreenIn = 10 MixerBlueOutBlueIn = 105 Lift = 1,1,1,0.0125 Gamma = 1,1,1,0.0125 Gain = 1,1,1,0.375 } EFFECT { name = DepthOfField FocusDistance = 75 Aperture = 5.69999981 FocalLength = 52 KernelSize = VeryLarge } EFFECT { name = Grain Intensity = 0.324999988 Size = 0.725000024 LumContrib = 0.869182408 } EFFECT { name = Vignette Mode = Classic Intensity = 0.351100624 Smoothness = 0.200000003 } EFFECT { name = LensDistortion Intensity = 1.88679242 Scale = 1.01569188 } } Thank you both for replying!

Hello! I may have a bug report. After updating to 1.0.7.0 via CKAN, when using RSS-Reborn and VolumetricClouds, HDR causes the planet and skybox to blur heavily when in space. No issues with the previous version of TUFX. Do you want me to file an issue in the repo? Without HDR: With:

Sorry, one thing you mentioned that I forgot to address is the variable section names across parts. That's an issue to a degree, as there are a few different types of parts that are similar (like Procedural Tanks and Modular Tanks), and have different sections. However, all Procedural tank-like parts (Balloon Tanks, Conventional Tanks, Isogrid, Service Module, etc) have common names - Sides and Ends. Modular Tanks (same types) have Core, Mount, and Nose. Procedural Wings and Control Surfaces have Surface, Section, Trailing Edge, and Leading Edge... etc. So you were right that could be a problem if multiple types of parts from multiple mods are selected, but I think even if you were able to color individual sections for all selected parts from a common family (i.e., Procedural, Modular, etc) that have the same section names, that would be a big help too. Totally get this could get messy! I dabble a bit with code but I am not a programmer by day. However, I work at a software company and I recognize this as something that my engineers would likely push back on. So it's totally fine to say it's out of scope! I just appreciate the consideration and discussion.

Thanks for considering it! The UI piece is challenging because of the variable number of sections there could be, depending on the parts selected. The only way I could think of to make it work would be to enumerate all the unique sections in the selected parts by their name (i.e., Core, End, Mount, etc), and provide that as a list in the upper section with a palette for each. Then, if colors were changed on the 'Core' palette (as an example), that would apply to every 'Core' section in the parts selected; same for 'End', 'Mount', etc. Not sure how easy it is to get a list of all the sections available, but something along these lines could be effective in allowing recoloring of multiple sections across multiple parts.

Thanks for the speedy reply! I sort of assumed that it was by design given the challenge of trying to support modded parts, which can be subject to change and implemented in a variety of ways. To answer your question, when playing with Realism Overhaul, the majority of the parts used are procedural, such as fuel tanks, probe cores, batteries, etc, and most have (or can have depending on texture) multiple sections. That results in the majority of my vessels having multiple sections. LazyPainter applies colors to every section, so after using it you need to go back and individually edit each part to update the other sections that were overwritten. So honestly I'm not sure LazyPainter is saving me much time with my RO save. That said, I think it works great in my closer-to-stock game, where it does save a huge amount of time. So I get why you made the decision to focus on that. I tend to recolor more in RO, so if you do end up ever supporting that, I'd be grateful! I understand though that supporting a variable number of sections across parts would be pretty challenging / problematic, so I'd totally understand if you weren't wanting to take that on.

Hi @Halban, just wanted to say thanks for making this mod - it's great. Very nice QOL improvement! Is there a way to use it with parts that have more than one component/color set, specifically to only set colors for one set at a time? I use a lot of procedural parts in my RO playthrough, and what I've noticed is that LazyPainter applies the paint selections to every set. Example: Here is a part with two color sets ('Sides' and 'Ends') that I manually colored (garishly to make it easy to see the issue ). And here is after using LazyPainter to paint the first slot red - it colors the first slot for every set. I imagine based on LazyPainter only having one set, this is not supported, and that's fine! If so, consider this a feature request if that's something you're open to.

I think something like this would work for you if you knew the tags would always be in the same order. It uses some wildcards to account for different capitalization or end of string. Give it a try! Also, it's rare but some engines have two gimbals, one for each axis. So by adding ',*' after the module selection, you are saying "make these edits to all ModuleGimbal modules" instead of "Make these edits to the first ModuleGimbal module I find" @PART[*]:HAS[@MODULE[ModuleGimbal]]:HAS[#tags[*aunch*ustainer*ocke*]]:FINAL { @MODULE[ModuleGimbal],* { @gimbalRange *= 1.5 %useGimbalResponseSpeed = true %gimbalResponseSpeed = 15 } }

Yeah, that's where I'd start! I don't know the Baker script very well, but I will also try to take a look at it this evening to see if I can help find the issue.

Edit - Nevermind, I'm lacking sleep and misread the question. However, when it throws an error with the line number, you can usually debug starting there. Search the file for menuanswer(), then look for where that function is. My guess is copying over to the local drive may be resulting in a path to a dependency being incorrect if an assumption was made in the script that you would be running this from the archive.

I've been using your mod for many years, and can't imagine playing without it. That said, I can definitely relate to getting burned out on a project. Take care, and thank you so very much for making something fun, unique, and special, and sharing it with us all.

Yes, you just need to specify the part name in the first line instead within the brackets. See below - this will create a copy of the part and that will include everything defined for the part up to that point. +PART[ISRU] { @name = IRSU_10x @MODULE[ModuleResourceConverter],0 { @OUTPUT_RESOURCE,0 { @Ratio = 444.0 } } } If there are mods that patch that part later in the loading process and you want to initiate the copy after that patch so you don't have to replicate it, you can do so by adding something like ':AFTER[<mod dll / folder name here>]' to the first line. The below example would copy the ISRU part after SystemHeat has patched it, for example: +PART[ISRU]:AFTER[SystemHeat] { @name = IRSU_10x @MODULE[ModuleResourceConverter],0 { @OUTPUT_RESOURCE,0 { @Ratio = 444.0 } } } Probably good to read up on patch ordering on the MM Wiki if you haven't done so.

I just wanted to mention that I downloaded this build, and the problem was resolved. Thanks so much!

Speaking of using on an existing save, I think it might be an issue if you're using a rescaled system. I added it in to my 2.5x save and the planets were in very different positions along their orbits, which would have resulted in a few in-progress missions being nowhere near their target on arrival. I removed the mod and the planets reverted back to where they were before. So while nothing broke per-se, there may be side effects. All that said, I loved the way Kerbol looked with this mod and am planning on using it with my next save!