Persistence

Now that Persistence is in the game, it would make sense to give us the ability to also locally store data that isn't game-breaking if it's lost, but that would benefit from not being constrained by networking limits (and not taking up the limited persistence space). Some examples would be: Settings for local-only state in the world. Precomputed textures/models for dynamic content, such as character customization. The game already does this for per-avatar parameters. And of course we wouldn't be able to choose where to store it for security reasons, but make it similar to PlayerData in that we only get to say what we want to save, but expanded a bit on data-types, such as textures & JSON. (and ability to only load the data from specific keys when you need the data, not all of it at once). Having this capability could reduce networking needs, especially for more ambitious worlds and open up more gameplay possibilities. Understandably there would still need to be limits on how much data could be stored, but it could certainly be much, much more than the 100KB each of Player and PlayerObjects, say 2GB for PC only worlds and 400MB for Quest, with limits that could rise as min-hardware levels change. (and creator can fallback to regenerating content instead if local-space limits are hit). Would probably want to display how much local-storage a world is using when a person clicks on the world in the menu and option to sort worlds by data usage, so people can identify junk worlds they might join that try to fill the space for no reason just to annoy, then user can hit the "Clear data" button for that world which already exists (or better have a button also for local-data specifically in case they are just trying to free space).

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.

Launch World: https://vrchat.com/home/world/wrld_882d1b16-ef0d-470f-b6e1-9523702e44d3 Check Logs to see Data has been written. Rejoin World. Check Logs again, notice that Test3 failed for both Continuous (expected) and Manual (unexpected). Manual Sync behaviours are expected to be able to persist one serialization on their own within a PlayerObject with Enabled Persistence. Test 1 works as expected. Test 3 serializes correctly over the network but fails to keep data between sessions. This is despite both storing roughly a similar amount of bytes in Manual sync and should be within the Manual Sync limit. Serialization expectedly fails for tests with Continuous > ~200 bytes. Tests 1-3 are ran on Empty Objects that are children of their own individual Player Objects with Enabled Persistence. Test 4 is ran on two individual empties. C = Continuous Sync Mode. Expected to fail at ~200 bytes. M = Manual Sync Mode. Expected to fail at ~280,496 bytes. Test4 - PlayerData test with SetBytes (40 & 256) Test1 - long[] test with 5 & 32 elements. Test2 - 5 long variables. Test3 - 32 long variables. Screenshot shows logs after rejoin.

When multiple Udon components with synced variables attach on the same child GameObject (whose parent has VRCPlayerObject and VRCEnablePersistence), Persistence only restores variables from the first Udon component. Steps to Reproduce: 1.Create two Udon components (A and B). Each Udon component contains one synced variable. 2.Create a parent GameObject with VRCPlayerObject and VRCEnablePersistence. 3.Create a child GameObject under it and attach components A and B. 4.Run a local test with a single client. 5.Set the values of the variables in A and B using any method. For example, set A to 3 and B to 5. 6.Rejoin the instance. 7.Check the values of the restored variables using any method. Expected Behavior: All variables are restored to their previously set values (A is 3, B is 5). Observed Behavior: Only the variable in component A, which was attached first, is restored. Component B's variable is reset to its initial value. (A is 3, B is 0). Additional Notes: Swapping the order of components A and B on the child GameObject reverses the result (A is 0, B is 5). This confirms that the issue is related to the component order. SDK version is 3.8.1. Similar issues found below, but it's unclear if they are related: https://vrchat.canny.io/bug-reports/p/pickup-events-may-not-be-called-when-multiple-udon-components-are-attached https://ask.vrchat.com/t/potential-issue-with-multiple-udon-components-execution-in-sdk-3-7-5/33845

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.

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

Currently worlds do not have the ability to check when persistence data fails to load or if there is any persistence data to load at all. OnPlayerRestored seems to only run when there is persistence data to load and only after all network objects have performed their checks for that player. 2 Suggestions: Create a new OnPlayerRestoreStatusUpdate event with a status parameter. This would tell the world the current state of the scene's (or better the object's) status for the Player Data Restoration process: Awaiting , Success , Failed , & NoDataToRestore . Or Add a similar parameter to OnPlayerRestored to indicate a general status for the whole scene. * Awaiting - Not all data has not been received from the server for the scene or object. The world knows to wait until a further update before doing anything related to persistence. * Success - All data was successfully restored from the server for the scene or object without any exceptions from VRChat's side. * Failed - Data restoration encountered an error on VRChat's side and data in the scene or on the object 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 for the whole scene or object, this is a new player or a player who recently deleted their data. This would be extremely helpful at preventing future data loss with networking issues from errors from either the Creator or VRChat. Such as when Network IDs are lost due to a regeneration with the Network ID Utility. Or when VRChat makes a breaking network patch that fails to load certain types of data correctly. Related: https://feedback.vrchat.com/persistence/p/add-getplayerrestorestatus-check

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.)

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)