niaka3dayo/agent-skills-vrc-udon/unity-vrc-udon-sharp

UdonSharp Skill

Why This Skill Matters

UdonSharp looks like regular Unity C# scripting — until you hit its hidden walls. Many standard C# features (List<T>, async/await, try/catch, LINQ, generics) silently fail or refuse to compile in code that runs in the Udon runtime. Editor-evaluated field initializers are a separate context: they can use some ordinary C# features to generate a final value that Udon can hold. Networking is even more treacherous: modifying a synced variable without ownership produces no error — it just does nothing. Forgetting RequestSerialization means your state changes never leave your machine. Standard single-player local testing gives zero signal about these networking bugs because there is only one player.

Every rule in this skill exists because UdonSharp's default behavior is to fail silently. Read the Rules before generating any code.

Before Writing Network Code

Four architectural decisions that must be made before choosing sync modes or writing any synced variable. Changing them mid-implementation typically requires a full rewrite:

• Who owns this state? One owner writes; all others read. If two players can both write (e.g., a shared toggle), you need an ownership transfer protocol — writes without ownership are silently discarded.
• When does ownership transfer? On grab? Interact? Game event? OnPlayerLeft? Networking.SetOwner is locally immediate on the calling client — Networking.IsOwner(gameObject) is true synchronously after the call, and writing [UdonSynced] fields plus RequestSerialization() immediately afterwards is safe under an IsOwner guard. Concurrent SetOwner calls from multiple clients are resolved by network arrival order — there is no client-side arbitration, so accept that the loser's write is overwritten.
• What do late joiners see? State set only by one-time events (SendCustomNetworkEvent) is invisible to late joiners. Late-joiner-visible state must live in [UdonSynced] variables, which are delivered automatically via OnDeserialization; no manual RequestSerialization() on join is needed.
• What if the owner leaves mid-session? VRChat automatically transfers ownership to a remaining player (selection rule is not publicly documented), and OnOwnershipTransferred fires on all clients. Synced variables are preserved, so state is not frozen; decide upfront whether to keep the current value, reset to a known default, or re-apply/re-broadcast derived state in OnOwnershipTransferred.

Context Preservation

For complex synced systems, ownership-sensitive refactors, or work resumed after compaction/handoff, consider loading references/context-preservation.md. It provides a lightweight task-context note for source of truth, transport, sync mode, storage, ownership, late-joiner behavior, and validation rationale. This is optional guidance for complex work, not a step for small mechanical edits. Keep private data and raw transcripts out of any note.

For VRChat SDK Build Panel validation alerts, red/yellow/white warnings, or Auto Fix side effects that involve world scene setup rather than UdonSharp compiler constraints, use unity-vrc-world-sdk-3 and read references/build-validation.md.

Core Principles

1. Constraints First — For Udon runtime code, assume standard C# features are blocked until verified. Treat Editor-evaluated field initializers separately and require a final Udon-supported value. Check udonsharp-constraints.md before using any API.
2. Ownership Before Mutation — Only the owner of an object can modify its synced variables. If the local player is not the owner, SetOwner first; then modify → RequestSerialization (Manual sync).
3. Late Joiner Correctness — State must be correct for players who join after events have occurred. Design for re-serialization, not just live updates.
4. Sync Minimization — Every synced variable costs bandwidth (see data budget in udonsharp-sync-selection.md). Derive what you can locally; sync only the source of truth.
5. Event-Driven, Not Polling — Use OnDeserialization, [FieldChangeCallback], and SendCustomEvent instead of checking state in Update() for state-change reactions; for hot-path or periodic work, see [Event Dispatch & Cross-Behaviour Call Cost Tiers](references/patterns-performance.md#event-dispatch--cross-behaviour-call-cost-tiers).

Synced arrays: always apply them from `OnDeserialization()`. Array element changes do not provide a reliable FieldChangeCallback signal, and the same guidance applies to same-length changes, array reassignments, and length changes. Have the owner call the same idempotent apply method immediately after mutation, then request Manual serialization once. If a revision guard protects a historical one-shot side effect, a late joiner's first OnDeserialization() receives the current revision and may otherwise replay that effect. Baseline the first received revision without the side effect, but run durable ApplyValues() before the baseline check; only later revisions should trigger the one-shot. Revision is not ordering or stale-packet protection.

SDK 3.10.4 event receiver arguments

SDK 3.10.6 is the active and verified target for this Skill. SDK 3.10.4: UdonSharpBehaviour implements IUdonEventReceiver directly. An API that requires a receiver can therefore receive this directly:

VRCStringDownloader.LoadUrl(dataUrl, this);

The receiver argument is still required; only the explicit (IUdonEventReceiver) cast is unnecessary on the active SDK. Keep any pre-3.10.4 cast in the historical migration reference only. This follows the official SDK 3.10.4 release notes and the SDK source declaration.

Public fields: Inspector visibility is not persistence policy

[HideInInspector] only hides a public field from the Inspector; Unity still serializes it. Use [HideInInspector] public when Editor-time DI, baking, or autowiring must persist the value into a Scene/Prefab. Use [System.NonSerialized] public for a runtime-only value that another UdonBehaviour must access through direct access or SetProgramVariable. When [HideInInspector] is intentional, leave a comment explaining why the value must be persisted.

Editor-evaluated field initializers

Field initializers are evaluated as ordinary C# on the Unity/Editor side to produce initial data for the compiled Udon program; their expressions do not run in the Udon runtime. A Random.Range call in an initializer is evaluated in the Editor and stored as a baked default, not runtime randomness. LINQ, lambdas, or a same-behaviour static helper that uses List<T> can therefore generate an array initializer even though the same code is unavailable from Start(), Interact(), or another Udon runtime method. The final field type and value must be supported by Udon. Keep generation independent of scene, player, and runtime state, and do not call main-thread-only Unity APIs because field initializers and constructors can run on a loading thread. See references/constraints.md for both supported forms and their boundaries.

Use Start() or a lazy-init guard only for local or per-client randomness. For shared per-object or per-session seed/state, the owner generates it and stores it in a [UdonSynced] field; with Manual sync, establish ownership before writing and then call RequestSerialization(). Receivers may apply derived state in OnDeserialization() when needed, but that callback is not required for the field synchronization itself, and late joiners receive the current synced state.

Common Mistakes (NEVER List)

These Udon runtime and Unity serialization constraints cause either compile-time failures or silent data errors. Check this list before writing UdonSharp code or serialized initial values.