Actions extending an interface instead of abstract MonoBehaviour.

[dreamora]

Problem

At this moment, it is impossible to use streaming levels, streaming prefabs or Addressables with VRTK because Actions extend from MonoBehaviour and are as such scene bound, making it impossible for the VRTK Setup to live anywhere but the same scene the prefabs using them exist in as the relationship is otherwise lost.

Proposed Solution

I would like to propose that Action instead of being an abstract MonoBehaviour, becomes an interface.
This would allow for the problem to be solved in simple, clean and scalable Dependency Injection approach where 2 kinds of actions can be implemented:

1. Action (Local Actions): The same as they are now, extending MonoBehaviour. These actions are geared at handling relationship within the same prefab to provide the current degree of flexibility and possibilities.

2. ActionSignal (Remote Actions): Using ScriptableObject as Action (Observer-Subscriber pattern) that is independent of the scene and specific game objects within it (explained in clean detail at https://www.raywenderlich.com/2826197-scriptableobject-tutorial-getting-started). Such actions could be used only as Source and Targets as serialized ScriptableObject asset can not hold scene dependencies, but at the same time they also ensure that no receiver of an action needs to know its sender or proxy sender.

Added benefit

This also addresses the current limitation of scene serialized coupling (cross prefab in scene dependency between the VRTK Setup, the interactions hierarchy and the actual interactable objects if we consider Farm as a baseline) by removing dependencies in the scene.
At the same time it makes it easier to design things if designers and developers have, for example, a single 'GrabActionSignal' they can use across the project.

Considered alternatives

1. I looked into the possibility of cross scene references as outlined by the Unity Spotlight Team (https://blogs.unity3d.com/2018/07/19/spotlight-team-best-practices-guid-based-references). While it would offer a short term solution for certain cases, it would be incomplete and make the scene dependency issue more troublesome and hard to maintain.

2. I looked into alternative ways along the path of code base Dependency Injection (Zenject/StrangeIoC) of key aspects like 'Main Interactions' (Grab, Use, ...) and the TrackedAliasFacade. While these would work for constrained situations. like getting global access to the tracking aliases, it is no scalable solution for the interaction side.

[thestonefox]

Could you provide steps to reproduce the actual problem you are facing. Whilst it is nice to propose solutions, there may be alternatives that you may not have considered which others can consider if they have clear guides of how to replicate the issue at hand.

[dreamora]

Sure. If there is a way to solve it simpler and in a maintainable form I'm all for it.
Lets assume the following scenario which is a simplified abstraction of what we have:

1. There is an initial scene with the VRTK Setup (Camera Rigs + Interaction hierarchy + the actions setup like Grab, Use etc to have it defined once) that acts as a world selection. This scene contains of a black render inside sphere with a mechanism to choose the world.

2. Every of the worlds you can select in the initial scene is its own set of multiple scenes, each consisting of a base scene with the static world and interactive chunks that get streamed in based on some logic. These interactives use the action setups for grab, use, teleport etc that exist on the VRTK Setup. At this point this is a problem because references can only be in the same scene even if the scenes are always loaded additively together (including inspector assignments at edit time with all scenes open for example)

3. The user can at any point return to this selection scene through a pause menu like approach so it needs to remain present along the world.

4. The transition to all of these worlds needs to be continuous in rendering and audio,

5. The project is focused first and foremost on Oculus Quest.

For productivity during design, development and testing, it is assumed that the simulation rig is supported as well.