Skip to content

fix(VR): disable hmd menu for incompatible openvr#1309

Merged
doodlum merged 10 commits into
community-shaders:devfrom
alandtse:open_vr_blocking
Jul 26, 2025
Merged

fix(VR): disable hmd menu for incompatible openvr#1309
doodlum merged 10 commits into
community-shaders:devfrom
alandtse:open_vr_blocking

Conversation

@alandtse
Copy link
Copy Markdown
Collaborator

@alandtse alandtse commented Jul 26, 2025

Summary by CodeRabbit

  • New Features

    • Added robust detection and display of OpenVR version and compatibility status in the VR debug UI.
    • Introduced an auto-reset feature for fixed world position overlay based on player movement distance.
    • Overlay auto-hide timeout is now configurable, replacing the previous boolean setting.
    • Added new VR settings for overlay auto-hide duration and auto-reset distance, with manual reset control.
  • Improvements

    • VR menus, overlays, and related UI elements are conditionally shown or hidden based on OpenVR compatibility, enhancing stability.
    • VR device input blocking now depends on OpenVR compatibility, improving input reliability.
    • VR overlay visibility and behavior dynamically respond to OpenVR version compatibility.
    • Updated VR controller button combo colors and labels for clearer identification.

@coderabbitai
Copy link
Copy Markdown
Contributor

coderabbitai Bot commented Jul 26, 2025

"""

Walkthrough

This update introduces robust OpenVR version detection and compatibility enforcement within the VR feature. It adds methods for gathering and validating OpenVR DLL information, integrates compatibility checks throughout the VR overlay and menu UI, and refines input and overlay logic to conditionally enable VR features only when a whitelisted OpenVR version is detected.

Changes

File(s) Change Summary
src/Features/VR.cpp, src/Features/VR.h Added OpenVR version detection, compatibility check, DLL info struct, new overlay auto-hide logic, and related settings.
src/Hooks.cpp Modified input device polling to block VR devices only if OpenVR is incompatible; added VR header include.
src/Menu.cpp Updated VR detection logic to use VR feature pointer and compatibility check instead of static module check.
src/Utils/VRUtils.cpp, src/Utils/VRUtils.h Refactored controller button combo colors to use centralized color utilities; added new color constants and getter functions.
src/Utils/UI.h Adjusted indentation of usage comment for DisableGuard class; no functional changes.

Sequence Diagram(s)

sequenceDiagram
    participant User
    participant Menu
    participant VR
    participant OpenVR DLL

    User->>Menu: Open VR-related UI or overlay
    Menu->>VR: Check IsOpenVRCompatible()
    VR->>OpenVR DLL: DetectOpenVRInfo()
    VR-->>Menu: Return compatibility status
    alt OpenVR compatible
        Menu->>VR: Show VR menus, overlays, process input
    else OpenVR not compatible
        Menu-->>User: Hide/disable VR menus and overlays
    end
Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Suggested reviewers

  • doodlum

Poem

🐇✨
I sniffed the VR wires, checked DLLs with care,
Only whitelisted versions may enter our lair!
If OpenVR’s friendly, the overlays shine bright,
If not, menus vanish—no crashes in sight.
With version checks hopping, stability’s near—
A rabbit’s proud work, for VR is clear!
🐰🎮
"""

Note

⚡️ Unit Test Generation is now available in beta!

Learn more here, or try it out under "Finishing Touches" below.

✨ Finishing Touches
  • 📝 Generate Docstrings
🧪 Generate unit tests
  • 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
🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Explain this complex logic.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai explain this code block.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and explain its main purpose.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

Support

Need help? Create a ticket on our support page for assistance with any issues or questions.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai generate docstrings to generate docstrings for this PR.
  • @coderabbitai generate sequence diagram to generate a sequence diagram of the changes in this PR.
  • @coderabbitai generate unit tests to generate unit tests for this PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

@github-actions
Copy link
Copy Markdown

Using provided base ref: de23937
Using base ref: de23937
Base commit date: 2025-07-25T00:26:48+01:00 (Friday, July 25, 2025 12:26 AM)
No actionable suggestions for changed features.

Copy link
Copy Markdown
Contributor

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

📜 Review details

Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between de23937 and 3be959d.

📒 Files selected for processing (4)
  • src/Features/VR.cpp (15 hunks)
  • src/Features/VR.h (7 hunks)
  • src/Hooks.cpp (2 hunks)
  • src/Menu.cpp (5 hunks)
🧰 Additional context used
🧠 Learnings (2)
src/Hooks.cpp (5)

Learnt from: alandtse
PR: #577
File: features/Wetness Effects/Shaders/WetnessEffects/WetnessEffects.hlsli:57-61
Timestamp: 2025-06-17T05:40:22.785Z
Learning: Default parameter values are supported in the HLSL compiler used by the skyrim-community-shaders project, contrary to standard HLSL (FXC/DXC) limitations.

Learnt from: alandtse
PR: #577
File: src/Features/WetnessEffects.h:36-36
Timestamp: 2025-06-08T11:25:14.536Z
Learning: In the skyrim-community-shaders project, boolean flags in C++ structs that interface with HLSL shaders use uint type instead of bool for compatibility reasons. This ensures consistent 4-byte size, proper 16-byte alignment in constant buffers, and cross-platform compatibility when passing data between C++ and HLSL shaders.

Learnt from: alandtse
PR: #577
File: src/Features/WetnessEffects.h:36-36
Timestamp: 2025-06-08T11:25:14.536Z
Learning: In the skyrim-community-shaders project, boolean flags in C++ structs that interface with HLSL shaders use uint type instead of bool for compatibility reasons. This ensures consistent size, alignment, and cross-platform compatibility when passing data to shader constant buffers.

Learnt from: alandtse
PR: doodlum/skyrim-community-shaders#0
File: :0-0
Timestamp: 2025-07-01T18:01:07.079Z
Learning: In the skyrim-community-shaders project, simple scalar constants in HLSL shaders use #define (e.g., #define NTHREADS 128), while more complex constants use static const within namespaces (e.g., Math namespace in Math.hlsli). For epsilon standardization, #define is the appropriate choice since epsilon values are simple scalar constants.

Learnt from: alandtse
PR: doodlum/skyrim-community-shaders#0
File: :0-0
Timestamp: 2025-07-05T05:20:45.823Z
Learning: In the skyrim-community-shaders repository, file deletion error handling improvements that replace existence checks and try-catch blocks with std::filesystem::remove error-code-based approaches are considered bug fixes rather than refactoring, as they address inadequate error handling and misleading log messages.

src/Menu.cpp (1)

Learnt from: alandtse
PR: #1157
File: src/Feature.cpp:42-49
Timestamp: 2025-06-17T09:27:49.594Z
Learning: In src/Feature.cpp, when an obsolete feature's INI file is deleted, the feature should be silently disabled without surfacing any issues to the user. This is the intended behavior because a deleted INI file for an obsolete feature indicates that the user has properly cleaned up the obsolete feature.

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
  • GitHub Check: Build plugin and addons
🔇 Additional comments (10)
src/Hooks.cpp (2)

15-15: LGTM: VR header include added correctly.

The include is properly positioned with other feature headers and is necessary to access the VR compatibility methods used in the input polling logic.


591-592: VR input blocking logic is correct

The existing expression correctly:

  • Blocks VR devices only when OpenVR is compatible (i.e., the in-game VR menu is active), preventing underlying game input.
  • Allows all VR input when OpenVR is incompatible (disabling the HMD menu fallback to normal controls).

No changes required here.

src/Menu.cpp (6)

304-306: LGTM: Proper VR compatibility checking in overlay initialization.

The change from REL::Module::IsVR() to globals::features::vr && globals::features::vr->IsOpenVRCompatible() correctly implements the new compatibility validation system while ensuring null safety.


1623-1625: LGTM: Consistent VR feature presence check for Frame Generation.

The updated logic correctly disables Frame Generation when the VR feature is present, maintaining consistency with the new VR feature architecture.


1659-1661: LGTM: Proper VR compatibility gating for overlay texture recreation.

The compatibility check ensures overlay textures are only recreated when OpenVR is compatible, preventing unnecessary operations on incompatible systems.


1663-1665: LGTM: Consistent VR compatibility check for controller input.

The controller input processing is correctly gated by the same compatibility check pattern used throughout the file.


1677-1682: LGTM: Updated VR input event filtering logic.

The input event filtering now correctly uses the new compatibility checking mechanism while maintaining the existing VR controller device detection logic.


1782-1784: LGTM: Proper VR compatibility check for overlay frame submission.

The overlay frame submission is appropriately gated by the compatibility check, ensuring VR overlay operations only occur when OpenVR is compatible.

src/Features/VR.cpp (1)

74-96: Good defensive programming with early OpenVR detection.

The implementation correctly detects OpenVR compatibility early in the initialization process and provides detailed logging. This prevents potential CTDs by avoiding incompatible OpenVR operations later.

src/Features/VR.h (1)

311-311: Well-designed overlay visibility logic.

The updated condition properly checks OpenVR compatibility before allowing overlay visibility, preventing potential crashes. The integration with auto-hide seconds and menu state provides good user experience control.

Comment thread src/Features/VR.cpp
@github-actions
Copy link
Copy Markdown

github-actions Bot commented Jul 26, 2025

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

Copy link
Copy Markdown
Contributor

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

♻️ Duplicate comments (1)
src/Features/VR.cpp (1)

2306-2332: Overly restrictive compatibility approach remains unchanged.

The strict whitelist still only allows a single specific OpenVR version, which may unnecessarily block users with potentially compatible versions. This matches the concern raised in previous reviews about being too restrictive.

Consider implementing the suggestions from the previous review:

  1. Support version ranges instead of exact matches
  2. Add user override options for advanced users
  3. Use a blacklist for known incompatible versions instead

The current approach may require frequent maintenance as new OpenVR versions are released and could prevent users from accessing VR features with compatible newer versions.

🧹 Nitpick comments (1)
src/Features/VR.cpp (1)

74-95: Good proactive compatibility detection approach.

The early OpenVR detection and comprehensive logging will help users understand compatibility issues. Consider using debug level for some of the detailed logging (lines 82-86) to reduce verbosity in normal operation.

-		logger::info("OpenVR DLL detected:");
-		logger::info("  Path: {}", openVRInfo.dllPath);
-		logger::info("  Version: {}", openVRInfo.version);
-		logger::info("  Size: {} bytes", openVRInfo.fileSize);
-		logger::info("  Modified: {}", openVRInfo.modificationTime);
+		logger::info("OpenVR DLL detected: {} (Compatible: {})", openVRInfo.version, openVRInfo.isCompatible ? "Yes" : "No");
+		logger::debug("  Path: {}", openVRInfo.dllPath);
+		logger::debug("  Size: {} bytes", openVRInfo.fileSize);
+		logger::debug("  Modified: {}", openVRInfo.modificationTime);
📜 Review details

Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between c386cd2 and 14bdad2.

📒 Files selected for processing (4)
  • src/Features/VR.cpp (21 hunks)
  • src/Utils/UI.h (1 hunks)
  • src/Utils/VRUtils.cpp (2 hunks)
  • src/Utils/VRUtils.h (2 hunks)
✅ Files skipped from review due to trivial changes (2)
  • src/Utils/UI.h
  • src/Utils/VRUtils.h
🚧 Files skipped from review as they are similar to previous changes (1)
  • src/Utils/VRUtils.cpp
🧰 Additional context used
🧬 Code Graph Analysis (1)
src/Features/VR.cpp (6)
src/Features/VR.h (3)
  • GetSingleton (267-271)
  • Both (120-120)
  • Primary (106-106)
src/Menu.h (1)
  • GetSingleton (16-20)
src/Utils/UI.h (1)
  • HoverTooltipWrapper (53-62)
src/Utils/UI.cpp (2)
  • HoverTooltipWrapper (25-32)
  • HoverTooltipWrapper (34-40)
src/Utils/VRUtils.cpp (2)
  • DrawButtonCombo (9-72)
  • DrawButtonCombo (9-9)
src/Utils/VRUtils.h (3)
  • GetControllerBothColor (35-35)
  • GetControllerPrimaryColor (33-33)
  • GetControllerSecondaryColor (34-34)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
  • GitHub Check: Build plugin and addons
🔇 Additional comments (9)
src/Features/VR.cpp (9)

20-21: LGTM - Necessary includes for version detection.

The addition of winver.h and linking version.lib are required for the new OpenVR DLL version detection functionality.


51-51: Good improvement from boolean to configurable timeout.

Changing from ShowHowToUseMessage to kAutoHideSeconds provides users with granular control over the overlay display duration instead of just on/off.


120-169: Excellent compatibility gating and timeout logic improvements.

The early return for incompatible OpenVR versions prevents crashes, and the conversion from boolean to configurable timeout seconds provides better user control. The UI text appropriately directs users to the new setting location.


203-211: Consistent compatibility gating across VR-specific UI elements.

The approach properly prevents users from configuring VR-specific features when OpenVR is incompatible, avoiding confusion and potential issues.


422-543: Excellent improvement to controller input instructions.

The new table-based layout with color-coded controller information and comprehensive thumbstick instructions greatly improves usability and clarity for VR users.


773-789: Valuable debug information for troubleshooting compatibility.

The OpenVR information section with color-coded compatibility status will greatly help users and developers diagnose VR-related issues.


1287-1291: Proper safety gating for overlay initialization.

The compatibility check prevents overlay creation attempts with incompatible OpenVR versions, avoiding potential crashes.


1394-1397: Consistent safety gating for overlay operations.

Early return for incompatible OpenVR maintains consistency with other overlay methods and prevents undefined behavior.


2241-2304: Robust OpenVR detection implementation.

The OpenVR DLL detection logic correctly uses Windows APIs to gather comprehensive version and file information. The implementation handles edge cases well and provides detailed diagnostic data.

Copy link
Copy Markdown
Contributor

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

♻️ Duplicate comments (1)
src/Features/VR.cpp (1)

2266-2357: Consider the restrictive whitelist approach

The current implementation uses a strict whitelist that only allows one specific OpenVR version (1.0.10.0). While this ensures stability, it may be overly restrictive and could unnecessarily disable VR features for users with potentially compatible versions.

Consider these improvements:

  1. Version range support instead of exact matches
  2. User override option for advanced users
  3. Blacklist approach for known incompatible versions

The detection logic itself is well-implemented with comprehensive version information gathering.

📜 Review details

Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 14bdad2 and 4f7d4a9.

📒 Files selected for processing (2)
  • src/Features/VR.cpp (22 hunks)
  • src/Features/VR.h (7 hunks)
🧰 Additional context used
🧬 Code Graph Analysis (2)
src/Features/VR.h (2)
src/Features/VR.cpp (6)
  • SetupResources (75-96)
  • SetupResources (75-75)
  • DetectOpenVRInfo (2266-2329)
  • DetectOpenVRInfo (2266-2266)
  • IsOpenVRCompatible (2331-2357)
  • IsOpenVRCompatible (2331-2331)
src/Globals.h (1)
  • globals (47-145)
src/Features/VR.cpp (6)
src/Features/VR.h (3)
  • GetSingleton (267-271)
  • Both (120-120)
  • Primary (106-106)
src/Menu.h (1)
  • GetSingleton (16-20)
src/Utils/UI.h (1)
  • HoverTooltipWrapper (53-62)
src/Utils/UI.cpp (2)
  • HoverTooltipWrapper (25-32)
  • HoverTooltipWrapper (34-40)
src/Utils/VRUtils.cpp (2)
  • DrawButtonCombo (9-72)
  • DrawButtonCombo (9-9)
src/Utils/VRUtils.h (3)
  • GetControllerBothColor (35-35)
  • GetControllerPrimaryColor (33-33)
  • GetControllerSecondaryColor (34-34)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
  • GitHub Check: Build plugin and addons
🔇 Additional comments (26)
src/Features/VR.h (7)

245-246: LGTM! Well-chosen default and maximum values.

The 30-second default auto-hide timeout provides a good balance between visibility and user experience, while the 5-minute maximum prevents indefinite overlay display.


291-291: LGTM! Proper override declaration for OpenVR compatibility detection.

The SetupResources() override follows the framework pattern and will handle early OpenVR detection to prevent crashes with incompatible versions.


311-311: Excellent safety improvement! OpenVR compatibility gating prevents crashes.

The updated visibility logic properly gates overlay display on OpenVR compatibility, preventing potential crashes with incompatible OpenVR versions while maintaining the existing auto-hide and menu state logic.


333-333: Good UX improvement! Fixed world positioning provides better stability.

Changing the default from HMD-relative (0) to fixed world position (1) improves user experience by providing more stable overlay positioning that's less disorienting during head movements.


381-385: Well-designed settings additions for enhanced VR functionality.

The new settings provide good configurability:

  • kAutoHideSeconds offers precise timeout control replacing the boolean approach
  • EnableDragToReposition gives users control over drag functionality
  • VRMenuAutoResetDistance (1000 units ≈ 14.3m) is a sensible default for auto-reset detection

418-418: Proper validation! Auto-hide timeout clamping maintains data integrity.

The clamping of kAutoHideSeconds to [0, kMaxAutoHideSeconds] follows the established pattern and prevents invalid timeout values that could cause issues.


596-596: Well-designed additions for OpenVR compatibility and auto-reset functionality.

The new member variables and method declarations provide clean interfaces for:

  • savedPlayerWorldPos: Reference point for auto-reset distance calculations
  • DetectOpenVRInfo(): OpenVR DLL detection and metadata gathering
  • IsOpenVRCompatible(): Compatibility validation against whitelist

The naming follows conventions and the design supports the safety-focused approach.

Also applies to: 604-605

src/Features/VR.cpp (19)

20-21: LGTM - Required includes for version detection

The winver.h header and version.lib linkage are correctly added to support the new OpenVR version detection functionality.


51-52: Settings structure properly extended

The changes correctly add the new kAutoHideSeconds timeout setting and VRMenuAutoResetDistance for the auto-reset functionality.


75-96: Well-implemented OpenVR compatibility detection

The new SetupResources() method correctly implements early OpenVR version detection with comprehensive logging. The approach of detecting compatibility early helps prevent crashes with incompatible versions.


121-122: Good early compatibility check

The early return for incompatible OpenVR versions prevents unnecessary overlay operations and potential crashes.


126-149: Timeout logic correctly updated

The change from boolean to integer-based timeout logic is properly implemented with consistent variable naming and calculations.


204-212: Smart conditional UI rendering

Hiding the "Bindings" tab when OpenVR is incompatible is a good UX decision that prevents user confusion and avoids exposing non-functional VR controls.


426-427: Consistent compatibility check

The early return for incompatible OpenVR maintains consistency with other UI sections.


430-434: Well-designed auto-hide timeout control

The slider with tooltip provides clear user control over the overlay timeout with helpful explanatory text.


435-542: Excellent UI reorganization

The table-based layout for controller input instructions is much more organized and readable than the previous format. The color-coded controller information enhances usability.


564-565: Consistent compatibility enforcement

The early return maintains consistency with other settings sections when OpenVR is incompatible.


604-615: Valuable auto-reset functionality

The auto-reset distance slider and manual reset button provide users with good control over fixed world position behavior. The formatted distance in the tooltip is a nice UX touch.


621-622: Consistent compatibility check in mouse settings

The early return maintains proper gating of VR-specific functionality.


633-634: Consistent compatibility check in drag settings

The early return maintains proper gating of VR-specific functionality.


787-803: Valuable diagnostic information

The OpenVR Information section provides comprehensive debugging details including compatibility status, DLL version, and metadata. This will be very helpful for troubleshooting VR issues.


1095-1102: Useful debugging addresses

The OpenVR Addresses section provides developers with debugging information about internal OpenVR objects and their memory locations.


1312-1316: Essential compatibility check

The early return in overlay initialization prevents potential crashes with incompatible OpenVR versions.


1419-1422: Important safety check

Skipping overlay operations when OpenVR is incompatible prevents crashes and undefined behavior.


1208-1220: Well-implemented auto-reset logic

The distance-based auto-reset functionality correctly tracks player movement and resets the overlay position when the configured threshold is exceeded. The position update after reset is handled properly.


1644-1644: Helpful debugging information

The handedness change logging will assist in troubleshooting VR controller issues.

Comment thread src/Features/VR.h
Comment on lines +585 to +594
// OpenVR version and compatibility information
struct OpenVRInfo
{
bool isAvailable = false;
bool isCompatible = true;
std::string dllPath;
std::string version;
uint64_t fileSize = 0;
std::string modificationTime;
} openVRInfo;
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🛠️ Refactor suggestion

Consider defaulting isCompatible to false for better safety.

The OpenVRInfo struct design is excellent for tracking OpenVR metadata. However, consider changing isCompatible = true to isCompatible = false as the default. This ensures that OpenVR features are disabled by default and only enabled after explicit compatibility validation, providing better fail-safe behavior.

-		bool isCompatible = true;
+		bool isCompatible = false;
🤖 Prompt for AI Agents
In src/Features/VR.h around lines 585 to 594, change the default value of the
isCompatible member in the OpenVRInfo struct from true to false. This means
updating the initialization from isCompatible = true to isCompatible = false to
ensure OpenVR features are disabled by default until compatibility is explicitly
verified.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants