Intencja jest prosta: farmy mają klepać drop non stop, gracze mają cieszyć się itemami i expem, a serwer ma trzymać stabilne 20 TPS – bez przycinek, cofek i duszenia się od setek leżących przedmiotów. Zamiast chaotycznie instalować kolejne pluginy typu „clear lag”, znacznie skuteczniejsze jest świadome ustawienie limitów itemów i dropów oraz dopasowanie konfiguracji do realnego obciążenia farm.
Dobrze poustawiane limity i konfiguracje dają kilka konkretnych korzyści naraz: farmy działają stabilnie, serwer nie dusi się od entity, a ty nie musisz co tydzień gasić pożaru, bo ktoś odpalił kolejną „mega farmę wszystkiego”.
Frazy związane z tematem: limity dropów w spigot.yml, optymalizacja farm mobów, item-merge-radius konfiguracja, clear lag na serwerze, per-player-mob-spawns, hoppery i wydajność, limity stackowania itemów, limit entity w chunku, konfiguracja Paper farmy, optymalizacja spawnera potworów.
Skąd biorą się lagi przy farmach i dropach
Jak silnik Minecrafta liczy entity i ticki
Minecraft działa w rytmie ticków – domyślnie 20 ticków na sekundę. Każdy tick to czas, w którym serwer musi przeliczyć wszystko: ruch mobów, fizykę itemów, hoppery, redstone, AI potworów, projektyle, pluginy. Jeśli serwer nie mieści się z tym w 50 ms na tick, TPS spada i zaczynają się lagi.
Przy farmach kluczowe są entity. Każdy leżący item, mob, exp orb, strzała, wagonik czy łódka to osobna jednostka, którą silnik musi „odpytać” przy każdym ticku: czy ma się ruszyć, czy wejść w kolizję, czy ma despawnować, czy wpadła do hoppersa. Im więcej entity w jednym miejscu i w jednym czasie, tym większy koszt CPU.
Farmy są zabójcze, bo kumulują kilka najgorszych rzeczy naraz: dziesiątki (lub setki) mobów w małej przestrzeni, potoki dropiących itemów, gęste linie hopperów, tony redstone’u i mechanizmów czasowych. To mieszanka, która bardzo łatwo przepala ticki.
Dlaczego farmy tak mocno duszą serwer
Przy dużych farmach zwykle nakłada się kilka typów obciążenia:
Moby – AI, pathfinding, kolizje, sprawdzanie światła, obrażeń, efektów; szczególnie przy farmach mobów i zwierzaków.
Itemy na ziemi – każdy przedmiot jest sprawdzany co tick: grawitacja, kolizja, despawn, pickup przez gracza lub hopper.
Hoppery – każda lewa skrzynka z dziesiątkami hopperów to stałe obciążenie: sprawdzanie nad sobą, poniżej i w ekwipunku, przepychanie itemów.
Redstone – timery, zegary, pistony – dodatkowe aktualizacje bloków i tile entity.
Gdy w jednym chunku (albo w kilku sąsiadujących) kumulujesz setki entity plus rozbudowane mechanizmy, serwer musi upchnąć ogromną ilość logiki w jednym ticku. Bez ograniczeń i limitów szybko kończy się to spadkiem TPS, ścinkami przy teleportacji do farmy i ogólnym „gumowaniem” rozgrywki.
Objawy „uduszonego” serwera przez dropy
Przy farmach zapchanych dropem pojawiają się bardzo charakterystyczne objawy:
Wejście do chunku z farmą powoduje nagłe mikroprzycięcie (chwilowe 5–10 TPS, potem powrót).
TPS waha się w okolicach 18–19, przy większym obciążeniu spada niżej.
Przy smierci dużej grupy mobów (np. farmy creeperów) gracze widzą „gumowanie” – serwer nadrabia ticki.
Teleport do bazy z mega-farmą powoduje kilkusekundową zwłokę w doczytywaniu chunków.
Jeśli równocześnie w konsoli nie widać wyjątkowych błędów pluginów, a w timings dominują sekcje entity i ticki świata, głównym winowajcą są właśnie moby i drop, a nie np. ekonomia czy chat.
CPU vs I/O – nie wszystkie lagi są takie same
Warto odróżnić lagi CPU (przetwarzanie ticków) od lagów I/O (zapisywanie świata na dysk). Farmy najczęściej zabijają serwer od strony CPU – zbyt dużo logiki w jednym ticku, za dużo entity i aktualizacji bloków. Z kolei lagi I/O to np. przycinki przy zapisywaniu chunków lub backupie.
Jeśli TPS spada, a mspt (milliseconds per tick) rośnie, to znak, że serwer nie wyrabia z obliczeniami. Właśnie wtedy limitowanie dropów, ustawianie merge-radius i porządkowanie farm ma największy sens. Limitowanie itemów nie pomoże natomiast na słaby dysk czy źle skonfigurowane autosave’y.
Jak szybko sprawdzić, czy winne są itemy i drop
Prosta metoda: wyłącz farmę i porównaj TPS. Jeśli masz przyciski „STOP” w farmach (np. dźwignie wyłączające zegary redstone, pętle z wodą, killery mobów), zrób test:
Sprawdź TPS i mspt przy działającej farmie.
Wyłącz farmę (zamknij dopływ mobów, zatrzymaj zegary, zatrzymaj hopper linie).
Odczekaj kilka minut i obserwuj TPS / mspt.
Włącz z powrotem i porównaj wyniki.
Jeśli przy wyłączonej farmie serwer wraca do 19–20 TPS, a przy włączonej zaczyna się dławić – odpowiedź jest jasna. Wtedy warto przejść do świadomej konfiguracji limitów dropów i itemów.
Podstawowe pojęcia: itemy, entity, dropy, ticki – bez mitów
Entity, block i tile entity – co serwer liczy przy farmach
Entity to wszystko, co jest „żywe” lub porusza się w świecie: moby, itemy na ziemi, strzały, łódki, wagoniki, exp orby, armor standy. Silnik musi je przeliczać w każdym ticku, jeśli są w aktywnym obszarze świata.
Block to zwykły blok w świecie: kamień, dirt, szkło, obsydian. Bloki same z siebie nie są ciężkie dla serwera – problem zaczyna się przy dużej ilości aktualizacji (np. gravel spadający masowo, lawowe mechanizmy).
Tile entity to specjalny typ bloku, który przechowuje dodatkowe dane i logikę: skrzynki, piecyki, hoppery, beczki, spawner, beacon, stół zaklęć. Każdy hopper to tile entity, które serwer musi regularnie sprawdzać, co znacząco zwiększa koszt farm.
Różne typy entity i ich wpływ na wydajność
Nie wszystkie entity są równie ciężkie. Kilka przykładowych typów:
Item – leżący przedmiot; nie ma AI, ale wymaga obsługi grawitacji, kolizji, sprawdzenia despawnu i zbierania.
Mob – zombie, creeper, zwierzęta; mają AI, pathfinding i często generują dodatkowe efekty (dźwięki, ataki).
Experience orb – kulki expa; z pozoru lekkie, ale w dużych ilościach potrafią mocno obciążać.
Przy farmach często pojawiają się setki itemów i exp orbs w jednym miejscu. To właśnie główny cel konfiguracji limitów i merge’owania: zminimalizować ich liczbę tak, by nie umierała wydajność, ale gracz nadal dostawał swój loot.
Tick, 20 TPS i „czas na przetworzenie”
Serwer dąży do tego, by wykonać 20 ticków na sekundę. Każdy tick to 50 ms realnego czasu. Jeśli logiki jest za dużo, tick zaczyna trwać dłużej – 60, 80, 150 ms. TPS spada wtedy poniżej 20, a gracze odczuwają lagi.
Przy farmach każdy tick to m.in.:
Sprawdzenie wszystkich entity w aktywnych chunkach (moby, itemy, exp orby, strzały).
Aktualizacja hopperów i innych tile entity (piecyki, skrzynki z minecartami, spawner).
Przeliczenie redstone, pistonów i innych mechanizmów.
Im mniej entity i mniej aktywnych tile entity w jednym tikcie, tym większa szansa na stabilne 20 TPS. Ustawienie limitów dropów i inteligentne merge’owanie itemów to w praktyce redukcja „pracy na tick”.
Co dzieje się z itemem na ziemi w każdym ticku
Leżący item to nie jest bierny obiekt. Serwer w każdym ticku wykonuje kilka prostych, ale kosztownych w skali setek sztuk czynności:
Aktualizuje jego pozycję (grawitacja, ruch w wodzie, przepływ).
Sprawdza kolizje z blokami i innymi entity.
Sprawdza, czy nie minął czas despawnu.
Sprawdza, czy nie dotyka go gracz (pickup) lub hopper.
Sto itemów leżących obok siebie to sto razy więcej pracy w każdym ticku niż jeden zmergowany stack. Dlatego tak kluczowy jest parametr item-merge-radius oraz sensowne ustawienie czasu despawnu.
Dlaczego 1000 itemów w jednym miejscu ≠ 1000 w 10 chunkach
Serwer dzieli świat na chunki 16×16 bloków. Logika entity jest przeliczana per chunk – ale gdy w jednym miejscu masz tysiąc itemów, cała ich obsługa kumuluje się w jednym obszarze pamięci i w jednym zestawie pętli. Do tego dochodzą kolizje między tymi itemami i interakcja z hopperami poniżej.
Rozsiana po świecie tysiąc drobnica (np. pojedyncze itemy po eksploracji) jest znacznie mniej problematyczna niż tysiąc itemów z farmy wrzucone w jeden ciasny punkt. Z tego powodu limity oparte o chunk i sensowne wykorzystanie merge’owania działają dużo lepiej niż „globalny clear lag co X minut”.
Narzędzia do diagnozy – zanim cokolwiek ograniczysz
/tps, /mspt – szybka ocena kondycji serwera
Podstawą są komendy typu /tps i /mspt. Na Paperze /tps pokaże aktualne ticki na sekundę oraz średni czas ticka. Odczytując te dane pod kątem farm i dropów:
19.9–20 TPS, mspt poniżej ~40 ms – jest dobrze, masz zapas.
18–19 TPS, mspt w okolicach 50–60 ms – zaczyna się duszenie, warto szukać winowajców.
Poniżej 18 TPS, mspt powyżej 70–80 ms – serwer jest wyraźnie przeciążony.
Jeśli spadki TPS pojawiają się wtedy, gdy kilka osób wchodzi w okolice dużych farm lub gdy odpalane są masowe grindery, to silny sygnał, że trzeba przyjrzeć się dropom, mobom i hopperom.
/timings paste – gdzie szukać sekcji od entity i itemów
Timings to potężne narzędzie diagnostyczne. Po włączeniu timings (Spigot/Paper), odczekaniu kilku minut i wykonaniu /timings paste dostajesz raport z rozbiciem na różne komponenty. Szukaj sekcji:
world – entityTick – ogólne przetwarzanie entity w światach.
entity – Item, entity – ExperienceOrb, entity – Monster – ile czasu zabierają konkretne typy.
tile entity – Hopper – ile kosztują hoppery.
tick – level dla danego świata – całkowity koszt logiki w tym świecie.
Jeśli Item lub ExperienceOrb ma duży udział procentowy w czasie ticka, to limitowanie dropów, przyspieszenie despawnu i merge’owanie itemów dają bardzo szybki efekt. Jeśli dominują hoppery – trzeba przyciszyć ich częstotliwość (Paper) lub ograniczyć ich ilość w farmach.
Na Paperze masz kilka dodatkowych, bardzo przydatnych komend:
/paper entity – pokazuje liczbę entity per świat i często per typ; łatwo wyłapać światy i obszary, gdzie leży najwięcej śmieci.
/paper mobcaps – prezentuje mob capy i aktualne wykorzystanie; pomaga przy farmach mobów i spawnerach.
/paper debug (lub dedykowane podkomendy) – głębsze profile wydajności, jeśli chcesz wejść poziom niżej.
To szybki sposób na znalezienie chunków z dziesiątkami tysięcy entity. W połączeniu z teleportacją do wskazanych koordynatów można namierzyć farmy, które najbardziej duszą serwer i pod nie dopasowywać limity dropów.
Prosta procedura testowa farmy
Aby podejść do tematu metodycznie, możesz użyć prostej procedury testowej:
Wybierz jedną dużą farmę (mobów, iron farm, farmę killującą setki potworów).
Poproś graczy, by na 10–15 minut ją wyłączyli (albo zrób to administracyjnie).
Włącz timings, obserwuj /tps i /mspt w tym czasie.
Włącz farmę ponownie i zostaw ją na pełnym cyklu (np. 15–30 minut).
Porównaj raport timings oraz statystyki /tps przed i po.
Na tej podstawie wiesz, jak bardzo dana farma obciąża serwer. To świetny punkt startu do ustawiania limitów dropów i radzenia sobie z itemami oraz expem.
Potem można przejść do mikrotestów: zmieniasz jedno ustawienie (np. czas despawnu itemów, promień merge’owania, limit exp orbs), restartujesz serwer i jeszcze raz odpalasz farmę w kontrolowanych warunkach. Jeśli po kilku takich iteracjach widzisz, że mspt spada, a farmy nadal działają sensownie z perspektywy graczy – masz potwierdzenie, że konfiguracja idzie w dobrą stronę. To znacznie lepsze podejście niż wrzucanie losowych wartości z internetu i liczenie, że „jakoś to będzie”.
Przy okazji takich testów zyskujesz też materiał do rozmowy z graczami. Zamiast ogólnego „farmy wam lagują serwer” możesz pokazać prosty wykres z timings albo krótkie porównanie: „ta konkretna farma podnosi czas ticka o 30%”. To ułatwia dogadanie się przy ewentualnym nerfie, limitach na chunk albo wymogu przeróbki konstrukcji.
Dobrze jest też zaplanować testy na „godziny szczytu”, kiedy na serwerze dzieje się najwięcej. Farma, która w nocy przy kilku osobach działa elegancko, przy pełnym serwerze może już dobijać mspt do czerwonej strefy. Kilka krótkich sesji pomiarowych o różnych porach dnia pokaże, gdzie faktycznie leży granica bezpieczeństwa.
Takie uporządkowane podejście – pomiar, zmiana, znowu pomiar – sprawia, że każde kolejne ustawienie w bukkit.yml, spigot.yml czy paper.yml jest świadomą decyzją, a nie strzałem w ciemno. Efekt uboczny jest bardzo przyjemny: mniej dram na czacie, spokojniejszy serwer i farmy, które dalej robią swoje, ale nie dławą wszystkiego dookoła.
Kluczowe ustawienia w bukkit.yml, spigot.yml i paper.yml związane z itemami
bukkit.yml – despawn i ogólne limity entity
Choć większość magii dzieje się w spigot.yml i paper.yml, to w bukkit.yml są dwa absolutne klasyki przy farmach: czas despawnu i globalne limity entity.
Te ustawienia nie sterują itemami bezpośrednio, ale wpływają na to, ile mobów może w ogóle wygenerować farma w jednym świecie. Jeśli masz wydajne grindery, warto:
podciąć monsters w światach, gdzie jest dużo farm mobów,
zastanowić się nad rozdzieleniem światów „survival” i „farmy” na osobne konfiguracje (per-world config przez pluginy lub system wielu instancji).
Mniej mobów = mniej dropów. Mało spektakularny, ale skuteczny suwak bezpieczeństwa.
Część dystrybucji Bukkita ma też globalne ustawienia despawnu (lub współdzielone z Spigotem), które definiują, jak długo item może leżeć na ziemi. Jeśli masz taką sekcję w bukkit.yml, niech będzie spójna z tym, co ustawisz w spigot.yml/paper.yml, żeby nie robić sobie konfliktów.
spigot.yml – serce konfiguracji itemów i dropów
Najwięcej kontroli nad dropami i itemami dostajesz w spigot.yml. Najważniejsze grupy parametrów przy farmach:
item-despawn-rate – domyślnie 6000 ticków (5 min). Przy serwerach z dużą liczbą farm opłaca się zejść do ok. 3000–4000 ticków, ale nie niżej, jeśli gracze często giną i muszą zebrać eq.
arrow-despawn-rate – jeśli masz farmy strzał (skeletony, farmy z dispenserami), agresywnie niższa wartość bardzo pomaga; strzały są tanie.
merge-radius.item – główny „spłaszczacz” liczby itemów. 2–4 bloki to rozsądny zakres testowy; powyżej 4 mogą się zacząć drobne bugi z wizualnym znikaniem drobnicy przy dużym lagspike.
merge-radius.exp – im wyższy, tym szybciej kulki expa z farmy łączą się w kilka dużych; wyższe wartości zwykle są bezpieczniejsze niż przy itemach.
To nie są limity ilościowe, ale „zasięgi życia” entity. Im mniejsza aktywacja, tym więcej mobów „usypia” w chunkach, gdzie gracz nie jest bardzo blisko. Efekt uboczny: „szare strefy” wokół potężnych farm mobów potrafią znacząco odciążyć serwer, bo część mobów po prostu nie wykonuje AI, jeśli gracz stoi w sprytnie dobranym punkcie.
Przy farmach xp i killroomach niewielkie zbicie zasięgu monsters/animals często usuwa sporą część kosztu AI, bez naruszania samego dropu. Dobrym nawykiem jest robienie tego per-świat, a nie globalnie – survival PvE może mieć większe zasięgi niż świat techniczny z farmami.
paper.yml – precyzyjna kontrola dropów i hopperów
Spigot daje ogólną kontrolę, ale to paper.yml pozwala ustawić farmy tak, żeby były „grzeczne” dla serwera. Kluczowe grupy ustawień:
hopper-transfer i hopper-check – jak często hopper sprawdza sąsiednie inwentory i przerzuca itemy. Wyższe wartości = rzadziej, ale mniej kosztownie. Dobrze jest przetestować wartości typu 8–10 zamiast domyślnych 1–2.
hopper-disable-move-event – redukuje wywołania eventów z pluginów przy każdym ruchu itemu; idealne, jeśli masz dużo pluginów słuchających inventory events.
cooldown-when-full – hopper „odpuszcza sobie” spamowanie próbą przesunięcia itemu, gdy docelowy kontener jest pełny; przy AFK-farmach to realna ulga.
Jeśli masz na serwerze farmy typu „ściana hopperów pod całym chunkami”, zmiana samych ustawień hopperów w Paperze potrafi zbić mspt bez dotykania farm od strony redstone.
Per-światowe limity i optymalizacje entity
Paper pozwala też docisnąć konkretne typy entity w światach technicznych:
Wyłączanie tickowania armor standów w świecie farm, ograniczanie nietoperzy, rybek czy innych „śmieciowych” entity to dodatkowy margines bezpieczeństwa. Sam drop może zostać nienaruszony, a serwer odetchnie.
Źródło: Pexels | Autor: Athena Sandrini
Ustalanie limitów dropów i itemów – strategia zamiast zgadywania
Najpierw cel: co chcesz osiągnąć dla graczy
Zanim zaczniesz kręcić suwakami, dobrze jest ustalić, jaki kompromis między wydajnością a wygodą chcesz osiągnąć. Kilka przykładowych „profili”:
Serwer techniczny – gracze chcą mocnych farm, ale akceptują krótszy despawn śmieciowego lootu i mniejsze exp orby.
Survival semi-vanilla – priorytetem jest niegubienie eq po śmierci; despawn ogólny zostaje łagodny, za to mocno optymalizuje się tanie itemy i exp.
Serwer publiczny z dużą rotacją graczy – trzeba agresywnie ciąć dropy z AFK-farm i czyścić śmieci, ale wypada zostawić zwykłą eksplorację i kopanie możliwie blisko vanilli.
Jasny cel ułatwia potem tłumaczenie graczom „dlaczego” i trzymanie się spójnych decyzji.
Mapa priorytetów: które typy dropów są krytyczne, a które śmieciowe
Dobra strategia zaczyna się od prostego podziału itemów na kategorie. Można to zrobić „na kartce”:
Kategorie A (święte) – eq gracza, diamenty, netherite, gear, rzadkie dropy bossów.
Kategorie B (ważne, ale farmowalne) – iron, gold, gunpowder, blaze rod, emeraldy, główne surowce z farm.
Kategorie C (śmieciowe) – rotten flesh, seeds, cobble, netherrack, stone, strzały ze skeletonów itp.
Pod farmy ograniczasz przede wszystkim kategorię C, częściowo B, a kategorię A zostawiasz praktycznie nietkniętą (standardowy despawn, ostrożne merge’owanie).
Kolejność działań: od najmniej inwazyjnych do twardych limitów
Zamiast od razu ciąć mob cap albo wprowadzać brutalne clear-lagi, lepiej przejść przez prostą drabinkę:
Per-światowe obniżenie spawn-limits lub mob capów dla farmowych światów.
Limity entity per chunk/region – ostatni etap, gdy poprzednie kroki nie wystarczyły.
Przy takim podejściu najpierw „odkurzasz” to, co gracze odczują najmniej, a dopiero na końcu sięgasz po mało lubiane nerfy dropów.
Projektowanie limitów pod konkretne typy farm
Inne ustawienia sprawdzą się przy farmach mobów, a inne przy iron farmach czy gold farmach w Netherze. Kilka gotowych kierunków:
Farma mobów XP (killroom, spawner, mob grinder)
priorytet: exp dla gracza, stabilne łączenie exp orbs, rozsądna ilość mobów żywych jednocześnie,
ustawienia: wysoki merge-radius.exp, lekko niższy merge-radius.item, krótszy despawn rotten flesh/arrowów/bone, lekkie zbicie mob cap w świecie, by nie kumulować setek mobów czekających na kill.
Farma ironu / golda / czystych surowców
priorytet: przepustowość surowca w skrzynkach, ograniczenie śmieci zalegających poza systemem hopperów,
ustawienia: agresywne alt-item-despawn-rate na blokach pomocniczych (np. stone, netherrack, mob drops), wyższy merge-radius.item w obszarze farm, dopieszczone hopper-transfer/check, by nie mieliły na darmo.
Farma z ubojem „na raz” (np. zbiornik mobów spuszczanych lawą)
priorytet: uniknięcie momentu, w którym naraz pojawia się kilkaset dropów,
ustawienia: wysoki merge-radius.item, krótszy alt-item-despawn-rate na tanie dropy, ewentualny pluginowy limit jednoczesnych itemów w chunku (opis poniżej).
Jeśli każde takie „profilowanie” połączysz z krótkimi testami timings, po kilku dniach konfiguracji masz serwer, który wyraźnie mniej się dusi przy farmach, a gracze nadal czują, że ich konstrukcje są opłacalne.
Merge itemów i despawn – szybkie zmniejszanie liczby entity bez zabijania farm
Jak działa merge itemów pod maską
Gdy dwa itemy leżą na ziemi blisko siebie, serwer próbuje je połączyć w jeden stack. Działa to tylko wtedy, gdy:
to ten sam typ przedmiotu,
mają ten sam stan (np. brak enchantów vs enchant, takie same tagi NBT),
łączny stack nie przekroczy maksymalnego limitu (np. 64).
Merge-radius określa, w jakiej odległości serwer w ogóle rozważy łączenie. Im większy promień, tym mniej osobnych entity na ziemi – przy farmach spada to często z setek do kilkunastu.
Przykład z praktyki: duża farma skeletonów bez merge’owania potrafi zostawić setki pojedynczych strzał i kości na krawędzi killroomu. Po podniesieniu merge-radius.item i skróceniu despawnu dla strzał masz kilka większych stacków, które hopper przełknie bez kaszlu.
Bezpieczne zakresy merge-radius dla różnych typów serwerów
Przy ustawianiu merge-radius warto trzymać się rozsądnych przedziałów:
Serwery techniczne / prywatne – merge-radius.item: 4–6, merge-radius.exp: 4–6. Większe wartości agresywnie czyszczą „chmurę” orbsów i pojedynczych dropów, co bardzo pomaga przy farmach XP i mob switchach.
Survival semi-vanilla – merge-radius.item: 3–4, merge-radius.exp: 3–4. Itemy wciąż zachowują się dość naturalnie, ale farmy nie wysadzają licznika entity.
Serwery publiczne / minigry – często sprawdzają się wartości pośrednie: merge-radius.item: 3, merge-radius.exp: 4–5, bo exp jest „lżejszy” wizualnie niż dywan z itemów.
Jeżeli gracze zgłaszają, że drop z mobów „magicznie” zbiega się im w jedno miejsce, można zejść o 0.5–1 w dół. Jeżeli natomiast w timingsach masz setki tysięcy ticków na minecraft:entity_item, podbij promień o 1–2 i porównaj sytuację po kilku dniach.
Drugie turbo dla farm to zróżnicowany czas despawnu. Zamiast ciąć globalne 6000 ticków, lepiej „dobijać” tylko śmieciowe rzeczy. W Paperze robisz to tak:
Konfiguracja jest per-świat, więc farmowy świat może mieć bardzo agresywne despawny śmieci, a główny survival – łagodniejsze. Dobrze jest trzymać eq-gracza i rzadkie surowce na standardowym czasie, a wszystko, co produkują masowo mob-grindery, czyścić szybciej.
Praktyczny trick: na początku ustaw wartości umiarkowane (np. 400–600 ticków), pograj z ekipą kilka dni i dopiero wtedy dociśnij do 200–300 dla najbardziej bezużytecznych itemów. Ludzie lubią mieć chwilę na „podniesienie, gdy zauważą”, ale nie potrzebują pięciu minut dywanu z rotten fleshem.
Jak testować nowe limity, żeby niczego nie „zabić”
Zanim odważnie zapiszesz nowe limity, dobrze przejść prosty cykl testów. Najpierw wybierz jedną lub dwie największe farmy, poproś właścicieli o krótkie sesje testowe i na czas prób włącz /timings on albo profiler z Panelu. Po zmianie merge-radius/despawnu zrób kilka serii „pełnego obciążenia” (AFK przez kilkanaście minut, zbiór całego lootu, sprawdzenie czy nic nie ginie „za szybko”).
Kiedy widzisz, że gracze dostają to, czego oczekują (ilość surowca na godzinę się zgadza, exp wpada płynnie), a w raportach mspt spada i entity count nie skacze w kosmos, możesz spokojnie przenieść te ustawienia na resztę światów. Takie małe pętle test–feedback robią większą różnicę niż dziesięć „magicznych” konfiguracji skopiowanych z internetu.
Łączenie merge-radius z limitem dropu na raz (soft cap na farmę)
Sam merge-radius i despawn to miękkie narzędzia. Można je jednak połączyć z prostym „soft capem” na ilość itemów generowanych jednocześnie przez farmę. Chodzi o sytuacje, w których w jednym ticku nagle spada cała fala dropu (zrzut lawy, piston crusher, giant creeper farm).
Najprostszy schemat działania takiego ograniczenia w pluginie wygląda tak:
nasłuchujesz EntitySpawnEvent dla Item,
zliczasz itemy w promieniu X bloków / w chunku,
jeżeli przekroczysz ustalony próg (np. 200 itemów), nowe dropy są:
albo od razu łączone w istniejące stacki,
albo anulowane / zamieniane na część stacków (np. 50% dropu przepada).
Taki „bezpiecznik” często uratował serwery, na których gracz zapomniał o wyłączniku farmy, a kilkaset mobów zginęło naraz. Lepiej stracić kilka stacków rotten flesha niż zabić tickrate dla całej mapy.
Jeśli masz kogoś od pluginów, poproś o dodanie prostego logowania, kiedy limit zostanie przekroczony – wtedy szybko znajdziesz najbardziej duszące farmy.
Limity entity i mobów na chunk – jak dusić farmy elegancko
Dlaczego limit per chunk jest skuteczniejszy niż globalny mob cap
Globalne mob capy (spawn-limits) rozlewają odpowiedzialność po całym świecie: kilku graczy z farmami zjada pulę, reszta świata ma pusto. Limity per chunk/region działają chirurgicznie – uderzają tam, gdzie powstaje problem, a nie w losowego eksploratora kopalni.
Dodatkowy plus: gracz widzi efekt. W pewnym momencie farma przestaje się „nakręcać” i zamiast 400 mobów w jednym zbiorniku ma stabilne 80–100. Z jego perspektywy: farma dalej działa, tylko nie kręci już hardcorowych rekordów, które topią serwer.
Przegląd narzędzi do limitów per chunk w Paper i pluginach
W samym Paperze znajdziesz kilka ustawień, które robią sporą robotę bez jednej linijki kodu:
per-player-mob-spawns – równiej rozdziela spawny między graczy, przez co trudniej „zmonopolizować” cap jedną farmą.
entity-per-chunk-save-limit – twardy limit ilości zapisanych entity danego typu w chunku (np. boaty, minecarty, zwierzęta).
max-entity-collisions – nie jest limitem ilości, ale mocno tnie koszt „ściany mobów stykających się ze sobą”.
Gdy to nie wystarcza, wchodzą pluginy typu ChunkyBorder, FarmLimiter, MobFarmManager czy proste customowe rozwiązania. Zwykle mają jedną z dwóch strategii:
monitorują liczbę entity per chunk i po przekroczeniu progu:
blokują nowe spawny (anulują event),
lub usuwają najstarsze nadmiarowe moby/itemy;
od razu „odchudzają” farmę – np. zabijają co drugiego moba powyżej limitu.
To nie musi być brutalne. Kluczem są sensowne wartości progów, żeby gracze czuli ograniczenie dopiero wtedy, gdy farma realnie szkodzi wydajności.
Propozycje limitów per chunk dla różnych typów serwerów
Konkrety są dużo lepsze niż abstrakcje, więc przykładowa siatka wartości:
Prywatny survival 5–20 graczy:
hostile mobs w chunku: 70–100,
zwierzęta gospodarskie (krowy, owce itp.) w chunku: 40–60,
villagerzy w chunku: 20–40 (więcej = duże koszty AI),
itemy w chunku: 200–300.
Publiczny survival 50+ graczy online:
hostile mobs w chunku: 40–60,
zwierzęta gospodarskie: 30–40,
villagerzy: 20–30 (czasem jeszcze mniej dla „świata handlu”),
itemy: 120–200.
Serwery skyblock / oneblock (kompaktowe wyspy):
hostile mobs w chunku: 30–40,
zwierzęta gospodarskie: 20–30,
villagerzy: 10–20,
itemy: 100–150.
Zakresy są celowo szerokie. Zacznij po łagodniejszej stronie, odpal timings, posłuchaj reakcji graczy i dociśnij, jeśli farmy wciąż topią TPS.
Jak komunikować limity, żeby gracze nie czuli się okradani
Limity per chunk to klasyczny punkt zapalny. Da się to jednak wygrać komunikacją i rozsądnym UX:
krótkie, czytelne powiadomienie na czacie, gdy farma dobija do limitu (np. „W tym chunku jest już 60 zombie, kolejne spawny są wstrzymane, aby chronić serwer”).
jasne zasady spisane na /regulamin lub stronie – z przykładami, co jest celem (stabilny serwer, brak lagów z powodu jednej mega-farmy).
okres przejściowy – najpierw same ostrzeżenia, dopiero potem faktyczne cięcia.
Dobrym pomysłem jest jeden krótki post z logami lub wykresem z panelu – „Patrzcie, przed limitami: 15 TPS przy 2000 mobów w jednym chunku, po limitach: 19–20 TPS i farma działa prawie tak samo”. Liczby robią robotę lepiej niż ściana tekstu.
Limitowanie villagerów i zwierząt a ekonomia serwera
Villagerzy i stada zwierząt bywają większym problemem niż farmy mobów. AI villagerów, pathfinding, gossip – to wszystko mieli CPU przez całą dobę, nawet gdy nikt nie bije mobów. Podobnie 150 krów upchanych w jednym rogu chunku nie tylko laguje serwer, ale potrafi wywalić FPS-y graczom z słabszymi PC.
Przy sensownych limitach:
gracze nie mogą mieć jednego, gigantycznego „villager megamall” na 300 mieszkańców – trzeba rozbić handel na kilka mniejszych hal,
automatyczne farmy jedzenia i wełny nadal działają, ale nie opłaca się trzymać dziesiątek nadmiarowych zwierząt „na zapas”.
Dobrą praktyką jest rozdzielenie światów: w głównym survivalu limity są umiarkowane, a jeśli naprawdę chcecie wielkie centra handlu, wydzielcie osobny „świat rynku” z bardziej poluzowanymi zasadami i mniejszą liczbą graczy jednocześnie.
Sprytne łączenie limitów chunk + merge + despawn
Najstabilniej działają serwery, które nie polegają na jednym magicznym ustawieniu, tylko składają kilka mechanizmów w spójny zestaw. Przykładowy pakiet dla mocno obciążonego publicznego survivalu:
Merge-radius.item 3–4 + merge-radius.exp 4–5 – mniej entity w powietrzu.
Alt-item-despawn-rate dla śmieci – bardzo krótki czas życia rotten flesh, netherrack itp.
Limit itemów per chunk (np. 150–200) – gdy farma przesadzi, nie pozwala stworzyć „dywanu” dropu.
Limit hostile mobs per chunk (np. 50–60) – farma przestaje się nakręcać powyżej praktycznego progu.
Efekt: żadna pojedyncza farma nie jest w stanie zabić serwera sama z siebie, ale gracze nadal mają motywację do budowania sprytnych, zoptymalizowanych konstrukcji. Dokładnie o to chodzi.
Praktyczne scenariusze strojenia limitów krok po kroku
Scenariusz 1: duża farma creeperów pali TPS
Objawy: przy włączonej farmie creeperów TPS leci do 14–16, rośnie licznik entity, timings pokazują wysokie zużycie na minecraft:creeper i minecraft:entity_item.
Proponowana ścieżka:
Zwiększ merge-radius.item do 4 oraz ustaw alt-item-despawn-rate na GUNPOWDER trochę krótszy niż vanilla, ale nie ekstremalny (np. 400–500 ticków), żeby nie zabijać opłacalności farmy.
Włącz prosty limit itemów per chunk na poziomie ok. 150–200. Gdy farma wypluje zbyt dużo prochu na raz, część dropu zniknie albo zmerge’uje się w kilka stacków.
Delikatnie przytnij mob cap dla creeperów w tym świecie albo ustaw limit hostile mobs per chunk (np. 60). Zamiast 200 creeperów naraz, farma będzie stabilnie trzymać ~60, ale dzięki mniejszej liczbie lagów realny zysk na godzinę potrafi wyjść podobny.
Po takiej serii często okazuje się, że farmę da się zostawić włączoną niemal non stop, a TPS trzyma się ponad 18–19.
Scenariusz 2: AFK-owe killroomy XP robią chmurę orbsów
Objawy: gracze stoją AFK przy killroomie, orbsy expa latają w miejscu, FPS-y spadają, a timingsy pokazują drogie ExperienceOrb.
Plan działania:
Ustaw merge-radius.exp na 4–6 (w zależności od typu serwera). Orbsy bardzo szybko zbiją się w jeden większy pakiet.
Jeśli killroom gromadzi moby i zabija je „falami”, spróbuj:
zmniejszyć ilość mobów per fala (np. wolniejszy transport),
lub wprowadzić limit exp orbs per chunk w prostym pluginie i nadmiar od razu łączyć / usuwać.
Zachęć graczy do stosowania systemu „przepalania” expa w mending / enchantach zamiast gromadzenia chmury orbsów przez kilka minut przed kliknięciem w kilof.
W praktyce kilka zmian potrafi zamienić „lag maszynkę” w wciąż bardzo wydajną, ale znacznie lżejszą farmę XP.
Scenariusz 3: lagujący „zoo serwerowe” – tysiące zwierząt i villagerów
Objawy: w hubie lub na wspólnym świecie ktoś robi gigantyczne farmy krów, kurczaków czy villagerów. TPS spada nawet gdy nikt nie jest w pobliżu farm mobów, ale timings pokazują wysokie koszty AI.
Kroki ratunkowe:
Wprowadź lub zaostrz limity zwierząt per chunk (np. 40–50) oraz villagerów per chunk (20–30 w głównym świecie).
Jeśli używasz pluginu do limitów, ustaw mechanizm „trimowania”:
nadmiar powyżej limitu usuwany jest najpierw ze starych, bezimiennych osobników,
zachowaj moby z nametagami, by nie kasować czyichś ulubieńców.
Dodaj prosty komunikat przy próbie breedowania powyżej limitu: „Za dużo krów w tym chunku, kolejne młode nie mogą się urodzić – ograniczenie lagów serwera”.
Po takim cięciu serwer często „oddycha” w kilka minut, a gracze uczą się, że liczy się jakość setupu, a nie same ilości mobów.
Scenariusz 4: świat kopalniany generuje góry śmieci w tunelach
Objawy: osobny świat do kopania (resource world) ma masę dropów w tunelach – cobblestone, dirt, gravel, pojedyncze rudki. TPS spada przy eksploracji, bo serwer trzyma w pamięci dywany śmieci.
Plan cięcia bez bólu:
W tym świecie ustaw agresywny alt-item-despawn-rate dla:
COBBLESTONE, STONE, DIRT, NETHERRACK, GRAVEL,
i tańszych rud, jeśli ekonomia to zniesie.
Podbij merge-radius.item do ok. 4–5, żeby tunel po TNT nie zostawiał tysiąca pojedynczych bloczków.
Rozważ limit itemów per chunk ok. 150–200, żeby ogromne projekty kopania tuneli TNT nie przytykały mapy.
Gracze dalej wyciągają z resource world tyle surowca, ile zdążą podnieść lub wciągnąć hopperami do wózków, a serwer nie nosi na plecach pozostałości po każdej eksplozji przez kolejne 5 minut.
Optymalizacja dropów przy pomocy pluginów – kiedy config to za mało
Typowe funkcje pluginów „anti-lag” związane z itemami
Narzędzia typu ClearLag, FarmLimiter, LagAssist czy niestandardowe rozwiązania mają często powtarzalny zestaw funkcji związanych z itemami i dropem:
automatyczne czyszczenie itemów co X minut z ostrzeżeniem na czacie,
dynamiczne usuwanie entity przy spadku TPS poniżej zadanej wartości,
ustalanie twardych limitów itemów i mobów na chunk lub region,
zaawansowane reguły whitelist/blacklist – czego nie usuwać nigdy (np. itemy z custom lore, netherite, drop bossów),
raporty i logi: kto, gdzie i czym generuje najwięcej śmieci.
Brzmi to kusząco, ale każda z tych funkcji może zarówno uratować TPS, jak i niechcący zjeść cenny drop gracza. Dlatego takie pluginy konfiguruj powoli i świadomie, a nie metodą „włącz wszystko na domyślnych”.
Jak bezpiecznie wdrażać pluginy ograniczające drop
Najrozsądniej jest zacząć od trybu obserwacji. Duża część pluginów anti-lag umożliwia logowanie, co byłoby usunięte przy danych ustawieniach, bez faktycznego kasowania itemów. Włącz ten tryb na kilka dni, przejrzyj logi i dopiero wtedy zaostrzaj reguły. Dzięki temu nie obudzisz się z falą skarg, że komuś zniknęły netherite’owe sety po śmierci na endzie.
Dobre efekty daje łączenie konfiguracji plików (spigot.yml, paper.yml) z lekkim pluginem, który domyka scenariusze niemożliwe do ogarnięcia „vanillową” konfiguracją. Przykład: Paper ogarnia merge i despawn, a prosty plugin pilnuje limitu itemów per chunk dla konkretnych światów i materiałów, dodatkowo wysyłając komunikat do gracza, że właśnie uderzył w sufit limitu.
Przed włączeniem automatycznych czyszczeń z broadcastem zrób krótką akcję informacyjną – post na Discordzie, tablica na spawnie, może jedno ogłoszenie przy logowaniu. Gdy gracze wiedzą, że co, dajmy na to, 10 minut serwer zmiata porzucone śmieci z ziemi, zaczynają budować sortowniki i magazyny zamiast zasypywać świat dropem. Zyskuje wydajność i estetyka mapy.
Dobrą praktyką jest też test na dummy-świecie: odpal na nim kopię pluginów i kilka botów/altów generujących drop, a potem sprawdź, czy żadne krytyczne itemy nie znikają w niespodziewanych sytuacjach. Godzina takich testów potrafi oszczędzić wiele dni nerwów po wdrożeniu zmian na produkcję.
Gdy zgrasz ze sobą limity chunków, rozsądne merge i despawn oraz lekko doprawisz to pluginami, serwer przestaje być zakładnikiem jednej chorej farmy czy dywanu dropu. Zamiast wiecznie „gasić pożary lagów”, możesz wreszcie skupić się na rozwijaniu świata i zachęcaniu graczy do budowy sprytnych, a nie tylko wielkich projektów.
Źródło: Pexels | Autor: panumas nikhomkhai
Balans między wydajnością a satysfakcją gracza
Same limity to za mało, jeśli rozwalą poczucie progresu. Gracz musi nadal widzieć sens w budowaniu farm i zbieraniu dropu, inaczej zacznie walczyć z administracją zamiast z potworami.
Dobrym punktem odniesienia jest odpowiedź na jedno pytanie: ile realnie surowca na godzinę chcesz, żeby dawała farma danej klasy (early / mid / late game)? Nie chodzi o apteczną precyzję, tylko o rząd wielkości. Potem pod to dobierasz limity:
farmy early game – lekkie ograniczenia, gracze dopiero uczą się mechanik,
farmy mid game – standardowy poziom surowców, przyzwoite limity, ale bez „infinitów”,
farmy late game – mogą mieć moc, ale pod warunkiem, że nie koszą TPS; tutaj bardziej dopieszczasz config i zachęcasz do optymalizacji.
Jeśli farma late game zamiast 3000 prochu na godzinę daje 2400 przez limity dropu, ale serwer nie klatkuje – to w praktyce ogromny plus dla wszystkich. Gracze szybciej docenią stabilny serwer niż 20% więcej surowca, którego nie mają gdzie użyć, bo co chwilę jest restart.
Jak komunikować limity, żeby nie wywoływać buntu
Największy ból pojawia się wtedy, gdy coś „po prostu znika”, a gracz nie ma pojęcia czemu. Tu wystarczą proste, czytelne sygnały:
krótkie komunikaty po uderzeniu limitu chunku: „Osiągnięto limit itemów w tym chunku – nadmiar się nie pojawia, aby nie lagować serwera”,
opis na tablicy na spawnie: ogólny zarys limitów (np. „max ~200 itemów/60 mobów hostile na chunk”),
jeden zwięzły wpis na Discordzie z infografiką albo screenem z configiem (bez całego pliku, tylko kluczowe linijki).
Jeśli gracz wie, że istnieje sufit, często sam zacznie kombinować z sortowaniem, filtrami i hopperami zamiast walić drop w nieskończoność na ziemię.
Zaawansowane techniki – ograniczanie dropu u źródła
Limitowanie itemów, gdy już leżą w świecie, to tylko jedna strona medalu. Druga – dużo czystsza – to zmniejszanie ilości dropu w ogóle, bez psucia gameplayu.
Modyfikatory dropu zależne od ilości mobów
Bardzo elegancki trik to lekkie redukowanie dropu w miejscach, gdzie mobów jest nienaturalnie dużo. Nie po to, żeby karać za farmy, tylko żeby zachęcać do jakości, a nie samej ilości.
Jak to może wyglądać w pluginie czy datapacku:
do 20 mobów danego typu w chunku – drop 100% (vanilla),
20–60 mobów – drop 80–90% (praktycznie niezauważalne),
powyżej 60 – drop 50–70%, tak żeby absurdalne farmy miały mocno malejące zyski.
Na papierze wygląda jak nerf, ale w praktyce zniechęca tylko do ekstremów, które i tak rozwalały TPS. Gracze, którzy budują rozsądne farmy, praktycznie nie odczują różnicy.
Inteligentne sortowanie i „przepalanie śmieci”
Zamiast kasować drop na ślepo, możesz wprowadzić mechanizmy jego automatycznego „przerabiania” na coś mniej uciążliwego. Kilka przykładów, które świetnie działają na dłuższą metę:
taniocha typu cobblestone/dirt w resource worldach – automatyczne zamienianie nadmiaru na kompresowane bloki (np. stone/cobble/bricks) albo bezpośrednio kasowanie powyżej N stacków w chunku,
nadmiar strzał, flesh, seeds – zamiana w niewielką ilość expa lub waluty serwerowej przy użyciu specjalnych bloków (np. „palnik odpadów”),
sygnał redstone + określony blok (np. dropper nad lawą) – działanie jak „spalarnia” z lekką nagrodą (kilka XP lub symboliczna moneta) zamiast dokładania kolejnego pluginu na śmieci.
Gracze widzą, że serwer nie tylko „kasuje im drop”, ale daje alternatywę – i dużo łatwiej akceptują ostrzejsze limity.
Różne typy światów, różne limity
Jednakowe ustawienia dla wszystkich światów zwykle kończą się kompromisem, który nikogo nie satysfakcjonuje. Dużo lepiej jest ustalić osobne profile:
świat główny (survival) – łagodniejsze limity, dbałość o komfort graczy,
resource world – agresywne despawny i limity dropu, bo to „świat narzędziowy”,
end/nether – specyficzne regulacje pod farmy endermanów, piglinów i złota,
światy eventowe – czasem wręcz bez dropu z mobów, żeby event nie topił serwera.
Paper i większość pluginów anti-lag pozwala na per-world configi. Warto z tego korzystać zamiast męczyć się jednym uniwersalnym wzorem.
Przykładowy podział per-world w praktyce
Prosty, ale skuteczny schemat:
world (overworld):
merge-radius.item: 3–4,
alt-despawn dla tanich bloków – lekko skrócony,
limit itemów per chunk: 200–250.
world_mining:
merge-radius.item: 4–5,
alt-despawn: bardzo agresywny dla śmieciowych bloków,
limit itemów per chunk: 150–200,
dodatkowo okresowe czyszczenie tylko w tym świecie.
world_the_end:
delikatny nerf dropu z endermanów po przekroczeniu określonego zagęszczenia,
łagodniejsze limity itemów, żeby nie sabotować walki z bossem / raidów.
Taki podział pozwala trzymać porządek tam, gdzie jest najwięcej „śmieci technicznych”, a zostawia więcej luzu tam, gdzie gracze bawią się fabułą, eksploracją i budowaniem.
Koordynacja limitów z mechanikami redstone
Farma dropu to nie tylko moby i itemy – to jeszcze cała otoczka redstone. Źle ustawione zegary, tysiące hopperów, dziesiątki dispenserów i pistonów potrafią dobijać serwer równie skutecznie jak „dywan itemów”. Łącząc limity dropu z rozsądnym podejściem do redstone, wyciskasz max z konfiguracji.
Hoppery, wózki, magazyny – jak nie dodusić I/O
Najcięższe elementy przy dużych farmach to masowe przerzucanie itemów. Kilka prostych zasad porządkuje temat:
promuj wózki z hopperem zamiast kilometrowych linii hopperów; w configu możesz minimalnie poprawić ich wydajność, dzięki czemu gracze chętniej z nich korzystają,
zachęcaj do buforów – hoppery, które łapią drop punktowo i potem wysyłają większe porcje do głównego magazynu (zamiast jednego, niekończącego się strumienia pojedynczych itemów),
jeśli plugin od limitów itemów ma taką opcję, najpierw próbuj przekierować nadmiar do najbliższych hopperów / skrzyń, a dopiero potem kasować.
Wielu graczy po prostym pokazie „magazynu na wózkach” całkowicie zmienia styl budowy farm. Wystarczy im dać działający wzór.
Redstone clocki a limity dropu
Stare, gęste clocki generujące setki ticków redstone na sekundę plus „dywan dropu” to mieszanka zabójcza. Ograniczenia można wprowadzać na dwóch frontach:
plugin blokujący clocki poniżej określonego delayu (np. szybkie 1-tickowe pętle) i zamieniający je na nieco wolniejsze,
delikatne wyłączenie dropu z niektórych akcji redstone przy zbyt częstych wyzwoleniach (np. dispenser wyrzucający wiadra lawy/wiadra wody co tick może działać inaczej powyżej pewnego progu).
Połączenie tego z limitami dropu i merge sprawia, że nawet bardziej chaotyczne farmy nie są w stanie „zagłodzić” serwera bezpośrednio z poziomu redstone.
Monitoring po wdrożeniu – pilnowanie, żeby limity nie żyły własnym życiem
Konfigurację można ustawić raz, ale świat graczy się zmienia. Pojawiają się nowe farmy, nowe mechaniki, nowe bugi. Bez prostego monitoringu łatwo przegapić, że coś, co kiedyś działało idealnie, dziś już nie wyrabia.
Jakie metryki obserwować przy limitach dropu
Nawet bez skomplikowanych narzędzi da się wyciągnąć sporo wniosków, patrząc na kilka podstawowych wskaźników:
średni i minimalny TPS w godzinach szczytu – czy trzyma się ponad 18–19,
maksymalna liczba entity (w tym Item i ExperienceOrb) w piku – czy nie pływa między 2000 a 8000,
logi pluginów anti-lag – ile razy w ciągu godziny wchodził limit chunku / globalne czyszczenie,
skargi graczy na „znikający drop” – nie po to, żeby się denerwować, tylko żeby wyłapać powtarzalne scenariusze.
Jeśli w logach widać, że jakiś chunk jest regularnie czyszczony z itemów co parę minut, to sygnał, że trzeba przyjrzeć się konkretnej farmie albo lekko skorygować limit w danym świecie.
Mini-cykl strojenia: obserwuj → koryguj → testuj z graczami
Najlepsze efekty daje podejście iteracyjne:
Obserwuj – przez kilka dni po zmianie limitów zbieraj timings, logi pluginów, podstawowe statystyki.
Koryguj – jeśli TPS trzyma się mocno powyżej 19–20 i zapasu jest sporo, możesz lekko poluzować najostrzejsze cięcia; jeśli nadal są dołki, wręcz odwrotnie.
Testuj z graczami – poproś 1–2 „farmiarzy” o feedback, czy farmy są nadal opłacalne i czy limity nie zabijają zabawy.
Kilka takich pętli w ciągu miesiąca potrafi zbudować naprawdę zdrową równowagę między wydajnością a funem – bez wojny admin vs. „inżynierowie redstone”.
Stopniowe zaostrzanie limitów zamiast szoku jednego restartu
Najgorsze, co można zrobić, to wcisnąć brutalne limity z dnia na dzień, bo „serwer laguje, więc teraz przycinamy wszystko”. Dużo skuteczniejsze jest podejście schodkowe.
Model „trybów pracy” serwera
Świetnie sprawdza się prosty model trzech trybów, który możesz realizować skryptem, pluginem albo ręcznie, obserwując TPS:
Tryb normalny (TPS ≥ 19):
standardowe limity itemów i mobów na chunk,
łagodny despawn,
merge-radius na komfortowym poziomie.
Tryb ostrzegawczy (TPS 17–19):
lekko podbity merge-radius.item i .exp,
nieco ostrzejszy despawn dla śmieciowych bloków,
być może ograniczenie spawnów w najcięższych światach.
Tryb awaryjny (TPS < 17 przez dłuższą chwilę):
tymczasowe włączenie agresywnego czyszczenia itemów,
ściśnięcie limitów mobów na chunk,
broadcast z krótką informacją, że serwer w trybie ratunkowym – i kiedy planowany jest powrót do normalu.
Takie podejście pozwala większość czasu spędzać w trybie komfortowym, a mocniejsze „cięcia” włączać tylko wtedy, gdy naprawdę dzieje się coś złego.
Kiedy limity są już „wystarczająco dobre”
Idealnych ustawień nie ma, ale da się dojść do stanu, w którym naprawdę nie ma sensu dalej śrubować. Dobra, praktyczna miara:
serwer w godzinach szczytu trzyma co najmniej 18–19 TPS bez częstych, głębokich dołków,
większość popularnych farm działa bez dramatycznego spadku wydajności (timings nie pokazuje jednej lokacji pożerającej połowę ticka),
skargi na „znikający drop” są sporadyczne i dotyczą raczej ekstremalnych setupów niż normalnej gry.
W tym momencie lepiej inwestować czas w nowe eventy, ciekawe mechaniki czy ulepszanie ekonomii niż w kolejne 5% optymalizacji. Limity mają być tarczą przed lagami, a nie główną atrakcją serwera.
Najczęściej zadawane pytania (FAQ)
Jakie ustawienia w spigot.yml i paper.yml najbardziej wpływają na lagi z itemami?
Największy wpływ na lagujące dropy mają: item-merge-radius, limity entity w chunku oraz zasięg aktywnych chunków wokół gracza. Dobrze ustawione sprawiają, że dziesiątki przedmiotów łączą się w kilka stacków, a silnik liczy znacznie mniej entity na tick.
Na start skup się na: item-merge-radius (większa wartość = szybsze łączenie dropu), merge-radius exp (łączenie exp orbs), limitach mobów w jednym chunku oraz ograniczeniu zasięgu aktywności hopperów i redstone. Zrób jedną zmianę, odpal farmy, sprawdź TPS – wtedy łatwo wychwycisz, co daje największy efekt.
Jak sprawdzić, czy to faktycznie farmy i dropy zabijają TPS na serwerze?
Najszybszy test to „STOP” na farmach. Zatrzymaj zegary redstone, wyłącz dopływ mobów, zatrzymaj linie hopperów i po prostu popatrz na TPS oraz mspt przez kilka minut. Jeśli po wyłączeniu farm serwer wraca w okolice 19–20 TPS, a po włączeniu znowu się dusi, masz winowajcę.
Dodatkowo odpal timings lub /spark profiler (na Paper). Jeżeli w raportach najwyżej stoją sekcje związane z entity, światem, mobami, itemami i hopperami, a nie np. ekonomia czy chat, to znak, że trzeba przyciąć właśnie farmy i drop.
Czy pluginy typu ClearLag wystarczą, żeby ogarnąć lagi z dropem?
Same pluginy „clear lag” tylko gaszą pożar, gdy już jest źle – wyrzucają nadmiar entity z mapy, ale nie rozwiązują przyczyny. Jeśli farmy generują nieograniczoną ilość dropu i expa, to co kilka minut wracasz do punktu wyjścia.
Najlepszy efekt daje połączenie: poprawnie ustawione limity i merge w spigot.yml/paper.yml, rozsądne projektowanie farm (mniej hopperów, kontrola ilości mobów) oraz ewentualny plugin jako awaryjna „miotła”. Zbuduj stabilne fundamenty w konfiguracji, a plugin nie będzie musiał ratować serwera co 5 minut.
Jakie wartości item-merge-radius są bezpieczne dla wydajności i graczy?
Zbyt mały item-merge-radius powoduje setki osobnych itemów, zbyt duży może dawać dziwne zachowania (itemy zasysające się z dużej odległości). Na klasycznych serwerach survival/skyblock często sprawdzają się wartości w okolicach 3–4 dla przedmiotów i podobne lub nieco wyższe dla exp orbs.
Ustaw nową wartość, odpal największe farmy i poobserwuj: czy drop naturalnie łączy się w kilka stacków, czy gracze bez problemu zbierają itemy stojąc przy farmie. Jeśli farmy chodzą płynnie, a w okolicy nie widać „chmury” pojedynczych przedmiotów, jesteś na dobrej drodze.
Jak ograniczyć liczbę mobów i entity w chunku, żeby nie zabić farm?
Najpierw policz realne potrzeby: ile mobów naprawdę musi stać w killroomie, by gracz dostał sensowny exp i loot. Potem ustaw limity w konfiguracji (np. per-chunk lub per-świat) tak, by nie dało się kumulować setek sztuk w jednym miejscu. Dzięki temu farmy nadal działają, ale nie zamieniają się w bombę lagów.
Na Paper pomogą też opcje typu per-player-mob-spawns, ograniczenia w spawn-konfiguracji świata, a nawet proste zasady projektowe: mniejsze komory, krótsze linie transportu, brak „mega-krów” upchanych w jednym bloku. Zasada jest prosta: mniej entity w jednym punkcie = spokojniejsze ticki.
Co bardziej laguje przy farmach: moby, itemy czy hoppery?
W praktyce najcięższe są kombinacje: dużo mobów + dużo itemów + ściana hopperów i redstone. Same itemy są lżejsze niż moby z AI, ale gdy masz ich setki, każdy z nich jest sprawdzany co tick. Hoppery z kolei stale „patrzą” nad sobą i pod sobą, więc długie linie pod farmą potrafią zabić wydajność.
Dlatego ustaw limity mobów, agresywnie łącz drop (merge-radius), a hoppery stosuj oszczędnie – krótkie linie, bufory w skrzynkach, alternatywne mechanizmy transportu. Kilka świadomych zmian potrafi zamienić lagującą farmę w stabilną maszynę do dropu.
Jak szybko „odetkać” farmę, gdy nagle wszystko zaczyna lagować?
Najpierw zatrzymaj źródło problemu: wyłącz dopływ mobów, odetnij zegary redstone i zatrzymaj linie hopperów jedną dźwignią. Potem usuń nadmiar entity – komendą (np. /kill @e[type=item] w kontrolowanych warunkach) lub awaryjnym czyszczeniem z pluginu. To da serwerowi oddech.
Kiedy TPS wróci do normy, przejdź do stałych zmian: podnieś merge-radius, wprowadź limity mobów i przemyśl na nowo projekt farmy. Szybka reakcja gasi kryzys, ale to konfiguracja i przebudowa decydują, czy sytuacja się nie powtórzy.
