During Worlds Group Stage Day 1: TSM vs RNG, there was an issue that prevented TSM Bjergsen from seeing the missiles orbiting RNG Xiaohu's Aurelion Sol.
In this post I will explain the technical details of why this happened. It's a complex issue, so stick with me - I'll walk you through the necessary foundations then follow the cause of the problem and what we're doing to resolve it.
#Background Technical Information
Aurelion Sol's missiles have him as their target object. Usually a missile's target is the object it homes in on, but in the case of orbiting missiles we utilize the target information to convey which unit the missile orbits around.
When the client is told about a missile that's targeting a unit out of vision, it creates a placeholder object to indicate that the client doesn't have proper information about that target. This placeholder prevents the game from utilizing outdated information from a known but not visible unit.
When one of Aurelion Sol's missiles can be seen but he himself cannot, we have a mechanism whereby the server sends positional information of Aurelion to clients so that the missile can be simulated in a reasonably correct position. I'll call this process "secondary synchronization." We had some issues with the missile showing up in the wrong place sometimes, which were fixed by having the missile stay hidden until correct positional information arrives. This can happen either through secondary synchronization or by Aurelion becoming visible.
The final bit of background that you need is that esports spectator clients are not set up like the spectate feature players use. When you spectate a game you're not connecting to the game server directly; you're connecting to a service that takes data from the game server and is able to broadcast it to a wide audience and introduce a delay. Neither of these properties are ideal for the esports broadcast, so those spectators use a specially created mechanism that allows them to connect directly to the game server.
With the background covered, let's dive directly to the root cause and work our way up.
The logic for deciding whether or not the secondary synchronization system should be turned on considers the visibility status of the first 12 clients. They are sorted by account ID value, regardless of if they represent a player or esports spectator. 12 is the maximum number of players in any kind of League of Legends game, so it's a reasonable amount for the secondary synchronization logic to check.
#Sequence Leading to Symptom
In the setup we were using on day 1, all of the spectator accounts were older than the players’ accounts. This led to them having lower account ID values, putting them ahead of the players in the client list. As I explained above, the logic for secondary synchronization looks at the visibility state of the first 12 clients. We use more than 12 spectators, so in this state it only considered spectators - and spectators see everything. So, even in a situation where secondary sync should be enabled, it would decide to keep itself disabled forever.
Without the secondary sync system functional, Aurelion's missiles won't appear to follow his motion once he enters fog of war. You can see this happen at the end of this clip:
That’s already troublesome, as the player gets misleading information. It gets worse; the client relies on the secondary synchronization system to resolve the target placeholder put in due to the original lack of vision. This puts the missile in a state where it will never have the correct target. Since the missile will only show itself once it either gets information through secondary sync or through its target becoming visible, the missile is now forever hidden as both of those triggers have been made impossible.
Proper fixes for this symptom are easy to identify now that we understand what happened step by step. However, since deploying a new build for an ongoing event is a significant risk on its own, we have decided to work around the issue instead. By using spectator client accounts that are newer than the players' accounts, we're able to consistently and completely bypass the root cause. Our tests have shown this workaround to be reliable.
We will be implementing the proper fixes as a part of our normal release cycle so that future events will not need to utilize this workaround.