HyTari Studios · Guía oficial

Server Inventory Sync

Sincroniza inventarios entre servidores sin depender de índices runtime.

Esta guía base describe el comportamiento público ya documentado: inventario compartido, perfil del jugador, bloqueo anti-duplicación y conservación semántica de ItemQuality entre registros distintos.

INICIAR LA GUÍA PÁGINA DEL MOD

ANTES DE EMPEZAR

Primeros pasos

PASO 01

Instala en los servidores participantes

Usa la misma versión en los nodos que deban compartir el perfil.

PASO 02

Conecta el almacenamiento compartido

Los servidores participantes deben usar el mismo backend de datos previsto por la release.

PASO 03

Prueba una transferencia completa

Verifica inventario, equipamiento y calidades antes de abrir la red.

Esta guía base no inventa nombres de campos de configuración: el repositorio actual del mod está vacío, así que los detalles JSON exactos se añadirán solo tras verificar la fuente/build.

CAPÍTULO 01 · 1 EJEMPLOS

Qué se sincroniza

Inventario, armadura, backpack, slots adicionales y datos de perfil compatibles.

01FLUJO

Perfil compartido entre servidores

El mod mantiene sincronizados los elementos de perfil compatibles entre los servidores del mismo sistema.

FLUJO
Servidor A
  ↓ guardar perfil
Base de datos compartida
  ↓ cargar perfil
Servidor B

Comportamiento del mod

QUÉ HACE

El mod mantiene sincronizados los elementos de perfil compatibles entre los servidores del mismo sistema.

COMPORTAMIENTO IMPORTANTE

  • El objetivo es mantener continuidad del inventario entre hub, survival, dungeons, arenas u otros servidores.
  • Se incluyen inventario, armadura, backpacks y slots adicionales compatibles.
  • Los datos de perfil añadidos por mods compatibles pueden sincronizarse cuando la integración lo soporte.

CAPÍTULO 02 · 1 EJEMPLOS

Flujo de sincronización

Carga, guardado y transferencias siguen un ciclo protegido.

01SECUENCIA

Carga y guardado protegidos

El perfil se carga y guarda en puntos controlados del ciclo del jugador para evitar sobrescrituras simultáneas.

SECUENCIA
JOIN / TRANSFER
→ adquirir bloqueo
→ cargar perfil
→ juego
→ autosave / guardado final
→ liberar bloqueo

Comportamiento runtime

QUÉ HACE

El perfil se carga y guarda en puntos controlados del ciclo del jugador para evitar sobrescrituras simultáneas.

COMPORTAMIENTO IMPORTANTE

  • El sistema está diseñado para no interrumpir cambios internos normales de mundo.
  • El guardado automático reduce la ventana potencial de pérdida de datos.
  • Los mensajes de carga/bloqueo pueden informar al jugador mientras el perfil todavía no está disponible.

CAPÍTULO 03 · 1 EJEMPLOS

Bloqueos y anti-duplicación

El perfil queda protegido contra accesos simultáneos durante las fases críticas.

01REGLA

Bloqueo anti-concurrencia

Un perfil no debe modificarse al mismo tiempo desde dos servidores.

REGLA
1 UUID de jugador
→ 1 perfil activo
→ 1 bloqueo válido
→ sin acceso simultáneo

Seguridad interna

QUÉ HACE

Un perfil no debe modificarse al mismo tiempo desde dos servidores.

COMPORTAMIENTO IMPORTANTE

  • El bloqueo protege contra duplicaciones y race conditions entre servidores.
  • La lógica de transferencia debe completar el guardado y el handoff antes de que otro servidor use el perfil.
  • Los bloqueos caducados o errores se tratan como condiciones de seguridad, no como motivo para cargar dos copias.

CAPÍTULO 04 · 1 EJEMPLOS

ItemQuality seguras

Las calidades se identifican semánticamente en vez de depender solo de índices runtime.

01EJEMPLO

Conservación semántica de ItemQuality

La misma calidad puede tener índices runtime distintos en servidores con mods o registros diferentes.

EJEMPLO
Servidor A: CustomEpic = índice runtime 12
Servidor B: CustomEpic = índice runtime 27

La sincronización usa la identidad de la calidad, no solo 12/27.

ItemQuality mapping

QUÉ HACE

La misma calidad puede tener índices runtime distintos en servidores con mods o registros diferentes.

COMPORTAMIENTO IMPORTANTE

  • Si el destino conoce la calidad original, se reconstruye correctamente.
  • Si no puede resolverla, se usa un fallback Common seguro conservando la identidad original cuando sea posible.
  • Cuando la calidad vuelve a estar disponible, puede restaurarse.

CAPÍTULO 05 · 1 EJEMPLOS

Diagnóstico

El mapping de ItemQuality puede registrarse cuando dos servidores no resuelven las mismas calidades.

01USO

Diagnóstico del mapping

Con registros diferentes, los logs de mapping ayudan a comparar nombres e índices de ItemQuality.

USO
Diagnóstico de mapping ItemQuality
→ activar solo para investigar
→ comparar servidor A / servidor B
→ desactivar tras la prueba

Diagnóstico opcional

QUÉ HACE

Con registros diferentes, los logs de mapping ayudan a comparar nombres e índices de ItemQuality.

COMPORTAMIENTO IMPORTANTE

  • El diagnóstico ayuda a entender diferencias entre registros; no es necesario para el funcionamiento normal.
  • Evita dejar activado el logging detallado sin motivo.
  • Esta página se completará con los campos exactos cuando se realinee el repositorio del mod.

Antes de usar un ejemplo

El objetivo principal es la seguridad del perfil, no simplemente copiar slots.

La conservación de ItemQuality está diseñada específicamente para redes con registros diferentes.

Los diagramas descriptivos se sustituirán por la configuración real cuando el repositorio del mod quede alineado.

VOLVER ARRIBA