Dépannage
- Dernière version
- 1.7.4
- Minecraft
- 26.x
- Plateformes
- Spigot, Paper, Folia, Purpur, Velocity, BungeeCord
- Version minimale de Java
- 25+
Cet article a été rédigé pour 1.7.0. La dernière version stable est 1.7.4 ; consultez les prérequis actuels ci-dessus.
Dépannage
Commencez par la console backend et
Le plugin ne démarre pas ou une classe manque
Vérifiez les prérequis d’Installation et utilisez la distribution Universal. Des erreurs HikariCP ou JDBC peuvent signaler un JAR de module incomplet ou un build endommagé. Remplacez-le par le Universal JAR complet et supprimez les doublons ; ne copiez pas de bibliothèques au hasard dans plugins.
Erreur MySQL de connexion ou de session
Vérifiez hôte, port, base, identifiants, droits, réseau et SSL depuis chaque backend. Les ID actifs dupliqués et réglages sync/groupes/admin différents sont refusés. Un backend arrêté brutalement peut conserver un verrou jusqu’à expiration. Corrigez la cause plutôt que désactiver restore-on-join ou kick-on-failure ; MySQL exige les deux.
Les mauvais mondes ou serveurs partagent des objets
Vérifiez sync.mode et le profil résolu. GLOBAL partage tout ; PER_WORLD partage les noms normalisés identiques, même entre serveurs. En PER_GROUP, une correspondance serveur remplace toutes celles de ses mondes. Gardez les listes identiques, redémarrez après modification et sauvegardez avant de réattribuer des données existantes.
Un nouveau profil commence vide
C’est normal lors d’un changement vers un profil absent : l’ancien est sauvegardé, puis l’inventaire manquant et les données coffre de l’Ender/XP activées commencent vides. Une connexion sans données enregistrées utilise l’état actuel. Vérifiez la correspondance avant toute modification ou récupération.
Joueur ou profil introuvable
Utilisez nom exact ou UUID. Les noms sont enregistrés à la connexion. Pour d’anciennes données hors ligne, essayez UUID et profil de base explicite. Le profil demandé d’un joueur en ligne doit être celui actif. Sans profil, les commandes hors ligne prennent le dernier enregistré pour ce type.
Éditeur en lecture seule ou sauvegarde refusée
Vérifiez droit de commande, .edit et, à distance, .remote-edit. Vérifiez aussi admin.allow-offline-view, admin.allow-offline-edit et admin.allow-remote-edit selon le cas. Le joueur peut synchroniser, avoir changé de profil ou de données. Actualisez avant une nouvelle modification.
Commandes coffre de l’Ender ou XP désactivées
Vérifiez sync.ender-chest ou sync.xp et redémarrez après activation. Désactiver la synchronisation désactive aussi l’outil de ce type. Pour permettre consultation sans édition, utilisez permissions et interrupteurs admin.
Les modifications disparaissent à la fermeture
Fermer et Cancel abandonnent volontairement les brouillons non sauvegardés. Utilisez Save et attendez la confirmation. Refresh abandonne aussi le brouillon. Les objets sélectionnés sont des copies administratives ; ce n’est pas une fenêtre de transfert classique.
Conflit, expiration ou sauvegarde incertaine
Un conflit indique que les données d’origine ont changé. Actualisez, examinez puis préparez une nouvelle modification. Après expiration ou sauvegarde incertaine, vérifiez les données avant de répéter, surtout pour ajouter/retirer de l’XP. Contrôlez la base et la session du backend propriétaire.
Pont proxy désactivé ou messages refusés
Activez-le sur proxy et backends, utilisez MYSQL, faites correspondre exactement les ID aux noms enregistrés et partagez le même secret valide. Vérifiez allowed-servers, protocoles, horloges et compteurs. Les messages exigent une connexion joueur active au backend cible ; les backends vides ne reçoivent pas d’anciennes requêtes en file. L’administration distante actuelle par base n’exige pas le pont.
Le pont authentifie par HMAC-SHA256 et refuse les messages expirés ou rejoués. L’authentification ne chiffre pas le contenu. Gardez le secret privé ; utilisez au moins 32 caractères aléatoires dans la plage 16–256. Un nombre élevé de refus peut aussi indiquer le budget par backend ; vérifiez la cause avant de le modifier.
Les réglages modifiés ne s’appliquent pas
Redémarrez après modification manuelle du backend. /isync reload applique les messages après validation, pas stockage ni synchronisation. Le GUI applique immédiatement ses interrupteurs. Utilisez /isyncproxy reload pour proxy.properties ; des réglages proxy ou un YAML de messages invalides conservent l’ancienne configuration.
Sauvegarde indisponible
La commande intégrée fonctionne uniquement avec SQLite. Pour MySQL, utilisez les outils de base. Avec SQLite, vérifiez console, droits d’écriture et espace disque. Sauvegardez la configuration séparément. Consultez Mises à jour et sauvegardes pour la récupération.
Commencez par la console backend et
/isync status. Avec le pont, consultez aussi la console proxy et /isyncproxy status. Gardez l’erreur complète et le backend/profil concerné pour demander de l’aide ; masquez mots de passe et secrets.Le plugin ne démarre pas ou une classe manque
Vérifiez les prérequis d’Installation et utilisez la distribution Universal. Des erreurs HikariCP ou JDBC peuvent signaler un JAR de module incomplet ou un build endommagé. Remplacez-le par le Universal JAR complet et supprimez les doublons ; ne copiez pas de bibliothèques au hasard dans plugins.
Erreur MySQL de connexion ou de session
Vérifiez hôte, port, base, identifiants, droits, réseau et SSL depuis chaque backend. Les ID actifs dupliqués et réglages sync/groupes/admin différents sont refusés. Un backend arrêté brutalement peut conserver un verrou jusqu’à expiration. Corrigez la cause plutôt que désactiver restore-on-join ou kick-on-failure ; MySQL exige les deux.
Les mauvais mondes ou serveurs partagent des objets
Vérifiez sync.mode et le profil résolu. GLOBAL partage tout ; PER_WORLD partage les noms normalisés identiques, même entre serveurs. En PER_GROUP, une correspondance serveur remplace toutes celles de ses mondes. Gardez les listes identiques, redémarrez après modification et sauvegardez avant de réattribuer des données existantes.
Un nouveau profil commence vide
C’est normal lors d’un changement vers un profil absent : l’ancien est sauvegardé, puis l’inventaire manquant et les données coffre de l’Ender/XP activées commencent vides. Une connexion sans données enregistrées utilise l’état actuel. Vérifiez la correspondance avant toute modification ou récupération.
Joueur ou profil introuvable
Utilisez nom exact ou UUID. Les noms sont enregistrés à la connexion. Pour d’anciennes données hors ligne, essayez UUID et profil de base explicite. Le profil demandé d’un joueur en ligne doit être celui actif. Sans profil, les commandes hors ligne prennent le dernier enregistré pour ce type.
Éditeur en lecture seule ou sauvegarde refusée
Vérifiez droit de commande, .edit et, à distance, .remote-edit. Vérifiez aussi admin.allow-offline-view, admin.allow-offline-edit et admin.allow-remote-edit selon le cas. Le joueur peut synchroniser, avoir changé de profil ou de données. Actualisez avant une nouvelle modification.
Commandes coffre de l’Ender ou XP désactivées
Vérifiez sync.ender-chest ou sync.xp et redémarrez après activation. Désactiver la synchronisation désactive aussi l’outil de ce type. Pour permettre consultation sans édition, utilisez permissions et interrupteurs admin.
Les modifications disparaissent à la fermeture
Fermer et Cancel abandonnent volontairement les brouillons non sauvegardés. Utilisez Save et attendez la confirmation. Refresh abandonne aussi le brouillon. Les objets sélectionnés sont des copies administratives ; ce n’est pas une fenêtre de transfert classique.
Conflit, expiration ou sauvegarde incertaine
Un conflit indique que les données d’origine ont changé. Actualisez, examinez puis préparez une nouvelle modification. Après expiration ou sauvegarde incertaine, vérifiez les données avant de répéter, surtout pour ajouter/retirer de l’XP. Contrôlez la base et la session du backend propriétaire.
Pont proxy désactivé ou messages refusés
Activez-le sur proxy et backends, utilisez MYSQL, faites correspondre exactement les ID aux noms enregistrés et partagez le même secret valide. Vérifiez allowed-servers, protocoles, horloges et compteurs. Les messages exigent une connexion joueur active au backend cible ; les backends vides ne reçoivent pas d’anciennes requêtes en file. L’administration distante actuelle par base n’exige pas le pont.
Le pont authentifie par HMAC-SHA256 et refuse les messages expirés ou rejoués. L’authentification ne chiffre pas le contenu. Gardez le secret privé ; utilisez au moins 32 caractères aléatoires dans la plage 16–256. Un nombre élevé de refus peut aussi indiquer le budget par backend ; vérifiez la cause avant de le modifier.
Les réglages modifiés ne s’appliquent pas
Redémarrez après modification manuelle du backend. /isync reload applique les messages après validation, pas stockage ni synchronisation. Le GUI applique immédiatement ses interrupteurs. Utilisez /isyncproxy reload pour proxy.properties ; des réglages proxy ou un YAML de messages invalides conservent l’ancienne configuration.
Sauvegarde indisponible
La commande intégrée fonctionne uniquement avec SQLite. Pour MySQL, utilisez les outils de base. Avec SQLite, vérifiez console, droits d’écriture et espace disque. Sauvegardez la configuration séparément. Consultez Mises à jour et sauvegardes pour la récupération.