Two clients joining at the exact same time can both be instance masters.
complete
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
e
euan
updated the status to
complete
Marking this as complete as I haven't heard a report of this in over a week since the fix went out. If people do see it again feel free to reopen a new post with details (linking this canny if repro steps are the same)
skecchy
I hit this too. My world ran fine for weeks, then on July 25 five of us were in an instance and nobody except me, the instance master, could interact with anything. A fresh instance got to 2 of 4 players to interact and 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. 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. If your owner-side handler just returns when it isn't the owner, this bug is invisible to you. Make that path log.
I wrote a small script to try to catch it in Build & Test and could not reproduce it. Build & Test launches clients seconds apart, so I doubt I ever created the near-simultaneous join this needs. Script in the comment below, in case someone can hit that window.
skecchy
Script attached as a .txt - this is the logging from my comment above. Purely observational: 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].
How to read it: line up two clients' lines from the same moment. Both saying isMaster=True, or the two naming a different ownerOfThis for the same object, is the split. Healthy is exactly one client saying True and all of them naming the same owner.
This needs at least two logs, and realistically every client's. 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 no single log can ever show it, and any two logs only show it if you happened to pick the two clients that disagree.
If anyone wants to try reproducing this: the hard part is getting two clients to load into the world at the same instant. Build & Test starts them seconds apart, which I think is why I never hit it. If you can get two clients entering simultaneously, this script should show it straight away.
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.
Load More
→