-
Posts
169 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by Zelda
-
-
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
-
6 hours ago, JonnyOThan said:
Yes please
Okay, will do after work!
4 hours ago, ballisticfox0 said:Can you verify that the profile you're using has/doesn't have Depth of Field?
There's some pretty strong differences between HDR and non-HDR
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.
-
5 hours ago, Halban said:
I can definitely see the use case there. How would you imagine it working from a UI perspective? I'm guessing that, between different mods and the stock game, section number, naming and order are arbitrary; so I don't feel like there's a really good way manage the section colours for multiple parts at the same time through the same window. Be good to hear how you think it could work.
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.
-
8 hours ago, Halban said:
@Zelda Thanks! The lack of support for individual sections is by design, at least for the moment. The target for Lazy Painter is painting the bodies of large craft quickly, so I didn't think I would be saving people much time with a feature that usually only affects parts that only appear in limited numbers like engines/cockpits, compared to the time it would take to design and implement the feature. I didn't anticipate what kind of modded parts might use sections though. With the kind of craft you're building, do you feel it would save you a very significant amount of time to be able to paint all the procedural tanks in one go?
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.
-
12 hours ago, kurgut said:
Hi,
Is it possible to search for specific part tags via MM, to apply patching ? For instance, to increase the gimbal range on engines, but only for sustainer/booster engine type.
Something like this ? (I have no idea about tags syntax, so help greatly aperciated ! )
@PART[*]:HAS[@MODULE[ModuleGimbal],tags[launch,sustainer,rocket]]:FINAL { @MODULE[ModuleGimbal] { @gimbalRange *= 1.5 %useGimbalResponseSpeed = true %gimbalResponseSpeed = 15 } }
Peace
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 } }
-
7 hours ago, Hippodingo said:
Thanks for your answer! Same thing happens if I try to launch the script in archive:
SWITCH TO 0.
RUN BAKER.
But you're talking about a dependency, maybe I should recheck that baker.ks doesn't call something that is not where it is expected to be.
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.
-
On 3/14/2023 at 2:19 PM, Hippodingo said:
Hello,
I would like to run Baker's kOS script:
I put the Baker2.2.0.ks in my /Ships/Script folder and rename it simply baker.ks.
Then I Iaunch KSP, make a test vessel with one cockpit and one kOS computer (with enough disk space to handle baker.ks).
I launch it and type in kOS terminal:
Did I do something wrong installing/launching this script? I'm a begginer with kOS and it's my first time using a heavy .ks like this.
Thanks in advance for your help!
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.
-
On 11/17/2022 at 3:58 PM, AlphaMensae said:
No, that's what the Saturn Tower General Arm is for. I don't care enough about SLS to bother making anything for it
All work on MLP has stopped. I don't care anymore, this is pretty much a goodbye.
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.
-
On 11/17/2022 at 8:47 AM, starman2022 said:
Is there a way to duplicate and then modify an existing PART (without copying its .cfg) file?
In C I could use the include statement to make a 2nd instance of the ISRU part. And then using MM I would rename the (first instance), having now two parts with different names.
#include "ISRU.cfg" @PART[ISRU] { @name = ISRU_10x }
Possibly this could be done with copy node?
+PART { #/PART[ISRU] // I'm thinking this would include everything within the brackets of PART from ISRU.cfg @name = IRSU_10x @MODULE[ModuleResourceConverter],0 { @OUTPUT_RESOURCE,0 { @Ratio = 444.0 } } }
TIA
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.
-
10 hours ago, HebaruSan said:
I think the root cause has been identified, and a fix pull request is awaiting code review. Those who would like to help test it can find the test build under the Artifacts dropdown here:
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!
-
14 hours ago, JonnyOThan said:
I changed the camera model (now it's a repainted Ant engine so you can tell the orientation better).
Can you show a screenshot of the misc parts screen?
Do you have restock installed? I wonder if it's interfering.
Can you post your logs?
Not who you were replying to but I just noticed the same. In my KSP log I see this:
[LOG 19:16:23.041] PartLoader: Compiling Part 'JSI/RasterPropMonitor/Library/Parts/ExternalCameraPart/external-camera-v2/JSIPrimitiveExternalCamera_v2' [ERR 19:16:23.043] PartCompiler: Cannot clone model 'Squad/Parts/Engine/liquidEngineLV-1_v2/Assets/Spider' as model does not exist [ERR 19:16:23.043] PartCompiler: Model was not compiled correctly [ERR 19:16:23.043] PartCompiler: Cannot compile model [ERR 19:16:23.043] PartCompiler: Cannot compile part
Since you mentioned ReStock, I did a bit of digging and I believe it is because this line in external-camera.restockwhitelist is missing the trailing slash. I added the slash to my local install, and the camera part now appears with the Spider model.
Literally a one char change but just in case it's easier I created a PR for this here: https://github.com/JonnyOThan/RasterPropMonitor/pull/52
-
16 hours ago, Carni35 said:
The flickering you are seeing in the video is due to the EVE city light . Just have to disable it.
Is this still the case with the latest version of EVE? BR pushed a fix explicitly for this, and I can confirm it is fixed for me at least using a 2.5x stock system and AVP.
-
This is cool, I'm not sure how I never noticed it before. Love the name too.
Will this work with CryoTanks? I don't see it explicitly called out in the Supports or FuelSwitchers section, but I believe it uses B9PartSwitch so I assume the answer is yes?
-
4 hours ago, shoe7ess said:
I love this mod not just for the parts, but for the graduated power response to engines. I like it so much I have an MM patch (don't know if I created this one or if this was one someone posted to the MM patch example thread) that adds graduated power response acceleration/deceleration to all engines (except for solid rockets). However, I've been working on a formula to set the acceleration/deceleration speed based on mass, but I can't seem to figure out what (if any) formula was applied to the KW engines to work off of for the formula I'm working on. Does anyone have a decent idea as to how we could use engine response time based off the engine properties? I thought of using mass as well as max thrust, but I figured I'd ask if the default graduated response config values for the KW engines was based off a formula and if not what the thought process was for each engine?
Thanks!
Looks like this post has it, and explains the methodology. Ctrl-F for "Spool" to find it.
-
I don't know about the scatters, sorry. I'm still too early in my career game to make it to OPM bodies. That said, I do know that the original OPM Parallax configs would cause issues with Kopernicus when used with Parallax 2.0. That has been fixed in the updated configs, so that's why I said it was compatible. Sorry for any confusion!
-
On 9/11/2022 at 3:56 PM, Socowez said:
Not to be overbearing, but are there any plans for Parallax 2.0 support?
It already has it. Just download OPM Parallax from CKAN or Spacedock:
-
11 minutes ago, kerbalboi said:
is there any way for me to disable system heat so i don't have to deal with loop temps?
Uninstall it? The loop feature is what this mod does.
-
6 hours ago, seaces said:
@Gameslinxyour Parallax v2 looks amazing. Will Beyond Home get ever updated to support latest Parallax?
Also what planet pack was used to make trailer for Parallax 2.0?
From the Parallax thread:
-
2 hours ago, Fabled_Mike said:
Do you plan on adding scatters to beyond home?
-
2 hours ago, fleventeen said:
It appears to be the same situation as before, however, I didn't have to remove the city lights textures to avoid clipping. Not entirely sure why.
Because you probably have the latest version of EVE. Blackrack pushed an update today with a fix for this:
[1.12.x] Textures Unlimited Recolour Depot
in KSP1 Mod Development
Posted
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