Persistence

There currently isn't a way to check how much data a local user's persistence data takes up in the PlayerData or PlayerObject data 100kb limits on the server. We could manually count the bytes, however, it's noted in the docs that VRChat uses a compression format meaning the final size is unknown compared to the raw byte size: https://creators.vrchat.com/worlds/udon/persistence/#limitations Functions like Networking.GetPlayerDataCompressedSize() and Networking.GetPlayerObjectDataCompressedSize() would help with worlds storing large sets of data by returning a byte count of the compressed file size for specifically the local player. This would also be better than manually counting due to other unknown extra information that may be appended on the data.

This is part bug report, part feature request. Play any world that has persistence data Have vrchat disconnect with the error "Your connection to VRChat timed out. Verify connection and try again." - preferably where the entire instance times out, not just you. (maybe photon crash?) Rejoin the world All persistence data for that session will have been lost. Ideally, VRC would either periodically permanently flush that data even without disconnect, or have some backup method to save persistence data in the case of a photon crash, so games where multiple hour long sessions occur don't result in total data loss. Alternatively, some way for the client to recover state upon reconnect in the case of a server crash (some kind of server-provided short-lived signed copy of the data that can be sent and reverified on reconnection, if it has a timestamp older than the server's copy) would be a nice to have, as it can prevent VRC-side infra netsplits resulting in total data loss in many cases. This was seen on US-east servers today, multiple times. Entire instance disconnects and total data loss for all users in the instance. The state gets reset back to how it was prior to loading into that instance initially - it is all rolled back/forgotten.

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.

A Networking.GetPlayerRestoreStatus(GameObject) and PlayerData.GetPlayerRestoreStatus(VRCPlayerApi) that returns a custom enum with the values: Incompatible , Awaiting , Success , Failed , & NoDataToRestore . This would only work on networked objects that can store persistence data like PlayerData or PlayerObjects with an Enable Persistence component. Other objects will always return the Incompatible value. This would allow worlds to ask for a particular object's persistence status for many things: * Incompatible - This object does not support persistence. Use a PlayerObject with the Enable Persistence component. * Awaiting - Data has not been received from the server so the world knows to wait until a further update before trying to read/write persistence data for that object. * Success - Data was successfully restored from the server without any exceptions from VRChat's side. The world knows it is safe to read and write data to it. * Failed - Data restoration encountered an error on VRChat's side and data should not be manipulated for data loss. The world can present an error message and/or allow the player to clear their data. * NoDataToRestore - There was no data to restore from the server. The world knows this is a new player, a new update bringing a new persistent compatible object, or a player who has recently cleared their data. This also indicates to the world that this object is ready for writing new persistence data. Related: https://feedback.vrchat.com/persistence/p/add-persistence-data-status-event-or-status-parameter-for-onplayerrestored

At the moment there is a high risk that a world builder may release an update to their world that ends up breaking everyone's Persistence data in an unrepairable way. This could be caused by bugs within Persistence itself. When either of these conditions occur, there is zero recourse for the world builder to correct peoples' data beyond telling everyone to wipe their data completely, losing all progress. This can be catastrophic in cases where player progress was enhanced by purchases through the Creator Economy. This problem isn't unique to VRChat, as it occurs within Roblox as well, and is especially important due to how many transactions are tied to progress in their games. However, Roblox provides a comprehensive interface where the world builder can force a roll back of player saved data to any prior date at any time. This effectively eliminates all risk with releasing world/game updates, giving the builder recourse in the case of irrecoverable corruption. I brought this to Fax who thought it was a good idea and recommended making a Canny post, so this post is to request that we get a similar feature, so world builders have the option of force rolling back a prior date of saved Persistence data. An example world is my world: Elite's RNG Land. Players can purchase an upgrade that speeds up progression, however there have been instances where a bug, either through code or API bugs, caused players to completely lose months-worth of progress. The only recourse was to tell people to wipe their player data and start over.

Have 2 clients, one on persistence and one to not Create an instance, have your non-beta friend join first Join from beta Be kicked for "World version incompatible with this instance" This does not occur when the first person in the instance has persistence enabled. I have not tested what happens if the first player in the instance is a persistence beta user, non-beta joins, beta rejoins (master transfer to non-beta)

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)

This ones a little odd and edge-casey, but I observed that even though we have OnPostSerialization(), this method doesnt actually seem to be called when the client has finished uploading the new persistence data to the vrc servers, and is instead called roughly when actual uploading happens. So if you have large enough data, you have no direct way of indicating to the user that its still being transmitted/saved remotely, and that they may lose data.

In the HealthBar example (Example Central > HealthBar > DamageOnTouch.cs), the Udon script attached to a scene object expects the Player Objects to be available on its Start method, at least the Player Objects for the local player. The current (2024/10/3) doc describes the "Start event of a Player Object". However, it doesn't explain this precondition for the scripts on scene objects. So, please add some notes. (I think we need the complete specifications for the lifecycle of Player Objects.)

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)