Add Transmission Capabilities to the Bridge and Related Scripts

[Sharkful]

Right Now, just focus on modules that make use of the bridge, which is the current main way of producing lab content.

Main Goals:

1. Need to add the option for the bridge to spawn an object using Transmission.Spawn()
2. Bridge needs to be able to send the rest of the object modifications using Transmission messages
3. Lab Scripts need a way to link bridge listener functions to Transmission to handle incoming object messages
4. Lab Scripts need a way to know to wait for objects to be sent if they are not host

Work on this is being done in the TransmissionBridge branch, points 1 and 2 have tentatively been covered.

[Sharkful]

Bridge and Transmission Synchronization

When the bridge is instantiated, it needs to link up to Transmission if the lab is a transmission lab. This should be made easy to check by added a field to a lab description object indicating if it is a transmission lab or not.

Need to add code to Login Manager that conditionally enables Transmission and Spatial Alignment if the lab is a transmission lab.

Also need to add Singleton access to the bridge so that just one instance is used across one lab, instead of being instantiated every time a new activity starts.

[Sharkful]

Points 1-3 are hopefully done. The bridge can now be hooked up by the lab manager once if the labdata object has its transmittable field set to true.

Now we need a way for peers to join the same group, and have a way to decide who gets to be the main user. This will be likely be done in the Lab Manager. Once the lab starts, it will go into a kind of waiting room. The first person to launch the lab will create a transmitted global variable that tells when they started the lab. Then when new peers join, they can check if that variable exists. If it does, it can further check if they have been running longer. essentially, the first person to start the lab will be the main user, and all other users will simply be receiving object spawn messages from the transmission and bridge systems.

EDIT: the OnPeerFound() event actually sends you the startup time of a found peer, making it easy to tell who's older! way simpler to use that

[Sharkful]

The lab manager can now identify if it is the oldest Transmission peer, and now we need to make the running activities respond to being transmission hosts or peers. IE, the Demo, or clip activity, needs to be able to accept a boolean value from the lab manager, or perhaps stored in its activity data, identifying that it is a transmission activity, and whether it is the generating host or receiving peers. Its internal logic will need to check if it needs to generate its own objects, or wait to receive them from a peer.

I am going to start looking through Demo.cs and demoActivity.cs to see how this can be fit in, but I don't want to interrupte @jfwallin 's work on his modules. This may be a good time for a code review, and look at how we should make demo.cs work.

[Sharkful]

The code should now cover points 1-4. Work should now focus on linking the lab manager and demo.cs to the transmission bridge. The lab manager should change behavior if it is a transmission lab, adding a waiting room that you can connect to peers in before the lab starts. Only the oldest peer should have the ability to start the lab. Demo.cs does a lot of it's object control with the bridge, but somethings it doesn't. It has calls to play audio and change lighting that also need to be synced up. This can likely be accomplished with a Transmission RPC message.

[Sharkful]

Have made progress on downloading the transmission lab, However since we are still using the Debug server endpoints, It always downloads the same lab file no matter which lab you select from the list. This can be fixed in the future, but it is not pressing enough currently. changed the lab list filename target to "dev_labs_list.json" from "testlabs001.json" changed the lob filename target to "TransmissionDemo.zip" from "TestLab.zip"