I am following the “Make Online Games Using Unity’s NEW Multiplayer Framework” course and while joining lobbies I am getting an exception. I have the full call stack to this exception, but to summarize it, it just says:
Unity.Services.Lobbies.LobbyServiceException: player is already a member of the lobby
This happens only when joining the same lobby from 2 different game instances running on the same machine on Linux platform. I had a hunch that it is because I am on a Linux platform. To confirm this I tested the same project on Windows and it worked perfectly fine there.
I am not 100% sure but I think it could be related to PlayerPrefs. I say this because, on Windows, when I launch one instance via Build and Run and another instance via Unity Editor, it seem to be using 2 different places to store the prefs (The stored player names stay unique for both of them). But on Linux, both the instances shows the same player name from prefs.
I know this is not a big issues as running the same game twice on the same machine is not the end goal of this course and this is a Linux specific problem. But if possible, can you provide some workaround for this? I’d really like to avoid switching to Windows just for this.
Hi there,
I guess Linux keeps the editor player prefs in the same spot as the build, which windows does not.
You could maybe add a player number field for testing. So you could set one to player 1 and one to player 2 and then store two different values for testing.
If by add player number field you meant make the player name unique, then I can confirm that it does not work. Let me know if you meant something else.
I did manage to find a not-so-good workaround though by forcing the two instances to use 2 different pref locations. I did this by using 2 different values for Company Name in the build settings for generating 2 different builds. That way, Unity runtime creates the prefs under 2 different path and the prefs do not conflict.
Sorry, my explanation was not very clear. I meant create an input UI element for the player number in the startup screen. Then save the player name in a unique location within the playerprefs (using the number you inpus), so they are not being overridden by the same player prefs path. Essentially your player prefs could have a “player 1 name” field and a “player 2 name” field.
Your work around sounds better though because it creates different play prefs entirely.
!
