Persistence

"Fired when a player is nearing their Player Data Storage limit." What does "near" mean? 50%? 75%? 90%? Without a clear figure that can be responded to or made use of, this warning is meaningless.

Documentation for OnPersistenceUsageUpdated is too confusing, "Triggered when a VRChat player's persistence usage has been updated" surely setting any value at all would update a player's persistence usage as in data? Is this referring to a change in the amount of used storage allowance? Or is it the number of individual keys? If this is about storage allowance, without returning how much the "usage" (amount used) is or the remaining allowance is, how is this more useful than OnPlayerDataUpdated ? Or is it meant to be the PlayerObject equivalent of OnPlayerDataUpdated ?

If OnPlayerRestored is designed to be the first event where you should use the data, enforce it. If OnPlayerDataUpdated fired before OnPlayerRestored is unreliable, don't fire it. Having to force every implementation to do checks if player is restored is poor design choice, because it is a trap every new user will fall into, and will be forced to include the extra check just to make it work at all, which is a performance sink. 3.1 If such "best practice" is mandatory, just make it automatic. Semantically "update" should mean there is a new version of something existing, and "restored" should mean the data is first restored (as it is currently designed and intended). These meanings should be actually implemented rather than labels you are relying the end user to sort out.

Currently there's no official way to backup and restore persistence data which can be a pretty big issue when you've spent many hours in a game world and find your progress wiped one day or encounter a game breaking bug that softlocks your progress. Your only option is to contact VRC support and wait and hope that there's still a backup of your persistence data. A solution to this would be to add an optional persistence backup system for worlds. If world creators choose to enable it, players will have the option to create a backup copy of the persistence data for the current world and be able to restore it at any time. The copy would have a timestamp and an optional player-editable note. It would also be kept entirely server side to prevent editing. This feature would be off by default, so if world creators don't want it, they can simply ignore it and leave it off for their worlds.

Issue: Setting any value on playerdata (for example, a setting for the world) syncs all playerdata keys/values to all users (for example, SaveData), even ones that were not changed. I don't want to to sync certain keys, as they are very big and not commonly changed. I also don't need other players to be able to see certain keys. Context: So this is very similar to https://feedback.vrchat.com/persistence/p/user-private-persistence however my reasoning is completely different. I have a leaderboard system and a settings panel in my world and they both use persistence, they work perfectly fine, but I recently introduced a Save-Load system, which lets players save pickup locations and pen drawings to their player-data, so they can load it later. The issue comes because when something unrelated gets changed in the player-data, for example a value on the leaderboard. All of that player's persistent data still gets sent over the network, including the large save data, this creates a LOT of network lag and makes the instance unstable. Using persistence is the only way I can make sure everyone can use the save-load system. I cant rely on a simple text box export alone or using the debug logs, as some users are on quest and that makes it quite difficult to extract debug logs/save text. And debug logs get automatically deleted, so It's unreliable. Solution: My idea is to have a third, optional argument for PlayerData.Set<T>(), For example: instead of: PlayerData.SetBytes(Key, Value); We would have: PlayerData.SetBytes(Key, Value, true); The third argument would be 'Local' it defaults to false so people would not need to update all their existing scripts When it is true, it makes it so that key is marked as Local Only, and doesn't get sent to other players, ever. If somewhere else in the code, localplayer calls PlayerData.SetBytes(Key, Value, false); or without the third argument, it sets that variable back to global. I have included a mockup screenshot.

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