Autorank i OnTime w testach: czy system nagród za czas gry ma jeszcze sens dla graczy

Problem, z którym mierzą się dziś serwery: rośnie czas online, spada zaangażowanie

Objawy, które widzi admin, zanim sięgnie po Autorank lub OnTime

Gracze wchodzą, zostają na chwilę, a potem… AFK. Statystyki czasu gry wyglądają okazale, ale czat cichnie, ekonomia stoi w miejscu, a eventy nie mają frekwencji. Do tego napływ skarg, że „ktoś ma rangę tylko za to, że zostawił włączony komputer”. Jeśli te sygnały brzmią znajomo, naturalną myślą jest wdrożenie lub przeprojektowanie systemu nagród za czas gry. Dwa popularne pluginy, Autorank i OnTime, oferują tę funkcjonalność – ale czy nadal daje ona realny efekt, czy tylko pudruje liczby online?

Co obiecuje system nagród za czas gry i gdzie bywa zawód

Prosty model brzmi zachęcająco: im dłużej grasz, tym więcej dostajesz (klucze, kasa, rangi). W praktyce zbyt liniowe nagrody powodują, że część graczy traktuje serwer jak zegarek do nabijania godzin. Znika radość z progresu, a zaczyna się metagaming: alt konta na tym samym IP, makra obracające myszką, boty trzymające grę w tle. Bez mechanizmów kontroli i mądrego projektowania progi czasowe zamieniają serwer w poczekalnię, nie w żywy świat.

Najczęściej zadawane pytania przed wyborem Autorank/OnTime

• Czy nagrody za czas gry realnie zwiększą retencję, czy tylko podbiją AFK?
• Który plugin lepiej kontroluje „aktywny” czas: Autorank czy OnTime?
• Jak to zintegrować z LuckPerms, ekonomią i PlaceholderAPI bez ładowania TPS?
• Kiedy progi czasowe mają sens, a kiedy lepiej postawić na zadania lub eventy?
• Jakie reguły i limity ustawiają dziś serwery, które ograniczają puste godziny?

Dlaczego same godziny online nie wystarczają: źródła problemu

AFK to nie lenistwo – to przewidywalna odpowiedź na przewidywalny system

Gdy nagroda jest wprost proporcjonalna do czasu online i jest przewidywalna, optymalna „strategia” pojawia się sama: zostawić klienta i minimalnie symulować ruch. W każdym MMO i sandboxie gracze znajdą najkrótszą drogę do celu; Minecraft nie jest wyjątkiem. To nie zła wola – to wynik projektowania, które nie wymaga aktywności o wysokiej wartości.

Ekonomia serwera i inflacja nagród

Nagrody za czas gry to dopływ waluty lub przedmiotów, który nie ma pokrycia w aktywności generującej popyt. Jeśli dziennie do obiegu trafia X monet per gracz bez powiązania z ryzykiem i wysiłkiem, każdy sklep i aukcja dostaje zastrzyk gotówki oderwany od produkcji. Efekt? Inflacja cen, dewaluacja nagród z eventów i zadań, spadek sensu handlu.

Konflikt z innymi systemami progresu

Jeśli na serwerze istnieją już zadania, osiągnięcia, mcmmo czy przepustka sezonowa, czysty playtime może wejść im w drogę. Gracze porównują: 3 godziny „czekania” kontra 3 godziny aktywności – co się bardziej opłaca? Jeżeli obie ścieżki prowadzą do podobnej lub tej samej rangi, część społeczności wybierze łatwiejszą, a druga poczuje się zniechęcona i niesprawiedliwie potraktowana.

Autorank vs OnTime – dwie drogi do nagradzania czasu

Filozofia działania i rdzeniowe możliwości

Autorank jest znany z podejścia „ścieżek” (ang. paths): awans lub nagroda mogą wymagać nie tylko określonego czasu gry, ale też spełnienia innych warunków – od osiągnięć, przez statystyki, po komendy zewnętrznych pluginów. Dzięki temu łatwiej budować miks czasu i aktywności. OnTime skupia się na precyzyjnym rejestrowaniu czasu online, dziennych/miesięcznych statystyk i prostych progów nagród (komendy po X minutach, nagrody cykliczne), najczęściej wykorzystywany do pamiętnych „milestonów” typu 1h, 10h, 50h itd.

Integracje i ekosystem

Oba pluginy współpracują z ekosystemem permsów i ekonomii (LuckPerms, Vault/eco), a także z PlaceholderAPI, co pozwala wyświetlać postęp gracza w scoreboardach czy GUI. Autorank bywa częściej wybierany tam, gdzie zależy nam na łączeniu warunków: playtime + osiągnięcia + np. postęp w zadaniach. OnTime, jako solidny rejestrator czasu i nagród czasowych, jest ceniony na serwerach, które chcą prostej, przewidywalnej drabinki nagród bez rozbudowanych zależności.

Utrzymanie, wydajność i stabilność

Wydajność obu rozwiązań zależy głównie od tego, jak często obliczasz postęp i czy trzymasz dane w SQLite czy MySQL. Autorank ze złożonymi ścieżkami wymaga uważnej konfiguracji, by nie wywoływać lawiny zapytań i placeholderów co tick lub co sekundę. OnTime, choć z natury prostszy, potrafi generować spore wolumeny zapisów przy wielu playerach online, jeśli loguje każde wejście/wyjście i odświeża placeholdery zbyt często. Praktyka: przechowywać historię w MySQL, cachować postęp i odświeżać placeholdery w rozsądnych interwałach (np. co 5–15 s, nie co sekundę).

Porównanie funkcji w skrócie

Zakres i dokładne nazwy opcji mogą się różnić w zależności od wersji pluginów i forka serwera. Przed wdrożeniem sprawdź dokumentację odpowiedniej wersji oraz listę kompatybilności z Paper/Purpur.

Metodyka testów: scenariusze, które odpowiadają codziennej administracji

Trzy typowe środowiska wdrożeniowe

Żeby uczciwie ocenić sens nagród za czas gry, konfiguracje warto sprawdzać w co najmniej trzech scenariuszach:

• Mały survival (15–40 graczy w peaku): bez rozbudowanej ekonomii, ale z silną społecznością i naciskiem na wspólną grę.
• Skyblock/OneBlock (50–150 w peaku): wyraźna ekonomia, dużo altów, rosnące ryzyko AFK-owania.
• SMP z eventami i rankingami (30–80 w peaku): nacisk na aktywność i współzawodnictwo, okresowe resety sezonowe.

Mierzenie efektu: jak odróżnić aktywną grę od „godzin w tle”

Zanim zmienisz konfigurację, ustaw licznik, który pokaże realny wpływ. Same „godziny online” nic nie powiedzą. W praktyce sprawdza się kilka prostych metryk (zbieranych np. przez Plan, PlaceholderAPI na scoreboardzie lub proste skrypty):

• Średnia liczba interakcji na gracza na godzinę: czat, otwarcia GUI, teleporty, sethome/warp.
• Aktywność budowlana: bloki postawione/wykopane na gracza (z wykluczeniem farm w pełni automatycznych).
• Ruch w ekonomii: liczba transakcji i łączna wartość handlu na aktywnego gracza (nie na online).
• Frekwencja eventów: udział procentowy graczy zalogowanych vs biorących udział.
• Retencja „D1/D7”: ilu wraca następnego dnia i po tygodniu (zamiast samego przyrostu playtime).

Ustal bazę z ostatnich 7–14 dni, wprowadź zmiany, a potem porównuj średnie tygodniowe. Jeśli rośnie aktywność per gracz i udział w eventach, a przy tym nie puchnie podaż waluty – system działa. Jeśli rośnie tylko playtime, a reszta stoi, masz sygnał, że płacisz za czekanie.

Konfiguracje testowe, które nie zafałszują wyniku

• Magazyn danych: MySQL z asynchronicznymi zapisami; SQLite tylko dla bardzo małych, jednoświatowych instancji.
• Liczenie czasu: ignorowanie statusu AFK z EssentialsX/CMI i pauzowanie licznika w Spectator/vanish.
• Okno łaski po wejściu: pierwsze 2–3 minuty nie liczą się do nagród (eliminuje logowania „na zegarek”).
• Dzienny limit punktowanego czasu: np. 90–120 minut pełnej stawki, potem malejący mnożnik.
• Rzadkie odświeżanie placeholderów: co 5–15 s, nie częściej; scoreboardy i TAB nie muszą migać co tick.
• Zakaz liczenia czasu w regionach „stania”: spawn, hub, wyjątkowo bezpieczne farmy (WorldGuard + lista światów w pluginie).

Warianty konfiguracji: Autorank i OnTime w praktyce

Autorank: ścieżki, które wiążą czas z działaniem

Największa przewaga Autorank to możliwość spięcia playtime’u z innymi warunkami. Zamiast „X godzin = ranga”, zrób lekkie, różnorodne ścieżki:

• Ścieżka startowa: 60–90 min gry + 1 prosty quest + minimalny obrót w ekonomii. Nagroda kosmetyczna i drobna wygoda (np. +1 sethome, efekt cząsteczek).
• Ścieżka społeczna: 3–5 h w tygodniu + udział w min. 1 evencie + brak statusu AFK >90% czasu. Nagroda: dostęp do /hat, drobny booster exp przez 30 min.
• Ścieżka progresu: 10–15 h w sezonie + osiągnięcie (mcmmo/advancement) + punkty zadań. Nagroda: ranga użytkowa lub klucz o średniej wartości.

W konfiguracji ustaw niższą częstotliwość sprawdzania warunków (np. co 30–60 s), cache placeholderów oraz wyłącz liczenie w niektórych światach. Przy sezonach dodaj reset ścieżek albo sezonowy prefiks rang, zamiast akumulować przywileje w nieskończoność.

OnTime: klarowne kamienie milowe bez przesytu

OnTime sprawdza się, gdy chcesz prostego, zrozumiałego systemu „milestonów”. Żeby nie karmić AFK, zrób rzadką, ale sensowną drabinkę i dodaj cykle:

• Milestony „pamiętne”: 1 h (powitalny kosmetyk), 6 h (użyteczna, ale nieprzełomowa korzyść), 24 h (unikalny tag), 72 h (ranga społeczna bez przewagi P2W).
• Nagrody cykliczne: 30–45 min aktywnego czasu dziennie – mała skrzynka/streak. Po 5–7 dniach ciągłości – bonus, ale z 1–2 dniami marginesu na przerwę.
• Wyklucz liczenie w spawn/hub i w trakcie AFK; włącz ograniczenie nagród na IP, jeśli masz problem z altami (z zastrzeżeniem, że nie karzesz rodzin dzielących łącze – dawaj whitelist wyjątków).

Ograniczanie AFK: kombinacja sygnałów zamiast jednej sztuczki

Jedna reguła rzadko wystarcza. Skuteczne są mieszanki lekkich „popychaczy”:

• Mnożnik za aktywność kontekstową: przez 20–30 min po ukończeniu questa/udziale w evencie czas liczy się 1.5–2x. Gdy nie robisz nic – 1x lub 0.5x.
• Regiony i światy: czas w bezpiecznych miejscach liczy się mniej lub wcale; w dzikich światach i na eventach – normalnie.
• Miękki autoskick AFK: po 15–20 min statusu AFK wyloguj na lobby, ale nie karz; gracz wraca, gdy naprawdę chce grać.
• Śledzenie „aktywności sygnałowej”: ruch + interakcje z blokami + otwieranie GUI + zmiana slotu w hotbarze; pojedynczy ruch myszy nie wystarcza.
• Transparentne zasady: krótki komunikat przy wejściu i na /nagrody wyjaśnia, kiedy czas się liczy, a kiedy nie.

Krótki przykład: na OneBlocku nagroda „streak 5 dni” zlicza maksymalnie 45 min dziennie i wymaga min. 50 interakcji/otwarć GUI w tym czasie. Po wprowadzeniu takiego warunku gracze przestają „stać” i robią krótkie, aktywne sesje.

Czego unikać, nawet jeśli kusi

• Wysokich zastrzyków gotówki za sam czas. Pieniądz bez ryzyka psuje sklepy, a eventy tracą sens.
• „Maratonów” 50–100 h po jednej nagrodzie. To prosta droga do AFK pooli i altów.
• Przywilejów przewagowych (np. większe dropy, silne enchanty) za sam playtime. Kosmetyka i wygoda są bezpieczniejsze.
• Placeholderów odświeżanych co sekundę na setkach graczy. TPS zapłaci za estetykę.
• Liczenia czasu w Spectator/vanish lub podczas AFK oznaczonego przez inne pluginy.
• SQLite na serwerach z peakiem >30–40 graczy i częstymi zapisami – rosną opóźnienia i blokady pliku.
• Globalnych blokad na IP bez wyjątków – skrzywdzisz legalnych graczy z jednego domu.

Dla kogo Autorank, dla kogo OnTime: szybkie kryteria wyboru

• Wybierz Autorank, jeśli chcesz, by czas był tylko jednym z warunków i planujesz łączyć go z questami, osiągnięciami, ekonomią lub udziałem w eventach. Najlepszy na serwery, które budują długofalowy progres i chcą aktywnie walczyć z AFK przez projekt nagród.

• Wybierz OnTime, jeśli chcesz prostego, przewidywalnego systemu kamieni milowych i dziennych „streaków”, bez skomplikowanych warunków i z jasnym komunikatem „za ile czasu co dostajesz”. Sprawdza się na serwerach z większym ryzykiem altów, gdzie łatwiej egzekwować limity i cykle.
• Nie wybieraj żadnego z nich, jeśli Twoje core loop to szybkie minigry lub sezonowe eventy, gdzie sesje trwają 10–20 min i liczą się wygrane, nie godziny. Wtedy lepsze będą nagrody za wyniki i misje dzienne.
• Hybryda: OnTime do prostych, cyklicznych bonusów „za bycie”, Autorank do „awansów” powiązanych z działaniem. To bezpieczny kompromis na sieciach z różnymi trybami gry.

Szybka mapa decyzji: weekendowe wdrożenie bez chaosu

Gdy masz mało czasu i nie chcesz ryzykować odpływu graczy, trzymaj się krótkiej ścieżki:

1. Ustal cel: retencja D7 czy większa aktywność godzinowa? Jedno pierwsze, drugie później.
2. Włącz metryki bazowe (Plan lub lekkie placeholdery): interakcje/h, udział w eventach, retencja.
3. Wybierz wariant nagród o niskiej sile ekonomicznej: kosmetyka, wygoda, tagi, klucze średniej wartości.
4. Dodaj twarde ograniczniki: pauza AFK, brak liczenia na spawnie, dzienny limit punktowanego czasu.
5. Test A/B przez 14 dni: połowa nagród przez czas, połowa przez zadania/eventy. Zostaw to, co podniosło interakcje i frekwencję.

Migracja bez bólu: między OnTime a Autorank

Zmiana pluginu często kończy się utratą zaufania graczy. Da się tego uniknąć, jeśli migrację rozbijesz na etapy:

• Zamrożenie starych nagród: ogłoś datę graniczną, po której stare kamienie milowe nie dają nowych profitów, ale nie odbieraj już przyznanych rang.
• Mapowanie progresu: wyeksportuj czas gry (lub rangę) do tymczasowych permisji LuckPerms i użyj ich jako warunków startowych w nowym systemie.
• Podwójne naliczanie przez 7 dni: licz czas w obu systemach, ale nagradzaj tylko nowy. Dzięki temu wyłapiesz błędy bez strat dla graczy.
• Komunikacja w grze: krótki /info z zasadami, kiedy czas się liczy, kiedy nie. Jednoznaczne, bez ściany tekstu.
• Archiwizacja: zrzut danych do MySQL/CSV i snapshot LP przed zmianami. Gdy coś pójdzie źle, przywracasz stan w minutę.

Drobna praktyka: przy migracji z OnTime do Autorank zostaw pierwszy „lekki” milestone OnTime (np. 1 h = kosmetyk). Działa jak pas bezpieczeństwa i łagodzi przejście na bardziej wymagające ścieżki.

Minimalne konfiguracje startowe: dwa sprawdzone wzorce

Wzorzec: survival społecznościowy

• Autorank: 2–3 krótkie ścieżki łączące 60–90 min czasu z drobnym questem i jednym osiągnięciem.
• Mnożnik 1.5x na 30 min po evencie/questcie; poza tym 1x.
• Brak nagród pieniężnych; kosmetyka + małe wygody (/hat, +1 sethome).
• Pauza w spawnie i podczas AFK; limit 90 min „pełnego naliczania” dziennie.

Wzorzec: Skyblock/OneBlock z altami

• OnTime: rzadkie, czytelne milestony (1 h, 6 h, 24 h, 72 h) + dzienne streaki po 30–45 min.
• Limit nagród na IP z listą wyjątków (rodziny), ścisły zakaz liczenia na wyspie AFK i w hubie.
• Nagrody bez wpływu na inflację: klucze kosmetyczne, tagi, krótkie boostery EXP.
• Dodatkowy warunek „aktywności sygnałowej” w godzinie: min. X interakcji/otwarć GUI.

Pułapki wydajnościowe i jak je obejść

• Zbyt częste sprawdzanie warunków: celuj w interwał 30–60 s. Placeholdery odświeżaj rzadziej niż scoreboard.
• Brak cache dla danych graczy: włącz wewnętrzne cache pluginów i asynchroniczne zapisy do MySQL.
• Dużo jednorazowych nagród przy logowaniu: rozłóż na ticki lub paczki co kilka sekund, żeby nie dusić serwera.
• Nagradzanie w trakcie eventów masowych: odłóż przyznanie do końca eventu (kolejka), unikniesz spike’ów TPS.
• Światy „farmowe” bez limitów: nadaj niższe mnożniki lub wyklucz z liczenia – mniej fałszywego czasu.

Rekomendacja wdrożenia na start: bezpieczny wybór i następny krok

Dla małych i średnich survivali: Autorank z krótkimi ścieżkami + mnożnik po aktywności, bez nagród pieniężnych, z limitem 90–120 min dziennie i pauzą AFK/spawn. Dla trybów z presją na alty: OnTime z rzadkimi milestone’ami, streakami 30–45 min, limitem na IP i warunkiem aktywności sygnałowej. Na serwerach eventowych połącz oba: OnTime jako tło, Autorank jako „awanse” za działanie.

Następny rozsądny krok: włącz metryki bazowe, ustaw wybrany wariant na 14 dni i porównaj interakcje na gracza, frekwencję eventów oraz retencję D7. Jeśli rośnie tylko playtime – zacieśnij warunki aktywności lub przenieś część nagród z czasu na zadania.

Pytania, które od razu ustawiają kierunek

Zanim wybierzesz wtyczkę i rozrysujesz nagrody, odpowiedz krótko na kilka pytań. Ułatwią dopasowanie rozwiązania bez nadmiaru konfiguracji:

• Czy chcesz, aby sam czas gry wystarczał do awansu, czy ma być tylko „klejem” między zadaniami? Jeśli „klej” – skłania to ku Autorank.
• Czy Twoja społeczność akceptuje dłuższy, czytelny progres (kamienie milowe), czy raczej krótkie dzienne sesje z małą nagrodą? Jeśli krótkie sesje – OnTime będzie prostszy.
• Czy masz realny problem z altami/AFK? Jeśli tak, preferuj prosty, cykliczny design z twardymi limitami i sygnałami aktywności (OnTime lub hybryda z jego streakami).
• Czy planujesz integrować questy/osiągnięcia/ekonomię? Jeśli tak, Autorank i jego warunki łączone dadzą większą elastyczność.
• Jaka jest „waluta” Twojego serwera: wygrane, współpraca, czy eksploracja? Jeśli wygrane – rozważ odejście od czasu gry na rzecz wyników/misji dziennych.

Integracje, które robią różnicę w praktyce

Słaby system nagród często „psuje się” nie przez samą wtyczkę, ale przez brak integracji. Kilka mostów, które oszczędzą Ci biegania za problemami:

• LuckPerms: przyznawaj rangę/perm na czas (temporary) i w kontekście (np. tylko w danym świecie). To łagodzi P2W i ogranicza inflację przywilejów.
• PlaceholderAPI: pokazuj progres selektywnie (np. w /nagrody i w menu), a scoreboard odświeżaj rzadko. Przez to oszczędzasz TPS bez odbierania informacji graczowi.
• Plan lub alternatywne analityki: patrz na interakcje/h, powroty D7 i udział w eventach. Sam playtime to zbyt płaska metryka.
• Quests/AdvancedAchievements/Jobs: łącz warunki – „x minut aktywnego czasu + drobny quest + 1 osiągnięcie”. Autorank zagra tu najczyściej.
• DiscordSRV: ogłaszaj milestone’y w dedykowanym kanale. Widoczność postępu podbija motywację bez pompownia nagród.
• Regiony/światy (WorldGuard, Multiverse): wyklucz lub osłab naliczanie w hubie i farmach. Jeśli wtyczka nie ma natywnego wsparcia, zastosuj komendy przy wejściu/wyjściu do regionu.
• AFK z EssentialsX/CMI/inne: szanuj flagę AFK – pauzuj licznik. Gdy brak natywnego hooka, stosuj „miękki” autoskick i warunek aktywności sygnałowej po stronie nagród.

Aktywny czas w praktyce: szybkie wdrożenie w obu wtyczkach

Jeśli nie chcesz przekopywać się przez dziesiątki opcji, przejdź ten krótki zestaw kroków.

Autorank – kiedy czas to tylko jeden z warunków

• Ustal krótkie ścieżki: 60–90 min „aktywnego” czasu + mini-quest + lekkie osiągnięcie.
• Powiąż nagrody z kontekstem LP (np. +1 sethome tylko na survivalu).
• Włącz mnożnik 1.5x po evencie/questcie (krótkie okno 20–30 min). Reszta – 1x.
• Oprzyj pauzowanie czasu o status AFK z zewnętrznego pluginu lub wyklucz wybrane światy/regiony.
• Progi i komunikaty: /nagrody pokazuje tylko najbliższy krok, nie całą ścianę nagród.

OnTime – kiedy potrzebna jest prostota i czytelne streaki

• Ustaw rzadkie kamienie milowe (1 h, 6 h, 24 h, 72 h) i dzienny limit punktowanego czasu (30–45 min).
• Dodaj warunek „aktywności sygnałowej” (ruch + interakcje + zmiana slotu). Brak aktywności – dzień bez streaka.
• Włącz limit nagród na IP z białą listą wyjątków (rodziny). Komunikat przy wejściu wyjaśnia zasady.
• Odłącz naliczanie w hubie/spawnie i na wyspach AFK. Jeśli to trudne, zastosuj mniejszy mnożnik (0.5x) w tych strefach.
• Nagrody trzymają się kosmetyki i wygody; pieniądz i surowce – poza systemem czasu.

Monitoring po 7 i 30 dniach: progi reakcji zamiast przeczuć

Krótka pętla sprawdzająca pozwala szybko wyłapać „puste” godziny i skorygować kurs:

• Interakcje na gracza/h: jeśli rosną tylko minuty, a interakcje stoją lub spadają, zaostrz warunki aktywności i skróć dzienny limit punktowania.
• Retencja D7: jeśli powroty nie drgnęły, a wydłużyły się sesje, przenieś część nagród z czasu na zadania/eventy.
• Udział w eventach: spadek przy jednoczesnym wzroście playtime to sygnał, że gracze „odbijają” godziny obok core loopa.
• Ratio unikalne IP → konta: jeśli rośnie liczba kont na to samo IP tuż po wprowadzeniu nagród – wzmocnij limity i włącz whitelist wyjątków.
• TPS i czasy zapisu bazy: gdy pojawiają się skoki, wydłuż interwały sprawdzania warunków i przenieś zapisy do MySQL z cache i zapisami async.

Mini-przykład korekty bez dramatu

Po tygodniu na Skyblocku widać wzrost playtime, ale interakcji/brak. Zamiast kasować system, wprowadzasz drobne zmiany: dzienny limit 45 → 30 min, dodany wymóg 40 interakcji i 1 mini-quest tygodniowo, a pierwsza nagroda pieniężna zamieniona na tag i krótkie boostery EXP. Po kolejnych 7 dniach rośnie udział w eventach i interakcje/h, a playtime utrzymuje się bez AFK-pooli.

Gdy czas nie powinien być walutą: szybki filtr negatywny

Nie każdy tryb skorzysta z czasu jako podstawy progresu. Jeśli rozpoznajesz te sygnały, odpuść lub zostaw system tylko w tle:

• Core loop to pojedyncze, krótkie mecze lub sezony resetowane co kilka tygodni.
• Największą wartością są wygrane, rangi sezonowe lub ladder – czas poboczny tylko rozmywa sygnał umiejętności.
• Wysoka podatność na alty i AFK, brak moderacji i mało zasobów na integracje/monitoring.
• Ekonomia napięta inflacją – każdy zastrzyk „za nic” szkodzi sklepom i progresji.

Migracja i hybrydy: bezbolesne przejście między Autorank a OnTime

Najczęstsza obawa przy zmianie systemu: utrata postępu i podwójne nagrody. Druga – chaos w permach po „przepięciu” ścieżek. Da się to przejść spokojnie, jeśli rozdzielisz źródło prawdy o czasie od logiki nagród i na chwilę „zamrozisz” awanse.

Skąd biorą się problemy podczas zmiany

• Różna semantyka czasu: OnTime liczy surowy playtime i streaki; Autorank – warunki łączone (czas + zadania). Prosty import minut potrafi zdewaluować ścieżki.
• Duplikacja nagród: oba pluginy mogą wywołać te same komendy (np. ranga + klucz) w tym samym oknie czasu.
• Niespójność baz: części graczy masz w SQLite, części w MySQL; do tego cache w pamięci, który nie odświeży się od razu.
• IP/alty: w trakcie migracji limity bywają chwilowo rozluźnione – idealny moment na nadużycia.

Plan przejścia w 6 krokach

• Zamroź awanse: na 24–48 h wyłącz automatyczne przyznawanie nagród (lub przenieś je na „tylko logowanie” do konsoli). Komunikat przy wejściu wyjaśnia przerwę techniczną.
• Ustal jedno źródło prawdy o czasie: wskaż, który plugin będzie licznikiem (np. OnTime → czas/streak; Autorank → warunki i komendy). Drugi czyta tylko placeholdery, bez własnego naliczania.
• Mapowanie postępu: zamiast 1:1 przenosić minuty, przypisz graczy do najbliższych kamieni milowych lub rang. To ogranicza inflację i „przepalenie” połowy ścieżek w dzień.
• Okres cienia (shadow): przez 7 dni trzymaj stary i nowy system równolegle, ale nagrody wydaje tylko jeden (np. OnTime). Drugi loguje, komu przyznałby nagrodę. Po tygodniu porównujesz rozjazdy.
• Bezpieczne przełączenie: gdy logi z cienia wyglądają dobrze, włącz nagrody w nowym systemie i usuń lub wycisz duplikujące się akcje w starym. Permy nadaj tymczasowo (temporary), by łatwo je cofnąć, jeśli coś strzeli.
• Anty-alt na czas migracji: podnieś próg interakcji, skróć dzienny limit punktowania i trzymaj whitelist IP dla rodzin. To minimalizuje „skok na kasę”.

Szybki przykład z praktyki: na małym survivalu OnTime dawał klucze za 1 h i 6 h. Po przejściu na Autorank, stare 6 h mapujesz do rangi „Settler”, ale bez retro-klucza – zamiast tego gracz dostaje okno 30 min z mnożnikiem 1.5x na aktywny czas. Efekt: nikt nie czuje straty, a serwer nie dostaje zastrzyku darmowych przedmiotów jednego dnia.

Czego unikać przy migracji

• Masowego „wypłacenia różnicy” w jednym momencie – rozłóż zaległe nagrody na kilka dni lub zamień je na kosmetykę.
• Resetu bez komunikacji – nawet uczciwe ruchy wyglądają źle bez krótkiego, konkretnego powodu i daty domknięcia.
• Mieszania logiki nagród – albo streaki (OnTime), albo ścieżki (Autorank) decydują, nigdy oba naraz o tej samej rzeczy.
• Importu minut AFK – jeśli nie masz wiarygodnych sygnałów aktywności z przeszłości, przenoś tylko progi (rangę docelową), nie surowy czas.

Rekomendacja: w sieciach i trybach z altami trzymaj OnTime jako licznik/streak i używaj jego placeholderów w Autorank do warunku „czas + aktywność”. Na prostym survivalu odwrotnie – Autorank niech steruje ścieżkami, a OnTime działa w tle jako dzienny limit i sygnał powrotów.

Sygnały aktywności, które działają, i takie, które mylą

„Aktywność sygnałowa” brzmi prosto, a najczęściej wysypuje się na szczegółach. Chodzi o to, by AFK z makrem nie przechodził, a normalny gracz nie czuł kar za budowanie czy handel.

Co liczyć, by nagradzać realną grę

• Miksy zdarzeń w oknie czasu (np. 5–10 min): ruch w przestrzeni + interakcje z blokami/GUI + zmiana slotu w hotbarze.
• Różnorodność interakcji: minimum X typów akcji (otwarcie skrzyni, craft, handel, zniszczenie/blokada, rozmowa z NPC), a nie tylko „porusz się 10 bloków”.
• Akcje powiązane z trybem: na Skyblocku ważniejsze są GUI/ekonomia; na survivalu – place/break, obrażenia zadane/otrzymane, eksploracja regionów.
• Losowy test żywotności: drobny, nieregularny „ping” – np. wymaganie pojedynczej interakcji w losowej minucie okna. Makro częściej tu zawiedzie.

Typowe fałszywe pozytywy i jak je wycinać

• Makro „kręciołek” myszką: licz łączny przesunięty dystans i zmianę wysokości, nie sam obrót kamery.
• Auto-kliker w jednym slocie: wymagaj zmiany slotu lub dwóch różnych interakcji w oknie czasu.
• Farmy z wodą/tłokami: ruch bez akcji traktuj jako 0.5x lub 0x – pełne punktowanie tylko przy mieszanych sygnałach.
• Spam w czacie: tekst sam w sobie nie podbija aktywności; liczy się w połączeniu z innymi zdarzeniami.

Krótki, bezbolesny próg startowy: w godzinie punktowania wymagaj minimum 30–60 „zdarzeń istotnych” i przynajmniej dwóch typów interakcji. Jeśli wypadnie event masowy, dopuść alternatywę – obecność w regionie eventowym + udział w jednej aktywności.

Pułapki wdrożeniowe

• Za ostry filtr na start: nowi gracze z krótkimi sesjami odpadają. Obniż próg w pierwszych 2–3 dniach od pierwszego wejścia.
• Globalne reguły dla wszystkich trybów: to, co działa na survivalu, zabija komfort na trybach z menu/GUI. Ustal reguły per-świat.
• Brak komunikacji: jeśli gracz nie wie, czemu „dzień bez streaka”, spróbuje obejścia. Dodaj lekkie wskazówki w /nagrody i krótkie tipy po niezaliczonej godzinie.

Rekomendacja: zacznij od miękkich sygnałów (miks ruchu i interakcji), przetestuj je na grupie stałych graczy, a dopiero później dokręcaj śrubę losowymi „pingami” i limitami per-świat. Zyskasz uczciwość bez wrażenia, że serwer „poluje” na każdą bezczynną minutę.