Persistence

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

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.

Currently there's no way for World Creators to clear PlayerData keys, we can set the value to whatever is the smallest, but the key is still going to exist forever, take space, and be synced to every other player unless the user manually resets his player data. If a complex world goes through rapid changes or frequent updates to their systems that involve PlayerData there's a big chance some keys will turn obsolete, and it is likely that recurring visitors will unavoidably store unused keys and data, unnecessarily cluttering the network and their persistence data. Udon Function: An Udon method for PlayerData.Remove(VRCPlayerApi player, string key) would allow for creators to manually handle clearing these keys. Some other solution: I think there should also be another option for creators that are not familiar with Udon and mainly rely on prefabs. Example scenario: using a badly coded prefab or too many prefabs that fill up the PlayerData size. Even if the prefab is deleted, a new player with no PlayerData would not experience issues, but a recurring player might because he still has the old keys.

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)

Steps to reproduce (TLDR: bold ): Create a world that has this UdonBehaviour(OurTestObject.cs): https://gist.github.com/hai-vr/3439f25571fcc4ad4f65107ad46657d8 Hierarchy example: - Pool - PlayerObject -- VRCPlayerObject + VRCEnablePersistence - OurTestObj -- UdonBehaviour(OurTestObject.cs) - Canvas 5x5 - Text -- TMP_Text 5x5 Alignment=Center&Bottom Wrapping=Disabled Overflow=Overflow In UdonBehaviour(OurTestObj), reference the TMP_Text component Upload the world Start two real clients Make Client A join the world Make Client B join Client A's world Make Client A rejoin the world After Client A finished rejoining the world, Make Client B rejoin the world At this stage, timesJoined should equal to 2 for both clients, confirming that Persistence is working for this world. In OurTestObject.cs, uncomment line 2. This will add a new UdonSynced bool field initialized to false, and a new line in the debug text. Recompile and reupload the world. Make Client A create and join a new instance of that world In Client A's perspective, notice the following in the debug text over the their own head: - The dateTime timer is ticking - timesJoined is equal to 3 - testBool has no text displayed (neither true nor false), but testBool is defined as a bool in U# (testBool appears to be null) Make Client B join Client A's instance In Client B's perspective, notice the following in the debug text over the Client A's head: - The dateTime timer is NOT ticking - timesJoined is equal to 2 (instead of 3) - testBool has no text displayed (neither true nor false), but testBool is defined as a bool in U# - The message "No new data received since ...s" appears, indicating no serialization has occurred. In Client A's perspective, notice the following in the debug text over the Client B's head: - The observations are identical to Client B's of Client A (serialization is failing, so no new data is received) (despite the above, data has been restored to persistent values because timesJoined is greater than 1) (testBool appears to be restored to null from the perspective of other clients, prior to the failed serializations) In Client B, go to the world description and click "Reset User Data", this will make Client B rejoin the world In Client B's perspective, notice the following in the debug text over the their own head: - testBool is equal to false In Client A's perspective, notice the following in the debug text over the Client B's head: - testBool is equal to false - The dateTime timer is ticking (resetting the User Data has correctly set testBool to its expected value of false, so testBool is correctly supposed to be initialized to a non-null value of false) In Client A, rejoin the world. In Client B's perspective, notice the following in the debug text over the Client A's head: - The message "No new data received since ...s" appears, indicating no serialization has occurred. In Client A's perspective, notice the following in the debug text over the their own head: - timesJoined is equal to 3 (despite the Client A having rejoined the world 4 times, the data can no longer be updated. VRChat servers still appear to retain the value of 2 being stored for timesJoined) Observed: Persistent data becomes frozen, unable to be updated any further, and is no longer syncable. UdonSynced fields is contaminated with illegal values (null is never supposed to be in a field of type bool), possibly affecting other Udon program that depend on the integrity of that data. Expected: Persistent data should remain updatable after new fields are introduced to Player Objects. Fields of a certain type should not be contaminated/overriden with illegal values for that type. A clear guideline about adding new fields to Player Objects should be documented officially. According to a VRChat representative on Discord: "in theory it should be just adding udonsynced fields and it's done. There's even metadata that is used to match up an old serialization to a new script to ensure compatibility (and this code has been in use for over a year when two people in the same instance are on different versions of the world). There seems to be some bugs with that system occasionally and it's definitely got room for improvement. Providing a default value rather than straight null would definitely be a good start, and I assume that's 90% of the issues, but it's hard to quantify so I'm not sure exactly what other issues might exist" https://discord.com/channels/189511567539306508/1294086083524432022/1330996987797045320

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

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.

I updated to the recent 3.7.2-persistence-beta.1 SDK and this line of code returns null when it used to work fine. Object reference is not null and the object has a VRC Object Sync component. MyGun.GetComponent<VRCObjectSync>().FlagDiscontinuity(); Edit: I cannot reproduce the issue in a clean project, even after an SDK upgrade. For some reason in the broken project null check on GetComponent<VRCObjectSync>() says it exists but when trying to call a function on it it returns null. Edit 2: This is only happening in editor and client sim. Works in Build and test and when uploaded.

Enable Unity Configurable Enter Play Mode https://docs.unity3d.com/Manual/ConfigurableEnterPlayMode.html Enter Play mode > Persistence Breaks

When clearing / regenerating Network IDs for worlds Player Object Data gets cleared (due to the difference in Network ID) and if the creator doesn't know the original Network ID of the Player Object they don't really have a way to know what it would have been. Maybe something like logging the Network IDs of all Player Object Data when the world loads and also logging if the ID attached to it is missing would be helpful for recovering the ID in a situation like that. (Not quite sure this is how the Persistence systems works 100% internally so I'm not sure if this implementation would work like this)