Gdzie naprawdę boli – typowe sytuacje na survivalu przed zmianą entity-activation-range
Serwer survival, TPS leci w dół i wszyscy patrzą na ciebie
Wyobraź sobie wieczór na survivalu: 20 osób online, kilka dużych baz, dwie farmy żelaza, jedna farma rajdów, kilka klasycznych mobgrinderów. Nagle ktoś na czacie pisze, że „moby gumują”, strzały cofają się do łuku, a pasek debug (/tps) pokazuje TPS w okolicach 15–17. Po sprawdzeniu timings widzisz, że największy udział w zużyciu czasu mają entity – setki mobów w farmach, villagerzy, golemy, raidy. Ktoś podsuwa radę: „Zmień entity-activation-range w Spigocie/Paper, to uratuje serwer”.
W tym momencie zaczyna się klasyczny dylemat admina survivalu: z jednej strony trzeba uratować TPS, z drugiej boisz się, że po zmianie konfiguracji przestaną działać farmy, villagerzy zaczną „głupieć”, a gracze techniczni rozniosą cię na Discordzie. Właśnie w takich sytuacjach bezpieczna optymalizacja entity-activation-range ma największy sens – ale tylko wtedy, gdy robisz to świadomie, krok po kroku.
Jak wyglądają lagi od entity w praktyce
Obciążenie ze strony entity zazwyczaj nie objawia się pojedynczym, nagłym skokiem lagów. Bardziej przypomina „ciężko chodzący” serwer, który zaczyna się dusić, gdy tylko kilka farm chodzi równocześnie. Najczęstsze symptomy:
TPS spada, gdy gracze włączają duże farmy żelaza, farmy rajdów lub masywne mobgrindery.
Przy większej liczbie graczy na mapie mspt (na Paper) rośnie powyżej 50 ms, a w timings widać, że największą część zjada entity tick.
Moby poruszają się nierówno („gumowe” ruchy, teleportowanie się w tył), strzały cofają się, a walki na miecze wydają się nieresponsywne.
Przy farmach villagerów NPC czasem długo reagują, wymiany lekko się przycinają, golemy spawnują się z opóźnieniem.
Jeśli obserwujesz tego typu problemy i widzisz wyraźny związek z liczbą entity na mapie, jesteś w idealnym miejscu, żeby zająć się entity-activation-range. Jeżeli jednak lagi pojawiają się głównie przy teleportach, autosave, generowaniu nowych chunków czy przy pluginach, szukanie winy tylko w activation-range może cię wyprowadzić na manowce.
Czego admin najczęściej się obawia po zmianach
Największy strach przy grzebaniu w entity-activation-range to „ukryte skutki uboczne” – coś przestaje działać, ale na początku trudno to skojarzyć z jedną konkretną wartością. Typowe obawy:
Farmy żelaza – golemy nie spawnują się, gdy gracz odchodzi kilka–kilkanaście bloków, villagerzy nie aktualizują stanów, panic mode nie włącza się poprawnie.
Rajdy – raiderzy „zamierają”, nie reagują z daleka, ścieżki do wioski głupieją, event staje się dziwnie łatwy albo bugujący.
Villagerzy – nie idą do stanowisk pracy, nie odświeżają trade’ów, nie rozmnażają się, farmy villagerów zaczynają zachowywać się nieprzewidywalnie.
Farmy expa i mobgrindery – moby zbyt szybko się „usypiają”, przestają się poruszać i spływać do komory zabijania, część farm działa tylko, gdy stoisz w konkretnym miejscu.
Zwierzaki i hodowla – zwierzęta nie rosną, nie idą za pszenicą z większej odległości, hodowla jest mniej wygodna.
Da się tego uniknąć, jeśli traktujesz konfigurację jak proces, a nie jednorazowe strzał w ciemno. Kluczowe jest ruszanie konkretnych grup entity małymi krokami, zamiast drastycznego obniżania wszystkiego naraz.
Mini checklista przed pierwszym dotknięciem entity-activation-range
Zanim otworzysz spigot.yml lub paper.yml, odpowiedz sobie na kilka krótkich pytań. To twoja osobista mapa do decyzji:
Ilu graczy średnio masz online? 2–10, 10–30, czy powyżej 30?
Jakie farmy i automaty dominują? jedna farma żelaza i prosty mobgrinder, czy raczej kilka rozbudowanych farm rajdów, mega-farmy zwierząt, gigantyczne mob swinery?
Jaki styl gry ma społeczność? casual survival, semi-vanilla z lekką techniką, czy wyraźnie techniczna ekipa, która lubi grzebać w mechanikach?
Kiedy pojawiają się lagi? przy dużej walce i eksploracji świata, czy raczej wtedy, gdy gracze siedzą w bazach z włączonymi farmami?
Czy TPS realnie spada poniżej 19–20? jeśli nie, być może entity-activation-range nie jest ci w ogóle potrzebne.
Jeśli po tej szybkiej analizie widzisz wyraźny związek między lagami a farmami i mobami, przejście do bezpiecznej optymalizacji entity-activation-range ma sens i może dać naprawdę zauważalny oddech serwerowi.
Źródło: Pexels | Autor: panumas nikhomkhai
Co naprawdę robi entity-activation-range i dlaczego aż tak wpływa na TPS
Aktywne vs uśpione entity – sedno mechaniki
Entity-activation-range steruje tym, które moby i inne entity są w danym momencie aktywne, a które są w pewnym sensie „uśpione”. Aktywne entity dostają pełne ticki AI – myślą, szukają ścieżek, reagują na otoczenie, walczą, biegają, śledzą graczy. Uśpione entity dostają ograniczoną liczbę ticków lub w ogóle są pomijane w części obliczeń, dzięki czemu serwer zużywa na nie dużo mniej CPU.
Serwer decyduje o tym, czy dane entity jest aktywne, głównie na podstawie odległości od najbliższego gracza i przypisanego dla tej grupy promienia aktywacji (w blokach). Jeśli mob jest bliżej niż ustawiony zasięg, działa w pełni. Jeśli dalej – jest „przycinany” lub całkiem usypiany, w zależności od konkretnej implementacji silnika.
Co dokładnie jest wyłączane lub ograniczane
Gdy entity znajduje się poza zakresem aktywacji, silnik może ograniczyć mu:
AI i ruch – mob przestaje chodzić losowo, przestaje szukać wrogów, nie goni gracza z daleka, „stoi w miejscu”.
Pathfinding – najcięższy element dla CPU: obliczanie ścieżek po blokach, uwzględnianie schodków, dziur, przeszkód.
Część ticków logiki – część interakcji, aktualizacji stanu, wewnętrznych liczników jest wykonywana rzadziej lub pomijana.
Specyficzne mechaniki – np. pewne zachowania villagerów (szukanie łóżek, stołów roboczych), niektóre eventy rajdów, reakcje zwierząt na gracza.
Blokowanie lub ograniczanie tych mechanizmów dla setek mobów przynosi ogromny zysk wydajnościowy. Zamiast liczyć skomplikowane ścieżki dla 300 zombie w farmach, serwer faktycznie przetwarza w pełni tylko te, które są blisko graczy. Właśnie dlatego manipulacja entity-activation-range tak mocno wpływa na TPS, zwłaszcza na publicznych survivalach z rozbudowaną automatyką.
Różnica względem view-distance i simulation-distance
Często myli się entity-activation-range z ustawieniami view-distance lub simulation-distance. To trzy różne rzeczy:
view-distance – ile chunków gracz widzi (wczytanych wizualnie).
simulation-distance (od nowszych wersji MC) – ile chunków jest symulowanych pod względem mechanik (redstone, wzrost roślin, itp.).
entity-activation-range – jak daleko od gracza entity nadal liczone są w pełnej logice AI.
Możesz mieć wysoki view-distance, ale mocno ścięty entity-activation-range – gracz zobaczy daleko, ale moby daleko od niego będą prawie uśpione. Możesz też mieć niską simulation-distance, a nadal dużo aktywnych mobów w małym obszarze. Stąd wniosek: entity-activation-range nie zmienia liczby wczytanych chunków, tylko głębokość logiki, jaką serwer wykonuje dla żywych obiektów w ich obrębie.
Dlaczego to działa tak dobrze na obciążone serwery survival
Na typowym serwerze survivalowym wąskim gardłem jest CPU. Gdy gracze stawiają kolejne farmy, mobgrindery i wioski villagerów, liczba aktywnych entity rośnie lawinowo. Każdy z tych mobów uruchamia swoje AI co tick – nawet jeśli stoi w komorze farmy i tak naprawdę nie musi „myśleć”.
Optymalizacja entity-activation-range działa jak inteligentne odcięcie zbędnego myślenia. Moby w farmach, do których nikt nawet nie podchodzi, przestają liczyć ścieżki, a villagerzy w odległej bazie nie szukają co sekundę stołu roboczego i łóżka. Dzięki temu:
mspt spada, bo serwer przelicza mniej skomplikowanych akcji w każdym ticku,
TPS stabilizuje się nawet przy większej liczbie graczy,
większa część mocy CPU zostaje dla aktywnej walki, eksploracji i faktycznej rozgrywki.
Dobra wiadomość: ten efekt można osiągnąć bez zabijania farm – o ile rozumiesz, które grupy entity możesz bezpiecznie ciąć mocniej, a które wymagają szerszego zakresu aktywacji.
Różnice w konfiguracji Spigot vs Paper – gdzie szukać i co widzisz w configu
Gdzie leży konfiguracja entity-activation-range
Podstawowe miejsce, które cię interesuje na Spigocie, to plik spigot.yml w katalogu głównym serwera. Szukasz w nim sekcji:
entity-activation-range:
...
Na Paper konfiguracja jest rozbita nieco inaczej, zależnie od wersji. Najczęściej kluczowe opcje znajdziesz w paper.yml lub w nowszych wersjach w paper-global.yml. Szukaj sekcji opisanych komentarzami w stylu „entity activation range”, „activation range” lub „entity settings”. Nazwy konkretnych kluczy i ich układ mogą się nieco różnić między wersjami 1.16, 1.18, 1.19, 1.20, dlatego za każdym razem warto przeczytać komentarze w samym configu.
Zanim ruszysz jakąkolwiek wartość, zrób prosty krok bezpieczeństwa: skopiuj aktualny spigot.yml i paper.yml/paper-global.yml do osobnego folderu. Dzięki temu każdą nieudaną próbę możesz błyskawicznie cofnąć.
Spigot – prosty model trzech głównych grup
W spigot.yml najczęściej zobaczysz uproszczony podział na kilka grup, np.:
To przykładowy układ – w twojej wersji część z tych kluczy może wyglądać nieco inaczej, ale idea pozostaje taka sama. Dla każdej grupy ustawiasz promień w blokach, w którym entity będzie liczone jako aktywne. Przykładowo:
villagers – villagerzy, których zachowanie jest mocno związane z farmami/handelkiem,
raiders – raiderzy z rajdów (pillagerzy, vindicatorzy itp.).
Spigot daje więc prostą gałkę: zmniejszasz lub zwiększasz promień dla całej grupy. Masz mniejszą kontrolę niż w Paper, ale też mniejsze ryzyko, że zgubisz się w dziesiątkach niuansów.
Paper – granularna kontrola i tiered activation
Paper rozwija pomysł z entity-activation-range i rozbija go na bardziej szczegółowe opcje. W zależności od wersji możesz spotkać:
osobne promienie dla animals, monsters, villagers, raiders, water, misc,
dodatkowe opcje typu tick-inactive-villagers (czy villagerzy mają dostawać ticki nawet, gdy są uznani za nieaktywne),
ustawienia związane z tiered activation range – wielopoziomową aktywacją, w której entity bliżej gracza działa w pełni, trochę dalej w trybie „oszczędnym”, a jeszcze dalej jest prawie uśpione.
Taki model pozwala na bardziej inteligentne podejście, np.:
mocne obcięcie aktywacji potworów i zwierząt w farmach (bo w komorze i tak nie muszą myśleć),
łagodniejsze traktowanie villagerów i raiderów, żeby rajdy i farmy żelaza działały poprawnie,
utrzymanie pełnej responsywności jednostek krytycznych dla rozgrywki PvE i ekonomii serwera (rajdy, handel, farmy villagerów), nawet jeśli zwykłe moby w tym samym czasie dostają tryb „oszczędny”.
Dobry punkt startowy na Paperze to ustawienie odrobinę niższych promieni niż w Spigocie dla grup „tłumowych” (monsters, animals, water), przy jednoczesnym zachowaniu nieco szerszego zasięgu dla villagers i raiders. Potem testujesz zachowanie konkretnych farm i rajdów: jeśli coś zaczyna działać nienaturalnie (np. villager nie zawsze wykrywa stół pracy, rajd się „zacina” na obrzeżach wioski), podbijasz o kilka bloków tylko tę jedną kategorię, zamiast luzować wszystko.
Tiered activation daje dodatkową dźwignię: zamiast jednego ostrego cięcia, konfigurujesz kilka „pierścieni” działania. Najbliżej gracza AI działa w 100%, w średnim dystansie rzadziej, a daleko – prawie wcale. Dzięki temu gracz stojący przy farmie lub w wiosce dostaje pełną mechanikę, a te same moby pozostawione same sobie z dala od kogokolwiek nie mielą CPU bez sensu. To szczególnie opłacalne na serwerach z bazami porozrzucanymi daleko od siebie, gdzie rzadko bywa więcej niż 1–2 osoby naraz w danym regionie.
Przy tak szczegółowej konfiguracji łatwo jednak przesadzić. Zawsze rób jedną zmianę naraz, zapisuj poprzednią wartość i obserwuj serwer przez realną rozgrywkę, nie tylko przez 5 minut na pusto. W praktyce najlepsze efekty przychodzą wtedy, gdy połączysz te ustawienia z kontrolą liczby entity (limity mobów z bukkita/papera, culling) i edukacją graczy, jak budować mniej „toksyczne” dla wydajności farmy.
Gdy już ogarniesz entity-activation-range, serwer przestaje walczyć o każdy tick, a zaczyna reagować płynnie nawet przy większej liczbie osób online. Wtedy zamiast gasić pożary przy 12 TPS, możesz spokojnie rozwijać świat, eventy i ekonomię – bo fundament w postaci rozsądnie przyciętej aktywacji entity robi za ciebie najcięższą robotę.
Jak bezpiecznie obcinać zasięg aktywacji – scenariusze serwerów survival
Konfiguracja entity-activation-range nie wygląda tak samo na każdym survivalu. Inaczej podejdziesz do małego serwera znajomych, inaczej do publicznej masówki z dziesiątkami farm, a jeszcze inaczej do pół-technicznego serwera, gdzie część graczy bawi się skomplikowanymi mechanikami.
Scenariusz 1: mały survival ze znajomymi (kilku graczy online)
Na takim serwerze typowa sytuacja wygląda tak: 2–5 osób online, kilka prostych farm żelaza, expa i jedzenia, sporadyczne rajdy. Najczęściej problemem nie jest skrajne zużycie CPU, tylko sporadyczne spadki TPS, gdy ktoś odpali większą farmę lub przywoła dużo mobów.
Bezpieczne podejście:
Spigot: minimalne przycięcie wartości, np. zejście o kilka bloków z domyślnych promieni dla monsters i animals, zostawiając villagers i raiders blisko vanilli.
Paper: lekkie obniżenie zasięgu dla grup „masowych” (monsters, animals, water), przy zachowaniu standardu lub delikatnie wyższych wartości dla villagers i raiders. Tiered activation – włączone, ale niezbyt agresywne.
Co zyskujesz: serwer rzadziej zalicza spadki TPS, a gracze praktycznie nie zauważają różnicy, bo większość czasu i tak jest blisko swoich mobów. Jeśli to twoja pierwsza poważniejsza optymalizacja, zacznij właśnie od tak delikatnych ruchów.
Scenariusz 2: publiczny survival z farmami „wszędzie”
Tutaj pojawia się typowy obrazek: kilkanaście–kilkadziesiąt osób online, rozrzucone po świecie bazy, każda z kilkoma farmami żelaza, villagerów, mobgrinderami, farmami zwierząt. TPS tańczy między 12 a 20, a w logach często widać ostrzeżenia o długich tickach.
W takim środowisku entity-activation-range to jedna z głównych dźwigni. Podejście krok po kroku:
Oceń, co was zabija: użyj komend pokroju /tps, /mspt (Paper) oraz prostych profilerów wbudowanych w Paper, żeby potwierdzić, że „Entity tick” jest w czołówce.
Zidentyfikuj najbardziej obciążające regiony: przeleć się po bazach, włączając F3 i sprawdzając liczbę entity w chunkach; zapytaj graczy, gdzie „najbardziej laguje”.
Obetnij najpierw zwykłe moby: zmniejsz promienie dla monsters, animals, water – ale tylko o jedno wyraźne „oczko”, nie od razu o połowę.
Sprawdź farmy krytyczne: farma żelaza, villager trading hall, farmy rajdów, farmy expa. Jeśli coś nie działa, lekko zwiększ villagers i raiders lub odpowiednie tiered-ranges.
Na takich serwerach najwięcej zyskujesz, kiedy sprawiasz, że nieużywane w danym momencie farmy nie mielą AI. Gracze dalej mogą bawić się automatyką, ale aktywna jest głównie ta część świata, w której ktoś faktycznie stoi. Dobrze przeprowadzone obcięcie entity-activation-range pozwala nagle podnieść komfort gry bez konieczności twardego limitu na liczbę mobów w każdej bazie.
Scenariusz 3: pół-techniczny survival z wymagającymi graczami
Tu pojawia się wyzwanie: część graczy buduje skomplikowane, pół-techniczne farmy, często bazujące na specyficznych zachowaniach mobów i villagerów. Ci ludzie bardzo szybko wychwycą, że coś „nie działa jak w vanilli”, jeśli przytniesz wartości za mocno.
W tym środowisku kluczem nie jest maksymalne cięcie, tylko przewidywalność:
trzymaj villagers i raiders bardzo blisko wartości domyślnych; jeśli musisz ciąć, rób to w małych krokach, testując konkretne konstrukcje,
agresywniejsze cięcia stosuj głównie do zwykłych mobów w farmach typu „mobgrinder z ciemnego pokoju” oraz do zwierząt hodowlanych,
wykorzystaj tiered activation – pełna AI blisko gracza, ale oszczędne tryby dalej; gracz, który stoi przy farmie, dostaje pełną vanillę, a ten, który odleciał, „parkuje” swoje konstrukcje w trybie ekonomicznym.
Przy takich serwerach sensowne jest też jawne zakomunikowanie graczom, jakie zakresy planujesz. Zyskujesz wtedy partnerów do testów, zamiast wojny o „zepsute mechaniki”.
Checklista bezpiecznej zmiany entity-activation-range
Zamiast zgadywać, lepiej przejść przez krótki, powtarzalny proces. Dzięki temu każdą zmianę da się cofnąć i zrozumieć, co faktycznie pomogło.
Krok 1: backup i zapis stanu wyjściowego
Skopiuj spigot.yml oraz paper.yml/paper-global.yml do folderu „backup-config”.
Zrób zrzut aktualnych wartości entity-activation-range (np. wklej do notatnika).
Sprawdź obecne TPS/mspt przy typowej liczbie graczy (przynajmniej kilkanaście minut obserwacji).
Ten etap to twoja siatka bezpieczeństwa – z nią możesz spokojnie eksperymentować.
Krok 2: jedna, świadoma zmiana
Zamiast przestawiać wszystkie suwaki naraz, wybierz jedną grupę, która najbardziej cię obciąża. Na większości survivalów są to monsters i animals.
Obniż promień o kilka bloków (np. 4–8, zależnie od skali), nie o połowę.
Na Paperze, jeśli używasz tiered activation, zacznij od delikatniejszego przycięcia dalszych pierścieni, zostawiając wewnętrzny (najbliżej gracza) niemal nietknięty.
Zapisz plik, uruchom ponownie serwer lub użyj bezpiecznego reloadu, jeśli twoja platforma to wspiera (pełny restart jest najpewniejszy).
Krok 3: test w realnej rozgrywce
Najlepsze dane zbierasz wtedy, gdy serwer pracuje normalnie: gracze robią rajdy, stoją przy farmach, eksplorują. Zaplanuj jedną sesję testową, w której:
obserwujesz TPS i mspt przez co najmniej 30–60 minut przy typowym obciążeniu,
proszisz 2–3 osoby, żeby specjalnie sprawdziły swoje kluczowe farmy (żelaza, expa, wioski villagerów),
zwracasz uwagę, czy moby zachowują się naturalnie: czy nie „zamierają” zbyt blisko graczy, czy rajdy nie zatrzymują się na skraju wioski.
Jeśli TPS zauważalnie się poprawił, a gracze nie widzą problemów – to sygnał, że idziesz w dobrą stronę.
Krok 4: wyłapywanie objawów zbyt agresywnych ustawień
Istnieje kilka powtarzalnych sygnałów, że cięcia poszły za daleko. W praktyce pojawiają się takie skargi:
Farma żelaza: golemy przestają się pojawiać, dopóki gracz nie stanie w bardzo konkretnym miejscu; czasem villagerzy „zapominają”, że są przestraszeni zombiem.
Rajdy: fale rajdowe „wiszą”, ostatni raider nie może znaleźć drogi do wioski, rajd ciągnie się nienaturalnie długo.
Mobgrindery: spada liczba mobów na godzinę, mimo że projekt farmy się nie zmienił, a gracze stoją tam, gdzie zawsze.
Zwierzęta: krowy, owce itp. przez dłuższy czas nie reagują na karmienie albo zachowują się, jakby „odżywały” dopiero przy bardzo małej odległości.
Jeśli którykolwiek z tych objawów wystąpi, zrób krok w tył: podnieś promień dla konkretnej grupy o kilka bloków lub złagodź najbardziej odległy tier w konfiguracji Paper. Nie cofaj od razu wszystkich zmian – lepiej znaleźć minimalny punkt, w którym rozgrywka wraca do normy.
Krok 5: zapis końcowej decyzji
Kiedy znajdziesz zestaw wartości, który balansuje TPS i komfort graczy, utrwal go:
zapisz aktualne ustawienia w osobnym pliku tekstowym z datą i krótkim opisem,
dopisując w kilku słowach: „dlaczego tak” (np. „publiczny survival, dużo farm; villagers prawie domyślne, monsters i animals przycięte o 8 bloków”),
ustal prostą zasadę: każda kolejna zmiana entity-activation-range też trafia do tej „historii ustawień”.
Dzięki temu za pół roku, po dużym updacie wersji, nie będziesz zgadywać, co kiedyś zadziałało – po prostu odtworzysz sprawdzony profil i dostosujesz go do nowej wersji.
Kiedy lepiej nie ruszać entity-activation-range, a kiedy iść dalej
Nie każdy serwer potrzebuje głębokiego grzebania w tych wartościach. Czasem więcej wygrasz, skupiając się na innych dźwigniach.
Sytuacje, w których wystarczą wartości zbliżone do domyślnych
mały, zamknięty survival bez masowych farm i bez długiego online – CPU prawie się nie nudzi, nie ma potrzeby kombinować na siłę,
serwer nastawiony na czystą przygodę, gdzie gracze prawie nie budują automatyki – tu zbyt agresywne cięcia mogą być bardziej odczuwalne niż zysk z kilku mspt,
świeży projekt, w którym na razie testujesz pluginy i mechaniki – najpierw upewnij się, że bazowy setup jest stabilny.
Sytuacje, w których optymalizacja entity-activation-range ma największy sens
publiczny survival, gdzie gracze budują wszystko, co tylko da się zautomatyzować,
serwery z długim czasem działania (24/7), gdzie świat jest „poszatkowany” bazami w wielu regionach,
projekty, które już wykorzystały proste optymalizacje (redukcja view/simulation-distance, limity entity), a nadal walczą o stabilne 20 TPS.
Jeśli rozpoznajesz swój serwer w drugim zestawie punktów, spokojne, świadome strojenie entity-activation-range może być dokładnie tym, czego brakowało, żeby gra z „ledwo zipiącej” stała się płynna – bez ofiary w postaci martwych farm i sfrustrowanych graczy.
Najczęściej zadawane pytania (FAQ)
Co to jest entity-activation-range w Spigot i Paper i jak wpływa na TPS?
Entity-activation-range to zestaw ustawień określających, w jakiej odległości od gracza moby i inne entity są w pełni „aktywne”. Aktywne entity korzystają z pełnego AI, pathfindingu i logiki – czyli mocno zużywają CPU. Te poza ustawionym zasięgiem są częściowo lub całkowicie „uśpione”, więc serwer liczy je znacznie lżej.
Dzięki temu możesz mieć na mapie setki mobów, ale serwer tak naprawdę „na poważnie” zajmuje się tylko tymi, które są blisko graczy. Zmniejszenie zasięgu aktywacji w kontrolowany sposób często podnosi TPS o 1–3 punkty na obciążonym survivalu, bez masakrowania rozgrywki. To jedno z najskuteczniejszych narzędzi, gdy winne są właśnie entity.
Kiedy warto ruszać entity-activation-range, a kiedy zostawić domyślne wartości?
Entity-activation-range warto ruszyć wtedy, gdy lagi wyraźnie rosną wraz z liczbą mobów i działających farm. Typowy scenariusz: TPS spada, gdy kilka osób jednocześnie odpala farmy żelaza, rajdów, gigantyczne mobgrindery, a w timings widać wysokie „entity tick” lub podobne sekcje.
Jeśli problemy pojawiają się głównie przy teleportach, autosave, generowaniu nowych chunków, laguje konkretny plugin albo TPS stoi stabilnie na 19–20, grzebanie w entity-activation-range nie ma większego sensu. Wtedy lepiej zająć się view-distance, pluginami, optymalizacją dysku lub ograniczeniem generowania świata. Zanim coś zmienisz, przeanalizuj timings i zrób własną „mini checklistę”, żeby nie strzelać w ciemno.
Czy zmiana entity-activation-range popsuje farmy żelaza, rajdy i villagerów?
Może – jeśli zrobisz drastyczne cięcia „na oko”. Zbyt mały zasięg dla villagerów i potworów potrafi rozwalić panic mode w farmach żelaza, zachowanie raiderów w rajdach czy ścieżkowanie villagerów do łóżek i stołów pracy. Efekt jest taki, że farmy działają tylko z konkretnego miejsca albo wcale.
Żeby tego uniknąć, zmieniaj wartości małymi krokami i testuj osobno: najpierw farmy żelaza, potem rajdy, potem farmy villagerów. Dobrym podejściem jest lekkie cięcie zasięgu dla typowych mobów (monsters, animals) i ostrożniejsze podejście do villagerów oraz raiderów. Po każdej zmianie przejdź się po bazach graczy technicznych i sprawdź, czy wszystko zachowuje się przewidywalnie.
Jak poznać, że lagi na survivalu powodują właśnie entity, a nie coś innego?
Najprostsza droga to połączenie obserwacji z timings / mspt. Sygnały, że winne są entity:
TPS spada głównie wtedy, gdy pracują duże farmy (żelaza, rajdów, mobgrindery) albo działają ogromne stada zwierząt.
Na Paper mspt skacze powyżej ~50 ms, a w raportach timings górne pozycje zajmują „entity tick”, AI, pathfinding.
W grze widać gumowe moby, cofające się strzały, opóźnione reakcje villagerów i golemy spawnujące się z wyraźnym lagiem.
Jeśli natomiast lagi pojawiają się głównie przy szybkiej eksploracji, teleportach, /rtp albo autosave’ach – prędzej chodzi o generowanie chunków, dysk lub konfigurację świata. Złap konkretny wzorzec lagów, wtedy decyzja o zmianie entity-activation-range staje się dużo prostsza.
Jak bezpiecznie zmienić entity-activation-range na serwerze survival krok po kroku?
Najrozsądniej jest podejść do tego etapami. Najpierw określ, ile masz graczy online i jak bardzo techniczna jest społeczność. Dla casual-survivala z kilkoma farmami możesz pozwolić sobie na mocniejsze cięcia, dla technicznego serwera – tylko delikatne korekty z dużą ilością testów.
Potem wybierz jedną grupę do zmiany (np. monsters), obniż zasięg o kilka bloków, zrestartuj serwer i sprawdź w praktyce: działanie mobgrinderów, walkę w nocy, komfort zwykłego gracza. Jeśli wszystko jest ok, dopiero wtedy rusz kolejne grupy, takie jak animals czy villager. Po każdej iteracji porównaj TPS, mspt i feedback graczy – wtedy zamiast loterii masz kontrolowany proces z realnym zyskiem.
Czym różni się entity-activation-range od view-distance i simulation-distance?
To trzy różne dźwignie. View-distance określa, ile chunków gracz widzi i ma załadowanych wizualnie. Simulation-distance (w nowszych wersjach) definiuje, w jakim promieniu od gracza symulowane są mechaniki świata: redstone, wzrost roślin, tickowanie bloków.
Entity-activation-range nie zmienia liczby chunków, tylko „głębokość myślenia” entity wewnątrz już załadowanych chunków. Możesz więc mieć wysoki view-distance, a niskie entity-activation-range – gracz dalej wszystko widzi, ale dalekie moby nie męczą CPU pełnym AI. Świadome ustawienie tych trzech parametrów daje ogromne pole manewru przy optymalizacji survivalu.
Jakie są typowe objawy zbyt niskiego entity-activation-range na serwerze?
Zbyt agresywne obniżenie zasięgów szybko widać w rozgrywce. Przykłady: moby przestają podchodzić do gracza z sensownej odległości, farmy expa działają tylko, gdy stoisz „w konkretnym pikselu”, a zwierzęta nie reagują na jedzenie, dopóki nie wejdziesz im prawie na głowę.
Przy villagerach objawia się to opóźnionymi lub nieodświeżającymi się trade’ami, brakiem rozmnażania, villagerami, którzy nie chcą chodzić do stanowisk pracy, oraz dziwnie działającymi rajdami (raiderzy zamierają, ścieżki głupieją). Jeśli po zmianach widzisz takie zachowania, podnieś minimalnie zasięgi dla krytycznych grup i przetestuj jeszcze raz. Lepiej zrobić dwa małe kroki w górę niż męczyć graczy półprzytomnymi mobami.
Najważniejsze wnioski
Problemy z TPS na survivalu bardzo często wynikają z dużej liczby aktywnych entity (farmy żelaza, rajdy, ogromne mobgrindery), co objawia się „gumowaniem” mobów, cofającymi się strzałami i wysokim mspt przy większej liczbie graczy.
Entity-activation-range decyduje, które moby są „w pełni żywe” (pełne AI, pathfinding, reakcje), a które są usypiane lub przycinane poza określonym promieniem od gracza – to właśnie daje ogromny zysk na CPU.
Źle dobrane wartości entity-activation-range potrafią po cichu zepsuć kluczowe mechaniki: spawn golema w farmach żelaza, zachowanie raiderów w rajdach, logikę villagerów i wydajność mobgrinderów czy hodowli zwierząt.
Konfiguracja entity-activation-range powinna być procesem krokowym: zmieniasz tylko wybrane grupy mobów, małymi wartościami i obserwujesz efekty, zamiast drastycznie obniżać wszystkie promienie naraz.
Przed dotknięciem konfiguracji trzeba sprawdzić, czy winne są na pewno entity: jeśli lagi pojawiają się głównie przy teleportach, autosave, generowaniu chunków albo przez pluginy, grzebanie w activation-range niczego nie naprawi.
Krótka checklista (liczba graczy, typ i skala farm, styl gry społeczności, momenty pojawiania się lagów, realny spadek TPS poniżej 19–20) pomaga zdecydować, czy w ogóle opłaca się ruszać entity-activation-range.
Bibliografia
SpigotMC High Performance Minecraft – Spigot Configuration Guide. SpigotMC – Dokumentacja spigot.yml, w tym entity-activation-range i wpływ na wydajność
Paper Server Configuration – Reference Documentation. PaperMC – Opis paper.yml, zaawansowane opcje aktywacji entity i optymalizacji ticków
Minecraft: Java Edition – Technical FAQ and Performance Notes. Mojang Studios – Oficjalne informacje o TPS, tickach, obciążeniu CPU i zachowaniu świata
Minecraft Wiki – Entity Activation Range. Minecraft Wiki – Opis mechaniki aktywacji entity, domyślne wartości i wpływ na AI
