Best Practices

CyanTriggers is based on Udon and there are some best practices that can work for both Udon and CyanTriggers

• When creating Custom Events, it is best to add an underscore prefix to all event names. This will prevent that event from being called from networked events. This will still work with networked broadcasts. The reason this is important is because Modified clients can call any event as a networked event, even when you never intend for the event to be networked. Example: “_MyCustomEvent”
• When working with CyanTrigger Custom Events, if the custom is on the same CyanTrigger, it is best to use the variable “This CyanTrigger”. Using this variable will optimize the program behind the scenes.
• Only use Update events when you need to. Doing a lot of work here can cause lag. While some things are required to be under an update loop, try to use event based design where something only happens based on some form of input.
• Do not call networked events from the Update event. This is a waste of bandwidth. You should rethink your logic design to avoid this.
• When adding CyanTriggers to your scene, it is best to put the CyanTrigger on an empty GameObject and not add other components. The UdonBehaviour.cs component has many unity callbacks in order to allow creators to use them. This means that Unity will call them even if you do not implement them. As an example, if you put a CyanTrigger/UdonBehaviour on an object with a renderer, then this means Every Frame this object is rendered, Unity will call OnRenderObject. One or two of these events may not make much of a difference, but you will notice an impact if hundreds of objects have this firing. There are many other events that can cause issues. It is best to read on the Unity documentation for MonoBehaviours to see what could be an performance issue.