Kormic

Nie zdziwiłbym się gdyby pojawienie się problemu było częściowym (jeśli nie całościowym) następstwem używania PlugMana (rzecz jasna, mówimy również o PlugManX). Dla samego sprawdzania proszę go odinstalować i zrestartować serwer. Jeśli to nie pomoże, należy szukać dalej. Warto również sprawdzić czy wszystkie wtyczki (pluginu) są aktualne dla wersji Pana serwera. PlugMan jeśli już to powinien być wykorzystywany do przeładowywania małych pluginów, które zazwyczaj się samodzielnie tworzy (choć i tu nie jest niemożliwe, że coś pójdzie nie tak w trakcie tego procesu), a nie do takich kobył jak Skript. Nie bez powodu większość wtyczek posiada własne komendy przeładowujące chociażby pliki konfiguracyjne. W ramach ciekawostki mogę zdradzić, że w wersji Skripta 2.10 może zostać wprowadzone ostrzeganie przez Skripta przy każdorazowym użyciu czy to PlugMana, czy to komendy /reload. Właśnie odbywa się rozmowa na ten temat na serwerze Discord SkUnity. I dobrze. Pozdrawiam.

Problem został rozwiązany.

Tak jak napisałem, oba te zdarzenia wykorzystują zdarzenie 'PlayerMoveEvent', które pochodzi z Bukkit API (w dużym skrócie, z tego korzystają wszystkie wtyczki (pluginy)), więc są one porównywalne. Warto jednak zauważyć, że zdarzenie 'on region enter' wiąże się z potencjalnym sprawdzaniem wielu informacji ze strony pluginu zarządzającego regionami, co skłania raczej ku użyciu zdarzenia 'on player move' jeżeli nie ma potrzeby wykorzystania regionów przy tym problemie. Jeszcze jedno. Proszę się nie bać korzystania ze zdarzenia 'on player move', ponieważ dla każdego gracza jest ono wywoływane nie więcej niż 20 razy na sekundę. Tego typu zdarzenia mają złą reputację przez to, że wielu twórców pluginów i skryptów (zwłaszcza tych drugich) ma tendencję do dodawania dziesiątek linijek kodu do listenerów tego zdarzenia. Kod, który Pan pokazał, nie będzie obciążający dla serwera. Swoją drogą, istnieją zdarzenia, które są znacznie częściej wywoływane. Dobrym przykładem jest zdarzenie 'on physics', które jest powiązane z każdą zmianą stanu bloku, która może być spowodowana przez jakikolwiek byt lub być następstwem naturalnych procesów zachodzących w grze. Na serwerach z większą ilością graczy zdarzenie te jest wywoływane czasem tysiące razy na sekundę (a więc niejednokrotnie kilkaset razy na tick). Pozdrawiam.

Pytanie trochę źle zadane, bo "poprawnie" raczej interpretowałbym jako to, że przeładowanie skryptu odbywa się bez błędów i nie występuje dziwne działanie z jego strony. No ale dobrze, mniejsza o to. Jeżeli gracz ma być teleportowany po przekroczeniu pewnej wysokości to nie ma innego sposobu aby to zrobić, bo musimy sprawdzać co tick czy gracz się poruszył (to właśnie robi zdarzenie 'on player move') i czy spadł poniżej zadanej wysokości. Oczywiście ktoś mógłby wpaść na genialny pomysł wykorzystania regionów i zdarzenia 'on region enter', ale wszystko nadal kręci się wokół zdarzenia 'PlayerMoveEvent', które wykorzystują zarówno Skript jak i chociażby WorldGuard za kulisami. Mogę więc stwierdzić, że trudno o wymyślenie lepszego rozwiązania. Pozdrawiam.

Ten temat został przeniesiony.

Ten temat został przeniesiony.

Ten temat został przeniesiony.

Ten temat został zamknięty.

Zlecenie zostało wykonane.

Ten kod jest niepoprawny, ponieważ każde przeładowanie skryptu będzie wiązało się z utworzeniem nowej pętli 'while', a taką pętlę można przerwać w Skript'cie tylko wewnątrz niej lub poprzez zrestartowanie serwera. W konsekwencji może powstać wiele pętli, które będą się na siebie nakładały swoim działaniem, co sprawi nieprzewidywalne ustawianie wartości zmiennej '{animation.welcome}'. Rozwiązanie powinno więc korzystać z okresowo wykonującego się fragmentu kodu (ang. 'periodical'), co zapobiegnie powstaniu równolegle działającym pętlom 'while'. every 10 ticks: set {_welcomeMessages::*} to "&aW&6ITAJ", "&6W&aI&6TAJ", "&6WI&aT&6AJ", "&6WIT&aA&6J" and "&6WITA&aJ" set {welcomeMessageIndex} to 1 if {welcomeMessageIndex} is not set set {animatedWelcomeMessage} to {_welcomeMessages::%{welcomeMessageIndex}%} if {welcomeMessageIndex} >= (size of {_welcomeMessages::*}): set {welcomeMessageIndex} to 1 else: add 1 to {welcomeMessageIndex} on placeholderapi placeholder request for prefix "sk": if identifier is "welcome": set result to {animatedWelcomeMessage} Pozdrawiam.

Ja widzę dwa rozwiązania, z czego drugie daje większą szansę powodzenia, ale ręki nie dam sobie uciąć. Należy anulować zdarzenie 'on connect' jeżeli łączy się gracz o takiej samej nazwie jaką ma gracz przebywający już na serwerze. Należy nasłuchiwać do pakietu, który informuje o łączeniu się gracza z serwerem. Zakładam, że będzie to pakiet typu "handshake" lub "login". Pozdrawiam.

To nie jest rozwiązanie. Cooldown powinien działać na zasadzie sprawdzania różnicy czasu między datą obecną a datą ostatniego użycia. # [...] if {cooldown::%uuid of player%} is set: difference between {cooldown::%uuid of player%} and now < 5 seconds send "&cOdczekaj chwilę." to player stop set {cooldown::%uuid of player%} to now # [...] To jest najlepsze rozwiązanie, ponieważ w przeciwieństwie do kodu wykorzystującego opóźnienia jest niezależne od jakości pracy serwera, o której informuje wskaźnik TPS. Pozdrawiam.

Ten temat został przeniesiony.

Problem został rozwiązany.

Ten temat został przeniesiony.

Nie. Po prostu trzeba się zalogować. Swoją drogą, gdybym szukał skryptu to takiego, którego kod jest od razu załączony na forum. Dołączanie zaproszenia na serwer Discord już powoduje pewien niesmak.

Jak najbardziej można ją skrócić i w sumie to naprawić. Nietrudno zauważyć, że w każdym przypadku zachodzi mnożenie przez liczbę o 1 większą od poziomu zaklęcia szczęścia na kilofie, więc najkrótszym rozwiązaniem byłoby użycie poziomu zaklęcia powiększonego o 1. Najlepszym rozwiązaniem natomiast byłoby sprawdzenie czy kilof gracza posiada w ogóle zaklęcie szczęścia. Jeśli tak, wykonujemy mnożenie przez (poziom zaklęcia + 1). Dlaczego najlepszym? Dlatego, że bardziej eleganckim wyjściem jest uprzednie sprawdzenie czy przedmiot jest zaklęty niż opieranie kodu na tym, że wyrażenie zwróci 0 jeśli przedmiot nie jest zaklęty. Co więcej, każdy warunek kończy się wręczeniem graczowi monet, a wystarczy tę instrukcję wykonać raz na samym końcu funkcji. Dlaczego powiedziałem "naprawić"? Proszę zauważyć, że warunki te będzie spełniał kilof z zaklęciem szczęścia, ale bez nazwy, lore i wszelkich innych informacji. Dlatego też nie należy porównywać narzędzia gracza, a sprawdzać jedynie poziom zaklęcia szczęścia. Proszę się samemu zastanowić jak można to rozwiązać. Dokumentacja Skripta z pewnością się przyda. Jeśli i ona nie pomoże, zostawiam swoją propozycję rozwiązania w spoilerze poniżej. Pozdrawiam.

Naukę warto rozpocząć od zajrzenia do działu "Skript > Skrypty > Nauka", w którym obecne są skrypty tworzone przez innych początkujących skrypterów. Przydałoby się również rzucić okiem na dział "Skript > Skrypty > Poradniki". Zalecam zapoznać się też z dokumentacją Skripta, którą cały czas wykorzystuje każdy skrypter. Jeżeli lektura powyższych źródeł nie wystarczy, służę pomocą. Bez znajomości Skripta nie ma sensu tłumaczyć struktury skryptu, bo to będzie rzucanie na głęboką wodę. Pozdrawiam.

To nie jest prawda. Ukośnik nie jest wymagany do poprawnego zdefiniowania aliasu. To samo tyczy się komend. command testcom: aliases: testcommand, testcmd trigger: send "Test." to sender Wystarczy sprawdzić powyższy kod, który działa poprawnie na najnowszej stabilnej wersji Skripta (tj. 2.9.0), ale również będzie działał na innych wersjach (o ile nie pojawiły się w nich błędy z tym związane). Pozdrawiam.

Problem został rozwiązany.

Nie istnieje takie zdarzenie jak 'on move' w Skript'cie, pochodzi ono z dodatku SkQuery. Proszę skorzystać z tego zdarzenia, które sam Skript wspiera. Nie jest to jedyny błąd w kodzie, ponieważ w następnej linijce znajduje się warunek, który nie istnieje w Skript'cie. Proszę zajrzeć do dokumentacji, tutaj podsyłam konkretny warunek. Ostatnia uwaga z mojej strony dotyczy dzielenia okresów czasu. Jest to jak najbardziej poprawna operacja, ale sugeruję skorzystać z tego wyrażenia, które pozwoli na pobranie minut z okresu czasu ('timespan'). Pozdrawiam.

Ten temat został przeniesiony.

Problem został rozwiązany.

Problem został rozwiązany.

Generalnie wygląda w porządku, ale mam dwie uwagi. Dlaczego w kodzie znajduje się opóźnienie o jedną sekundę ('wait 1 second')? Nie widzę powodu, aby je tu zostawić. Użycie metadaty w skrypcie pozwala na rezygnację z użycia zmiennych (zwłaszcza globalnych), a tutaj widzę, że użył Pan zmiennej globalnej '{zycie_pierwszy_atak}'. W mojej ocenie jest ona niepotrzebna i sama metadata wystarczy. Podpowiedź: Można zauważyć, że trudno będzie z oparciem skryptu na samych wartościach logicznych prawda/fałsz. Da się to zrobić w ten sposób, ale można prościej i wygodniej. Metadata może przechowywać właściwie dowolną informację, więc wykorzystamy tę możliwość do zapisania w niej informacji o czasie ostatniego uderzenia ofiary (wyrażenie 'now'), a po odczekaniu x sekund będziemy sprawdzali czy różnica czasu między ostatnim zapisanym czasem uderzenia a obecnym jest większa lub równa x sekund. Jeśli tak, oznacza to, że byt został uderzony co najmniej x sekund temu, więc możemy usunąć jego 'display name'. Zostawiam w spoilerze poniżej propozycję tego jak ja bym to napisał wraz z wyczerpującym komentarzem. Pozdrawiam.