HyTari Studios ¡ Guida ufficiale

Server Inventory Sync

Sincronizza inventari tra server senza affidarti agli indici runtime.

Questa guida-base descrive il comportamento pubblico giĂ  documentato della mod: inventario condiviso, profilo giocatore, locking anti-duplicazione e preservazione semantica delle ItemQuality tra registry differenti.

INIZIA LA GUIDA PAGINA MOD

PRIMA DI INIZIARE

Per iniziare

PASSO 01

Installa sui server coinvolti

Usa la stessa versione sui nodi che devono condividere il profilo.

PASSO 02

Collega lo storage condiviso

I server partecipanti devono usare lo stesso backend dati previsto dalla release.

PASSO 03

Testa un trasferimento completo

Verifica inventario, equipaggiamento e qualitĂ  prima di aprire la rete.

Per questa guida-base non vengono inventati nomi di campi di configurazione: il repository corrente della mod è vuoto e i dettagli JSON verranno aggiunti soltanto dopo verifica della release sorgente/binary.

CAPITOLO 01 ¡ 1 ESEMPI

Cosa sincronizza

Inventario, armatura, backpack, slot aggiuntivi e dati profilo compatibili.

01FLUSSO

Profilo condiviso tra server

La mod mantiene sincronizzati gli elementi del profilo supportati sui server che partecipano allo stesso sistema.

FLUSSO
Server A
  ↓ salva profilo
Database condiviso
  ↓ carica profilo
Server B

Comportamento della mod

COSA FA

La mod mantiene sincronizzati gli elementi del profilo supportati sui server che partecipano allo stesso sistema.

COMPORTAMENTO IMPORTANTE

  • L'obiettivo è mantenere continuitĂ  dell'inventario tra hub, survival, dungeon, arene o altri server.
  • Sono inclusi inventario, armature, backpack e slot aggiuntivi supportati.
  • Dati di profilo aggiunti da mod compatibili possono essere sincronizzati quando previsti dall'integrazione.

CAPITOLO 02 ¡ 1 ESEMPI

Flusso di sincronizzazione

Caricamento, salvataggio e trasferimento seguono un ciclo protetto.

01SEQUENZA

Caricamento e salvataggio protetti

Il profilo viene caricato e salvato in punti controllati del ciclo giocatore, evitando sovrascritture concorrenti.

SEQUENZA
JOIN / TRANSFER
→ acquisizione lock
→ caricamento profilo
→ gioco
→ autosave / save finale
→ rilascio lock

Comportamento runtime

COSA FA

Il profilo viene caricato e salvato in punti controllati del ciclo giocatore, evitando sovrascritture concorrenti.

COMPORTAMENTO IMPORTANTE

  • Il sistema è progettato per non interrompere il normale cambio mondo interno al server.
  • Il salvataggio automatico riduce la finestra di perdita dati.
  • Messaggi di loading/lock possono informare il giocatore quando il profilo non è ancora disponibile.

CAPITOLO 03 ¡ 1 ESEMPI

Lock e anti-duplicazione

Il profilo viene protetto da accessi concorrenti durante le fasi critiche.

01REGOLA

Lock anti-concorrenza

Un profilo non deve essere modificato contemporaneamente da due server.

REGOLA
1 player UUID
→ 1 profilo attivo
→ 1 lock valido
→ niente accessi concorrenti

Sicurezza interna

COSA FA

Un profilo non deve essere modificato contemporaneamente da due server.

COMPORTAMENTO IMPORTANTE

  • Il locking protegge da duplicazioni e race condition tra server.
  • La logica di trasferimento deve completare salvataggio e handoff prima che il profilo venga usato altrove.
  • I casi di lock scaduto o errore vengono gestiti come condizioni di sicurezza, non come motivo per caricare due copie.

CAPITOLO 04 ¡ 1 ESEMPI

ItemQuality sicure

Le qualitĂ  vengono identificate semanticamente invece di dipendere solo dagli indici runtime.

01ESEMPIO

Preservazione semantica ItemQuality

La stessa qualità può avere indici runtime differenti su server con mod/registry diversi.

ESEMPIO
Server A: CustomEpic = runtime index 12
Server B: CustomEpic = runtime index 27

Sync usa l'identitĂ  della qualitĂ , non solo 12/27.

ItemQuality mapping

COSA FA

La stessa qualità può avere indici runtime differenti su server con mod/registry diversi.

COMPORTAMENTO IMPORTANTE

  • Se la destinazione conosce la qualitĂ  originale, viene ricostruita correttamente.
  • Se non può risolverla, viene usato un fallback Common sicuro mantenendo l'identitĂ  originale quando possibile.
  • Quando la qualitĂ  torna disponibile può essere ripristinata.

CAPITOLO 05 ¡ 1 ESEMPI

Diagnostica

Il mapping ItemQuality può essere registrato quando due server non risolvono le stesse qualità.

01USO

Mapping diagnostico

Quando due server hanno registry differenti, i log di mapping aiutano a confrontare nomi e indici delle ItemQuality.

USO
ItemQuality mapping diagnostics
→ abilita solo per investigazione
→ confronta server A / server B
→ disattiva dopo il test

Diagnostica opzionale

COSA FA

Quando due server hanno registry differenti, i log di mapping aiutano a confrontare nomi e indici delle ItemQuality.

COMPORTAMENTO IMPORTANTE

  • La diagnostica serve a capire divergenze tra registry, non è necessaria per il normale funzionamento.
  • Evita di lasciare logging dettagliato attivo senza motivo.
  • Questa pagina verrĂ  completata con i campi di configurazione esatti quando il repository corrente della mod verrĂ  riallineato.

Prima di usare un esempio

Il punto centrale della mod è la sicurezza del profilo, non la semplice copia di slot.

La preservazione ItemQuality è pensata proprio per reti con registry differenti.

Domani possiamo sostituire i diagrammi descrittivi con la configurazione reale appena riallineiamo il repository della mod.

TORNA SU