We were hoping to get our VR Module for Game Creator 1 finalised and packaged up to post to Unity before the end of the month. But those of you in the Game Development industry will know, nothing ever goes according to plan. Testing the code on various devices and in different modes was essential for shipping a quality product. As most of the GC users suggested that their VR platform of choice was the Quest 2 from Oculus, that has been our development standard over the past few months. As the Quest is essentially an Android phone, the Unity platform for the Builds has been Android during most of our development cycle.
But as fate would have it, when we tested using the Airlink, or on other VR tethered devices, it did not quite work as planned. Do get me wrong, 98% of the product works just peachy, but when we flip between first person and third person cameras using the hand-control trigger, things went into the twilight zone. In the Android build, it was perfect, in the PC build, the 3rd person camera vector was inverted.
I figured that it was something to do with the different platforms, and I was correct, but not in the way I had thought. I spent the next couple of days coding all possible scenarios and alternatives in a way that would cope with each of the application's platforms, but I could not seem to get it to work as designed. To cut a long story short, I was barking up the wrong (Virtual Reality) tree.
Apparently, as I should have read earlier in the week, there are some issues with the execution order of scripts when running on an Android. This problem has already been reported, but sadly nobody told me. And as I was using the Android as my base device, it worked correctly in the incorrect order, if you can understand that. Hence I have now recoded it to work correctly on the PC and added an Attribute to force the execution order to be correct on the Quest.
Yes, there is the Update loop and the Late Update loop, where scripts will also be actioned in Update before Late Update. There is also a Fixed Update loop but you would mostly use this for physics and animation code. In Unity's defence, they write....
A common use for LateUpdate would be a following third-person camera. If you make your character move and turn inside Update, you can perform all camera movement and rotation calculations in LateUpdate. This will ensure that the character has moved completely before the camera tracks its position.
Now this is kind of what we were doing with the VR rig, but as it is the camera that moves the character, we need it in the reverse order. You can also manipulate the order that scripts will execute by adding them to the Execution Order Panel in the project settings. But as we want our product to work seamlessly, this was not an option.
However, all was not lost. There is an undocumented attribute that we can use. And yes, you read correctly, it is undocumented. Within the Unity forums, users have asked as to why it is undocumented, and Unity's official answer was....
"the DefaultExecutionOrder was probably left undocumented because its effect doesn't show up in the Execution Order window, which could lead to confusion." - Unity Technologies.
They are correct, (maybe not about the confusion) the attribute will not add your script to the project settings order table, but we tested in thoroughly in both the editor and within builds on the PC and Android, and it works just fine.
So, for those interested to read further, 0 is the Update loop. Scripts with minus numbers are executed first (top of the table) and higher numbers executed last (bottom of the table). In this graphic from my project you can see that Valve require their code to run first, and Rootmotion want their Final IK scripts to run last.
