Avant de commencer
Vous devez administrer le monde et disposer de ses fichiers. Vérifiez d’abord que votre service permet les processus et allocations nécessaires : une offre DST ne confirme pas l’inclusion automatique de deux shards. Conservez une sauvegarde et demandez confirmation des ports avant de commencer.
Définir un cluster plutôt que deux mondes isolés
Master désigne habituellement la surface et Caves le monde souterrain. Ils appartiennent au même cluster, mais tournent dans des processus séparés. Préparez le mode de jeu, les règles PvP éventuelles, les accès et les réglages de génération avant de créer un monde. Changer un paramètre de génération ne reconstruit pas automatiquement les zones déjà sauvegardées. Relevez la version de jeu et les mods utilisés par le groupe.
Repérer les fichiers sans imposer un chemin universel
Le répertoire de stockage dépend de la plateforme et des options de lancement. Dans le dossier du cluster, cluster.ini contient les paramètres partagés. Chaque shard possède son server.ini, par exemple Master/server.ini et Caves/server.ini. Les réglages du monde et de ses mods doivent correspondre au shard concerné. Conservez la structure existante et une copie des fichiers avant modification ; une arborescence d’exemple n’est pas une raison de déplacer des données actives.
Créer le token Klei et séparer les secrets
Depuis le compte Klei, utilisez la gestion officielle des serveurs pour générer votre token. Le fichier cluster_token.txt sert à l’authentification du cluster ; gardez-le privé et hors des captures partagées. Il ne faut pas le confondre avec la clé interne de communication entre shards. Cette clé doit être cohérente entre les parties concernées, mais ce n’est ni le mot de passe du compte Klei ni celui des joueurs.
Faire valider les processus et les ports attribués
La documentation Klei montre deux lancements avec le même nom de cluster et des paramètres -shard Master et -shard Caves distincts. Chaque processus doit avoir des ports de jeu et Steam compatibles avec ses allocations et différents lorsque nécessaire. Faites confirmer la communication inter-shards et les valeurs à utiliser par le service. Ne recopiez pas les ports d’un autre hébergeur, ne lancez pas une deuxième instance non prévue et ne modifiez pas le réseau de la machine hôte.
Introduire les mods sans casser la traversée
Séparez les mods client et les mods qui doivent être chargés par le serveur. Consultez la fiche Workshop de chaque mod, ses dépendances et sa version compatible. Vérifiez les fichiers de préparation et de configuration de mods utilisés par la version DST, puis appliquez les réglages aux shards concernés. Ajoutez un seul mod à la fois. Testez l’entrée sur la surface, le passage dans une caverne, le retour et le comportement des personnages avant d’ouvrir au groupe.
Sauvegarder et restaurer l’ensemble de façon cohérente
Prévenez les joueurs et interrompez les écritures des deux processus avant une copie cohérente. Conservez Master, Caves, les fichiers communs et la configuration des mods ensemble, avec une date et la version. Une copie de la surface seule ne représente pas le cluster complet : restaurer des parties à des dates différentes peut désynchroniser progression et objets. Gardez une copie hors du serveur. Après restauration, vérifiez connexion, traversée et persistance avant de reprendre la session.
Selon votre situation
| Situation | Prochaine vérification |
|---|---|
| La surface fonctionne sans cavernes | Vérifiez le support du deuxième processus, ses fichiers et sa communication avant d’ajouter des mods. |
| Le passage souterrain échoue | Comparez journaux, allocations et configurations des deux shards sans divulguer les clés. |
| Le cluster doit être restauré | Utilisez une copie coordonnée des deux mondes et des paramètres communs. |
Sources officielles
Ces documents décrivent les protocoles et logiciels concernés. Les conditions de votre service et sa configuration restent à vérifier.