Kalkulator ticków Minecraft

W Minecraft czasem myślisz o czasie w sekundach, a gra w tle liczy ticki. Drzwi redstone zamykają się o dwa kroki za wcześnie, linia hopper opróżnia się wolniej, niż oczekujesz, albo wpisujesz liczbę w komendzie /time set, ale słońce nie zatrzymuje się tam, gdzie chcesz. Najczęściej problem nie polega na tym, że gra jest zepsuta; chodzi o to, że traktujesz czas rzeczywisty, game tick i redstone tick jak to samo. Takie pomyłki zdarzają się bardzo często, szczególnie osobom, które dopiero zaczynają z redstone.

Czas gry nie płynie jak sekundy

Podstawowy rytm Minecrafta działa na game tickach. W grze vanilla docelowa prędkość to 20 game ticków na sekundę. Czyli:

$$
1 \text{ sekunda} = 20 \text{ game tick}
$$

Jeden game tick odpowiada też 0,05 sekundy.

$$
1 \text{ game tick} = 0{,}05 \text{ sekunda}
$$

Na papierze jest to całkiem proste.

Jeśli wpiszesz 60 sekund, otrzymasz 1200 game ticków. 1 minuta to tak samo 1200 game ticków. 10 minut to natomiast 12000 game ticków. Stąd łatwo też zrozumieć, dlaczego pełny cykl dnia w Minecraft ma 24000 ticków; w świecie działającym przy 20 TPS 24000 ticków to 20 minut w rzeczywistości.

Gdy TPS spada, sytuacja się zmienia. 1200 game ticków trwa 60 sekund przy 20 TPS. Jeśli serwer spadnie do 10 TPS, te same 1200 ticków rozciągnie się w rzeczywistości do 120 sekund. To, na co patrzysz w grze i pytasz „czemu to się spóźniło?”, czasem nie wynika z układu, lecz z przeciążenia serwera.

Główny wzór do obliczania czasu jest taki:

$$
\text{Game Tick} = \text{sekunda} \times \text{TPS}
$$

Odwrotnie zapisuje się go tak:

$$
\text{sekunda} = \frac{\text{Game Tick}}{\text{TPS}}
$$

Dla wersji vanilla zazwyczaj przyjmuje się TPS jako 20. Jeśli serwer laguje i próbujesz zrozumieć rzeczywisty czas oczekiwania, trzeba wpisać faktyczną wartość TPS; w przeciwnym razie obliczenie pozostanie teoretyczne.

To rozróżnienie szczególnie przeszkadza w automatycznych farmach i układach redstone. Konstrukcja, która działa poprawnie w trybie singleplayer, na zatłoczonym serwerze może zachowywać się wolniej. Gra nadal wymaga tej samej liczby ticków, po prostu przetwarza je wolniej.

Redstone tick mówi innym językiem

W Minecraft samo słowo „tick” bywa trochę zdradliwe. Jeśli ktoś mówi „dodaj delay 10 ticków”, najpierw trzeba zrozumieć, czy chodzi o game tick, czy redstone tick. Po stronie redstone 1 redstone tick przyjmuje się jako 2 game ticki. Przy prędkości vanilla daje to 0,1 sekundy.

$$
1 \text{ redstone tick} = 2 \text{ game tick}
$$

$$
1 \text{ redstone tick} = 0{,}1 \text{ sekunda}
$$

10 redstone ticków to 20 game ticków. Ale 10 game ticków to tylko 5 redstone ticków.

$$
\text{Game Tick} = \text{Redstone Tick} \times 2
$$

$$
\text{Redstone Tick} = \frac{\text{Game Tick}}{2}
$$

Gdy pomylisz te dwa pojęcia, czas układu rozjedzie się dwukrotnie. W drzwiach pistonowych, blokadach item sorterów i łańcuchach observerów ta różnica od razu staje się widoczna. Drzwi zacinają się tam, gdzie powinny się zamknąć, piston nie łapie bloku, sorter przepuszcza za dużo itemów. Potem człowiek obwinia okablowanie. A czasem przewody są niewinne.

Dlatego opóźnienie repeatera trzeba traktować osobno. Repeater może dać opóźnienie 1, 2, 3 albo 4 redstone ticków. Jeśli chcesz dłuższe opóźnienie, ustawiasz repeatery jeden za drugim.

Załóżmy, że potrzebne jest opóźnienie 46 game ticków. Najpierw przeliczamy je na redstone ticki:

$$
46 \text{ game tick} \div 2 = 23 \text{ redstone tick}
$$

Aby zbudować 23 redstone ticki za pomocą repeaterów, potrzeba 5 pełnych repeaterów 4-tick, a zostają jeszcze 3 redstone ticki.

$$
23 = 5 \times 4 + 3
$$

Czyli układ odczytuje się tak:

5 x 4-tick + 1 x 3-tick.

Tutaj wchodzi też logika zaokrąglania w górę. Jeśli obliczenie nie trafia dokładnie w redstone tick, bezpieczniej jest dopełnić je do wyższej wartości, zamiast dać zbyt małe opóźnienie. W końcu nie ma połówkowego ustawienia repeatera. Jest albo 2 ticki, albo 3 ticki. Nic pomiędzy.

Praktyczne wyrażenie używane po stronie repeaterów wygląda tak:

$$
\text{Repeater Redstone Tick} = \left\lceil \frac{\text{Game Tick}}{2} \right\rceil
$$

Następnie znajduje się liczbę repeaterów 4-tick:

$$
\text{Liczba repeaterów 4-tickowych} = \left\lfloor \frac{\text{Redstone Tick}}{4} \right\rfloor
$$

Pozostałe opóźnienie wyznacza się przez modulo:

$$
\text{Pozostałe} = \text{Redstone Tick} \bmod 4
$$

W redstone takie małe różnice potrafią czasem bardzo urosnąć. Szczególnie w szybkich konstrukcjach pistonowych sygnał, który ma przyjść „o jeden tick później”, może decydować o tym, czy cała budowla zadziała poprawnie. To jedna z bezlitosnych stron gry.

Dlaczego wartości /time set wyglądają dziwnie?

Dzień w Minecraft trwa 24000 game ticków. Ruch słońca, cykl dnia i nocy oraz komenda /time set działają właśnie na tej osi. Gdy wpiszesz 6000, robi się południe. Około 12000 to zachód słońca. 18000 można traktować jak północ.

Ale logika zegara na pierwszy rzut oka nie zaczyna się tak jak w prawdziwym świecie. Tick 0 w grze odczytuje się mniej więcej jako 06:00. Dlatego 6000 ticków odpowiada około 12:00. 18000 ticków wypada w okolicy 00:00.

Obliczenie ticka w obrębie dnia sprawdza resztę z dzielenia wpisanej wartości ticków przez 24000:

$$
\text{Dzień Tick} = \text{Game Tick} \bmod 24000
$$

Czyli nawet jeśli wpiszesz 25000 ticków, gra odczyta to jako 1000. tick nowego dnia. Po 24000 cykl zaczyna się od nowa.

Przybliżone obliczenie odpowiednika godziny wygląda tak:

$$
\text{Godzina} = \left\lfloor \left(\frac{\text{Dzień Tick}}{1000} + 6\right) \bmod 24 \right\rfloor
$$

Dla minut pozostałą wartość ticków mnoży się przez 0,06:

$$
\text{Minuta} = \text{round}((\text{Dzień Tick} \bmod 1000) \times 0{,}06)
$$

Dla 6000 ticków wynik wychodzi w przybliżeniu 12:00.

$$
\left(\frac{6000}{1000} + 6\right) \bmod 24 = 12
$$

Twórcy map często z tego korzystają. Przydaje się to również przy robieniu zrzutów ekranu. Czasem nawet kierunek cienia zmienia scenę; osoby robiące zdjęcia w grze wiedzą, że światło poranka i światło południa nie dają tego samego wrażenia.

Tę krótką listę łatwo zapamiętać:

Wpisanie 24000 i wpisanie 0 w większości przypadków prowadzi do tego samego. Gra przewija cykl z powrotem na początek.

Czekanie z prędkością hoppera to osobny problem

Hopper jest jednym z najcichszych elementów Minecrafta, ale też jednym z tych, które najczęściej tworzą wąskie gardła. Przeniesienie jednego itemu do innego ekwipunku wymaga 8 game ticków. Przy 20 TPS daje to 0,4 sekundy.

$$
1 \text{ transfer przez hopper} = 8 \text{ game tick}
$$

$$
1 \text{ transfer przez hopper} = 0{,}4 \text{ sekunda}
$$

Prędkość przesyłania jednego hoppera na minutę oblicza się tak:

$$
\text{Item / Minuta} = \frac{\text{TPS} \times 60}{8}
$$

Jeśli TPS wynosi 20:

$$
\frac{20 \times 60}{8} = 150
$$

Czyli jeden hopper przenosi około 150 itemów na minutę.

Wyobraźmy sobie stos 400 itemów. Najpierw znajdujemy jego odpowiednik w tickach:

$$
400 \times 8 = 3200 \text{ game tick}
$$

Potem przeliczamy to na sekundy:

$$
\frac{3200}{20} = 160 \text{ sekunda}
$$

160 sekund to 2 minuty i 40 sekund.

Ta liczba może wyglądać na małą, ale nie wydaje się taka mała, gdy stoisz przy skrzyni i czekasz, aż farma pracuje. Zwłaszcza jeśli system produkuje 300 itemów na minutę, a ty próbujesz zbierać je jednym hopperem, zator jest nieunikniony. Itemy zaczynają się gromadzić, potem powstaje kolejka hopperów, a następnie widzisz itemy leżące na ziemi.

Itemy na ziemi to sposób, w jaki system magazynowania mówi: „nie nadążam”.

W obliczeniach hoppera nie należy popełnić jednej pomyłki: ta prędkość dotyczy jednego hoppera. Jeśli kilka linii działa równolegle, przepływ rośnie. Jeśli łańcuch hopperów jest bardzo długi, każdy transfer dodaje własne opóźnienie. Jeśli używasz kanału wodnego, linii dropperów, chest minecartu albo modowanego systemu transportu, temat się zmienia. To obliczenie służy głównie do szybkiego odczytania zachowania vanilla hoppera.

TPS wpływa tutaj również na rzeczywisty czas. 400 itemów przy 20 TPS przenosi się w 160 sekund, ale przy 10 TPS wydłuża się to do 320 sekund.

$$
\frac{3200}{10} = 320 \text{ sekunda}
$$

Liczba ticków w grze jest taka sama, ale rzeczywisty czas oczekiwania jest dwa razy dłuższy. To czasem powód, dla którego na serwerze ktoś pyta: „czy hopper się zepsuł?”. Nie zepsuł się, po prostu świat stał się cięższy.

Którego trybu używać i kiedy?

Jeśli masz pytanie „ile sekund?”, wystarczy prosta konwersja. Na przykład jeśli mówisz „drzwi mają się zamknąć po 5 sekundach”, 5 sekund to 100 game ticków.

$$
5 \times 20 = 100 \text{ game tick}
$$

Tyle wiedzy wystarczy do command blocków albo prostych zadań z opóźnieniem.

Jeśli budujesz układ redstone, patrz na opóźnienie repeatera. Bo w grze umieszczasz nie sekundy, lecz ustawienie repeatera. Opóźnienie 2 sekund to 40 game ticków, czyli 20 redstone ticków.

$$
2 \times 20 = 40 \text{ game tick}
$$

$$
40 \div 2 = 20 \text{ redstone tick}
$$

20 redstone ticków można zbudować za pomocą 5 repeaterów 4-tick.

Dla czasu Minecraft potrzebna jest wartość /time set. Jeśli chcesz „niech będzie południe”, wpisujesz 6000; jeśli chcesz „niech będzie północ”, wpisujesz około 18000. Tutaj nie mówimy o sekundach, tylko o pozycji ticków w obrębie dnia.

Po stronie hoppera pytanie jest zupełnie inne: „Ile czasu zajmie przepływ tylu itemów?”. Rozsądniej jest wpisać liczbę itemów i zobaczyć czas. Przydaje się to szczególnie przy wyjściach automatycznych farm, aby zrozumieć, czy jeden hopper wystarczy.

Wybór jednostki ma znaczenie. Game tick, redstone tick, sekundy, minuty, transfer hoppera i dzień Minecraft mogą wyglądać jak różne oblicza tej samej rzeczy, ale w grze służą do różnych decyzji. Możesz myśleć o sekundach jako o czasie człowieka, o game ticku jako o czasie gry, a o redstone ticku jako o czasie układu.

Trochę na skróty, ale działa.

Jeśli obliczenie jest poprawne, dlaczego gra zachowuje się inaczej?

Nawet jeśli obliczenie ticków jest poprawne, wynik w grze może nie pokrywać się idealnie. Jest kilka powodów.

Pierwszy to TPS. Jeśli serwer nie działa przy 20 TPS, rzeczywisty czas się wydłuża. Zanim gra powie „minęło 1200 ticków”, w rzeczywistym świecie mogłeś czekać ponad 60 sekund. Komenda, redstone ani obliczenie hoppera nie są zepsute; po prostu kończą się później.

Drugi to ładowanie chunków. Jeśli chunk nie jest załadowany, niektóre systemy w tym miejscu nie działają tak, jak oczekujesz. Linia hopperów, farma, redstone clock; wszystko zależy od tego, czy świat pozostaje aktywny. Konstrukcja zostawiona daleko od gracza nie zawsze będzie nadal działać tak, jak zakładasz.

Trzeci to kolejność aktualizacji redstone. Redstone to nie tylko obliczanie czasu. Liczy się to, skąd przychodzi sygnał, który blok aktualizuje się pierwszy, kierunek repeatera, zachowanie comparatora oraz to, co piston widzi i kiedy. Czasem 4 ticki to poprawna wartość, ale układ obwodu jest zły.

Są też różnice między Java i Bedrock. Chociaż większość podstawowych proporcji czasu wygląda tak samo, różnice w zachowaniu redstone między wersjami mogą sprawiać problemy. Nie jest zaskoczeniem, gdy ktoś ogląda układ Java na YouTube, buduje go jeden do jednego w Bedrock, a potem okazuje się, że nie działa.

Kalkulator nie robi w tym miejscu magii. Daje czysto część związaną z czasem. Resztę określa fizyczny układ w grze.

Kilka małych, ale przydatnych nawyków

Najpierw doprecyzuj, o który „tick” chodzi. Game tick czy redstone tick? Wchodzenie w obliczenia układu bez tego pytania jest trochę jak stawianie bloków bez mierzenia.

W długich liniach hopperów nie polegaj na prędkości jednego hoppera. Jeśli farma produkuje więcej niż 150 itemów na minutę, jedna linia w pewnym momencie się zatka. Czy potrzebne są dwie linie, przepływ wody, czy dropper clock; to zależy od projektu.

W komendach /time set zamiast zapamiętywać wszystkie liczby, poznaj kilka głównych punktów: 0 rano, 6000 południe, 12000 wieczór, 18000 północ. Resztę można ustawić na oko. Minecraft i tak jest trochę grą wyczucia.

Przy opóźnieniu repeaterów wygodnie jest myśleć blokami 4-tick. Najpierw przelicz opóźnienie na redstone ticki, a potem podziel je na części po 4. Jeśli zostanie 1, 2 albo 3, dodajesz na końcu jeszcze jeden repeater.

Nie zapominaj też całkowicie o TPS. W świecie singleplayer założenie 20 TPS zwykle wystarcza. Jeśli na serwerze rzeczy zaczynają zachowywać się dziwnie, rozsądniej jest najpierw sprawdzić TPS. Zanim rozbierzesz linię redstone, właśnie tak.