Network Update Season & Master Transfer (Creator Feedback Wanted!)

Creator Hub Worlds
21

I have no issue with this, provided that there is ample time in beta for creators to test. I would also agree with Hai that changes of this nature are going to increase the difficulty of individual testing even further – and we know testing Udon networking is difficult enough as it is now – so anything in the SDK tooling that could help with this would be very welcome.

Having it as a per-world toggle like avatar scaling, defaulting to the old behavior for existing worlds, makes sense to me. Whereas a per-instance toggle seems like it would only be useful as a workaround for world-side bugs or deficiencies that should be fixed instead.

1 Like
22

Oooh I see! Thank you for elaborating :))

23

Question. Would the “old” network master behavior be eventually phased out, once the “new” behavior has been fleshed out enough that it’s worthy of being fully integrated? If so, it makes me wonder if an SDK toggle, swapping between the 2 behaviors, is a good idea for the long run, especially if the old behavior will be retired when the new behavior is fully ready. My fear is that some world devs will continue using the old behavior and be blindsided once the new behavior swaps into live.

I have no problems with an SDK toggle at the beginning stages. If anyone is confused at my wording I can elaborate.

24

As I understand it, there already exists a breaking change to older/current worlds regardless of whether or not a toggle is introduced, which is that there exists clients who can enter a sleep state as an instance master, which didn’t used to be the case. Adding a new feature to handle this scenario sounds like a good plan moving forward, but if the present situation without that feature already has the potential to break existing worlds, what is the benefit of having a toggleable world flag to maintain the old behavior?

If a toggle does remain for the old behavior, perhaps a backwards compatible “hack” fix could be implemented? Would it be possible to fire the “OnPlayerLeft” event in Udon for players who have gone to sleep, without actually disconnecting them from the instance, and firing “OnPlayerJoined” if they reawaken? For the sleeping client this could resolve the “starting over” problem in many worlds, but for everyone else it would allow for instance master transfers to function in Udon as they did before, bypassing the initial concern. I understand there may be many reasons why this may not work or could cause other issues, but figured so long as we’re looking for potential solutions, it’s worth considering the options and what may or may not work and why.

25

Just my two cents - this would probably be a bad idea regardless of situation. There are already other places where the master can change like that. I think the best bet would be to encourage event hosters who create their own world to rely on group roles; if they can’t do that, worlds should have explicit permissions systems starting with the owner and unless it’s a public instance (not group public), should never switch based on master change. Would mean event hosters would have to be vigilant and assign backup people with permissions, but with master always being able to change, it shouldn’t be relies upon for permissions.

26

That is a very good point! There are currently no plans to phase out the old behaviour, but tech is unpredictable - it might need to happen further down the road. If anything, this is a good point against an SDK toggle and instead something similar to avatar scaling on web.

This is not quite correct - sleeping users, master or not, have been a thing since Quest came around. The timeout may have changed, as well as the aforementioned bug being introduced where the timeout appears to never trigger at all - that part will be fixed, and adjusted accordingly to go back to previous behaviour.

This is, as you already mentioned, about the plan after that fix (the “proper” one, if you will).

This bug only occurs in a selection of cross-platform worlds. Introducing it as a general case might mean causing more harm than it fixes - one of the points of this thread specifically is finding out whether that’s the case.

As for other workarounds - Any change we make there just increases the surface area of stuff that could be broken. That isn’t to discard your idea, but rather that we’d want to be even more careful in that scenario.

I’ve thought about some explicit callbacks to notify Udon when a user went to sleep as well, for example. There’s technical hurdles there, but it is something I at least explored in my head for a while :)

1 Like
28

I see, thanks for the reply!

29

I meant the breaking change relative to the current implementation of only transferring instance master on leave which was established before both Quest and Android came along as devices that can sleep. The proposed new instance master change event then being the future-proof fix to the long standing breaking change of clients that can sleep without leaving causing worlds to cease to function.

It would definitely require consideration and not be a free fix, and I can certainly imagine some worlds with code on the leave/join events that could cause some issues to the sleeping client on wake (not to mention other things that would need changing like GetPlayers). But when all of udon networking already breaks as the instance master sleeps, I figured kicking the can a little further to potentially benefit the remaining people still in the instance could potentially be worth it ;) But yeah, absolutely fair enough!

30

In my regards the missing piece of the puzzle here is that, we already have a event for “OnOwnershipTransferred” that we can monitor.

But we have none for when the master changes meaning we forced to constantly monitor or check when player leaves.
Nor do we have a solid way of changing master on demand.

First off the difference between owner and master is poorly understood in general.

Object owner is the person responsible for synched data being sent from a specific script in the world, any data alteration attempts from others is ignored and reset by owner after a external change attempt has occurred.

But there is no documentation nor explanation to what significance being the master has.

If you intend to have a synched script rely on locally storaged data for it’s networking dependant interactions, your likely already coding the world script badly.

There is no way to get around the issue that the android/quest hibernates, this means a quest/android world has to inherently be scripted differently for it to work flawlessly.

My policy for scripting worlds is to make all network dependant interactions be synched by object owner like intended.
Either by changing owner or having a persistant object owner that can change at any given time with no detectable glitching.

Btw. Would be useful if we could check if a player is afk/hibernating. That should be added regardless as it would have uses.

31

Also, sorry to double post, but - I think this points to something that I think should be talked about, which is that leveraging instance master for any player-facing world behavior is a Pretty Bad Call.

I can’t say the amount of times I’ve seen a public instance lock up, not because of the timeout issue, but because the instance master doesn’t know how to do anything, the world doesn’t say who the instance master is, the instance master just doesn’t feel like doing anything, etc. It’s a concept that’s always confusing to new players (especially since master can be separate from instance owner but some worlds still rely on master even when an instance owner is available - why why why?), and it’s mostly there for technical networking reasons anyways.

I think this issue is a symptom of this. Master switching SHOULD be able to happen automatically when the client goes to sleep and can’t respond, even if they haven’t timed out yet. It shouldn’t have to matter that someone might have put their headset down and could come back to their instance ravaged - fault tolerance should kick in as soon as is possible. Waiting 4 minutes for an instance to become usable again is a pretty frustrating and confusing experience, and one I didn’t even realize was behind instances dying before when I’ve played.

Unfortunately, since it’s leveraged in many places for permissions (ownership of video players, who can start and stop a game, who can go behind stage at a public music instance such as club orion), this can’t really happen. However, I think really a better solution to this moving forward is just to tell world creators “HEY, THIS IS INTERNAL, DON’T USE IT FOR USER-FACING WORLD LOGIC” - sort of how we treat private functions, and encourage them to abstract it.

I understand it will break some legacy content, and is legacy behavior, and that’s a consideration to have. I think providing a “new type” world feature toggle to allow creators to convert to a logic type that always switches master when unresponsive, allowing them to design around it, would be beneficial - leaving older worlds on a “legacy type”, maybe improved as you have suggested here, or left completely untouched.

Obviously in non-public instances, one can use the instance owner or group roles - in public instances, however, this would require more thought, and possibly even lead to creative UX solutions that are even better than they have right now - for example, implementing vote-to-start or vote-for-settings in a games world, implementing a media queue and vote to skip in public worlds with media players, implementing a timed stage lock w/ cooldown in public music worlds like club orion so public worlds essentially become built for open decks, permissions systems to fall back on, etc.

The point being, I don’t think moving forward master should be something any end user has to think about, period, at all. I understand it’s a legacy thing, and consideration should maybe be provided to that, but its behavior thats inconsistent and hard for the average player to predict, understand and work around. I fully expect this to be dissected, but wholly welcome it - this is a good discussion to have, I think! <3

EDIT: Wow, I think I completely misunderstood the original post lol. Sounds like you’re planning most of what I’m talking about. Still, leaving this up, I think the logic here is something I want to express - as well as my opinions on abstracting away master (Which I think would make many worlds better and should REALLY REALLY HAPPEN!)

1 Like
32

Imo IsWorldCreator would be better.

33

In reply to both @hitoriou and @polyjitter: Yes, using IsMaster should be avoided at all costs either way. We even document it as outdated on our official documentation page.

Unfortunately, that isn’t something that we can change - only the community can, and that isn’t true for all existing content either.

As adding documentation will be a major part of this change, we will also make it more explicitly clear what master implies and how it should be handled.

For clarification, just in case: “Master” simply means having ownership of all objects that haven’t been manually assigned an owner via SetOwner or a VRC_Pickup grab. That is all it does, it’s the “fallback owner” of every object in an instance.

Instance Owner, World Creator, etc. are all entirely different concepts - ones that should be used, but in many cases aren’t today.

I agree, in a perfect world, making a change to switch master on the fly would be a non-issue - but we recognize that worlds aren’t written that way, and also that writing new worlds this way can be a challenge.

2 Likes
34

When it comes to breaking already existing worlds.
I think everyone would preffer if older worlds would not stop functioning.

Best solution for this would be to have a separate ruleset that is enforced on older worlds.

It will mean a bit more work and consideration on the vrc staff/devs part.

But at least it would avoid people having to resort to Necromancy in order to update a world that been around for multiple years with no updates due to the creator having vanished.

And as a result of this, old worlds would still function with it’s glitches, and any new uploads/updates of worlds would have to be fixed in order to conform to the new standard/ruleset.

35

In general, I agree - but the question to ask as well is “would content even break” - so far, I haven’t encountered an issue in practice, though obviously the existance of such content is very likely.

36

Master is the person who gets ownership of objects by default, either when they join or when someone else owning an object leaves. That’s it, as far as VRC is concerned. Worlds which build additional functionality on top of master and give it a stronger meaning are the problem here.

You’re right to point out that OnOwnershipTransferred already exists - and guess what, people can and should use ownership for nearly all the things that they’ve been using master for. Not only does ownership have better tools to handle what happens when it transfers, but udon also has the ability to initiate a transfer. In other words: that’s everything that people are requesting to be able to do with master.

The reason why master is not built out as extensively as ownership transfer is because it was never intended to be used in this way. It is merely the default owner, and if scripts were to build on top of ownership instead without ever transferring, they would implicitly be using master, but they would have far better tools to deal with potential issues.

Unfortunately, there is one exception - security. This is a valid concern, and using master is one way to handle that problem, because it means that you can lock down the authority to just one person, and so modded clients can’t come in and take everything over. This is the reason why allowing udon to initiate a master transfer would be counter-productive - it destroys the one currently valid reason to use master in the first place. I would much prefer to discuss solutions to this that allow you to make your worlds safe and secure without using master, because it much more directly solves the problem.

37

Well i do have a few older SDK2 worlds that depending on it’s version (i updated them as separate versions) either works or refuses to even launch and boots you to your homeworld instead.

Having a seperate ruleset in place depending on the worlds last update age, would completely bypass any concerns of a older world breaking.

38

Kinda the point I was getting at though. Any world with networking already breaks somewhat when the instance master sleeps as things are now. I get that maintaining the current behavior as a toggle for older worlds instead of allowing instance master transfers without the sleeping instance master actually leaving removes another potential breaking point, but I also feel it’s a fair bit of extra work (not to mention maintenance in perpetuity) to employ a fix that leaves things in the existing broken state for some older worlds anyways.

Perhaps the different solutions could be tested in beta, and we could get at least a sampling of how much of an impact the change and potential solutions will have on older worlds.

39

So it’s fairly much as what i been guessing when it comes to master.

I guess it mostly comes down to that we currently have no way of detecting when a quest user is going to cause issues for the scripts.

40

@_tau @phasedragoon I assume there’s some event sent from the device when Android/Quest sleeps that you guys detect on your end, and not simply that it stops responding/processing? As in it’s functionally a different process than just having the client lose connection, correct?

41

Well that kind of extra work is sort of already being done when it comes to still supporting the older SDK2 worlds.

And for all we know, sorting those out might not even be part of the solution, it would be sad tho if what is decided on as a solution will remove 80% the existing worlds on vrc by default.

And same concerns was addressed in the past when we swapped over to SDK3.