Fax I can confirm that this issue still occurs on Beta Build 1862, with at least 3 players in an instance (in my experience, I can reliably reproduce this using 3 Build & Test clients). One player takes ownership of all 1200 VRCObjectSyncs through UdonSharp by interacting with the world's UI, then moves approximately 100 of them by picking them up using their respective VRCPickup components, then one of the other 2+ players rejoins to see most or all of them reporting "No Samples" in Debug Menu 8, a state I have yet to find any information about unfortunately. The VRCObjectSync components that report "No Samples" have their rotation correct, but not their position, as described in the original post. The rest are fine.

Attached is a screenshot of the Debug Menu 8 stats of a pile of 15 bugged VRCObjectSync components from the perspective of the late joiner on Beta Build 1862 (as, again, all 3 clients were running the same Beta Build 1862). Each object in the pile is initially overlapping, and has its child objects (most of which either having a MeshRenderer, or TMP_Text component) initially disabled, until the player joins and Udon enables these child objects according to manually synced strings (each string pertaining to a given pile of VRCObjectSyncs, for a total of 16 synced strings).

I don't believe the issue to just be related to any of the factors I've outlined, though. I've made a test world where I've recreated most of the relevant functionality present in the bugged world, and I haven't been able to reproduce it there. The only world I've been able to reliably reproduce this issue in is that one public world on my account with all the cards, so I'm inclined to believe it has something to do with how VRCObjectSync behaves when something specific happens, that only happens in that world. It doesn't seem to be related to string/image loading, any number of video players, MiniGreen's Coffee Set prefab, or significant amounts of Udon data serialized upon joining (that public world doesn't serialize nearly as much data as my test world, and doesn't have nearly as many VRCObjectSync objects as the test world has, yet the test world is perfectly fine). I could absolutely be missing something in my test world implementation, but regardless, hopefully at least some of that information proves helpful in fixing this issue.

Also, thank you so much for looking at this canny and attempting to fix VRCObjectSync!

Piano Walrus: Thank you for confirming that the issue is still present! We have not yet published a fix, but we expect it to be included in a future release.

Fax Ah okay, apologies for the misunderstanding then! I assumed the VRCObjectSync reliability improvements mentioned in yesterday's beta release were in reference to this canny post.