# 6. Multiplayer Services Pitfalls Part of [[Lobby, Relay and Multiplayer Services]]. Prev: [[5. Worked Example Join-Code Session]]. ## Standalone Lobby + Relay packages left installed The official migrate path unifies them into `com.unity.services.multiplayer`. Two SDKs fighting will waste a lab. ## Calling session APIs before sign-in `InitializeAsync` then `SignInAnonymouslyAsync`. A cached token may restore a player; still check `IsSignedIn`. ## `StartHost()` plus `CreateSessionAsync` The default handler already starts NGO. Two hosts on one manager is a classic foot-gun. ## Join code vs session ID Players type `Code`. Browsers join with `Id`. Queries never return private sessions. ## Invented reconnect helpers Use `ReconnectToSessionAsync` / `ISession.ReconnectAsync`. If the player was kicked, they must join again. ## Password too short Official: 8–64 characters. Confirm join options in IntelliSense. ## Dashboard services not enabled / wrong environment A perfect script fails if the Project ID is missing or Relay is off. Check Services project settings and the dashboard before rewriting C#. ## 2.3 vs 2.4 API drift This series was checked against **2.3.3**. If you take **2.4.1**, re-read the API before you copy `QuerySessionsResults` field names. ## Matchmaker or Distributed Authority "while we are here" Out of scope. Official APIs exist; follow those manuals when you need them. ## Blocking the main thread These methods are async. Use [[Async Code]]; do not `.Result` on the UI thread. ## Sources - Migrate: https://docs.unity.com/en-us/mps-sdk/migration-path - `IMultiplayerService` 2.3.3: https://docs.unity3d.com/Packages/[email protected]/api/Unity.Services.Multiplayer.IMultiplayerService.html