Kormic

Jeśli Pan sprecyzuje co sprawia trudność w napisaniu skryptu, będę w stanie pomóc. Dodatkowo, jeśli Pan nie zrozumiał w pełni któregoś z punktów w moim poprzednim poście, proszę powiedzieć czego Pan nie zrozumiał. Spróbuję wyjaśnić bardziej szczegółowo, możliwie bez użycia żargonu programistycznego.

Szanowny Panie, na forum już wielokrotnie udostępniano skrypty na sprawdzanie. Poniżej podam trzy przykłady, powinny wystarczyć.

Pan w prawidłowy sposób zapisał wywołanie wbudowanej w Minecrafta komendy /kick. Jeśli Pan poprawnie podaje argumenty do swojej komendy /kicka, a powód nie jest wyświetlany wyrzuconemu graczowi, jest to dziwne. Mimo to chciałbym zwrócić uwagę na dwie rzeczy w Pana kodzie. Proszę zauważyć, że nawet jeśli argumenty komendy /kicka nie zostaną podane, skrypt wykona komendę 'kick'. W dodatku Pan określił te argumenty jako opcjonalne, więc pole 'usage' jest całkowicie zbędne. Należy więc po linijce wysyłającej do gracza wykonującego komendę /kicka wiadomość "[...] Poprawne uzycie: /kick [...]" dodać instrukcję 'stop', aby skrypt już dalej się nie wykonywał. Dzięki temu unikniemy sytuacji, w której argumenty nie zostały podane, a więc konsola próbuje wykonać komendę "kick <none> <none>". Jeśli jakaś instrukcja jest wprowadzona w Skript, warto rozważyć jej użycie zamiast używania efektu 'command'. W tym przypadku zalecam użycie efektu 'kick', w którym można podać powód wyrzucenia.

@Kamateo Proszę czytać moje posty ze zrozumieniem, a nie od razu wklejać kod do pliku. Do poprawnego działania skryptu wymagany jest dodatek SkBee.

Zanim pokażę moje rozwiązanie, pozwolę sobie wypunktować błędy w Pana kodzie. Skrypt zawsze należy pisać tak, aby możliwie zablokować wszelkie sceniarusze, które mogłyby spowodować błąd przy wykonywaniu kodu. W kolejnych punktach wymienię rzeczy, które są źródłem błędów, ale również pokażę co warto poprawić. Zamiast pisać każdorazowo 'last spawned zombie', lepiej zapisać wartość tego wyrażenia do zmiennej lokalnej, a później jej używać w miejsce owego wyrażenia. Jest to uwaga kosmetyczna z mojej strony i nie jest to błąd, ale warto pamiętać, że istnieje różnica między wyrażeniami 'name' i 'display name' w przypadku bytów. Pierwsze jest odpowiednikiem znaczników (nametagów), a więc tak ustawiona nazwa jest widoczna tylko po najechaniu na dany byt. Drugie odpowiada za nazwę bytu, która jest zawsze widoczna. Odsyłam do dokumentacji. Nie jestem w stanie teraz sprawdzić czy Skript poprawnie interpretuje '[...] with %enchantment type%', jednakże dokumentacja wskazuje, że jedynym poprawnym słowem jest 'of', nie 'with'. Nie wiem skąd Pan wziął składnię obecną w Pana skrypcie, jednakże ani SkBee, ani tym bardziej skript-reflect nie dodają takiej składni. Warto jednak dodać, że SkBee oferuje tworzenie bossbarów. Dokumentację tego dodatku skupioną na nich można znaleźć tutaj. Należy zauważyć, że do danego bossbaru można odnieść się za pomocą jego ID, a więc eliminujemy potrzebę tworzenia zmiennej globalnej, która miałaby przechowywać stworzony przez nas bossbar. W listenerach zdarzeń 'on damage:' i 'on death:' należy odnosić się do 'victim' oraz 'attacker', nie do 'entity', gdyż takie odniesienie jest niejednoznaczne (Skript nie wie czy odnosimy się do atakowanego, czy też do atakującego). Pana listener zdarzenia 'on damage:' nie jest wyposażony w warunek 'attacker is a player', bądź w jego rozszerzenie o 'by player:'. Brak tego warunku może doprowadzić do sytuacji, w której zapisujemy zmienne dla bytów innych niż gracze (np. żelaznych golemów). Po raz kolejny pojawia się w Pana kodzie wyrażenie, które nie występuje w Skript. Mowa o wyrażeniu '%player% with highest of {damage::*}'. Zakładam, że Pan przypadkiem nie skopiował całego kodu, ale ostatnia linijka skryptu jest niedokończona. Poniżej udostępniam mój skrypt realizujący zlecenie Pana, który założył ten wątek. Nie miałem sposobności do sprawdzenia kodu pod kątem ewentualnych błędów, jednakże wszystko powinno działać w porządku. W razie problemów proszę dać znać. options: bossName: &bBoss barID: zombieBoss function getMostDamagingPlayerUUID() :: text: loop {zombieBossEvent::playerDamage::*}: if {_bestUUID} is not set: set {_bestUUID} to loop-index set {_bestDamage} to loop-value continue if loop-value is bigger than {_bestDamage}: set {_bestUUID} to loop-index set {_bestDamage} to loop-value return {_bestUUID} command /spawnboss: executable by: players trigger: spawn a zombie at player's location set {_zombieBoss} to last spawned zombie set display name of {_zombieBoss} to "{@bossName}" set helmet of {_zombieBoss} to diamond helmet of protection 4 set chestplate of {_zombieBoss} to diamond chestplate of protection 4 set leggings of {_zombieBoss} to diamond leggings of protection 4 set boots of {_zombieBoss} to diamond boots of protection 4 equip {_zombieBoss} with diamond sword set {_bossBar} to bossbar named "{@barID}" with title "{@bossName}" with progress 100 set bar color of {_bossBar} to red set bar style of {_bossBar} to solid add all players to {_bossBar} on damage of zombie by player: if display name of victim is "{@bossName}": set {_bossBar} to bossbar named "{@barID}" if {zombieBossEvent::playerDamage::%attacker's uuid%} is not set: set {zombieBossEvent::playerDamage::%attacker's uuid%} to 0 add damage to {zombieBossEvent::playerDamage::%attacker's uuid%} set bar progress of {_bossBar} to 100 / (max health of victim) * (health of victim) set bar title of {_bossBar} to "{@bossName} - Top Damage: %max({zombieBossEvent::playerDamage::*})%" on death of zombie: if display name of victim is "{@bossName}": set {_winner} to getMostDamagingPlayerUUID() parsed as offline player execute console command "luckperms user %name of {_winner}% parent addtemp svip 10d" clear {zombieBossEvent::playerDamage::*} remove all players from bossbar named "{@barID}" delete bossbar named "{@barID}"

TL;DR: Tłumacze, nie. Pluginy pozwalające na wstawianie skryptów do .jar - tak. Szczegółowe wytłumaczenie: Każdy plugin (ogólniej mówiąc, projekt) składa się początkowo z plików o rozszerzeniu .java, w których zapisujemy nasz kod w języku programowania Java. Aby nasz kod mógł zostać wykonany przez komputer, musimy skompilować nasz projekt (mikroskopowo - każdy plik .java). W rezultacie otrzymujemy pliki o rozszerzeniu .class. Dopiero po tym możemy "spakować" owe pliki .class w jeden byt, którym jest właśnie plik o rozszerzeniu .jar. Dlatego też pliki .jar nazywa się archiwami, co jest analogią do chociażby plików o rozszerzeniu .zip. Należy sobie odpowiedzieć na pytanie czy istnieje jakaś strona/program pozwalający na przepisanie skryptu napisanego w Skript do de facto projektu napisanego w języku Java. Nie ma takich programów, ponieważ żaden szanujący się deweloper nie chciałby marnować swojego czasu na rozwijanie takiej abominacji. Poniżej udostępniam linki do wcześniej wspomnianych "tłumaczy", które pozwalają na wrzucanie plików Skript do .jar. Proszę zauważyć, że ich rozwój został porzucony dawno temu. https://www.spigotmc.org/resources/deprecated-skript-packager.26293/ https://dev.bukkit.org/projects/skriptinstaller

To, że Pan wstawi efekt 'command' do listenera zdarzenia 'on chat:' (zakładam, że Pan właśnie tak zrobił), nie sprawi, że wpisana komenda nie będzie wyświetlana. Ja mówiłem o tworzeniu własnego systemu od podstaw. Niech Pan nie próbuje mieszać pluginu do logowania z własnym skryptem. Albo plugin, albo własny skrypt niezależny od pluginu i napisany od podstaw.

Pan bohatersko stara się zwalczyć problem, który Pan sam sobie sprawił. Proszę zwrócić uwagę, że ja mówiłem o dodaniu listenera zdarzenia 'on chat:', nie zdarzenia 'on command:'. Na Pana miejscu taki mechanizm zaimplementowałbym w taki sposób: gdy gracz dołączy, może on wpisać swoje hasło na czacie w formie zwykłej wiadomości, nie komendy. Rzecz jasna wszelkie wysyłane wiadomości będą blokowane dopóki gracz nie wpisze poprawnego hasła, a po zalogowaniu się czat gracza zostanie odblokowany.

Jak najbardziej jest to możliwe. Dokumentacja opisuje efekt 'command', który pozwala na osiągnięcie tego. W tym efekcie należy jako wykonawcę komendy określić konsolę. Przykładowy skrypt zawierający tę instrukcję udostępniam poniżej. command /test1: trigger: execute console command "test2" send "Konsola wykonała komendę ""test2""." to sender command /test2: trigger: send "Test." to sender

Nie istnieje w Skript takie wyrażenie jak 'parent of %player%'. Jeśli Pan skorzystał z jakiegoś dodatku, warto byłoby o tym wspomnieć, bo Pan nie pomógł, a jedynie niepotrzebnie wprowadził zamieszanie. Tak, ma Pan rację, że pierwsza instrukcja jest błędna. Napisał Pan również dobrze komendę z LuckPerms, chociaż trzeba mieć na uwadze fakt, iż argument 'set' sprawi usunięcie graczowi pozostałych grup permisji i ustawienie jej jako grupę podstawową, więc bezpieczniejszym wyborem będzie użycie w jego miejsce 'add'. Rzecz jasna, najlepiej, aby Pan, który zlecił napisanie owego skryptu, sam sobie odpowiedział na pytanie który wariant go interesuje. Należy jednak powiedzieć o jednym - w Skript należy unikać wykorzystywania efektu 'command' jeśli to tylko możliwe. Zdecydowanie lepszą praktyką jest korzystanie z wbudowanych wyrażeń w Skript. W tym przypadku oferuje on nam dwa wyrażenia, które pozwolą napisać taki skrypt - mowa o 'group[s] of %offline player%' i 'all groups'. Wydaje mi się, że mój skrypt zadowoli Pana. Proszę bardzo. Dodałem przy linijkach 10, 11 i 13 komentarze, które za chwilę wytłumaczę co oznaczają. Po przeczytaniu mojego posta może Pan usunąć resztę komentarzy, nie mają one żadnego znaczenia dla działania poniższego kodu. Jeśli Pan życzy sobie, aby skrypt ustawiał jedynie nową grupę permisji graczowi oraz usuwał pozostałe, proszę usunąć wszystkie linijki z numerem 1. Druga opcja - jeśli Pan życzy sobie, aby skrypt nie usuwał poprzedniej grupy permisji (tej podstawowej) graczowi, a jedynie zmieniał jego grupę podstawową, proszę usunąć linijkę z numerem 2. Oczywiście istnieje jeszcze kilka innych możliwych wariantów, ale myślę, że po moich wyjaśnieniach Pan sam będzie już w stanie dojść do rozwiązania. W razie ewentualnych problemów proszę się nie krępować, pomogę. command /ranga <offline player> <text>: usage: &c/ranga <gracz> <nowa grupa> permission: serwer.komenda.ranga permission message: &cNie posiadasz wystarczających uprawnień do wykonania tej komendy. trigger: set {_allGroups::*} to all groups if {_allGroups::*} don't contain arg-2: send "Grupa o tej nazwie nie istnieje." to sender stop set {_playerGroups::*} to arg-1's groups # 1 remove arg-1's group from {_playerGroups::*} # 1 2 set arg-1's group to arg-2 add {_playerGroups::*} to arg-1's groups # 1 send "&aRanga została pomyślnie zmieniona." to sender

Rozumiem, w takim razie będzie musiał Pan zaimplementować samemu taki mechanizm. Jak wspomniałem wcześniej, jeśli Pan chce dodać taką komendę w Skript, będzie Pan potrzebował dodatku skript-reflect, aby móc skorzystać z API pluginu SternalBoard. Pozwoliłem już sobie przejrzeć kod źródłowy pluginu - zdziwił mnie brak zastosowania wzorca projektowego "singleton". Nie powinno to jednak stać na przeszkodzie dodania komendy przełączającej scoreboard danemu graczowi. Ostrzegam jednak, że nie jestem doświadczony w tworzeniu pluginów do Minecraft, a więc moje rozwiązanie może być wadliwe. Wyjaśnię w paru krokach jak najprościej zaimplementować taki mechanizm wykorzystując metody przygotowane przez autora tego pluginu. Przy tym będę dodawał odpowiednie załączniki, aby ułatwić Panu proces poszukiwania odpowiednich rzeczy w dokumentacji skript-reflect. Pomijając samą definicję komendy, należy rozpocząć od pobrania instancji pluginu Sternalboard. Tutaj załączam fragment dokumentacji. Zamiast %javatype/string% wystarczy wstawić nazwę pluginu, czyli "SternalBoard". Instancję najlepiej zapisać do zmiennej (lokalnej, nie widzę potrzeby zapisu jej w zmiennej globalnej). Mając już wyżej wspomnianą instancję pluginu, jesteśmy gotowi, aby korzystać z metod zawartych w API SternalBoarda. Tak więc pobieramy managera scoreboardów z tego pluginu - korzystamy z metody getScoreboardManager() i zapisujemy zwróconą przez nią instancję managera do kolejnej zmiennej lokalnej. Ów manager pozwala nam na modyfikację scoreboardów poszczególnych graczy. Wywołujemy więc metodę toggle(Player player) na instancji managera, co powinno przełączyć widoczność scoreboardu danego gracza. Jako parametr do metody wystarczy przesłać 'player'. Jeśli by zignorować linijki od definicji komendy (to są 'command /x:', 'trigger:', itd.), kod będzie miał długość 3 linijek. Co prawda można rozwiązanie skrócić do 2 linijek (a nawet 1 linijki), jednakże wymagałoby to łańcuchowego wywoływania metod (którym nie chcę mieszać w Pana głowie). Zresztą, próba skrócenia do 1 linijki wiązałaby się najprawdopodobniej z pogwałceniem jednej z konwencji pisania skryptów z użyciem skript-reflect. Może mieć Pan uczucie bycia rzuconym na głęboką wodę, dlatego zalecam podejść na spokojnie do dokumentacji dodatku skript-reflect. Pojawiają się tutaj również podstawy wiedzy o języku Java. W samej dokumentacji jest sekcja "Basics", która powinna pomóc Panu w dojściu do rozwiązania. Gdyby Pan miał problem ze zrozumieniem samej Javy i jednocześnie chciał poznać więcej, zachęcam do sprawdzenia tego kompendium wiedzy. W razie jakichkolwiek pytań proszę się nie krępować, chętnie pomogę/wytłumaczę jeśli będzie taka potrzeba.

Jeśli autor pluginu udostępnił do użytku komendę pozwalającą każdemu graczowi na włączanie i wyłączanie scoreboardu, może Pan dodać do pliku commands.yml alias "tabela" dla tej komendy. Możliwa jest również opcja dodania aliasu w pliku konfiguracyjnym pluginu (o ile autor przewidział taką funkcjonalność). Jest również możliwy drugi wariant - autor pluginu nie udostępnił takiej komendy. W takim wypadku może Pan skorzystać z dodatku skript-reflect, aby wykorzystać API pluginu SternalBoard do sterowania scoreboardem. Zanim jednak pokażę jak można tego dokonać, niech Pan najpierw powie czy każdy gracz ma możliwość przełączania scoreboardu w tym pluginie.

Javy tutaj Pan nie uświadczy, gdyż dopiero po zainstalowaniu dodatku skript-reflect pojawia się możliwość korzystania z dobrodziejstw przeróżnych bibliotek Javy i silnika serwera. Niemniej jednak z całego serca polecam ten dodatek, ponieważ w odpowiednich rękach staje się niezwykle potężnym narzędziem, które poszerza horyzonty Skripta. Wracając do meritum - Pan dobrze napisał listener zdarzenia 'on command'. Wystarczy, że Pan zamieni linijkę odtwarzającą dźwięk za pomocą komendy na linijkę, którą Panu podałem. Do tego wystarczy dodać opóźnienie przed odtwarzaniem dźwięku, aby dźwięk się odtworzył po, nie przed teleportacją gracza. Aby nie być gołosłownym, podam Panu strukturę skryptu w formie pseudokodu (ściślej mówiąc, marnej próby przetłumaczenia Skripta na język polski). gdy gracz wpisze komendę "spawn": odczekaj 1 tick odtwórz graczowi dźwięk "ENTITY_GENERAL_EXPLODE" Może Pan to uznać za złośliwość z mojej strony, ale uspokajam. Robię tak, bo jestem przeciwny powierzaniu innym gotowego kodu - zwyczajnie brak w tym jakiejkolwiek wartości dydaktycznej, nauki. W ten sposób Pan już powinien być w stanie dojść do odpowiedzi (we wcześniejszych postach podałem wszystkie potrzebne instrukcje, wystarczy je wstawić w odpowiednie miejsca w powyższym pseudokodzie).

Czy można prosić o doprecyzowanie jeśli chodzi o wspomnianą wyżej skrzynkę czy też mnożniki? Nie rozumiem o jakiej skrzynce mowa. Jedynie rozumiem, że mnożnik różdżki wpływałyby na ostateczną cenę sprzedaży.

Jeśli Pan pozwoli, zacznę od wypunktowania złych praktyk w Pana kodzie. Umieszczenie instrukcji 'stop' przed instrukcją 'send' sprawia, że wiadomość nigdy nie zostanie wysłana do wykonującego komendę. Należy więc zamienić linijki 5 i 6 miejscami. Po zastosowaniu się do uwagi nr 1 nietrudno zauważyć, że otwieranie sekcji 'else' jest zbędne. if arg is not set: send "" to player stop if arg <= 0: send "" to player stop # Dalszy kod... Jak widać, kod stał się czytelniejszy, a sposób jego działania się nie zmienił. Analogiczna sytuacja do uwagi nr 2 jest w przypadku warunku 'if player's balance is less than arg-1' oraz następującej po nim sekcji 'else'. Proszę zauważyć, że Pan niepotrzebnie w linijce nr 17 stosuje zapis w formie tekstu - Pan już zapisał komendę w formie tekstu linijkę wyżej. Tak więc wystarczy w efekcie 'execute console command %texts%' wstawić zmienną z zapisaną ową komendą. Dobrze, teraz możemy przejść do Pana problemu. Najprostszym rozwiązaniem będzie sprawdzenie czy reszta z dzielenia argumentu komendy przez 10 jest równa 0. Tak więc należy użyć tutaj funkcji mod reprezentującej funkcję obliczającą resztę z dzielenia. Odsyłam do dokumentacji Skripta w celu zapoznania się z wyżej wspomnianą funkcją.

Wystarczy, aby Pan to sprawdził za pomocą warunku '%offline player% is online'. W Pana przypadku należy podstawić za %offline player% wyrażenie 'loop-value' reprezentujące aktualnie zapętlany element listy. Tutaj pojawia się również kwestia łączenia tekstu (poszczególnych nazw graczy w listę nazw). Jak tego dokonać - dokumentacja podpowiada. Do powyższych pojęć dodałem załączniki, aby ułatwić Panu znalezienie rozwiązania.

W tym przypadku wystarczy dodać opóźnienie przed odtworzeniem dźwięku. Chciałbym jeszcze dopowiedzieć odnośnie dwóch rzeczy. Po pierwsze, 'wait %timespan%' nie jest funkcją, a efektem (ogólniej można nazwać ją instrukcją). Funkcja to obiekt przyjmujący opcjonalnie pewne argumenty, możliwy do wywołania w każdym miejscu innego kodu. Po drugie, zalecam używać instrukcji 'play sound' zamiast wywoływać komendę 'playsound'. Dodałem załącznik, aby Pan mógł zapoznać się z tym efektem. Listę dźwięków możliwych do odtworzenia znajdzie Pan chociażby w dokumentacji Spigot. Listę wszystkich dźwięków w Minecraft znajdzie Pan tutaj. Tak więc wystarczy napisać linijkę odtwarzającą dźwięk w poniższy sposób. play sound "ENTITY_GENERIC_EXPLODE" to player Jeśli Pan chce, może Pan również zmienić głośność odtwarzanego dźwięku. Wszelkie informacje znajdują się w dokumentacji Skripta.

Nie rozumiem. Wszystko jest już w porządku? Czy przetestował Pan kod komendy /cooldowntest w taki sposób jak zaproponowałem?

Jak sam Pan widzi, nigdzie w przykładowym kodzie nie dodałem takiej funkcji. W celu upewnienia się przed chwilą uruchomiłem swój serwer i jestem w stanie spokojnie wpisywać komendę 4 razy na sekundę, a jedyna wiadomość wysyłana do mnie to "Odczekaj x.". Wynika z tego, że Pan po swojej stronie ma jakieś zabezpieczenie powstrzymujące graczy przed zbyt częstym wpisywaniem komend. command /cooldowntest: trigger: send "Test." to sender Niech Pan przetestuje powyższy kod poprzez jak najczęstsze wpisywanie tej komendy. Może Pan sobie zmienić jej nazwę, ona nie gra roli. Jeśli i w tym przypadku pojawi się wiadomość o zbyt częstym używaniu komendy, moja teza się potwierdzi.

Wedle mojej wiedzy nie ma internetowych interpreterów Skripta. Nie wiem czy Panu jakkolwiek to pomoże, ale SkEditor 2.0 autorstwa Notro posiada oficjalny dodatek o nazwie "Analyzer" sprawdzający kod pod kątem błędów. Po więcej informacji zapraszam do wątku poniżej.

Taki skrypt nietrudno jest napisać. Wystarczy w listenerze zdarzenia 'on right click:' sprawdzić czy lokalizacja bloku, na który patrzy gracz, jest taka sama jak wymagana przez nas lokalizacja. Podam przykład takiego warunku. if target block's location is location at (100, 100, 100) in world "world": Jeśli tak - wysyłamy do gracza wiadomość za pomocą efektu 'message' /' send'. Do każdego zagadnienia dodałem załącznik, aby Pan mógł sprawnie przejrzeć dokumentację wraz z przykładami. W razie problemów proszę dać znać, pomogę.

Gdyby trzeba było napisać taki skrypt/plugin od podstaw, należałoby to zrealizować w kilku krokach: znaleźć jakieś API zwracające skin gracza (najlepiej samą głowę) w formie pojedynczych pikseli, zapętlić zapisane wcześniej piksele i sprawdzać kolor każdego z nich, dopasować kolor danego piksela do najbliższego mu koloru czatu dostępnego w Minecraft (odsyłam do enuma ChatColor), wypisywać kolejno odpowiednio pokolorowane nasze kwadraty na czacie tak, aby pokazały głowę gracza. Jeśli Pan nie jest zdecydowany samemu skonstruować taki skrypt/plugin, ten plugin wydaje się być rozwiązaniem Pana problemu. EDIT: Co prawda plugin został stworzony dla starszych wersji, jednak o ile samo API się nie zmieniło, raczej wszystko powinno być w porządku.

Proszę bardzo. W razie problemów z przywracaniem przedmiotów, proszę spróbować dodać opóźnienie (np. 'wait 1 tick') w miejscu znaku "#". Sam znak "#" oznacza komentarz, więc może go Pan spokojnie usunąć. command /inventorialis: executable by: players trigger: loop 41 times: set {playerInventory::%player's uuid%::%loop-number%} to slot loop-number of player's inventory send "Twoje przedmioty zostały zapisane." to player on respawn: size of {playerInventory::%player's uuid%::*} > 0 # loop 41 times: set slot loop-number of player's inventory to {playerInventory::%player's uuid%::%loop-number%} send "Przywrócono Ci twoje zapisane przedmioty." to player

Ciekawe pytanie Pan zadał z tą funkcją wait(). Podaję przykładowy kod poniżej jak mógłby taki mechanizm działać. function wait(t: timespan) :: boolean: wait {_t} return true command /test: trigger: wait(10 ticks) is true # Dalszy kod... To byłoby rozwiązanie najbliższe temu, które Pana interesuje. Niemniej jednak muszę rozczarować - powyższy kod nie zadziała wedle Pana oczekiwań. Skript zignoruje opóźnienie umieszczone wewnątrz kodu funkcji i przejdzie dalej w kodzie wywołującym ową funkcję nie zważając na zwracaną wartość przez nią. W konsekwencji warunek w komendzie /test sprawdzi '<none> is true', co oczywiście zwróci fałsz, a więc dalszy kod się nie wykona. Dla eksperymentu można sprawdzić, że w przypadku wariantu "wait(x) is not false" wszystko poza samym opóźnieniem działałoby bez zarzutów. Można poszukiwać rozwiązania przy pomocy dodatku skript-reflect udostępniającego wszelkie biblioteki Javy do użytku (oraz sekcje, bardzo przydatne narzędzie), ale i tam poszukiwania najprawdopodobniej okażą się bezowocne. Konkluzja jest taka - najlepiej używać wbudowanych opóźnień w Skript. Odsyłam do dokumentacji Skripta w razie wątpliwości. Jeśli chodzi o Pana drugi problem z dźwiękiem eksplozji, zakładam, że Pan używa w tym celu listeneru zdarzenia 'on command "spawn":'. Musi mieć Pan na względzie to, że te zdarzenie jest wywoływane przed faktycznym wykonaniem komendy, czego głównym atutem jest możliwość anulowania zdarzenia. W tej sytuacji proponuję dodać zwykłe opóźnienie 'wait 1 tick:' przed wydaniem dźwięku eksplozji. Nie jest to rozwiązanie idealne, gdyż najlepiej byłoby zmodyfikować samą komendę /spawn i odtworzyć graczowi dźwięk po teleportacji, jednak zakładam, że Pan ma ją (komendę /spawn) zaimplementowaną przy pomocy któregoś z pluginów.

Błąd wprost mówi Panu, że w zdarzeniach typu "periodical" (na przykład "every x seconds:") nie ma informacji o graczu, gdyż jest to fragment kodu wykonujący się co jakiś czas. Jeśli Pan chce odnieść się do jakiegoś gracza, musi Pan zapętlić wszystkich graczy i dla każdego z nich sprawdzać wartość zmiennej {autoMessage::%loop-player%}. Zamiast tego można jednak podejść do problemu nieco inaczej. W tej sytuacji estetyczniejszym rozwiązaniem będzie stworzenie listy graczy, którzy włączyli automatyczne wiadomości na czacie, a następnie wysyłanie do nich wiadomości. Przykład poniżej. every 10 seconds: send "Wiadomość." to {autoMessage::players::*} Do takiej listy wystarczy, że Pan będzie zapisywał tych graczy, bądź z niej usuwał jeśli wyłączą sobie ów wiadomości. Przełączanie opcji ich wysyłania można zaimplementować przy użyciu wcześniej wysłanej przeze mnie komendzie /toggleautomsg, którą należy nieco zmodyfikować.