Manual Udon serialization starts unsolicited 0-byte retry loop depending on same-GameObject UdonBehaviour composition/cardinality
ZYNX_404
Summary
I found a reproducible Udon networking issue where a Manual-sync
UdonBehaviour begins serialization without any user-code call to
RequestSerialization().
The behaviour repeatedly receives:
OnPreSerialization()
OnPostSerialization(success = false, byteCount = 0)
while the RequestSerialization call count remains 0.
The issue depends on the composition/cardinality of UdonBehaviours attached
to the same GameObject.
Moving the additional UdonBehaviours to separate GameObjects prevents the
issue in my isolated tests.
Observed Behaviour
With a Manual-sync Authority UdonBehaviour and certain additional
UdonBehaviours on the same GameObject:
- RequestSerialization calls: 0
- OnPreSerialization: repeatedly called
- OnPostSerialization: repeatedly called
- SerializationResult.success: false
- SerializationResult.byteCount: 0
I instrumented the first unsolicited serialization attempt.
At FIRST OnPreSerialization:
- RequestSerialization count = 0
- Networking.IsClogged = false
- Networking.IsNetworkSettled = true
- Networking.IsObjectReady = true
- local player is owner
- Authority SyncMethod = Manual
Therefore the first observed serialization attempt was not preceded by an
instrumented RequestSerialization call and did not begin while IsClogged was
true.
Minimal Cardinality Reproduction
Using the same Authority behaviour and repeated copies of the SAME additional
ProgramAsset on the SAME GameObject produced this pattern:
Additional sibling UdonBehaviours:
0 -> QUIET
1 -> QUIET
2 -> unsolicited serialization loop
3 -> QUIET
4 -> unsolicited serialization loop
5 -> QUIET
6 -> unsolicited serialization loop
7 -> QUIET
The positive cases repeatedly produced:
Req = 0
Pre > 0
Post > 0
success = false
byteCount = 0
This was not specific to one ProgramAsset.
I reproduced the same cardinality pattern with another Udon ProgramAsset:
1 -> QUIET
2 -> unsolicited serialization loop
3 -> QUIET
4 -> unsolicited serialization loop
I also reproduced it using distinct sibling ProgramAssets:
1 sibling -> QUIET
2 siblings -> unsolicited serialization loop
3 siblings -> QUIET
4 siblings -> unsolicited serialization loop
I am NOT claiming that all even numbers of UdonBehaviours are generally
broken. This is only the reproducible pattern observed under this isolated
fixture configuration.
Same-GameObject Isolation
I then tested the registration/layout layer.
Same GameObject:
Authority + two relevant siblings
-> unsolicited serialization loop
Split GameObjects:
Authority on GO-A
Sibling 1 on GO-B
Sibling 2 on GO-C
-> QUIET
Partial split:
Authority + one sibling on GO-A
second sibling on GO-B
-> QUIET
This suggests that same-GameObject Udon registration/composition is involved.
Additional Cause-Layer Tests
The problem was NOT reproduced simply by creating arbitrary zero-field
behaviours.
Controlled variants using inert zero-field Manual / Continuous behaviours
remained QUIET in my tests.
Changing between zero and one synced field also did not independently
reproduce the issue.
Therefore I currently classify this as a multifactor same-GameObject
registration/composition issue rather than a bug in one specific script,
NoVariableSync alone, synced-field count alone, or Manual sync alone.
Expected Behaviour
For a Manual-sync UdonBehaviour:
If user code never calls RequestSerialization(), the owner should not enter a
continuous OnPreSerialization / OnPostSerialization failure loop.
In particular, I would not expect the addition/removal or placement of sibling
UdonBehaviours on the same GameObject to cause unsolicited Manual serialization.
Actual Behaviour
Under the affected same-GameObject composition:
RequestSerialization count remains 0, but serialization begins anyway.
The first observed attempt occurs while:
IsClogged = false
IsNetworkSettled = true
IsObjectReady = true
It then repeatedly calls:
OnPreSerialization()
OnPostSerialization(false, 0)
Important distinction
VRChat documentation states that failed Manual serialization may be cached
and retried when networking is clogged.
That could explain repeated attempts AFTER a failed serialization event.
However, in this reproduction the FIRST observed serialization attempt occurs
with:
RequestSerialization count = 0
IsClogged = false
So the unresolved issue is what creates the initial Manual serialization event.
Possible Related Existing Reports
There are existing tracked reports involving multiple Udon components on the
same GameObject, including:
- Persistence only restoring synced variables from the first Udon component
- Pickup events not reliably reaching multiple Udon components
Those reports may or may not share the same underlying cause.
This report describes a different failure mode involving the Manual
serialization lifecycle.
Impact
This is particularly difficult to diagnose because:
- gameplay code does not call RequestSerialization
- the affected behaviour is Manual sync
- the behaviour may work or fail depending on same-GameObject composition
- changing hierarchy/component composition can make the issue disappear
- the resulting failed serialization loop can continue at a high rate
In a modular Udon system, adding/removing otherwise unrelated sibling
UdonBehaviours can therefore change networking behaviour unexpectedly.
Workaround
Separating the networking Authority UdonBehaviour and the additional
UdonBehaviours onto different GameObjects prevents the reproduction in my
isolated test.
I consider this a workaround, not an explanation of the underlying behaviour.
Reproduction Evidence
I have retained:
- isolated minimal fixtures
- cardinality matrices
- ProgramAsset identities
- runtime SyncMethod fingerprints
- first-unsolicited-event instrumentation
- prefab/scene hashes for tested builds
- repeated runtime observations
I can provide a stripped minimal Unity/VRChat reproduction project if useful.
Log In