refactor(weather-editor): use existing functions for lock retarget

[SkrubbySkrubInAShrub]

In the previous PR I missed that I could reuse a function I made earlier.
No changed functionality.

Summary by CodeRabbit

• Refactor
  • Internal improvements to the weather editor code organization and maintainability through refactored method usage patterns.

[coderabbitai]

📝 Walkthrough

Walkthrough

Refactored weather selection handling in the editor by replacing direct assignment to editorWindow->lockedWeather with an encapsulated LockWeather() method call. The conditional logic guarding the operation remains unchanged, improving code encapsulation while preserving existing behavior.

Changes

Cohort / File(s)	Summary
Weather Editor Encapsulation src/Features/WeatherEditor.cpp	Replaced direct field assignment with LockWeather() method call when updating locked weather on user selection, improving encapsulation without altering control flow logic.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

Possibly related PRs

• feat(weather editor): improve weather picker UI and functionality #1863: Modifies WeatherEditor weather-lock behavior with additional Prepass/lock enforcement and UI controls
• fix(weather-picker): lock weathers enforcement #2146: Updates how user-selected weather is applied when the weather lock is active, ensuring lockedWeather target is updated

Suggested reviewers

• davo0411
• alandtse

Poem

🐰 Direct writes we did once favor,
Now through methods we encapsulate with savor,
Locked weather finds its proper gate,
Refactored clean, oh what a state! ✨

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title directly reflects the main change: replacing direct field manipulation with an existing public method for weather lock retargeting, which matches the changeset.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[github-actions]

No actionable suggestions for changed features.

[coderabbitai]

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

src/Features/WeatherEditor.cpp (1)

683-690: ⚠️ Potential issue | 🟡 Minor

Avoid double-applying weather when retargeting an active lock.

This refactor introduced a behavioral change. The previous code directly assigned editorWindow->lockedWeather = selectedWeather;, but now calls editorWindow->LockWeather(selectedWeather), which applies ForceWeather() again. This causes:

• Accelerated path: ForceWeather() called twice in succession
• Non-accelerated path: SetWeather() (transition) followed immediately by ForceWeather() (cancels transition)

Since the PR states "no functionality changes are intended," consider adding a RetargetLockedWeather() helper that updates only the locked target without re-applying the weather, or revert to direct assignment if the lock is already active.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/Features/WeatherEditor.cpp` around lines 683 - 690, The change calls
editorWindow->LockWeather(selectedWeather) when the lock is already active,
which re-applies ForceWeather/SetWeather and alters behavior; instead add or use
a RetargetLockedWeather helper that only updates the lock target (e.g.,
editorWindow->lockedWeather) without invoking ForceWeather/SetWeather, and call
that when editorWindow->IsWeatherLocked() is true (or revert to direct
assignment to editorWindow->lockedWeather) so s_accelerateWeatherChange,
sky->ForceWeather and sky->SetWeather are not invoked a second time.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Outside diff comments:
In `@src/Features/WeatherEditor.cpp`:
- Around line 683-690: The change calls
editorWindow->LockWeather(selectedWeather) when the lock is already active,
which re-applies ForceWeather/SetWeather and alters behavior; instead add or use
a RetargetLockedWeather helper that only updates the lock target (e.g.,
editorWindow->lockedWeather) without invoking ForceWeather/SetWeather, and call
that when editorWindow->IsWeatherLocked() is true (or revert to direct
assignment to editorWindow->lockedWeather) so s_accelerateWeatherChange,
sky->ForceWeather and sky->SetWeather are not invoked a second time.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: c609949c-7848-41f5-aa5f-659bb0f43dc4

📥 Commits

Reviewing files that changed from the base of the PR and between 31a7b55 and 9de94bb.

📒 Files selected for processing (1)

• src/Features/WeatherEditor.cpp

[github-actions]

✅ A pre-release build is available for this PR:
Download

[SkrubbySkrubInAShrub]

the AI comment may be valid, but double applying is not that big of a deal since it only triggers on the button press once.
If it's a concern I'll hgave to make a new func for this. Which defeats the point of this PR.