Vrtk: Question about Event Listeners

[garytyler]

I'm not very experienced with Event systems like this and have a few questions if you don't mind. This toolkit is a true gift to the vive dev community. Thank you!

I'm using the Grabbing() and Ungrabbing() funcions from SteamVR_InteractGrab.cs to trigger SceneManager functions and other things throughout the scene (not just on the grabbed object). I also saw the Whirlygig example/script where it inherits SteamVR_InteractableObject.cs. Would it be beneficial to use something the listener example scripts you provided (that must be attached to the controller) or something like the Whirlygig example and spread the interaction scripts throughout the scene? Are there performance benefits in either?

Why is the "new" keyword being used in the listener example instead of just ...+= DoInteractTouch; etc.?

This question is unrelated to the others. If I pick up an object (using any of the 3 interaction modes) then set it down, I have to move my controller away from the object (out of it's trigger range?) and back again to pick it up again. Otherwise it doesn't react when trying to pick it up again. Is there any way to change this?

[thestonefox]

hey @garytyler thanks for the compliments!

The grabbing/ungrabbing event is useful if you want to trigger something in a script that isn't attached to the controller object.

The Whirlygig extends the interactable object so it can add custom code to when an object is used, which is a good way to do something specific on use (or grab if that's your case). But this works because the interactable object knows which controller is doing the grabbing because the object is passed at the point of grabbing.

However, if you had an item that needed to be affected on grab or on use (but it wasn't an interactable object) then you could use the event to know when the grab happened.

A better example of this is in the touchpad walking branch. The headset collision fade throws a headset collided event when the headset hits an object, then the play area listens for that event and moves the player back to a safe location without needing to know about the headset object.

Events are just a clean way of separating and encapsulating code.

As for the grab/touch issue .I'll look into it and see what I can do to improve/fix it.

[thestonefox]

@garytyler I just tried the pick up interactions. I'm not getting the same experience as you.

I can pick up an object, set it down and while the controller is still touching it, I can pick it up again. I don't need to move the controller away to pick it up again.

Can anyone else confirm they're having this issue?

[garytyler]

Thanks for the reply!! Very clear response.

Can you give any insight as to why the "new" keyword is being used in the listener example instead of just ...+= DoInteractTouch; etc.? Is there a reason it should be instantiated at runtime?

[thestonefox]

You have to instantiate an instance of the event class as it's just a delegate on it's own. otherwise it's just an abstract definition.

The DoInteractTouch is a non-invokable method so you need to instantiate an instance to use it.

Not sure if that helps explain things :/

[garytyler]

Thank you very much for the responses!