cancel
Showing results for 
Search instead for 
Did you mean: 

[Bug] OVRPlatformTool doesn't work at all on Integration > v13 - can't deploy app from Unity anymore

Aurelinator
Explorer

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.
 

2 REPLIES 2

Aurelinator
Explorer
Well, it looks like my Code tags got eaten in the message above. Sorry. 

I'm going to post them as images.
9kqe5cwxjmfe.png

Command, now on another thread calls genUploadCommand:

ay4jyo2qeguh.png
This has a ton of calls to these Pref-based statics, which will throw exception since they're not on main thread:

4yitje1dhiji.png


Sorry, not sure why my code tags above got eaten and collapsed to one single line.

lostsomfan
Protege
Nice update, we have problem to upload our Application with same error. We have our application updates on hold atm to find a fix how to upload to store.