This looks like itll be fine, I have a few examples of code which might break without me accommodating change, which will be my Udon boxing world. It frequently has quest users, but I think simply changing from isMaster check to isOwner check will fix any issues I might have where the master has changed.
The only issue I can see in the future is related to my data archiver, which is a semi data persistence script that stores all player data into an object, and shares that data with others. The owner of the object is used as the ultimate record keeper, and if that changes, it could cause data loss depending on in that moment if the new master had new data. Obviously, when we get proper data persistence this will become irrelevant, but anything using a similar issue will def need to compensate.
I see. So, this time, you will only tune the parameters for the timeout and make hook points for Udon programmers without “mechanism modification”.
Then, another idea. Is it worth making another event that fires on the suspended player side when resumed? It might be helpful to indicate to the user that you had network trouble or something.
I’m a little confused as to what the benefit is to an external (website) toggle as opposed to one in the SDK, if you do retire the legacy system, in both cases you’ll be forcefully migrating legacy users to the new system, when done on the SDK you can at least provide people with the option to test both versions, and if you do eventually retire the old system it’ll only be then that old SDK versions would mismatch the in-game behavior, and in that case you could even block uploads that use an otherwise compatible SDK but with a no-longer incompatible feature enabled (the legacy switch).
Also, if you truly wish to not break anything wouldn’t it be beneficial to leave existing/older SDK uploads on the legacy system (while it is still supported)? In that case you could even force the migration for newer SDKs so that all newer/updated worlds would be using it.
An event triggering on resume would presumably also trigger on the local player, yes. Although if you’ve been idle too long you will have been kicked out of the instance already, in which case Udon is suspended.
The downside of an SDK switch is that older content cannot be switched to the new system without a reupload, even if all scripts are technically compatible. The upside of course is that it is closer to the place where you’d actually set it.
Either way, since we will not be implementing the live master transfer, this discussion point is moot for now.
Ah, yeah, that. I don’t really think persistence is going to be happening anymore, based on how things are going, if this year is only going to be focused on Creator Economy. Wish they’d prioritized this first - having player and world persistence would make it MUCH more enticing for players to pay into the economy.
On the Intelligent Master Selection.
I am very used to lowest ID being the determining factor, so it might goof a script or 2 that i have made in the past.
The suggested New APIs would at least allow me to fix this once i am aware of this issue occurring.
The main concern i would have on this topic would be that people have to be aware of this, so accessible & solid documentation plz and maybe a good log entry for more effective debugging and to help raise awareness for the people not reading every note/discussion in history.
My second concern on it tho, would be, how would a stable user connection reliably be determined, what can actually be regarded as a stable connection and not just a passing fluke, and the reason we have different region servers is for more stable and responsive connections in those regions, but when as soon as and often happens a player from a different region emerges a conflict of interest may emerge from a outside region player having a more stable and low ping connection.
For example how i with my fibre-optic connection somehow have lower ping measured into a different continent than people connecting from within that continent may have due to older connection methods.
For example i know of one person with such a horrid connection that they have a 70% packet loss (on a wired connection).
At that point no low ping would help and putting more traffic on the connection would result in their voice stream being more garbled than it already gets.
I do like the idea of preffering PC users over quest tho as it help mitigate the issue at hand.
My second concern on it tho, would be, how would a stable user connection reliably be determined, what can actually be regarded as a stable connection and not just a passing fluke,
That’s a really good point! We’ll monitor how it affects worlds, but we’re hoping that the first implementation of this feature is going to be better than choosing the master player randomly. We’re interested in making further enhancements in the future.
We are working on adding the new events and Udon properties as discussed above to the next beta, which will be 2024.1.2, during its progression. Stay tuned!
Excellent timing!
this look super cool and i’m really excited!