Master + Sleeping Quest => Potential networking issues (and they can sleep for more than an hour)
available in future release
Puppet~
See the screenshot below.
These players can exist like that for up to an hour, if not longer.
This causes issues when they are the master and you rely on them to handle important networking logic. They won't be able to send data to others, which can mess stuff up, like Cyan's Object Pool.
In my case I rely quiet heavily on it and it renders the world completely unusable in the time the quest player is master and sleeping.
Proposed Solution:
- kick the quest player
- get their master status revoked after some time
- add way to transfer master manually in udon
Log In
This post was marked as
available in future release
ᴋᴀᴡᴀ
How it's AVAILABLE IN FUTURE RELEASE?
Aren't you guys sayd on the forums, you going to delay this feature as unexpected master switch can break prefabs?
Fax
in progress
A fix for this issue is being worked on. We're hoping to release it in the next few weeks,
before
VRChat's next major release. We appreciate your patience!_
_tau_
For reference, this is related to our creators thread over on the forums: https://ask.vrchat.com/t/network-update-season-master-transfer-creator-feedback-wanted
Master transfer as in the original post will not ship, but intelligent master selection, a fix for not timing out at all, and stricter timeout limits for suspended players are in the works right now :)
_
_tau_
Merged in a post:
Quest/Android users freezing when removing HMD.
blueasis
If you take off your HMD while playing on android (only tested on quest) your device will go to sleep and VRChat will not remove the player. This is problematic particularly for game worlds, as it often locks up the logic behind a vegetative quest user, freezing the game entirely.
This is a new bug, and now we have to work around it to make games playable again.
Repro:
Put quest HMD on.
Launch game.
Join Super VR Ball instance where you are the master.
Have another player join.
Take quest HMD off.
Fax
We've been able to reproduce this bug, but not
reliably
.If you have any details on how to reproduce the "indefinitely stuck" issue, or know how to reliably trigger it, please share it with us!
Puppet~
Fax What I did is quickly press the quest power button to get into sleep mode. If you are talking about the "stuck in ground" visuals, that only appears if you join the world AFTER that quest player went into sleep mode. Not sure if relevant, but I noticed it in my tests.
Let me know if you are looking for a more specific state or behavior and I'll try to replicate it tomorrow.
Fax
> What I did is quickly press the quest power button to get into sleep mode
Unfortunately, we're unable to reliably reproduce the issue just by entering sleep mode. Players
usually
get kicked in 4 minutes or less.Does the issue occur more reliably when you test it?
Puppet~
Fax Yes, it happens every single time. I simply press the power button since it's the fastest way. As I'm writing this, my quest is occupying an instance while in sleep mode, nobody else in it. It has been there for a while, easily more than 4 minutes. And now I join them on desktop, yep still there in the ground and the world is not working. Doesn't matter if I stay with them or not.
I don't know what the difference might be between us hmm. I am using a regular quest 2 by the way. I usually don't use it that much, so no clue what it could be.
miner28_3
This seems to be causing many large issues to MANY worlds, there's pretty high chance that if you go into any Game World it'll be affected.
Blue-kun
This is causing issues in Just B Club with empty rooms failing to unlock due to reliance on the master
AltCentauri
This is causing massive problems for my worlds as well, I really hope they get a fix out asap. Worlds breaking just from users removing their HMD is a massive problem and is probably affecting basically every single multiplayer Quest world on the platform.
blueasis
Super VR Ball also suffering from this, glad its tracked. hope its fixed asap.
Fax
tracked
Thank you for reporting this issue!
This issue has always been around, but has gotten more severe late last year due to networking changes on Android.
We'll be investigating a solution. Please let us know if you're aware of other worlds that may be affected.
Puppet~
Fax Thanks!
Aside from Omegle VR, there is also the Nevermet Matchmaker world, which has different code but the same methodology. It's most noticable in there because of how reliant these world are on the object pool, but I bet the issue happens to smaller extent in any code that relies on the master.
Hopefully, the fix is as simple as forcing a rejoin after a minute or so. Really curious what you can do, since I don't see many ways to work around this on my end. Pretty much the only way is to rewrite the pool, but that sounds rather complex and might break other things in the process.
Oh btw, another thing to look into are mobile devices. The mobile app release kinda fits with the timeline. I'll try to test it out myself when I have the time.
Puppet~
Tested the app on my phone and it seems to work fine. The player disconnects properly after a short while of like 1 minute, the way it should.
So unless other people's phones don't do that for some reason, then the issue is most likely with the quest, which can be alive for much much longer.
Puppet~
Okay, this looks worse than I thought initially.
Look at the first screenshot. All these people take their headset off, never get cleaned up, and block entire lobbies from functioning.
This actually super bad in worlds like Omegle VR, that rely on the master to assign rooms. Again, I use Cyan's Object Pool which does a lot of cool stuff to make all of this reliable that I'd have a hard time to work around it.
Also, looks like No Time Two Talk is also affected. So it seems like an actually new bug that might affect more worlds than I thought.
Load More
→