refactor: core feature version mismatch UI enhancement

[brucenguyen]

Core features should never have a version mismatch. Unless the core feature was originally a separate feature and the user installed the old separate download. Telling the user that it's a version mismatch and to download a new version is misleading.

Here's an example of a screenshot a user posted asking for support.

This is what it should look like now. (I've also changed the "wrong version" subtext, but the screenshot is from a older build)

Summary by CodeRabbit

• Bug Fixes
  • Refined error messages when features are incompatible, distinguishing between core-included and non-core installations to provide appropriate guidance.
  • Improved detection and UI presentation of version compatibility issues with updated messaging for better user clarity.

[coderabbitai]

📝 Walkthrough

Walkthrough

This PR refines feature version-incompatibility messaging and UI behavior by introducing core-feature-aware handling. When a feature version is incompatible, the system now distinguishes between core-included and optional features, providing tailored error messages and preventing core features from being offered replacement downloads or deletion via the standard path.

Changes

Cohort / File(s)	Summary
Core Feature Compatibility Messaging src/Feature.cpp	Modified Feature::Load to distinguish core-included features from others when version incompatibility occurs, returning specific uninstallation guidance via mod manager for core features instead of generic version-mismatch warnings.
Feature Issues UI and Helpers src/FeatureIssues.cpp	Added static helper IsVersionMismatchForCoreFeature() to identify core features with version mismatches; updated display, download, and deletion logic to provide different messaging and restrict certain actions for core-feature version mismatches.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Possibly related PRs

• refactor(ibl): move ibl to core feature #1396: Introduces IBL as a core feature (IsCore()=true), directly triggering the new core-feature code paths added in this PR.
• fix(ui): distinguish missing vs pending features #1188: Modifies feature load and version-mismatch messaging, including required-version UI changes that overlap with this PR's messaging updates.
• feat: check feature compatibility (#1136) #1163: Alters the same Feature::Load and FeatureIssues code paths modified here, including version-mismatch and compatibility handling.

Suggested reviewers

• alandtse
• doodlum
• davo0411

Poem

🐰 Core features now stand tall and wise,
With special care and tailored guise,
No hasty deletes, no swapped repair,
Just gentle guidance, handled with care! ✨

🚥 Pre-merge checks | ✅ 3 | ❌ 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 (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately describes the main change: refactoring UI logic to distinguish core feature version mismatches from other version mismatches, with a focus on enhancing how these cases are presented to users.
Merge Conflict Detection	✅ Passed	✅ No merge conflicts detected when merging into dev

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

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

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]

Using provided base ref: afa9b41
Using base ref: afa9b41
Base commit date: 2026-02-15T21:17:17+10:00 (Sunday, February 15, 2026 09:17 PM)
No actionable suggestions for changed features.

[coderabbitai]

🧹 Nitpick comments (3)

src/Feature.cpp (1)

99-105: Core-feature log message omits feature identity.

When IsCore() is true, failedLoadedMessage is a generic string without the feature's short name or version. This is fine for the UI tooltip (the feature name is rendered separately), but at line 129 it's the only thing logged — making it hard to identify which core feature triggered the issue.

Consider including the feature name in the message, even if it's displayed differently in the UI:

Suggested diff

 				if (IsCore()) {
-					failedLoadedMessage = std::format("This feature is already included as part of the core Community Shaders installation. Uninstall this feature with your mod manager.");
+					failedLoadedMessage = std::format("{} {} is a core feature already included in the Community Shaders installation. Uninstall this feature with your mod manager.", GetShortName(), value);
 				} else if (majorVersionMismatch) {

src/FeatureIssues.cpp (2)

632-635: Consider extracting the compound condition for readability.

The canSafelyDelete expression spans a long single line with three sub-conditions. Breaking it out would make the comment above it easier to match to the code.

Optional refactor

-	bool canSafelyDelete = (!issue.ModifiedShaderDirectory() || (issue.IsObsolete() && !issue.replacementFeature.empty())) && !IsVersionMismatchForCoreFeature(issue);
+	bool isSafeIssueType = !issue.ModifiedShaderDirectory() || (issue.IsObsolete() && !issue.replacementFeature.empty());
+	bool canSafelyDelete = isSafeIssueType && !IsVersionMismatchForCoreFeature(issue);

---

578-584: Minor: PR title could be fix(ui) instead of refactor.

Since the change corrects misleading user-facing messaging (not just internal restructuring), fix(ui): clarify core feature version mismatch guidance may be a better fit per conventional commits. Also consider adding an issue reference (e.g., Fixes #NNNN``) if a tracking issue exists. As per coding guidelines: "type(scope): description" format with appropriate type.

[github-actions]

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

[alandtse]

The solution is probably not to even warn on core features unless it truly is a mismatch (like old version installed)? Or maybe we need to fix the scritp on how it detects the last valid version for core. I don't think changing the message solves the core problem. We also train people to ignore items that appear in the list.

[alandtse]

Blocking merge since this is just hiding the symptoms. Please see my earlier comment to figure out the best long term approach.

[brucenguyen]

The solution is probably not to even warn on core features unless it truly is a mismatch (like old version installed)? Or maybe we need to fix the scritp on how it detects the last valid version for core. I don't think changing the message solves the core problem. We also train people to ignore items that appear in the list.

Not sure if I follow. This is improving the messaging for the specific scenario where a feature used to be separate but was moved to core. But the user erroneously installed the deprecated separate download.

Otherwise, core features should never be version mismatched, it's enforced at build time. So core features never trigger feature issues other than this specific case.

Basically somehow the user replaced the core feature ini shipped with CS.

[davo0411]

The solution is probably not to even warn on core features unless it truly is a mismatch (like old version installed)? Or maybe we need to fix the scritp on how it detects the last valid version for core. I don't think changing the message solves the core problem. We also train people to ignore items that appear in the list.

I think bruce's approach is valid - its to better explain to people that something is now core, currently it looks like they need an update... which doesn't exist on the modpage. the average user is not going to go mod page -> cs main -> realise its now core -> delete old one. they will just get confused lol

[alandtse]

1. User has mismatched versions.
   Warn.

2. User has the core version and no other version.
   No warning.

I may have misread that you were providing a warning for 2. There's a use case where there's a core feature but it's not supported (like in VR). That was also a case to consider.

My point was is the detection logic wrong? If so, we have to fix that.

[brucenguyen]

1. User has mismatched versions.
   Warn.
2. User has the core version and no other version.
   No warning.

I may have misread that you were providing a warning for 2. There's a use case where there's a core feature but it's not supported (like in VR). That was also a case to consider.

My point was is the detection logic wrong? If so, we have to fix that.

detection logic seems sound, perhaps too good which is why it pops up for this case