Zelda

Just my opinion, "nutrient-full slurry/goo" sounds massively less pleasing to me than "Snacks". Snacks is just far more fun too, and this is a game after all. If you feel the name should be changed, though, you can do that in your own game with a Module Manager patch.

This is awesome! Thank you so much for considering then implementing this, I'm excited to try it out. Thank you!

Some of the contracts do have those values, some do not (at least in my copy of the file). My thinking was adding those values to the contracts that were missing them may override a default value, but I guess not. Darn. I agree it would take a DLL mod, but personally I am not sure Contract Configurator is/should be that mod. CC has an entirely different and complex contract definition system, and it seems like writing in support for the stock system alongside of it would add a ton of extra complexity and compatibility surface area that would be a headache to maintain. Releasing an entirely separate mod for modifying the stock system makes more sense to me. Just my $0.02 though.

Based on my experience, Contract Configurator cannot modify stock contracts. However, you might be able to write a Module Manager patch that can make the changes you want, since the stock contracts are all defined in a .cfg file under GameData/Squad/Contracts/Contracts.cfg. Maybe play with adding / modifying the 'MaximumExistent', 'MaximumActive', and/or 'MaximumAvailable' values.

Hello! I'm having an issue where every time I start the game, it resets the opacity setting to default. I saw it was reported earlier along with the next flight issue, and the subsequent release fixed the that problem, so I just wanted to see if it should have fixed this issue as well? I can create an issue on GitHub with logs if needed.

I'm not the mod author or maintainer, but my understanding and experience from using this mod extensively has been it encourages recoverability. Most rockets are scrapped after a single use because they are expended, i.e. boosters dropped into the ocean or on land, and upper stages typically reenter and are burned up. This mod encourages you to design your rockets to survive all of that so you have parts to recover. At that point, I'm assuming the idea is that the parts get refurbished behind the scenes (given they still cost some funds to use) and are like new.

Hi! I gave this build a try. I really like the changes to the UI, thank you! The close button in particular makes taking screenshots with different profiles *much* easier, and while I haven't tested saving profiles yet, that's also a huge QOL improvement, so again, thank you - these things are very much appreciated. While I haven't had a chance to test out many scenarios yet, one issue I noticed is that TUFX no longer seems to apply in the VAB, no matter what profile I choose. Is that intended?

Sorry I've been absent from the forums lately but it seems like you've made good progress! I noticed you're using ModulePartVariants - you're using that to change textures? Have you tried instead using KSPTextureSwitch or ModuleB9PartSwitch? Both are able to also switch textures and I found them a bit more intuitive. You said what you have works, but I wonder if ModulePartVariants loads differently vs the others to where the others would load the default recolor correctly; I've never used it myself so I'm not sure - I'll have to read up on it. In case you are interested in trying KSPTextureSwitch or ModuleB9PartSwitch and would like a few examples, I'd be happy to share a few of my personal patches for you to review. I play RP-1 so it's possible you might not have the parts that they are for, but it would give you an idea of how these modules are used in various situations. If I remember right, you were also interested in specifying default colors for parts, right? If so, and you haven't found this yet (which I'm sure you have given how behind I am on this convo), KSPTextureSwitch should pick up on default color settings in the KSP_TEXTURE_SET definition. You'd define the defaults via a COLORS node, and the KSPTextureSwitch link above goes to the config section of the wiki that shows this as well as how to use KSPTextureSwitch in general. Also, random thought, and I may be wrong about this, but the game generates thumbnails for viewing parts in the menus and caches them, right? Is it possible that changing the texture to your recolor mask somehow invalidates the cache, but at a point where the recolor texture is not yet loaded? Long shot here, but the only other thing I can think of.

Sorry, work was crazy this week and forgot to follow up, but looks like MWNN came up with an excellent suggestion. Nice.

Question 1: There should be multiple KSPTextureSwitch modules for each of those sections and you'd need to modify them all. See here for an example of a part like that, for how it is configured; your ModuleManager patch should target each: https://github.com/B9-Procedural-Wings/B9-PWings-Modified/blob/92969640221a47c18b615f61a931e1176ec4de08/GameData/B9_Aerospace_ProceduralWings/B9PWingsUnlimited.cfg#L202 And how you'd target them individually would be to use a HAS qualifier, within the patch, you'd do something like: @MODULE[KSPTextureSwitch]:HAS[#sectionName[Base]] { <your changes here> } Question 2: I think you can define your colors as color presets, then set them as the default colors in the KSP_TEXTURE_SET for the part. I think all the recolor textures in TURD start with a base texture set that defaults to absolute_red, absolute_blue, etc. If you wanted you could, after each part's KSP_TEXTURE_SET is created, run another patch that changes the default colors to your color presets. See 'Colour_Presets.cfg' and 'Recolour_Texture_Sets.cfg' under TU_Stock_Recolor for examples of how these things are defined. Edit: One more thing, I highly recommend defining your own color presets to use regardless, and putting them in a category of their own so you can reuse your favorite colors. I have several categories set up, one for Metallics, one for Regular colors, one for colors that work well as fuel tank insulation, etc. It's nice to be able to just recall them with one click instead of needing to remember the color codes every time. There is one thing that doesn't seem to get saved, which is the Detail slider, but it's easy enough to adjust that per-part, and you are still spending less time even with that quirk than setting every slider. I hope this helps!

That's great! That's sort of what I meant by you'll need to so them for each part (or parts using common textures), though it sounds like you might have taken a different approach of affecting the shader itself instead of reordering the textures in the KSPTextureSwitch model to save a bit of work? If so, nice find! I have done a ton of recolors and hadn't thought of that. I agree, it will be a LOT of copy and pasting, but if you're willing to do that, you should release it as a patch for the community. Out of curiosity, does that still preserve the stock shaders / textures as well, or overwrite them?

That may be the case for parts that share common textures, but each texture will need to be placed at the front of the queue using ModuleManager. To do that, I think you'd need to specify the specific texture for each part. You can use wildcards for some parts, I'm not saying it's not possible, just a lot of work. If you can make it work, or someone else has, great! Edit: Forgot to include this: https://github.com/shadowmage45/TexturesUnlimited/wiki

Someone can correct me if I'm wrong, but I believe to make the TU texture a default, you'd need to write a ModuleManager patch for each and every part that contains the textures, assuming that those textures would be different for each part (which they have to be in order to have the colors end up in the right spots).

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.