Quand il manque un mur dans le monde de votre bande d'amis, CoreProtect peut retrouver précisément les modifications enregistrées et en annuler une partie. Commence par examiner le dégât concerné et la zone correspondante. Un grand rollback lancé sur un simple soupçon peut aussi toucher des modifications voulues.
Ce guide présente une petite réparation de blocs. Il ne prétend pas que toute progression ultérieure soit automatiquement conservée lors de chaque intervention. Sur un même emplacement en particulier, les modifications récentes et anciennes peuvent s'influencer mutuellement. Un état de départ sauvegardé reste indispensable.
Vérifié le 7 octobre 2026. Les images montrent une démonstration antérieure avec Paper 1.21.1 et CoreProtect 24.0. Elles ne constituent pas un nouveau test de votre monde ni une mesure d'exécution actuelle.
Documenter le dégât avant une réparation
Note le monde, les coordonnées et la période connue. Demande aux amis concernés si l'on a volontairement continué à construire à cet endroit entre-temps. Arrêtez les modifications dans la petite zone touchée pendant la vérification ; une zone modifiée en même temps est plus difficile à évaluer.
Sauvegarde l'état actuel du monde et les données réelles de CoreProtect avant de planifier une intervention en écriture. Si la base de données est externe, une copie du dossier du plugin ne constitue pas à elle seule une sauvegarde complète. Le petit stockage Free de 10 Go doit aussi accueillir le monde, les logs et les extensions ; conserve une copie indépendante en dehors de cet essai.
CoreProtect doit déjà avoir enregistré l'événement en question. Une installation après le dégât ne crée aucun ancien historique. Vérifie la version chargée, le fonctionnement à l'époque et les enregistrements réellement activés. L'aperçu de la configuration mène à la configuration adaptée à votre version. Un indicateur de serveur au vert ne prouve pas que chaque action souhaitée a été journalisée.
D'abord observer, ne pas restaurer tout de suite
Un compte d'assistant prévu à cet effet peut examiner l'endroit touché avec l'Inspector. Pour cela, on utilise /co inspect ; la même fonction peut ensuite être désactivée à nouveau. Utilise l'aide à l'utilisation affichée dans ta version et lis les événements à l'endroit réel du dégât.
Un nom de compte dans le journal ne prouve aucune intention. Une action accidentelle, un compte partagé ou d'autres circonstances doivent éventuellement être clarifiés. Ne partage les résultats qu'avec les personnes concernées et masque les noms sur les images publiques. Pour la réparation, ce qui compte d'abord, c'est de savoir quelle modification a été enregistrée.
Démonstration antérieure sur la façade d'une maison. L'heure, le type de bloc et le lieu aident au recoupement ; les noms de comptes sont masqués. Cette sortie n'est pas un résultat de recherche de votre monde.
Ne donne pas coreprotect.* à la légère à un assistant qui doit seulement vérifier. D'après les permissions de CoreProtect, l'inspection, le rollback, le restore et la suppression des journaux sont des autorisations distinctes. Pour une mission de lecture convenue, coreprotect.inspect et coreprotect.lookup entrent en ligne de compte ; vérifie aussi les catégories de données souhaitées. Les amis ordinaires n'ont pas besoin de droits de réparation pour jouer. Vous configurez les rôles avec LuckPerms.
Limiter la recherche à votre cas
L'exemple de jeu suivant ne convient qu'à un petit dégât de blocs observé récemment. Remplace SPIELERNAME par le compte identifié avec certitude. Vérifie la période et la distance pour ton cas réel avant d'utiliser la commande :
/co lookup u:SPIELERNAME t:30m r:8 a:-block
| Limite | Signification dans l'exemple |
|---|---|
| Compte | Uniquement le compte de jeu vérifié et identifié |
| Durée | Événements des 30 dernières minutes |
| Lieu | Rayon de 8 autour de ta position de jeu actuelle |
| Action | Destruction de blocs enregistrée |
Lis tous les résultats correspondants et les coordonnées. Si la liste reste vide, vérifie les hypothèses de départ une par une au lieu de lancer directement une réparation à l'échelle du monde. Un rayon de recherche plus grand peut montrer d'autres événements, mais ce n'est pas encore une autorisation de tous les annuler.
La référence officielle des commandes décrit les filtres et l'aperçu. Lookup et rollback ont des limites par défaut différentes lorsque des indications manquent. Dans l'exemple, le rayon est donc défini explicitement. Ne te fie pas à l'ancienne affirmation générale selon laquelle tout rollback sans rayon touche automatiquement le monde entier.
Comparer l'aperçu et la petite intervention
Reste dans le même monde, à la même position. Avec vos filtres confirmés, vérifie d'abord un aperçu :
/co rollback u:SPIELERNAME t:30m r:8 a:-block #preview
Examinez ensemble l'endroit touché et les modifications voisines voulues. Si l'aperçu ne correspond pas exactement à la réparation prévue, abandonnez l'essai par la voie prévue dans votre version et revérifiez les filtres. Un aperçu ne remplace ni la sauvegarde ni le contrôle de l'effet réel.
Une fenêtre de temps relative avance entre deux appels. Votre position doit aussi rester la même si le rayon en dépend. « Mêmes paramètres » ne signifie donc pas automatiquement un instantané historique inchangé. N'exécutez la petite commande finale qu'après un nouveau recoupement :
/co rollback u:SPIELERNAME t:30m r:8 a:-block
L'implémentation actuelle du rollback contient des vérifications supplémentaires et le traitement de l'intervention. Les fonctions disponibles dépendent de la version réellement installée chez vous. N'adopte pas comme garantie générale un prétendu filet de sécurité tiré d'un ancien guide.
À l'époque : six blocs répartis sur deux chunks, rayon 15 et fenêtre de temps d'une minute. Il s'agit d'un autre test documenté que les valeurs d'exemple volontairement modestes de cet article.
Vérifier l'état du jeu après la réparation
Ne te contente pas du message de réussite. Contrôlez le mur, les éléments de construction voisins et la progression souhaitée depuis. Faites attention à ce que le filtre de blocs choisi ne couvre pas du tout : le contenu des coffres, les inventaires et d'autres actions sont des catégories de données à part. N'étendez pas l'intervention à toutes les catégories sans y penser.
L'image montre la zone restaurée à l'époque. Elle ne prouve pas que tout effet secondaire possible d'un rollback est exclu.
Si l'intervention était erronée, un restore correctement limité peut réappliquer les modifications enregistrées. Prévois pour cela d'abord le même examen minutieux et un aperçu. N'envoyez pas plusieurs commandes inverses de grande ampleur à la suite. Si des données manquent ou si l'effet reste flou, il reste le retour en arrière sauvegardé et une clarification concrète de la situation.
Ne supprimez pas d'anciens journaux pendant un dégât non élucidé, simplement pour libérer de l'espace. Les événements supprimés ne sont plus disponibles pour de futures questions de recherche ou de réparation. La durée de conservation est une décision d'exploitation distincte et non une condition préalable à cette petite intervention.
Limiter les futurs dégâts
Convenez de qui peut effectuer les réparations et de la façon dont les amis concernés sont informés. Une petite réparation documentée est plus facile à vérifier qu'une restauration générale de toute la soirée. Pour les zones durablement importantes, mettez en place une protection WorldGuard ciblée.
CoreProtect, la protection de régions et la sauvegarde remplissent des tâches différentes. Vous n'avez pas besoin de faire de chaque ami un administrateur pour les utiliser tous les trois de façon judicieuse. Testez la fonction de journalisation assez tôt avec un petit essai de blocs à vous, afin de ne pas vous contenter de supposer qu'elle enregistre le jour où ce sera nécessaire.
FAQ
Une installation après le dégât sert-elle à quelque chose ?
Elle enregistre les futurs événements correspondants. Pour un dégât antérieur, sans enregistrement à l'époque, les données historiques nécessaires manquent. Vérifie les sauvegardes existantes et d'autres indices avérés.
Pourquoi le lookup est-il vide ?
Vérifie séparément le monde, la position, la période, le compte, l'action et l'enregistrement de l'époque. L'absence de résultats n'est pas une raison pour lancer un rollback global non vérifié.
Toutes les nouvelles constructions sont-elles conservées à coup sûr ?
Ce n'est pas une garantie générale. Même une intervention limitée peut influencer des modifications ultérieures voulues au même endroit. Vérifie l'aperçu, les filtres et la progression voisine.
La commande présentée répare-t-elle aussi un coffre vidé ?
Le déroulé d'exemple est limité à la destruction de blocs. Le contenu des coffres nécessite une action enregistrée à part et un processus de vérification distinct, soigneusement limité.
L'assistant en lecture a-t-il besoin de rollback et de purge ?
Non. Ce sont des permissions distinctes. Examine la tâche de lecture concrète et n'accorde pas de wildcard d'administration générale uniquement pour consulter des résultats.
CoreProtect remplace-t-il l'état sauvegardé du monde ?
Non. Une base de données d'événements et une copie du monde résolvent des problèmes différents. Les fichiers endommagés, les mondes supprimés et les opérations non enregistrées nécessitent un autre retour en arrière.
CoreProtect: Voir l'exemple
Captures réalisées dans un environnement de démonstration. La version et la configuration présentées peuvent différer de celles de ton serveur.
- La façade de la maison est intacte.
- Un deuxième joueur retire des blocs.
- /co lookup indique qui a extrait quoi.
- /co rollback restaure la façade.
CoreProtect 24.0 · Paper 1.21.1 · 2026-09-14
CoreProtect 24.0 · Paper 1.21.1 · 2026-09-14
CoreProtect 24.0 · Paper 1.21.1 · 2026-09-14
CoreProtect 24.0 · Paper 1.21.1 · 2026-09-14