Find out if user enabled Switch Oculus and Menu option
Hi, I'm working on a game, and in the tutorials we would like to show the players what can they do with the buttons of the controllers, and in some cases we are waiting until the player press the correct button. I can't find any way to figure out if a player enabled or not the Switch Oculus and Menu option in the Hands and Controllers setting menu on a Quest, so if he did, the game will highlight the menu button on the wrong controller, and it confuse the players, because if they press that, the Oculus Dashboard will pop up instead of the in game menu. My question is, how can I check which button is the menu button? Oculus integration package is already added to the project, but I didn't find any reference to this.1.3KViews1like2Comments
[Bug] OVRPlatformTool doesn't work at all on Integration > v13 - can't deploy app from Unity anymore
Bug in OVRPlatformTool Ever since Oculus V13, the integration made a change to OVRPlatformToolSettings.cs to move a lot of the data objects that previous were stored in a scriptable object resource to EditorPrefs. I welcome this - I don't like the idea of committing App IDs and app secrets into my projects, so everyone on our team has that file in their gitignore so we don't actually push up app specific information into our repo. So when I actually went to try it out, I noticed that it just flat out doesn't work for deployment. Why's it broken? The OVRPlatformTool kicks off a few extra threads, which each pass through from one thread to the other. See `ExecuteCommand` in OVRPlatformTool.cs, for example: var thread = new Thread(delegate () { // Wait for update process to finish before starting upload process while (activeProcess) { Thread.Sleep(100); } retryCount = 0; Command(targetPlatform, dataPath); }); thread.Start(); Cool! I'm glad y'all found a really great solution for making things work dynamically. The irony, is that this code is unchanged. It's always done this sort of thread passing thing. The issue, is that now, by virtue of moving things to EditorPrefs, the actual deploy fails constantly because you can't access the EditorPrefs when you're not on the Unity Main Thread, and it throws and error and it's not able to do the actual deploy. Here's for example, the call to get the AppID now: public static string AppID { get { if (Instance.targetPlatform < OVRPlatformTool.TargetPlatform.None && EditorPrefs.HasKey("OVRPlatformToolSettings_AppID" + (int)Instance.targetPlatform)) { return EditorPrefs.GetString("OVRPlatformToolSettings_AppID" + (int)Instance.targetPlatform); } ... An exception will be thrown on the first HasKey that is invoked, because EditorPrefs must be on main thread. I like that the solution was to move to Prefs instead of stored in Resources, but... did nobody test this? After noticing it being broken on V13 I downgraded it, but I figured it'd be fixed on 14... nope, had to revert those files back to the previous version. I feel like I'm either being really stupid and missing something incredible obvious, or... nobody tested this before deployment, because it's literally impossible to use the tool at all for anything meaningful other than to see the UI and for it to not work. Solution for anyone using this: - The Previous version of the integration's OVRPlatformToolSettings.cs works fine on V13/14 right now. - Use the dashboard to upload if you don't have Expansion Files. - Manually use the ovr-platform-util to try doing a deployment yourself, but then you don't get the nice UI and fancy options. Solution for Oculus Folks: Capture the variables you need locally before diving into the thread chain; don't rely on the nice fancy calls like OVRPlatformToolSettings.ReleaseChannel or AppIdas that will fail when accessed from a different thread. (See `genUploadCommand` to see where the actual failure is happening). The issue when tested in editor complains about `HasKey` on the prefs, so it should be really easy to see when trying to upload anything using the tool.1.2KViews1like2Comments