Persistence

I was playing the Suika game and streaming some music over VRCDN. Then suddenly my Internet connection became very unstable. My stream stopped, and while I was trying to figure out what was wrong with it, I got the "connection to VRChat timed out" message. After a couple retries a managed to get back into the world, but the game was not functioning - all players and their games were frozen, their avatars weren't loading, and as I noticed later, the persistence data hadn't loaded either (I had only 1 Melbux instead of 425 billion). After half a minute I got another "connection timeout" message and rejoined the world again. This time it was working, but very sluggish, and my persistence data didn't restore - it was gone at this point. Here's a recording of all of this happening: https://youtu.be/rL3wOgvS0rQ Also attaching the log file and two screenshots: the first shows that I had 425B Melbux before the disconnection, and second shows me having only 1 after rejoining.

World persistence in VRChat can for example allows creators : Build global leaderboards that carry across instances. Share cumulative player statistics. Create worlds that evolve based on player actions, etc. Allowing groups making changes or perform actions or set custom parameteres in a world, save them, and later these settings would be applied to any users who joined. Basically, creating more advanced worlds that attract and retain players on the platform. Limiting it to Creator Economy members would encourage more creators to join the program rather than rely on external services, while helping increase VRChat’s revenue. This feature could be offered as a paid option with a small fee, because data storage has real costs. The service could provide access to a lightweight database (such as SQLite, with XX.XX MB of storage) for use in a single world or shared across multiple worlds. Single World Database Plan : $5/month (or ~600 credits) Access to a dedicated SQLite database for one specific world. Universal Database Plan : $10–15/month (or ~1200 credits) Access to a shared SQLite database usable across multiple worlds. You pay for a limited database, and depending on your plan, you can use it in one or multiple worlds. Similar feature request: https://feedback.vrchat.com/feature-requests/p/multi-world-persistence https://feedback.vrchat.com/persistence/p/cross-world-persistency https://feedback.vrchat.com/feature-requests/p/vrchat-provided-world-data-persistence PS: For anyone concerned about the cost -> VRChat needs revenue to operate, and since this feature is limited to Creator Economy users, they can earn money that will quickly covering the cost.

I made 2 Udon Graph scripts with 2 Persistence Keys One is to not show the disclaimer again when rejoining the world, And one saves and enables the tablet if rejoined. In one scenario, when toggling the "don't show again" toggle and leaving the tablet, sometimes when rejoining, either you see the disclaimer again, or the tablet gets disabled despite the toggle for it (and persistence key) being still on. + Sometimes when despite the disclaimer being set to don't show again, and toggling the tablet, the disclaimer shows up again. It works fine in Unity with Client Sim, but is messed up in game. Tested in Open Beta and Stable.

Hi, as a world creator, I’d like to report a potential exploit in the persistence system: Players can run multiple VRChat clients simultaneously and join two different instances of the same world. In one instance, they intentionally spend all their in-game currency within the world. Since they remain logged in a different instance of the same world, they can leave and rejoin the first client to revert their spent currency by overwriting the persistent player.data file. Currently, there appears to be no reliable way to detect or prevent this intentional rollback behavior. To discourage such exploitation and maintain fair gameplay, I recommend implementing a "Pull Player Data from Server" feature. Alternatively, introducing an automatic periodic sync mechanism (e.g., every 10–30 seconds) would help ensure that player data stays consistent across all active sessions. I would greatly appreciate it if this could be addressed in a future update. Please keep me informed regarding any developments on this matter.

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.