Object set to sync mode None should exclude from NetworkIDs.
tracked
frou01
Objects that are attached to NetworkIDs while in Syncmode (None) behave unexpectedly and increase the length of NetworkIDs unnecessarily.
There is a strange object that synchronizes even though it is supposed to be in SyncMode (None), I suspect this is the cause.
I'm using a SyncMode(None) Udons for locally behaviour. I noticed that a large number of objects were attached into VRC Scene Descriptor.NetWorkIDs. It contains a SyncMode(None) Udons. Although it is not always included, it seems that it may be included.
In any case, it is useless to have NetworkID when it only includes Syncmode (None) Udons.
Log In
Phasedragon
tracked
Rest assured this is something we also want to do, and have attempted multiple times. Turns out that there are a lot of things which break when you do this blindly, from initialization to update dispatch to ownership transfers. We've been putting in the work to decouple that behavior and solve those problems, and we hope to have something for you eventually.
In the meantime, though, to correct some misunderstandings - none sync behaviours do get assigned network IDs and do get networking components, but they are strictly forbidden from initiating
or
receiving any networking information. That should not be an issue.frou01
Phasedragon For now, I decided to use an editor script to strip the NetworkID from the object attached only SyncMode(None) Udon. It's going well.
Next, in the case of PickUp & Syncmode(None) Udon, which shares the same code as Syncing object, there is a suspicion that OwnerTransfer will fire. Now that I know how to force the Network ID, I plan to try debugging it later.
frou01
>Next, in the case of PickUp & Syncmode(None) Udon,
It's not depend on NetworkID. Debugger didn't show the object as synced object, but owner transfer is working.
It's strange.
I'll send another post as a bug report.