Last reviewed 31 Jul 2026

Migrate Legacy VRChat World Triggers to Udon

Older trigger tutorials can still explain what a world interaction was meant to do, but the implementation needs to be rebuilt around the current Worlds SDK. This guide helps you turn a legacy trigger into a small Udon behaviour with an explicit event, network scope, ownership rule, and test plan.

Legacy Trigger Playlist

CyanLaser's playlist records the structure and terminology used by older VRChat world-trigger workflows. Use it to identify the intended interaction, then use the current event and networking references below for the replacement.

Playlist creator: CyanLaser

Write a Behaviour Specification

Do not begin by copying component settings. Describe the observable behaviour in plain terms:

Question	Example answer
What starts it?	A player presses a wall button.
What changes?	A door opens and its indicator turns green.
Who should see it?	Everyone in the instance.
Must it survive a late join?	Yes. A new player should see the current door state.
Who may change it?	Any player who interacts with the button.
How is it reset?	A second interaction closes the door.

This separates the interaction design from the legacy component that happened to implement it.

Map Trigger Concepts to Current Udon

Legacy behaviour	Current implementation
Click or use an object	Handle Interact on a GameObject with both a Collider and an UdonBehaviour.
Use a held pickup	Handle OnPickupUseDown or OnPickupUseUp on the pickup's UdonBehaviour.
Enter or leave a zone	Use a trigger Collider with OnPlayerTriggerEnter and OnPlayerTriggerExit.
Play a local sound or animation	Run the action locally when only the activating player needs it.
Play a temporary effect for current players	Send a network event to the required target. Network events do not persist for late joiners.
Keep a door, switch, or score consistent	Store the persistent result in a synced variable and apply that state after deserialization.
Synchronize a moving object	Use VRC Object Sync when its synchronized position, rotation, kinematic state, and gravity behaviour fit the object.
Allow a player to change synced state	Confirm or transfer ownership before that player writes the synchronized variables.
Restrict logic to the instance master	Reconsider the rule. VRChat recommends ownership checks instead of relying on master for networking logic.

Choose Local, Event, or Synced State

The most important migration decision is not the graph shape. It is how long the result matters and who must receive it.

Result	Use	Late join result
Local menu, personal audio, or player-only visual	Local Udon logic	Each player keeps their own local state.
Short animation, sound, or effect for players currently present	Network event	A late joiner does not receive the earlier event.
Door position, game phase, score, or other lasting shared state	Synced variable	A late joiner receives the latest synchronized value.
Frequently changing synchronized value	Continuous sync, when justified by the behaviour	The current value is synchronized.
Infrequently changing important state	Manual sync with RequestSerialization()	The latest serialized value is synchronized.

Do not use a network event as the only record of a persistent state. VRChat documents network events as one-time actions and synced variables as the mechanism for state that late joiners need.

Rebuild One Interaction

1. Create a clean test object

Duplicate the relevant scene or build the replacement in a small test scene. Keep the old object available as a visual reference, but disable it while testing the new behaviour so both systems cannot respond to the same interaction.

2. Add the physical requirement

Match the event to the object:

• Interact requires a Collider and an UdonBehaviour on the interactive GameObject.
• Player trigger events require a Collider with Is Trigger enabled.
• Pickup-use events belong on the held object's UdonBehaviour.

3. Implement the local action first

Make the door, animation, light, audio source, or other target respond locally before adding network synchronization. This confirms that the event and object references work.

4. Add the correct multiplayer rule

• Leave personal feedback local.
• Use a network event for a temporary action that current players should see.
• Use a synced variable for a state that must remain correct for late joiners.
• Obtain ownership before writing synchronized variables.

For manual synchronization, change the variable and then call RequestSerialization(). When another player needs to write the value, transfer ownership to that player before the change.

5. Apply received state

When a synced value arrives, use the received value to update the scene object. The visual result should be derived from the synchronized state rather than relying only on the original button press.

Ownership Checklist

Every networked GameObject has an owner, and only its owner can modify its synchronized Udon variables.

Before migrating a shared interaction, answer:

• Which GameObject owns the synchronized variable?
• Does the interacting player already own it?
• If not, when should ownership transfer?
• What happens when the owner leaves?
• Can two players activate it almost simultaneously?
• Does the interaction still work after ownership changes?

Avoid making the instance master a permanent controller. VRChat can reassign master, and recommends ownership-based logic for networked objects.

CyanTrigger Projects

CyanTrigger provides an in-scene event-and-action interface that resembles legacy VRC_Trigger workflows. Its creator states that it is no longer receiving new feature updates and recommends learning VRChat's official creation tools for long-term work.

For an existing CyanTrigger world:

• Keep a working project backup before changing packages or behaviours.
• Record each behaviour's event, actions, variables, and network scope.
• Prioritize systems that depend on current Udon features or need frequent maintenance.
• Rebuild and test one system at a time in Udon Graph or UdonSharp.
• Do not remove the original behaviour until the replacement passes multiplayer and late-join tests.

Test the Replacement

ClientSim can test interactions, pickups, UI, stations, and Udon variables in Unity Play Mode. It only simulates the local player, so it is not the final networking test.

Test	Expected result
Local activation	The event runs once and changes the intended object.
Second activation	Toggle or reset behaviour is deterministic.
Two-player instance	Both players observe the intended shared result.
Non-owner activation	Ownership transfers or the request is routed correctly.
Late join	Persistent synced state appears without replaying the original action.
Owner leaves	Another player can continue using the interaction.
Rapid repeated input	The system does not queue unnecessary network events or enter an invalid state.
Desktop and VR input	The interaction remains reachable and understandable on both control types.

Use ClientSim for fast local iteration, then use Build & Test or a private upload with multiple VRChat clients for networking, ownership, and late-join behaviour.

Migration Release Checklist

• [ ] Every legacy trigger has a written event, action, audience, and persistence requirement.
• [ ] Local-only effects remain local.
• [ ] Temporary shared effects use network events only when necessary.
• [ ] Persistent shared state uses synchronized variables.
• [ ] Manual-sync behaviours call RequestSerialization() after the owner changes the value.
• [ ] Non-owner interactions have an explicit ownership path.
• [ ] Trigger Colliders and interactive Colliders match the selected Udon events.
• [ ] ClientSim interaction tests pass.
• [ ] Two-player, late-join, owner-leave, and rapid-input tests pass in VRChat.
• [ ] The legacy behaviour is disabled or removed only after the replacement is verified.

Troubleshooting

The Interact event never runs.

Confirm the interactive GameObject has both a Collider and an UdonBehaviour. Check that the Collider is reachable and that another Collider or UI element is not blocking the interaction.

The trigger zone does not detect players.

Use a Collider with Is Trigger enabled and the player-specific trigger events. VRChat notes that very fast movement or teleporting can skip trigger-enter or trigger-exit edge cases, so avoid making critical persistent state depend on one unverified boundary event.

The interaction works for the owner but not another player.

Only the owner can write synchronized Udon variables. Check ownership before the change or transfer ownership to the interacting player, then serialize the new state.

Current players see the change, but late joiners do not.

The system is probably relying on a network event or a local action without synchronized state. Store the lasting result in a synced variable and apply that value when it is received.

The replacement passes ClientSim but fails in VRChat.

ClientSim does not simulate remote players and its networking serializer differs from VRChat. Repeat the test in a private instance with multiple clients, including a late join and an ownership change.

Rapid interactions cause delayed effects.

Check whether the behaviour is sending network events more often than required. VRChat queues events that exceed their rate limit, so consolidate the interaction around a stable synchronized state or reduce event frequency.

Official References

• Udon Overview
• Udon Event Nodes
• Player Collisions and Trigger Events
• Udon Networking
• Network Variables
• Network Events
• Object Ownership
• Networking Performance
• VRC Object Sync
• ClientSim

Tool Reference

• CyanTrigger package page and maintenance notice

Continue Learning

• UdonSharp Guide
• Udon Networking Decision Guide
• ClientSim World Testing
• VRChat Prefab Hub
• World Creation Guide
• VRChat Documentation