Here's what we now have live on the Production Server:

WebRTC Updates

Update 1 - Resolving the Chain of Calls

When WebRTC activates it begins connecting individual users sequentially from the first user to log into the game to the very last. The expected result was that each user would go down the chain of users until everyone was connected to the call.

  1. Call 1: User A is hailed, User A receives the request and connects to the call, Move on to Call 2
  2. Call 2: User B is hailed, User B receives the request and connects to the call, Move on to Call 3
  3. Call 3: User C is hailed, User C receives the request and connects to the call, Move on to Call 4
  4. Call 4: User D is hailed, User D receives the request and connects to the call, Move on to Call 5
  5. (repeat this process until all Users currently logged into the game are connected)
The unexpected problem we discovered is that when a user in the order fails to connect, the entire chain of connections stops cold. So we have the following occur:

  1. Call 1: User A is hailed, User A receives the request and connects to the call, Move on to Call 2
  2. Call 2: User B is hailed, User B does not receive the request, doesn’t connect to the call, Process Hangs
  3. There are no Calls 3, 4, 5, … made out to the remainder of the users in the group. The Chain dies at User B.
Worse, we also didn’t have an error being thrown out when this occurred so we wouldn’t know when the connection breaks. For those in a game, it would feel like the entire call failed rather than being able to identify which user in particular was having difficulties with WebRTC.

Now with this update, there is a purposely made delay as it connects to the users down the chain. If a user is unable to connect, the chain of connections will continue onto the next user until all users have been given a chance to connect to the call. This way the gaming group will be able to identify the user who needs Video/Voice troubleshooting.

Update 2 - No More Doubled-Up Calls

Previously, if two users logged in to a game at close to the exact same time, WebRTC would have the two users call each other and the result would be two separate connections between the two users rather than one. This lead to a great deal of call instability where one of the video feeds would be overwritten by the other and it would be impossible to tell which one. This made it impossible for our system to know which feed to attach the Volume and Whispering controls to.

With this update we’ve locked down the connection system and made the process “atomic”. In programming terms, the calls between users are locked down to a specific order even if the two users log in within a fraction of second apart. Multiple users doing the exact same thing, at the exact same time, with the same data doesn’t have an impact on the order in which the calls are being sent out and connecting.


Update 3 - No More Volume Meter Stacking

We have added more polish to the Volume Meter. Previously, when users reconnected, it was possible for multiple instances of the same volume meter to stack on top of each other. This would cause the volume meter to flash at best or be entirely unstable at worst. Now everyone should only have a single Volume Meter that clears itself properly in the case of a browser refresh or reconnect.

Remaining Issue

Sometimes a call connection with a user may go through without issue, but all anyone else sees is a Black Box for their video feed and no audio transmitted. This issue is due to a browser hiccup (likely caused with all the other background processes Roll20 is doing at that very moment) when the call connection was made. From Roll20's side, it looks like the connection is made, but the user's browser isn’t actually sending any video or voice data.

In most cases, all the User should have to do is click on the Reconnect Button from the Settings Tab to kickstart the browser to establish a new connection.

Game Defaults Improvements

There were some issues where certain drag and drop actions that generate tokens were not receiving the GM’s specified Game Defaults.

Now the following will receive Token Defaults:
  • Tokens dropped onto the Tabletop from a file folder on your computer
  • Tokens generated from the Avatar image applied to a Character Journal
  • If a Card Deck is set to be drawn as tokens rather than drawings, these will also receive token defaults

Character Sheet Listing Improvements

We’ve made a change on how we organize the order of Character Sheets that feature on the drop down list. Previously we had some outlier sheets that weren’t being sorted properly alphanumerically or listed under the incorrect system. This is now fixed.

Dynamic In-Game Page and Folder IDs

Previously, when you first created a game, the Start Page and the initial Character and Handout folders had static ID numbers. This became an issue when we incorporated the Game Addon feature. These static IDs could cause content being overwritten unintentionally or the Journal tab’s folder structure was pulled apart when an Addon was brought into a game. Now these game item IDs are dynamic and should be unique for each game to prevent this issue from occurring again.

Game Search Improvements

Previously, if you ran a search through your game collection, the search results would only pull the games that you were the Creator of. Now results will match games you’ve created and also ones that you are a Player in.