GameHosting.pl

Notatki operatora

CoreProtect: cofanie griefów i logowanie zmian na serwerze Minecraft

Praktyczny przewodnik po CoreProtect, czyli pluginie, który zapisuje każdą zmianę na serwerze i pozwala cofnąć grief jedną komendą. Od tego, czym właściwie jest logowanie bloków, przez instalację i wybór bazy danych, po komendy inspect, lookup, rollback i restore oraz scenariusz cofania griefu krok po kroku. Z perspektywy kogoś, kto już raz odbudowywał spawn po nocnej wizycie griefera.

Opublikowano · ~9 min czytania

W skrócie: CoreProtect zapisuje, kto, kiedy i co postawił, zniszczył albo wyjął ze skrzyni. Klikasz blok inspektorem (/co inspect lub /co i), żeby zobaczyć historię miejsca, a grief cofasz komendą rollback z parametrami: /co rollback u:Nick t:1d r:10 cofa zmiany gracza Nick z ostatniej doby w promieniu 10 bloków. Plugin musi działać, zanim grief się wydarzy, cofa tylko to, co zdążył zapisać. Domyślnie używa lokalnej bazy SQLite, MySQL jest opcjonalny. Jeśli nie chcesz ręcznie wgrywać pluginów, weź hosting z gotową obsługą wtyczek.

Czym jest CoreProtect i po co go używać

CoreProtect to plugin Bukkit (działa na Spigot i Paper), który robi jedną rzecz, ale robi ją bardzo dobrze: loguje zmiany na serwerze. Każde postawienie i zniszczenie bloku, otwarcie skrzyni, wyjęcie przedmiotu, zabicie moba czy wpisana komenda trafiają do bazy danych z dokładnym znacznikiem czasu i nickiem gracza. Dzięki temu masz dwa narzędzia w jednym:

Najważniejsza rzecz do zapamiętania, zanim na nią wpadniesz w praktyce: CoreProtect cofa wyłącznie to, co sam zarejestrował. To rejestrator, nie wehikuł czasu. Jeśli wgrasz go dopiero po pierwszej awarii, nie cofnie zniszczeń, które wydarzyły się wcześniej, bo nie ma ich w bazie. Dlatego CoreProtect wgrywa się na samym początku, razem z pierwszym uruchomieniem serwera, a nie reaktywnie po incydencie.

Instalacja na Paper lub Spigot

CoreProtect to zwykły plugin Bukkit, więc instalacja wygląda znajomo, jeśli wgrywałeś już jakąkolwiek wtyczkę. W przeciwieństwie do WorldGuard nie ma żadnej zależności, działa samodzielnie.

  1. Sprawdź wersję serwera. Ustal, na jakiej wersji Minecraft chodzi serwer (na przykład 1.20.x czy 1.21.x). Pobierz wersję CoreProtect przeznaczoną dla tego zakresu, niezgodna wersja to najczęstszy powód, że plugin się nie ładuje.
  2. Pobierz plik .jar. CoreProtect bierzesz z oficjalnego źródła (strona projektu PlayPro / SpigotMC). To jeden gotowy plik .jar, nie rozpakowujesz go.
  3. Wrzuć do folderu plugins. Skopiuj plik do katalogu plugins/ na serwerze.
  4. Zrestartuj serwer. Przy pierwszym starcie CoreProtect utworzy folder plugins/CoreProtect/ z plikiem config.yml oraz lokalną bazą danych SQLite (plik database.db). W logu konsoli pojawi się informacja, że plugin wstał i zaczął logować.
  5. Zweryfikuj komendą. Wejdź na serwer i wpisz /co status, zobaczysz wersję pluginu i informacje o stanie. Od tej chwili wszystko, co dzieje się na mapie, jest zapisywane.

Baza danych: SQLite domyślnie, MySQL opcjonalnie

Domyślnie CoreProtect używa lokalnej bazy SQLite i dla pojedynczego serwera to optymalny wybór, nie wymaga żadnej konfiguracji ani osobnego serwera bazy. W pliku config.yml odpowiada za to opcja use-mysql ustawiona domyślnie na false.

MySQL ma sens głównie wtedy, gdy chcesz współdzielić dane logowania między wieloma serwerami (na przykład sieć serwerów) albo trzymać bazę na osobnej maszynie. Wtedy w config.yml ustawiasz:

Dla typowego serwera ze znajomymi nie ruszaj tego, SQLite zrobi swoje. MySQL dokłada warstwę, którą trzeba utrzymać.

Kluczowe komendy z przykładami

Wszystkie komendy CoreProtect zaczynają się od /co (lub pełnego /coreprotect). Najpierw same komendy, potem najczęściej używane parametry.

/co inspect, czyli kto tu był (skrót /co i)

To pierwsze narzędzie, po które sięgasz przy zgłoszeniu griefu. Wpisujesz /co inspect albo skrótem /co i, żeby włączyć tryb inspektora. Teraz:

Inspektor wyłączasz, wpisując komendę ponownie (/co i). To tryb przełączany: włącz, poklikaj, wyłącz.

/co lookup, czyli przeszukanie logów

Lookup (/co lookup lub skrótem /co l) przeszukuje bazę bez klikania bloków, na podstawie parametrów. Przykłady:

Lookup zawsze rób przed rollbackiem, to podgląd tego, co rollback miałby zmienić. Pokrewny skrót /co near wykonuje szybki lookup w promieniu 5 bloków dookoła.

/co rollback, czyli cofnięcie zmian

Rollback (/co rollback lub skrótem /co rb) cofa zmiany do stanu sprzed griefu. Najważniejsza komenda w całym pluginie:

/co restore, czyli odwrócenie rollbacku

Restore (/co restore lub skrótem /co rs) jest operacją odwrotną do rollbacku: ponownie nakłada zmiany, które wcześniej cofnąłeś. Przydaje się, gdy rollback objął za szeroki obszar lub za długi czas. Składnia parametrów jest taka sama jak przy rollbacku, na przykład /co restore u:Nick t:1d r:10. Do szybkiego odwrócenia ostatniej operacji jest jeszcze prostszy skrót /co undo.

/co purge, czyli sprzątanie bazy

Z czasem baza CoreProtect rośnie, bo trzyma całą historię. Purge (/co purge) usuwa stare zapisy, żeby utrzymać ją w rozsądnym rozmiarze:

To operacja nieodwracalna, czyści dane logowania, nie dotyka samego świata. Dobry kompromis to trzymanie historii z kilku tygodni do kilku miesięcy, w zależności od tego, jak szybko reagujesz na zgłoszenia.

Parametry lookup i rollback

Te same parametry działają w lookup, rollback i restore. Łączysz je w jednej komendzie i to one decydują, jak precyzyjny będzie efekt.

ParametrZnaczeniePrzykład
u:Gracz (user), którego akcje bierzemy pod uwagę.u:Nick
t:Czas wstecz. Jednostki: w tydzień, d dzień, h godzina, m minuta, s sekunda. Można łączyć.t:1d, t:5d2h
r:Promień (radius) w blokach wokół Twojej pozycji.r:10
a:Typ akcji: block, +block (postawione), -block (zniszczone), container, item, click, kill, chat, command, session, sign.a:-block
i:Ogranicz do konkretnych bloków lub bytów (include).i:stone
e:Wyklucz konkretne bloki lub byty (exclude).e:tnt

Przykład złożony: /co rollback u:Nick t:1h i:stone a:-block r:10 cofnie tylko bloki kamienia zniszczone przez gracza Nick w ostatniej godzinie, w promieniu 10 bloków. Im węższe parametry, tym bezpieczniejszy rollback.

Cofanie griefu krok po kroku

Typowy scenariusz: ktoś zgłasza, że na spawnie zniknął fragment budynku albo opróżniono skrzynie. Tak to ogarniasz spokojnie i bez psucia czyjejś legalnej pracy:

  1. Włącz inspektora i zlokalizuj sprawcę. Wpisz /co i i kliknij lewym przyciskiem na zniszczone albo podejrzane bloki. Zobaczysz nick gracza i czas akcji. Zanotuj nick i mniej więcej, jak dawno to było.
  2. Sprawdź zakres lookupem. Stań w centrum zniszczeń i zrób podgląd, na przykład /co lookup u:Nick t:6h r:20. Zobaczysz listę wszystkiego, co ten gracz narobił w ostatnich 6 godzinach w promieniu 20 bloków. Tu oceniasz, czy to faktycznie grief, czy ktoś po prostu rozbudowywał teren.
  3. Wykonaj rollback z tymi samymi parametrami. Gdy zakres się zgadza, zamień lookup na rollback: /co rollback u:Nick t:6h r:20. CoreProtect odbuduje zniszczone bloki i usunie te, które griefer dostawił.
  4. Zweryfikuj efekt na miejscu. Rozejrzyj się: budynek powinien wrócić do stanu sprzed griefu. Jeśli coś się nie zgadza, masz dwie drogi wyjścia.
  5. W razie potrzeby odwróć operację. Jeśli rollback objął za dużo (na przykład cofnął też czyjąś legalną budowę), wykonaj /co restore z tymi samymi parametrami albo szybkie /co undo, a potem powtórz rollback z węższym zakresem (krótszy t:, mniejszy r: lub dodany a:-block).

Z doświadczenia: zawsze rób /co lookup przed /co rollback z dokładnie tymi samymi parametrami. Lookup to próba na sucho, pokazuje, co rollback zmieni, zanim cokolwiek ruszysz w świecie. Najczęstszy błąd początkujących to rollback bez parametru r:, który cofa zmiany gracza na całej mapie, łącznie z jego legalnymi budowlami sprzed griefu.

Dobre praktyki

Uprawnienia: kto może klikać i cofać

Komendy CoreProtect są mocne, rollback potrafi zmienić sporo terenu, więc nie dawaj ich wszystkim. Dostęp do /co inspect, /co lookup i zwłaszcza /co rollback zostaw zaufanej kadrze (administracja, moderatorzy). Najwygodniej rozdzielić uprawnienia per komenda przez plugin uprawnień, na przykład LuckPerms, i nadać poszczególnym rangom tylko to, czego naprawdę potrzebują. Zwykły gracz nie powinien móc cofać niczego.

Wydajność i rozmiar bazy

Samo logowanie jest tanie, prawdziwy koszt to rosnąca baza i ciężkie rollbacki na wielkim obszarze. Trzy nawyki, które trzymają to w ryzach:

Czas przechowywania historii

Nie ma jednej dobrej wartości. Im dłużej trzymasz historię, tym dalej wstecz cofniesz grief, ale tym większa baza. Praktyczny kompromis dla małego i średniego serwera to historia z kilku tygodni do około miesiąca. Jeśli zwykle reagujesz na zgłoszenia w ciągu doby lub dwóch, krótsza retencja w zupełności wystarczy.

Najczęstsze pytania

Czy CoreProtect cofa zniszczenia po fakcie, czy trzeba go włączyć wcześniej?

CoreProtect cofa tylko to, co zarejestrował, więc musi działać, zanim grief się wydarzy. To rejestrator zmian: od chwili instalacji zapisuje, kto, kiedy i co zrobił, i dopiero na tej podstawie cofa zmiany. Griefu sprzed instalacji nie odwróci. Wgrywaj go od razu na nowym serwerze.

Jaką bazę wybrać: SQLite czy MySQL?

Dla pojedynczego serwera zostań przy domyślnym SQLite (use-mysql: false), nie wymaga konfiguracji. MySQL włączasz tylko, gdy chcesz współdzielić dane między serwerami lub trzymać bazę osobno: ustawiasz use-mysql: true i dane połączenia (mysql-host, mysql-port, mysql-database, mysql-username, mysql-password).

Jak cofnąć grief jednego gracza z ostatniej doby?

Stań blisko zniszczeń i wpisz /co rollback u:Nick t:1d r:10, czyli cofnij zmiany gracza Nick z ostatniej doby w promieniu 10 bloków. Wcześniej zrób /co lookup z tymi samymi parametrami, żeby zobaczyć zakres.

Czym różni się rollback od restore?

Rollback cofa zmiany do stanu sprzed zdarzenia (odbudowuje zniszczone bloki). Restore robi operację odwrotną: ponownie nakłada cofnięte zmiany, służy do naprawy zbyt szerokiego rollbacku. Do szybkiego odwrócenia ostatniej operacji jest skrót /co undo.

Czy CoreProtect mocno obciąża serwer?

Samo logowanie jest szybkie. Realny koszt to rozmiar bazy i ciężkie rollbacki na dużym obszarze. Bazę czyścisz komendą /co purge t:30d, a rollbacki zawężaj parametrami r: i t:, zamiast cofać całą mapę naraz.

Powiązane