Two clients joining at the exact same time can both be instance masters.
needs more information
ville672
I used the build and test feature with two clients and somehow they happened to join at the exact same time. I see in the log that both clients got the "I am MASTER" line. in the udon scripts, localP.IsOwner(gameObject) outputs true for both players.
Log In
skecchy
I'm a beginner world dev, world not published yet, only tested with friends. I hit this on the same dates. Since it's tagged as needing more info, I re-tested with logging on.
July 25, five of us in a live instance of my uploaded world: I was the instance master and could use the world normally. Nobody else could take a seat - the table sat at 1 of 4 (mine) all session, and my log shows the seat state never changing once for the other four while they clicked. A fresh instance got to 2 of 4, then stalled the same way. An hour later, same build, another instance: fine all evening.
One thing I haven't seen mentioned: what this does to a world that routes input to the owner. Mine sends every click to the object owner with SendCustomNetworkEvent(NetworkEventTarget.Owner, ...) and validates it there. If the instance doesn't agree who owns that object, a click either reaches a client that checks Networking.IsOwner, decides it isn't the owner and discards it, or it gets applied by one of two believed owners into a state nobody else sees. I can't say which happened to me (my build didn't log that path), but both are silent, and the master is immune since it applies its own clicks locally. So it presents as "only the master can use the world", which reads exactly like your own permission check being broken. Cost me two sessions before I found this report.
Note for other world devs: if your owner-side handler just returns when it isn't the owner, this bug is invisible to you. Make that path log.
Re-test after your server-side fix: July 29, 8 clients via Build and Test. Exactly one client reporting isMaster=True, all eight naming the same object owner, zero discarded owner-targeted events, no warnings in any of the eight logs. No reproduction.
Limits: Build and Test starts clients seconds apart - ~37s first to last across my eight - so I may never have created the simultaneous-join condition. Read it as "can't reproduce any more", not verification. That run was join-and-lobby only, so non-master input with 8 clients is untested.
My July 25 logs have rotated out, and that build silently dropped unroutable requests, so I can't fully rule out a bug of my own. Offering this as correlation with your July 23-27 window, not proof.
skecchy
Script attached as a .txt - this is the logging from my comment above. Observational only: no network events, no game logic, never serializes, logs playerIds and never display names. Drop it on any GameObject and grep each client's log for [MasterSplit].
For reference, this is what the clean July 29 run looked like - 8 clients via Build and Test, at the moment all eight were present. These lines come from the same four values logged inside my own game manager, so the field names differ slightly from the attached script. Redacted to playerIds (all eight are the same account, so display names were identical anyway):
client 1: I am id1 master=True | owner = id1 | players=8
client 2: I am id2 master=False | owner = id1 | players=8
client 3: I am id3 master=False | owner = id1 | players=8
client 4: I am id4 master=False | owner = id1 | players=8
client 5: I am id5 master=False | owner = id1 | players=8
client 6: I am id6 master=False | owner = id1 | players=8
client 7: I am id7 master=False | owner = id1 | players=8
client 8: I am id8 master=False | owner = id1 | players=8
How to read it: compare two clients' lines from the same moment. Both saying isMaster=True, or the two naming a different owner for the same object, is the split. Healthy looks like the eight lines above - one client saying True, all of them naming the same owner.
Why it takes two logs: under this bug a client's own view is self-consistent. It believes it is master and believes it owns the object, and nothing it can read locally contradicts that - the disagreement exists only between clients, so passive logging on one client can never see it. You could make it visible locally by having the owner announce itself over the network and comparing that against GetOwner, but that means sending something rather than just watching.
A shortcut to avoid: I first assumed the master always holds the lowest playerId present, which would have worked from one log. My test above disproved it - closing all eight at once, id1 left and VRChat made id7 master while id2-id6 were still there with lower ids, every client agreeing on id7. Normal behaviour, not the bug. Same when id6 later took over with id4 and id5 present. A high-playerId master is legitimate, so that check would cry wolf on every ordinary handover. If that isn't how master election is meant to work, I'd like to know.
e
euan
updated the status to
needs more information
A server side fix was deployed just under two hours ago. If you are still encountering this issue for instances created after this point please post a comment with details
_
_tau_
updated the status to
tracked
This was caused by a bad server deploy towards the end of last week. We are working on a fix now.
_
_tau_
Merged in a post:
Master Conflict During Near-Simultaneous Player Joins (Reproducible)
Wing_
The bug is real and highly reproducible. This issue started yesterday and appears to affect some worlds randomly, especially worlds with heavier networking logic.
When multiple players join the same instance at nearly the same time, for example through a portal, some clients may incorrectly believe they are the instance Master. By extension, they also appear to believe they are the default network object owner.
In the attached screenshot, using the debug network overlay (Shift + ~ + 8), two players correctly receive different player IDs (1 and 2), but both clients believe they are the object owner. On each client, Networking.Master also reports the local client as the Master. It affects all udon logic that check for master.
When this bug occurs, it reproduces every time in local SDK Build & Test. I suspect the instance join timing for each player in Build & Test is short enough to consistently trigger the issue. In production (real game) instances, this likely only affects players who join within a very short time window, but it is still a real bug.
I tested a completely new blank world, simple blank world do not have this bug. However, after adding certain Udon scripts, I can reproduce the bug every time. I uploaded a test world for the VRChat team to inspect:
My other published worlds had been working reliably before yesterday, but started showing this problem from yesterday. Because of that, I suspect a recent VRChat backend change may have introduced a bug, and some (not all, but maybe a specific function) Udon scripts may act as triggers that cause the issue to surface.
I do not believe this is isolated to my world. Some creator friends have also reported similar issues today, and I have seen similar reports discussed in the official VRChat Discord server.
Please see the attached image showing both players believing they are the network owner, marked by the green O indicators beside players 1 and 2.
I am not using Open Beta.
Photo Viewer
View photos in a modal
hikaru313
In fact, it doesn’t only affect game instances. Regular global buttons are affected as well, preventing the objects linked to those buttons from being activated globally. This means the issue has a very wide-ranging impact.
Vincil
Has anyone tested if this also occurs on the live version of the game, or only on the beta?
Wing_
Vincil This can occurs on the live version, non-open-beta. Tested and confirmed. Many game worlds are randomly broken by this bug recently
Crescent_Evil
Ah… so it wasn’t an issue specific to my setup after all. The game world I’m currently developing is experiencing the same problem. During Build & Test, both clients are identified by the system as the instance Master. The last time I was able to run a normal multiplayer test successfully was July 23.
In my case, the two clients can see each other and are clearly connected to the same local test instance, but each client behaves as though it is the Master and the owner of the same networked objects.
This causes shared game state to split between the two clients. For example, my world has a player-registration system where the first player should be assigned to the first available slot and remain the game master, while the second player should be assigned to the next slot. With this issue, both clients behave as though no player has registered yet, so both assign themselves to the first slot and both independently treat themselves as the game master.
Changes made by one client are also not reflected on the other client. This affects several multiplayer systems that rely on shared state, including player registration, game-master assignment, and ownership-based game logic.
I initially suspected that this had been caused by a recent change to my own scripts or scene setup. However, the issue remained after reverting the related changes, removing newly added networked objects, restarting Unity and the computer, updating the Worlds SDK, and testing again.
From the player-facing behaviour, the situation is consistently:
Client 1:
Treats itself as the instance Master
Treats itself as the owner of the shared networked objects
Assigns itself to the first player slot
Client 2:
Also treats itself as the instance Master
Also treats itself as the owner of the same shared networked objects
Also assigns itself to the first player slot
Both clients are launched through the same Build & Test session and enter using the same local test room ID. They can see and interact with each other normally, but their shared game state does not remain consistent.
This currently makes reliable multi-client testing impossible for systems that depend on shared state, object ownership, or instance-Master status.
WubTheCaptain
ShingenPizza
can confirm, it has happened to me about 1.5 days ago too.
the thing is, i've started the same test world literally 100 times (across 2 clients) that day in total, specifically to check data sync and ownership between 2 clients, and it was working perfectly fine (except my own bugs from time to time, naturally ;)) until just when i was about to finish.
when it eventually happened, the issue was repeating - using build and reload, even closing the clients and restarting them with build and test gave the same result.
i was able to work around it by just starting up a second client with "test the last build" after a delay.
testing it the next day (after restarting the unity editor in the meantime) worked fine.
however, testing it just now, i'm back to 2 masters/owners of everything in the same test instance. :/
it seems that with 2 masters, each of them is refusing to accept variables changed and synchronized from the other.
for what it's worth, i'm using unity editor 2022.3.22f1 with the newest (3.10.4) sdk, and VRC client on the unity 6 beta.