Persistence

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.

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!"

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)

Issue: Currently Player Data doesn't support VRCUrl, which makes using persistence for URL Input Fields really annoying to do. Currently the only way to store a VRCUrl is with PlayerObjects, which can often lead to some quite cursed setup. Suggestion: Add VRCUrl to the support data types of Player Data, this would allow us to more easily store and access them.

I can envision a situation in which one PlayerData key (or a collection of keys) might contain a large amount of data (for example: saving the state of a 'tycoon' world or other UGC), but other keys might be updated rapidly or in succession (example: world settings). Currently, if the PlayerData gets too big, updating the smaller more frequently updated keys will start to throttle the network. The docs suggest using PlayerObjects for larger AND more frequent data, but PlayerObjects have an entirely separate API lacking the ability to dynamically specify a key (and currently a separate data limit). It would be much better if a partial update could be sent over the network so we can update smaller fields without worrying about larger data which is already stored throttling the network.

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

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.

Issue: PlayerData is currently not really usable if you want to have multiple Prefabs of something using it, as we currently don't have an unique ID we could reference that also doesn't change. Currently you would have to implement your own system giving out IDs to your scripts, so that you can differentiate them. Suggestion: A relatively easy way to solve this is by giving us access to NetworkIDs on runtime. Doing so would allow us to differentiate between Game Objects when storing PlayerData, by adding that ID to the key.

Instead of the button not being there at all for the current world you are in, it should be greyed out and give a popup when you press it that lets you know that you cant actively be in the world to clear the data

Currently, the only way to know if any player has fully initialized is with the OnPlayerRestored event. The easiest way for any single UdonBehaviour to know if any random player's PlayerObject/PlayerData is "ready" is by having a global singleton UdonBehaviour that uses OnPlayerRestored and a list, which is then queried by other behaviours. It would be much simpler - both organizationally and performance wise - to have this function built into the API rather than having it implemented by creators and linked as an UdonBehaviour throughout everyone's' projects.