HyTari Studios · Guia oficial

Server Inventory Sync

Sincronize inventários entre servidores sem depender de índices runtime.

Este guia-base descreve o comportamento público já documentado do mod: inventário partilhado, perfil do jogador, locking anti-duplicação e preservação semântica de ItemQuality entre registries diferentes.

INICIAR O GUIA PÁGINA DO MOD

ANTES DE COMEÇAR

Primeiros passos

PASSO 01

Instale nos servidores participantes

Utilize a mesma versão nos nós que devem partilhar o perfil.

PASSO 02

Conecte o armazenamento partilhado

Os servidores participantes devem usar o mesmo backend de dados esperado pela release.

PASSO 03

Teste uma transferência completa

Verifique inventário, equipamento e qualidades antes de abrir a rede.

Este guia-base não inventa nomes de campos de configuração: o repositório atual do mod está vazio, então os detalhes JSON exatos serão adicionados apenas após verificar a fonte/build.

CAPÍTULO 01 · 1 EXEMPLOS

O que é sincronizado

Inventário, armadura, backpack, slots adicionais e dados de perfil compatíveis.

01FLUXO

Perfil partilhado entre servidores

O mod mantém sincronizados os elementos de perfil suportados entre os servidores do mesmo sistema.

FLUXO
Servidor A
  ↓ guardar perfil
Base de dados partilhada
  ↓ carregar perfil
Servidor B

Comportamento do mod

O QUE FAZ

O mod mantém sincronizados os elementos de perfil suportados entre os servidores do mesmo sistema.

COMPORTAMENTO IMPORTANTE

  • O objetivo é continuidade do inventário entre hub, survival, dungeons, arenas e outros servidores.
  • Inventário, armadura, backpacks e slots adicionais suportados estão incluídos.
  • Dados de perfil adicionados por mods compatíveis podem ser sincronizados quando a integração oferecer suporte.

CAPÍTULO 02 · 1 EXEMPLOS

Fluxo de sincronização

Carregamento, gravação e transferências seguem um ciclo protegido.

01SEQUÊNCIA

Carregamento e gravação protegidos

O perfil é carregado e guardado em pontos controlados do ciclo do jogador para evitar sobrescritas concorrentes.

SEQUÊNCIA
JOIN / TRANSFER
→ adquirir lock
→ carregar perfil
→ jogo
→ autosave / gravação final
→ disponibilizar lock

Comportamento em runtime

O QUE FAZ

O perfil é carregado e guardado em pontos controlados do ciclo do jogador para evitar sobrescritas concorrentes.

COMPORTAMENTO IMPORTANTE

  • O sistema foi projetado para não interromper mudanças internas normais de mundo.
  • O gravação automático reduz a janela potencial de perda de dados.
  • Mensagens de loading/lock podem informar o jogador enquanto o perfil ainda não está disponível.

CAPÍTULO 03 · 1 EXEMPLOS

Locks e anti-duplicação

O perfil é protegido contra acessos concorrentes durante fases críticas.

01REGRA

Lock anti-concorrência

Um perfil não deve ser modificado por dois servidores ao mesmo tempo.

REGRA
1 UUID de jogador
→ 1 perfil ativo
→ 1 lock válido
→ sem acesso concorrente

Segurança interna

O QUE FAZ

Um perfil não deve ser modificado por dois servidores ao mesmo tempo.

COMPORTAMENTO IMPORTANTE

  • O locking protege contra duplicações e race conditions entre servidores.
  • A lógica de transferência deve concluir gravação e handoff antes que outro servidor utilize o perfil.
  • Locks expirados ou erros são tratados como condições de segurança, não como motivo para carregar duas cópias.

CAPÍTULO 04 · 1 EXEMPLOS

ItemQuality segura

As qualidades são identificadas semanticamente em vez de depender apenas de índices runtime.

01EXEMPLO

Preservação semântica de ItemQuality

A mesma qualidade pode ter índices runtime diferentes em servidores com mods ou registries diferentes.

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

A sincronização usa a identidade da qualidade, não apenas 12/27.

ItemQuality mapping

O QUE FAZ

A mesma qualidade pode ter índices runtime diferentes em servidores com mods ou registries diferentes.

COMPORTAMENTO IMPORTANTE

  • Se o destino conhece a qualidade original, ela é reconstruída corretamente.
  • Se não puder resolvê-la, usa um fallback Common seguro preservando a identidade original quando possível.
  • Quando a qualidade volta a ficar disponível, pode ser restaurada.

CAPÍTULO 05 · 1 EXEMPLOS

Diagnóstico

O mapping de ItemQuality pode ser registrado quando dois servidores não resolvem as mesmas qualidades.

01USO

Diagnóstico de mapping

Quando dois servidores têm registries diferentes, os logs de mapping ajudam a comparar nomes e índices de ItemQuality.

USO
Diagnóstico de mapping ItemQuality
→ ativar apenas para investigação
→ comparar servidor A / servidor B
→ desativar após o teste

Diagnóstico opcional

O QUE FAZ

Quando dois servidores têm registries diferentes, os logs de mapping ajudam a comparar nomes e índices de ItemQuality.

COMPORTAMENTO IMPORTANTE

  • O diagnóstico ajuda a entender divergências entre registries; não é necessário para uso normal.
  • Evite deixar logging detalhado ativo sem motivo.
  • Esta página será completada com os campos exatos de configuração quando o repositório atual do mod for realinhado.

Antes de utilizar um exemplo

O objetivo central é a segurança do perfil, não simplesmente copiar slots.

A preservação de ItemQuality foi projetada especificamente para redes com registries diferentes.

Os diagramas descritivos poderão ser substituídos pela configuração real quando o repositório do mod for realinhado.

VOLTAR AO TOPO