Please have native support for locomotion devices
It would be great to have native support for integrating VR locomotion devices (Freeaim VR Shoes, Kat Walk, Virtuix Omni, Natural Locomotion, etc.) similar to how it works with SteamVR. In SteamVR, we can implement our own driver that will translate movement from the device to joystick commands. SteamVR loads the driver and then forwards the joystick commands. We can also retrieve useful information from the headset via the driver and send it to the device, such as HMD position and orientation. Currently, to support a locomotion device on the Meta Quest, game developers have to integrate support. This isn't scalable and is a lot more work than if the locomotion manufacturer could just implement a driver/plugin/background process that works for all games that have locomotion.
OculusMatchMaker error_subcode 1891537
Hi! We have almost all the Oculus Data Use Checkup permissions, and we can't tell why we can't create a public matchmaking room any more (We realise it's being discontinued, but our games have used it for a long time) This is the error we get : (error_subcode 1891537) [OculusMatchMaker] Received create matchmaking room Error: [{"error":{"message":"This call accesses the Matchmaking platform feature, which requires certifying through the Oculus Data Use Checkup program. Please visit this page for more detail: https:\/\/developer.oculus.com\/distribute\/publish-data-use\/. If you have already completed a Data Use Checkup, please ensure that all compliance issues are resolved by visiting the Compliance Dashboard: https:\/\/developer.oculus.com\/resources\/publish-compliance-dashboard\/.","type":"OCApiException","code":10,"error_data":{},"error_subcode":1891537,"fbtrace_id":"A2Tbh26mzIjIhIoO0Q8isJl"}}] It seems to indicate we need new permissions but we have a-lot and can't see anything that's related to Matchmaking we don't have, does anyone know what the subcode is? Jon
New Loading/Splash Screen
Hello, the system splash screen behavior was recently updated. In the past the image supplied by the App would be shown centered on black with the three loading dots below and the size of the logo was pixel perfect so changing the resolution would change the display size. As described here: https://developers.meta.com/ Now after the recent update, the system shows this new fancy animated light rays thing and the image is scaled to fill the entire screen width, i think.. It's very large now and as a result it's very blurry. I was wondering if there is any updated documentation with newer recommendations on what resolution to use now or how the behaviour has changed. I want to avoid submission problems by just guessing, thanks everyone
MQDH Won’t Connect Quest 3 at Final Cable Step Despite USB and ADB Working
Hello everyone, I’m encountering a frustrating issue with Meta Quest Developer Hub (MQDH) v5.7.2 on macOS while trying to set up a Quest 3 running firmware V78. ISSUE DESCRIPTION I enabled Developer Mode on Quest 3 via the mobile app. In the Quest headset, I selected “Always allow USB access.” SideQuest and ADB (adb devices) can successfully detect the Quest 3. However, when I run “Set Up New Device” in MQDH, it stalls at the final step asking me to plug in the cable, even after doing exactly that. No prompt appears inside the headset; MQDH hangs without progressing. I tried reinstalling MQDH and rebooting both Mac and headset—problem persists. WHAT I’VE TRIED Verified Developer Mode is enabled, and USB Connection Dialog permission is granted. Confirmed USB‑C cable works (SideQuest and ADB both connect). Rebooted Quest and Mac multiple times. Uninstalled and reinstalled MQDH, cleared caches/settings. Used both bundled Quest cable and a known good USB‑C data cable (I tested USB 3.2 cable / Thunderbolt cable with Mac mini USB‑C Thunderbolt port). adb works fine. REQUESTED HELP Could someone please advise on potential causes why MQDH stalls even though ADB and SideQuest work? Has anyone else experienced this on Quest 3 running firmware V78 with MQDH 5.7.2? Are there any logs or advanced diagnostics I can capture to pinpoint the blockage? If anyone has successfully connected MQDH after the V78 update, what steps resolved it? FULL ENVIRONMENT INFO Headset Firmware: Quest 3 V78 MQDH Version: 5.7.2 (macOS) OS: macOS (latest version) USB cable: Verified data-capable USB‑C ADB Output: adb devices correctly lists the headset (adb cmd / MacDroid) MQDH Behavior: stuck at final prompt, no progress NEXT STEPS I’m considering doing a factory reset and strictly following the community-suggested flow (skip Air Link until first USB prompt), but not sure if firmware V78 changed behavior. Thank you in advance!Achievements feature.
Hello, I am thinking about adding achievements to my game. But from what I see in the documentation, the achievement checker app will be discontinued at the end of the year and the meta itself does not encourage the implemtation of this feature. Will this functionality be completely removed in the future ? Or are there other plans. I'm wondering if I should spend time on this, from what I'm orenting people like this feature.getAuthToken not supported when trying to use colocation since Firmware 70 and 71 (Unity)
Hi, my team and I have been able to successfully use the experimental Colocation Building Block in Unity successfully until recently. Some of our headsets have been updated from firmware version v69 to v70 or v71. Since then, the Colocation feature is failing to initialize. When PlatformInit.GetEntitlementInformation gets called, it throws the following error: Failed to retrieve access token: 1 - getAuthToken not supported This seems to only affect some headsets that have been updated, on another one it works. Headsets with v69 all seem to work. I tried both Unity Netcode for Gameobjects and Photon Fusion and different users on the headsets which have all been added as test users for the app in the correct release channel in the Meta Developer Dashboard app, the problem persists on the headsets affected. They have also been factory reset - nothing seems to work. Any help would be appreciated. Kind regards, DanielPre-Existing Kotlin Android App - Unable to upload without Oculus SDK
Hi, I have an existing android application written in kotlin which I wish to upload to the quest store. I have built and run the application on a headset locally and it all works perfectly. Upon uploading to the store i get the error "* Oculus SDK not found or older than 1.0." The app does not include the Oculus SDK or similar as it is not needed. It does not take advantage of any headset specific features and is just your standard 2d app. Is bundling the sdk in required to upload to the store? If so is there documentation on how to do so with an existing kotlin app as all the documentation is largely around apps containing native code and doesn't provide clear guidance on this use case. I've considered grabbing the OpenXR samples and smashing that together with the existing app. Is this a reasonable approach? It seems over the top especially for an app that won't require the SDK (for now). Thanks, Nathan
OVRBoundary.GetGeometry returns incorrect play area data when using Link
I am calling OVRBoundary.GetGeometry(OVRBoundary.BoundaryType.PlayArea) and receiving an array of four Vector3 as expected. Since the docs say these are in local space I'm converting them into world space by transforming them by OVRCameraRig.trackerAnchor. This produces different results based on headset: 1. Correct on Rift S in Unity Editor (Windows) 2. Correct on Quest 3 in a build (Android) 3. Incorrect on Quest 3 + usb Link in Unity Editor (Windows) 4. Incorrect on Quest 3 + Air Link in Unity Editor (Windows) 5. Incorrect on Quest 3 + usb Link in build (Windows) The common denominator seems to be Link. In this case while the actual dimensions seem correct, the OVRCameraRig.trackedAnchor has not been updated. It (and OvrCameraRig, and it's 'TrackingSpace' child) are all at identity. Which places the PlayArea points around where I booted the game, and not where the center of the PlayArea should be. This can be reproduced by creating an empty scene and adding the OVRCameraRig, and setting the tracking origin to 'Stage', then visulising the PlayArea rectangle in some way. Adding a LineRenderer under the TrackedAnchor and populating it directly with positions from GetBoundary shows the issue. Unity 2022.3.22f1 / Windows 10 Meta All-in-one SDK v63.0.0 Unity Oculus XR Plugin 4.2.0 OpenXR Plugin 1.10.0 Configured to use the 'Oculus' plugin via the Project Settings -> XR Plug-in Management.