SyncMode None should be "weaker" than other sync modes
complete
bd_
According to a response from Phasedragon on the official discord, putting a UdonBehaviour with None syncmode on a gameobject will break syncing for any other UBs on that gameobject.
When building reusable components, it would be preferable to be able to slap None mode onto any UdonBehaviour that does not, itself, require sync, while still being able to add other UdonBehaviours that need sync. Consider, for example, a simple UdonBehaviour that adds collision sounds to any rigidbody. We should be able to add this regardless of whether the object is synced or not. With the proposed None sync mode behavior, it would be necessary to mark this helper UB as being either continuous or manual sync mode (and it would only be able to coexist with UB of the same type).
If, instead, none sync mode was considered 'weaker' than ObjectSync, Continuous, or Manual modes, and to defer to those modes if a corresponding component was present, we'd have much better composability than the proposed semantics.
Log In
Tupper - VRChat Head of Community
marked this post as
complete
Phasedragon
marked this post as
in progress
This has been implemented in the 1144 open beta.
Tupper - VRChat Head of Community
marked this post as
open
Tupper - VRChat Head of Community
marked this post as
tracked
Phasedragon
Sync mode is a gameobject-wide decision, so you really shouldn't slot together reusable components onto the same gameobject if they have different sync modes. You should have them on separate gameobjects.
bd_
Phasedragon: I'm more asking that reusable UdonBehaviours which don't care about networking, have a way of saying "I don't care about networking; don't initialize it just for my sake, and don't get in the way of anything else on the GameObject that wants to do networking". I don't see a use case for the current ("I actively want networking to break") that isn't covered by the "I don't care" semantics I propose above.
In particular, due to the way unity event routing works, it's often not an option to move things to separate gameobjects (see the collider-to-audio component above - you can't move that to a different GameObject than the collider, and if sometimes you also need Object Sync on that object, you're stuck).
While it's possible to configure on a per-UB basis to get things consistent, that's extra configuration work - with U# the sync mode can be set automatically, removing error-prone manual setup steps, but not if you need to change it each time to match the other UBs.
bd_
Phasedragon Are there any documentation pages describing the final behavior with conflicting none+other sync modes in the new open beta version?
Phasedragon
bd_: No changes have been made to this behavior in open beta 1132. This is still under review and if anything changes it will be included in the patch notes.