HyTari Studios · Guide officiel

Server Inventory Sync

Synchronisez les inventaires entre serveurs sans dépendre des index runtime.

Ce guide de base décrit le comportement public déjà documenté du mod : inventaire partagé, profil joueur, verrouillage anti-duplication et conservation sémantique des ItemQuality entre registries différents.

COMMENCER LE GUIDE PAGE DU MOD

AVANT DE COMMENCER

Bien démarrer

ÉTAPE 01

Installer sur les serveurs concernés

Utilisez la même version sur les nœuds qui doivent partager le profil.

ÉTAPE 02

Connecter le stockage partagé

Les serveurs participants doivent utiliser le même backend de données prévu par la release.

ÉTAPE 03

Tester un transfert complet

Vérifiez inventaire, équipement et qualités avant d'ouvrir le réseau.

Ce guide de base n'invente volontairement aucun nom de champ de configuration : le dépôt actuel du mod est vide, les détails JSON exacts seront ajoutés après vérification de la source/build.

CHAPITRE 01 · 1 EXEMPLES

Ce qui est synchronisé

Inventaire, armure, backpack, slots supplémentaires et données de profil compatibles.

01FLUX

Profil partagé entre serveurs

Le mod maintient les éléments de profil supportés synchronisés entre les serveurs participant au même système.

FLUX
Serveur A
  ↓ sauvegarder le profil
Base partagée
  ↓ charger le profil
Serveur B

Comportement du mod

CE QUE ÇA FAIT

Le mod maintient les éléments de profil supportés synchronisés entre les serveurs participant au même système.

COMPORTEMENT IMPORTANT

  • L'objectif est la continuité de l'inventaire entre hub, survival, donjons, arènes et autres serveurs.
  • Inventaire, armure, backpacks et slots supplémentaires supportés sont inclus.
  • Les données de profil ajoutées par des mods compatibles peuvent être synchronisées si l'intégration le prévoit.

CHAPITRE 02 · 1 EXEMPLES

Flux de synchronisation

Chargement, sauvegarde et transferts suivent un cycle protégé.

01SÉQUENCE

Chargement et sauvegarde protégés

Le profil est chargé et sauvegardé à des étapes contrôlées du cycle joueur afin d'éviter les écrasements concurrents.

SÉQUENCE
JOIN / TRANSFER
→ acquérir le verrou
→ charger le profil
→ jeu
→ autosave / sauvegarde finale
→ libérer le verrou

Comportement runtime

CE QUE ÇA FAIT

Le profil est chargé et sauvegardé à des étapes contrôlées du cycle joueur afin d'éviter les écrasements concurrents.

COMPORTEMENT IMPORTANT

  • Le système est conçu pour ne pas interrompre les changements de monde internes ordinaires.
  • La sauvegarde automatique réduit la fenêtre possible de perte de données.
  • Les messages de chargement/verrou peuvent informer le joueur tant que le profil n'est pas disponible.

CHAPITRE 03 · 1 EXEMPLES

Verrous et anti-duplication

Le profil est protégé des accès concurrents pendant les phases critiques.

01RÈGLE

Verrou anti-concurrence

Un profil ne doit pas être modifié simultanément par deux serveurs.

RÈGLE
1 UUID joueur
→ 1 profil actif
→ 1 verrou valide
→ aucun accès concurrent

Sécurité interne

CE QUE ÇA FAIT

Un profil ne doit pas être modifié simultanément par deux serveurs.

COMPORTEMENT IMPORTANT

  • Le verrouillage protège contre les duplications et race conditions inter-serveurs.
  • La logique de transfert doit terminer la sauvegarde et le handoff avant qu'un autre serveur utilise le profil.
  • Les verrous expirés ou erreurs sont traités comme des conditions de sécurité, pas comme une raison de charger deux copies.

CHAPITRE 04 · 1 EXEMPLES

ItemQuality sécurisées

Les qualités sont identifiées sémantiquement plutôt que seulement par leurs index runtime.

01EXEMPLE

Conservation sémantique ItemQuality

Une même qualité peut avoir des index runtime différents sur des serveurs avec mods ou registries différents.

EXEMPLE
Serveur A : CustomEpic = index runtime 12
Serveur B : CustomEpic = index runtime 27

La synchro utilise l'identité de qualité, pas seulement 12/27.

ItemQuality mapping

CE QUE ÇA FAIT

Une même qualité peut avoir des index runtime différents sur des serveurs avec mods ou registries différents.

COMPORTEMENT IMPORTANT

  • Si la destination connaît la qualité d'origine, elle est reconstruite correctement.
  • Si elle ne peut pas la résoudre, un fallback Common sûr est utilisé tout en conservant l'identité originale si possible.
  • Quand la qualité redevient disponible, elle peut être restaurée.

CHAPITRE 05 · 1 EXEMPLES

Diagnostics

Le mapping ItemQuality peut être journalisé lorsque deux serveurs ne résolvent pas les mêmes qualités.

01UTILISATION

Diagnostic du mapping

Avec des registries différents, les logs de mapping aident à comparer noms et index ItemQuality.

UTILISATION
Diagnostics de mapping ItemQuality
→ activer uniquement pour enquêter
→ comparer serveur A / serveur B
→ désactiver après le test

Diagnostics optionnels

CE QUE ÇA FAIT

Avec des registries différents, les logs de mapping aident à comparer noms et index ItemQuality.

COMPORTEMENT IMPORTANT

  • Les diagnostics servent à comprendre les différences de registry ; ils ne sont pas requis en fonctionnement normal.
  • Évitez de laisser un logging détaillé actif sans raison.
  • Cette page sera complétée avec les champs de configuration exacts lorsque le dépôt du mod sera réaligné.

Avant d'utiliser un exemple

L'objectif central est la sécurité du profil, pas la simple copie de slots.

La conservation ItemQuality est conçue précisément pour les réseaux ayant des registries différents.

Les schémas descriptifs seront remplacés par la configuration réelle lorsque le dépôt du mod sera réaligné.

RETOUR EN HAUT