-
Posts
181 -
Joined
-
Last visited
Reputation
104 ExcellentProfile Information
-
About me
Bottle Rocketeer
Recent Profile Visitors
-
[1.10.1+] Contract Configurator [v1.30.5] [2020-10-05]
Zelda replied to nightingale's topic in KSP1 Mod Releases
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.- 5,201 replies
-
[1.10.1+] Contract Configurator [v1.30.5] [2020-10-05]
Zelda replied to nightingale's topic in KSP1 Mod Releases
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.- 5,201 replies
-
[1.12.x] Waypoint Manager - New Dependency added
Zelda replied to linuxgurugamer's topic in KSP1 Mod Releases
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.
- 225 replies
-
- failure
- reliability
-
(and 3 more)
Tagged with:
-
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?
-
[1.12.x] Textures Unlimited Recolour Depot
Zelda replied to Manwith Noname's topic in KSP1 Mod Development
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. -
[1.12.x] Textures Unlimited Recolour Depot
Zelda replied to Manwith Noname's topic in KSP1 Mod Development
Sorry, work was crazy this week and forgot to follow up, but looks like MWNN came up with an excellent suggestion. Nice. -
[1.12.x] Textures Unlimited Recolour Depot
Zelda replied to Manwith Noname's topic in KSP1 Mod Development
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! -
[1.12.x] Textures Unlimited Recolour Depot
Zelda replied to Manwith Noname's topic in KSP1 Mod Development
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? -
[1.12.x] Textures Unlimited Recolour Depot
Zelda replied to Manwith Noname's topic in KSP1 Mod Development
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 -
[1.12.x] Textures Unlimited Recolour Depot
Zelda replied to Manwith Noname's topic in KSP1 Mod Development
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). -
[1.12.x] Textures Unlimited Recolour Depot
Zelda replied to Manwith Noname's topic in KSP1 Mod Development
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!