FOS Sync Doctor

Versión 1.2.1 · requiere FOS Essentials Core 1.1.0 o posterior

Revisa los comportamientos sincronizados de tu mundo en busca de los errores que nunca dan error: esos que solo descubres cuando un jugador entra en tu instancia y ve un mundo distinto al de los demás.

Gratuito. Requiere FOS Essentials Core 1.1.0.

Menú: FOS Essentials > FOS Sync Doctor > Audit.

---

No añade nada a tu mundo

Este pack contiene solo código de editor. Ningún componente, ningún prefab, ningún comportamiento. Lee tus scripts y los componentes de tu escena, e informa; nunca se ejecuta en el juego y no cuesta nada en tiempo de ejecución.

Por eso también se entrega sin ensamblado Runtime ni carpeta Prefabs, a diferencia de todos los demás packs de FOS: no habría nada que poner dentro.

---

Qué comprueba

Un modo de sincronización que contradice al script — error

El modo que declara un script no es el que se ejecuta. Lo que se ejecuta es el valor guardado en el UdonBehaviour de tu escena, y ambos se separan en cuanto un componente se sustituye, se duplica o se vuelve a pegar. Nada te avisa: el inspector sigue mostrando el modo declarado.

Cuando una sincronización manual acaba guardada como continua, la carga supera el tope de unos 200 bytes del modo continuo, el codificador falla, VRChat lo reintenta sin fin y ya nada sale de la máquina del propietario. Todo sigue funcionando en local, así que el mundo simplemente parece muerto para los demás, sin ningún error que lo explique.

Es el único hallazgo que la ventana sabe reparar. Fix restablece el modo declarado; guarda la escena después o la corrección se pierde.

Variables sincronizadas sin OnDeserialization — error

El fallo más común con quienes llegan tarde. Los valores llegan y nada los aplica. Para quien acaba de entrar, el mundo se queda en su estado inicial, para siempre.

Un campo con [FieldChangeCallback] no se señala: la llamada se dispara al deserializar, así que ese patrón ya es correcto.

RequestSerialization() dentro de Start() — advertencia

VRChat documenta que una serialización pedida desde Start() no alcanza a quienes entran después. Envíala desde un evento o desde OnPlayerJoined.

Sincronización manual que nunca serializa — advertencia

La sincronización manual no envía nada hasta que lo pides. Sin un solo RequestSerialization(), las variables son en la práctica locales.

Los atajos del Core cuentan como serialización: un script que llama a FOSSync() o a FOSTakeOwnershipAndSync() no se señala, porque ambos la solicitan por ti.

Serializar sin comprobar la propiedad — advertencia

Solo el propietario puede serializar. Llamado por cualquier otro, RequestSerialization() no hace nada en silencio: el fallo más desconcertante de Udon, porque en local todo parece correcto.

Sincronización continua con un array o una cadena — advertencia

La sincronización continua está limitada a unos 200 bytes por comportamiento. Un campo de longitud variable lo supera sin avisar. La manual transporta mucho más.

Varios comportamientos en un objeto, en desacuerdo sobre el modo — error

VRChat aplica un solo modo de sincronización por GameObject. Pon dos comportamientos de Udon en el mismo objeto y los demás heredan el modo que gana, sea cual sea el que declare su propio script: una pantalla en NoVariableSync junto a una autoridad en Manual degrada esa autoridad sin decir nada.

Esta es la causa que se esconde tras el hallazgo anterior. Sin ella reparas el modo guardado, guardas, y vuelve en la siguiente recompilación sin que nada indique de dónde.

La solución nunca es un valor que cambiar: mueve el comportamiento que sincroniza a su propio GameObject.

Ningún modo de sincronización declarado — nota

Sin [UdonBehaviourSyncMode], el modo vale Any por defecto y sigue siendo modificable en el inspector, donde puede cambiarse por accidente.

Un evento difundido que actúa sobre el jugador local — advertencia

El que más tiempo cuesta entender. Un evento de red enviado a todos los clientes se ejecuta en todos los clientes, y Networking.LocalPlayer designa a un jugador distinto en cada uno. Un teletransporte pensado para una persona mueve a toda la instancia.

Eventos de jugador usados sin isLocal — advertencia

OnPlayerTriggerEnter y sus hermanos se disparan en todos los clientes, para cada jugador que entra. Sin la comprobación, un desconocido que atraviese tu volumen dispara el efecto en tu máquina.

Un evento de red cuyo nombre empieza por _ — advertencia

VRChat se niega a ejecutar remotamente un evento así. La llamada sale, no pasa nada, y no se registra nada.

---

Cierto, y probable

Los hallazgos son de dos clases, y la ventana no los mezcla nunca.

Los hallazgos ciertos se establecen inspeccionando los tipos compilados: qué campos llevan [UdonSynced], qué modo de sincronización se declara, si OnDeserialization está sobrescrito. Son hechos.

Los hallazgos probables se deducen del texto de tus scripts, porque el cuerpo de un método no se puede inspeccionar de otro modo. «Este script nunca llama a RequestSerialization» es falso si otro script lo llama por él. Esos hallazgos llevan la etiqueta probable y merecen una mirada, no una corrección a ciegas.

Los comentarios y las cadenas literales se eliminan antes de cualquier búsqueda: un script que explica «aquí no hay comprobación de propiedad» en un comentario no se confunde con uno que sí la hace.

Una herramienta de auditoría incapaz de decirte cuánto fiarte de ella no vale gran cosa.

---

Qué no hace

• Lee tus scripts y una sola cosa de tu escena: el modo de sincronización guardado en cada componente. El cableado se le escapa: un comportamiento perfectamente escrito pero apuntando al objeto equivocado le sigue pareciendo impecable.
• No comprueba rendimiento, iluminación ni presupuestos de Quest. VRWorldToolkit lo hace bien, y gratis.
• No cambia nada por su cuenta. Cada hallazgo es un informe, y el único botón Fix —el del modo de sincronización contradictorio— solo actúa si haces clic.

Por defecto se omiten los propios packs de FOS: estás auditando tu mundo, no esta línea de herramientas. El interruptor existe si quieres mirar.