fix(weather-editor): corrected slider behaviour for the weather widget#2132
Merged
Merged
Conversation
Contributor
📝 WalkthroughWalkthroughConverted multiple weather parameters from signed 8-bit to unsigned 8-bit handling across interpolation, UI controls, persistence, and display logic (precipitation fades, lightning fades/frequency, visual-effect and transition fields). Changes
Sequence Diagram(s)(No sequence diagrams generated — changes are primarily type/representation edits rather than new multi-component control flows.) Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
No actionable suggestions for changed features. |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
src/WeatherEditor/Weather/WeatherWidget.cpp (1)
717-729:⚠️ Potential issue | 🟠 MajorNormalize the other UINT8-backed properties on load too.
Only
Thunder Lightning Frequencygets converted back into the new 0–255 editor domain here. The precipitation fade, lightning fade, and visual-effect fields were also moved toUINT8_SLIDER, so loading them through the old direct path will still bring raw values above 127 back as negative ints after reopen/reload.Proposed fix
// Precipitation - weatherProps["Precipitation Begin Fade In"] = data.precipitationBeginFadeIn; - weatherProps["Precipitation End Fade Out"] = data.precipitationEndFadeOut; + weatherProps["Precipitation Begin Fade In"] = static_cast<uint8_t>(data.precipitationBeginFadeIn); + weatherProps["Precipitation End Fade Out"] = static_cast<uint8_t>(data.precipitationEndFadeOut); // Lightning - weatherProps["Thunder Lightning Begin Fade In"] = data.thunderLightningBeginFadeIn; - weatherProps["Thunder Lightning End Fade Out"] = data.thunderLightningEndFadeOut; + weatherProps["Thunder Lightning Begin Fade In"] = static_cast<uint8_t>(data.thunderLightningBeginFadeIn); + weatherProps["Thunder Lightning End Fade Out"] = static_cast<uint8_t>(data.thunderLightningEndFadeOut); weatherProps["Thunder Lightning Frequency"] = (uint8_t)data.thunderLightningFrequency; ColorToFloat3(data.lightningColor, weatherColors["Lightning Color"]); // Visual Effects - weatherProps["Visual Effect Begin"] = data.visualEffectBegin; - weatherProps["Visual Effect End"] = data.visualEffectEnd; + weatherProps["Visual Effect Begin"] = static_cast<uint8_t>(data.visualEffectBegin); + weatherProps["Visual Effect End"] = static_cast<uint8_t>(data.visualEffectEnd);🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/WeatherEditor/Weather/WeatherWidget.cpp` around lines 717 - 729, The UINT8-backed fade/slider fields other than thunderLightningFrequency are not normalized on load: convert data.precipitationBeginFadeIn, data.precipitationEndFadeOut, data.thunderLightningBeginFadeIn, data.thunderLightningEndFadeOut, data.visualEffectBegin, and data.visualEffectEnd into the editor's 0–255 domain (as uint8_t) before assigning into weatherProps (the same way thunderLightningFrequency is cast); update the assignments for the keys "Precipitation Begin Fade In", "Precipitation End Fade Out", "Thunder Lightning Begin Fade In", "Thunder Lightning End Fade Out", "Visual Effect Begin", and "Visual Effect End" to store the normalized uint8_t values so reopened/loaded files don't produce negative ints.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@src/Features/WeatherEditor.cpp`:
- Around line 133-145: LerpWeather is still using signed blending helpers for
fields edited as 0–255 (unsigned) in the UI, causing values >127 to be treated
as negative during transitions; update the blending calls in LerpWeather
(replace uses of LerpInt8_t with LerpUint8_t for the unsigned timing fields such
as Trans Delta / Visual Effect Begin / Visual Effect End and any similar members
around the shown block), ensure you pass uint8_t arguments/casts into
LerpUint8_t and assign back to the unsigned destination members (keep signed
helpers like LerpInt8_t only for genuinely signed fields like
sunDamage/sunGlare).
---
Outside diff comments:
In `@src/WeatherEditor/Weather/WeatherWidget.cpp`:
- Around line 717-729: The UINT8-backed fade/slider fields other than
thunderLightningFrequency are not normalized on load: convert
data.precipitationBeginFadeIn, data.precipitationEndFadeOut,
data.thunderLightningBeginFadeIn, data.thunderLightningEndFadeOut,
data.visualEffectBegin, and data.visualEffectEnd into the editor's 0–255 domain
(as uint8_t) before assigning into weatherProps (the same way
thunderLightningFrequency is cast); update the assignments for the keys
"Precipitation Begin Fade In", "Precipitation End Fade Out", "Thunder Lightning
Begin Fade In", "Thunder Lightning End Fade Out", "Visual Effect Begin", and
"Visual Effect End" to store the normalized uint8_t values so reopened/loaded
files don't produce negative ints.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: b3f347bb-582b-4d4c-bab1-e3d50d09dfb6
📒 Files selected for processing (3)
src/Features/WeatherEditor.cppsrc/WeatherEditor/Weather/WeatherWidget.cppsrc/WeatherEditor/WeatherUtils.cpp
Contributor
There was a problem hiding this comment.
🧹 Nitpick comments (1)
src/Features/WeatherEditor.cpp (1)
126-127: PR metadata suggestion: tighten title and add issue linkage if applicable.Suggested title (<=50 chars):
fix(weather-editor): correct weather slider ranges
If this fixes a tracked bug, add:Fixes #<issue-number>.As per coding guidelines: "When reviewing PRs, please provide suggestions for Conventional Commit Titles ... and Issue References ..."
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/Features/WeatherEditor.cpp` around lines 126 - 127, Update the PR title to a concise Conventional Commit-style title and add an issue reference if this change fixes a tracked bug: use the suggested title "fix(weather-editor): correct weather slider ranges" and, if applicable, append "Fixes #<issue-number>" to the PR description; reference this change pertains to WeatherEditor::LerpWeather so reviewers can correlate the metadata update with the weather slider/range fix in that function.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@src/Features/WeatherEditor.cpp`:
- Around line 126-127: Update the PR title to a concise Conventional
Commit-style title and add an issue reference if this change fixes a tracked
bug: use the suggested title "fix(weather-editor): correct weather slider
ranges" and, if applicable, append "Fixes #<issue-number>" to the PR
description; reference this change pertains to WeatherEditor::LerpWeather so
reviewers can correlate the metadata update with the weather slider/range fix in
that function.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 808e8e1a-1e5c-4ebb-92db-3f5cef98c80a
📒 Files selected for processing (1)
src/Features/WeatherEditor.cpp
|
✅ A pre-release build is available for this PR: |
davo0411
approved these changes
Apr 16, 2026
This was referenced Apr 17, 2026
YtzyFvra
pushed a commit
to YtzyFvra/skyrim-community-shaders
that referenced
this pull request
Apr 19, 2026
This was referenced Apr 21, 2026
ParticleTroned
pushed a commit
to ParticleTroned/skyrim-community-shaders
that referenced
this pull request
May 2, 2026
community-shaders#2132) (cherry picked from commit 7d194aa)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR contains a set of corrections for expected values based on feedback from lamin and my own testing.
slider maxima and minima have been corrected, as well as some variable types.
Summary by CodeRabbit