Persistence

The ability to open two instances of VRChat in separate windows under the same account, each being a different instance of the same world, creates significant issues for any game world that relies on persistence. I'll refer to the two windows as "Window 1" and "Window 2." Both are running the same world but in different instances. If a player performs an action in Window 1, such as getting a reward or losing progress, and the world saves that, they can simply close Window 1, switch to Window 2, and wait for the world to save their data. This will entirely overwrite the changes from Window 1, restoring their progress as if nothing had happened. This exact issue happens very commonly on mismanaged Minecraft servers, where you can have two instances open on the same server but in different subservers. This is most commonly used to duplicate items, which no RPG-style game world wants. An example in VRChat would be the world "Project Aincrad". If, in Window 1, Player 1 trades 10,000 in-game coins they have to Player 2 while Window 2 is up, then at the end of the trade, when the game forces them to save their persistence data, Player 1 in Window 1 will have 0 coins, Player 2 will have 10,000 coins, but Player 1 in Window 2 will still have the 10,000 coins, meaning that 10,000 coins have now turned into 20,000 Coins. I'm not very technical, so this is more of a guess for a potential solution, something like only allowing Window 1, or whichever window was first in that specific world, to be capable of changing the persistence data for that user and world.

Currently there's no way for World Creators to clear PlayerData keys, we can set the value to whatever is the smallest, but the key is still going to exist forever, take space, and be synced to every other player unless the user manually resets his player data. If a complex world goes through rapid changes or frequent updates to their systems that involve PlayerData there's a big chance some keys will turn obsolete, and it is likely that recurring visitors will unavoidably store unused keys and data, unnecessarily cluttering the network and their persistence data. Udon Function: An Udon method for PlayerData.Remove(VRCPlayerApi player, string key) would allow for creators to manually handle clearing these keys. Some other solution: I think there should also be another option for creators that are not familiar with Udon and mainly rely on prefabs. Example scenario: using a badly coded prefab or too many prefabs that fill up the PlayerData size. Even if the prefab is deleted, a new player with no PlayerData would not experience issues, but a recurring player might because he still has the old keys.

If the Unity project settings Reload Domain is disabled, ClientSim doesn't properly handle Player Objects, causing exceptions and stopping work. Repro Start Unity. Create a scene. Add VRCPlayerObject component(s). Enable Play Mode Options and disable Reload Domain (via Unity menu > Edit > Project Settings > Editor > Enter Play Mode Settings) Press the Play button to start ClientSim (it will work normally at the first launch). And exit play mode. Press the Play button again. Then, MissingReferenceException occurs (see attached). And it doesn't work correctly anymore. Version World SDK 3.7.5 Analysis Clientsim caches the Player Objects in ClientSimNetworkingUtilities._playerObjectList . And it depends on the reloading to initialize it. It should be initialized when starting the simulation. Snipping from the log for searching MissingReferenceException: The object of type 'VRCPlayerObject' has been destroyed but you are still trying to access it. Your script should either check if it is null or you should not destroy the object. VRC.SDK3.ClientSim.ClientSimPlayer.SetupPlayerPersistence (VRC.SDK3.ClientSim.IClientSimEventDispatcher eventDispatcher, VRC.SDK3.ClientSim.IClientSimUdonEventSender udonEventSender, VRC.SDK3.ClientSim.IClientSimBlacklistManager blacklistManager, VRC.SDK3.ClientSim.IClientSimUdonManager udonManager, VRC.SDK3.ClientSim.IClientSimSyncedObjectManager syncedObjectManager, VRC.SDK3.ClientSim.IClientSimPlayerManager playerManager) (at ./Packages/com.vrchat.worlds/Integrations/ClientSim/Runtime/Player/ClientSimPlayer.cs:198)

Although it would still be best practice to save data periodically, it would be a nice quality of life feature to have one final opportunity to save as the player leaves. Please allow us to save data in OnPlayerLeft OR provide a new event before OnPlayerLeft to the local player which would allow us an opportunity to save any data.

Saw this comment under the latest dev-blog by the user "harunadev" and thought it would be worth to propose. I don't know the actual limits of the backend but i can defo see value fort this. "I would love to see if the persistent user data could sync between worlds (within the same author). For example, User makes a change on world A, then whenever the user joins the world B (same creator from world A), world B gets to read the changes the user made on world A. This could allow world creators to sync user settings/infos within their collection of worlds. And also I really hope to see a custom resolution option (whether it’s in config.json or UI configurable) for the new desktop stream camera in open-beta. Keep up those good things team!"

Setup a scene with this player object hierarchy and the included script Launch a test build or live build with 2 clients, allow the master to settle first Join with the 2nd client and view their debug log, a warning will appear if you happen to see a duplicate packet (via a small histogram dictionary checking for ContainsKey) this is unexpected and duplicate packets can result in duplicate calls to logic. In cases where sequence matters or you're doing something like instantiating objects by a net id, this is pretty bad. I think the duplicate packet is being queued to whatever is holding packets prior to player restore firing, potentially on the same frame as the restore and normal packets firing (I'd guess that this packet happens to fire on the restore frame as a normal packet, but is also added to some internal queue)

I would love a way to store persistent data that doesn't get replicated. This likely wouldn't make as much sense on PlayerObjects, but it would be great to have either a flag or a section in PlayerData that's scoped only to the local user, for storing more private data. This would be great for things like a "last entered code" for admin panels, for example, where it improves UX but you wouldn't want it replicated out to all clients in an instance. I can forsee one potential issue with this however, users storing potentially sensitive information in these keys (such as passwords) so this would likely need to come with some kind of disclaimer.

VRChat SDK Base, Worlds 3.7.6 This can be confirmed on the LeaderBoard in Example Central. Open the LeaderBoard Scene in Example Central without editing it, and run Build & Test with three or more Clients. Jump and check. The client data of the instance master will not be synced to other players. This case may not occur. When I checked, it was successfully synced about once in ten times. I also made a leaderboard that used user data with a minimal, but similarly the client data of the instance master did not sync. (I noticed this case when I wanted to create a simple leaderboard, focusing on the User data feature that allows you to get other players' data.)

Steps to Reproduce Create a GameObject with VRC Player Object and VRC Enable Persistence Create an UdonSharp script that have 27 or more [UdonSynced] int fields (27 int is 108 byte) Attach it to the GameObject Build & Test the world Change field value and save by RequestSerialization Rejoin [UdonSynced] fields are not restored Additional Information * Serialization succeeds with OnPostSerialization * It does not output any errors, so I am unsure if it is failing to save to the server or if it is failing when restoring * ClientSim does not have this issue * 14 or more double fields also leads the same issue * I attached UdonSharp script that reproduce the issue Proposal This limit is easily reached, and I would like to be able to handle more fields if possible. Also, this limitation is not written in the documentation and should be added.

Being able to have the approaching max size and hit max size events be triggered in a udon function, and being able to poll how much space we are currently using compared to how much max we are allowed to store, would be very useful for prefab and world creators to prevent lost data