`RequestSerialization` during `Start` does not synchronise to Late-Joiners
available in future release
Cake․
Trying to request serialisation of values during the
Start
Event, when loading into the world, by invoking RequestSerialization
results in no synchronisation.I noticed this when Late-Joiners were not receiving the synced variable values on the networked
UdonBehaviour
in question.If I delay the execution of
RequestSerialization
by a few seconds, it works again.This started happening with
2024.4.1p3
and was not a bug before this version.Log In
KokiM1018
I am encountering similar problems since the update, and continue to have them after updating to `
2024.4.1p4
, build
1538
`For example, in this world, a Late-Joiner who joins after starting a poker table may not get any synchronization data, in which case any operations that cause synchronization of the poker table are no longer possible.
It is still possible that other existing worlds that synchronize on Join will have similar problems with Late-Joiner.
_
_tau_
Extra details:
Some of the issues with late joiner syncing have already been fixed for new instances via a server-side change.
The original issue about
RequestSerialization
not working in Start
will be fixed with a client update very soon.Μerlin
_tau_ Cool, now please don't push updates like this to live immediately. This was pain for many people that could've been avoided trivially with a correct process for releases.
This post was marked as
available in future release
Kinix~
I've run into a similar issue after the update. Not quite like this with Start but similar to what it was mentioned earlier from DrBlackRat.
For some reason, my late joiners would not get any data once the world launches and fully join, only after owners of scripts made a RequestSerialization on their end I would finally get the data to work with. This sadly ended up breaking the world entirely.
Vincil
So for a year+ ago I discovered that RequestSerialization does not work if you fire it in the Start of an object that is not active during scene load. I concluded that it takes one or more frames for networking to actually start working on an object when it is set active for the very first time.
I wonder if the current issue is linked to this and the fix for Start events occurring over multiple frames (they use to occur after networking was loaded and functional for an object and now occur before)
Vincil
Update: after doing some testing, doing networking on Start for objects set active post scene load works perfectly fine. This appears to be exclusively an issue with objects active on scene load.
Also in my testing, while RequestSerialization() failed to work on Start() for these objects, attempting it again a frame later did work. The logs also might lend a clue as to what is happening (note, the "Performing Serialization a second time" log is made during Start(), before a SendCustomEventDelayedFrames is called)
Pikapetey
This broke my world last night. I fixed it by moveing requestion serialization to an UdonBehaviour.SendCustomEventDelayedFrames and that fixed nearly everything. Although, requesting serialization worked on start for so long, I don't know how many pre-fabs and things made for vrchat that this affects.
DrBlackRat
This seems to be a much bigger issue as for me
OnDeserialization
just doesn't fire at all
for late joiners, so they never recive the current state of the instance unless you manually do a RequestSerialization
again.This behaviour is also different when comparing 2 local test build clients and 2 actual clients.
For the 2 local test builds you wont get
OnDeserialization
when doing a RequestSerialization
on Start directly, doing it a frame later works however.With 2 actual clients it doesn't work at all, I don't receive
OnDeserialization
no matter how late I call RequestSerialization
. The only way to get data for them is to do a RequestSerialization
after they have joined.All of this can be tested here:
_
_tau_
tracked
FairlySadPanda
Another test suite here: https://vrchat.com/home/world/wrld_bb2eaca5-de6b-4414-9f46-d642e8f7625e
Confirmed regression between open beta (i.e. last patch) and live.
You can assert this by joining the above world and eyeballing your logs. Note the bugs below are using local test, so there's a chance that has polluted the results.
-- Normal Udon Behaviours --
Player joins world; they own a manually-synced UB, in Start() they set a synced string value and then call RequestSerialization()
The player detects someone is joining, OnPre/Postserialization are run on the object.
Expected:
Player 2 joins: the object triggers OnDeserialization.
Actual:
Player 2 joins: the object never triggers OnDeserialization.
Also what appears to be a bug with POs:
-- Player Object --
Player joins world, a player object spawns for them with a child UB with manual sync.
Expected: The player sees that they own the UB when checking for ownership in Start().
Actual:
In Start(), the player does not believe they own the UB.
Also an unexpected behaviour:
-- Player Object --
Player joins empty world, they have both an owned normal UB w/ manual sync and a child-of-a-playerobjecct with UB with manual sync.
Another player starts joining.
Expected: The player syncs both the normal and PO UBs whilst the player joins.
Actual: The player seems to sync their PO UB when they first join the world, and they sync the normal UB when the first remote player joins.
Not 100% sure on the last one but it's what my logs seemed to show in testing. It's just weird inconsistency in what's already a weird inconsistency about how syncing data works.
FairlySadPanda
To replicate, you can join the above world. Keep an eye on your logs; I've made it easy to spot what I'm reporting because I've added a big [TEST] prefix to each log line of the test.
Wing_
Can confirm this bug.
Tested a udon that RequestSerialization() won't sync to late-joiners in Start(), but will sync correctly if called in Update()
Load More
→