Need another MonoBehaviour event to support VR physics controller events

The lack of control over script execution makes it very hard to sequence user physics interactions in VR. My player can use colliders to press a button and its like a virtual gamepad button. When the framerate is low (or I have debug statements in the script) then all is fine. When things are running at 100fps it stops working or get haphazard.

It goes like this
FixedUpdate - reset all sensors
OnTriggerStay/OnCollisionStay - check to see if any interactions occurred set static values
-rest of game works on update

Or another version
OnTriggerStay/OnCollisionStay - check to see if any interactions occurred
- rest of game runs on update
LastUpdate - calculate anything that happened in the last frame and carry forward to the next.

Neither of these produces the correct results. I need a buttonDown and buttonUp on the same frame as they occur and a Pressed if its pressed. I cant do this as either buttondown or buttonup will have a frames delay, so I can have down and up in the same frame.

I know that the docs say that at high framerate FixedUpdate may not be called at all, but that makes it worse as it means there is no real way to determine if your just processing the same input twice. Basically, I might get FixedUpdate called, in which case I know my sampled input is good (but delayed), but I might not get it called in which case its bad. But as I have no way to tell (cant fix execution order and no extra call) I have to guess, try to use the framecounter, or other exotic methods to get round the problem.

What would be a perfect solution would be a step between OnMouseXXX and Update (lets call it InputUpdate). This would allow me to process the results of any physics interactions that should be treated like controller events before all the Update()'s ran for all the other scripts. I can then process the results of the physics interactions that are valid for this frame.

Would this be feasible?

 

Ok, so I think I fixed this by using a mixture of flags and script execution for update which for the moment works.

 

Actually no it doesn't.

Script A samples input (OnCollisonStay) and sets a flag depending on the state of Script B. Script B sets its state from OnCollisionStay AND Script A.

If there were an additional step after collision stay, I could remove the interdependence of these.