Kormic

Jak najbardziej. Zamykanie GUI działa niezależnie od podanej komendy. W takim razie proszę podmienić kod listeneru zdarzenia 'on right click' na poniższy. on right click: player's tool is compass named "&6&lSerwery" set {_gui} to chest inventory with 3 rows named "{@GUIName}" set slot (integers from 0 to 26) of {_gui} to lime glass pane named " " set slot 12 of {_gui} to iron sword named "TEKST" with lore "LORE" set slot 13 of {_gui} to iron pickaxe named "TEKST" with lore "LORE" set slot 14 of {_gui} to diamond block named "TEKST" with lore "LORE" open {_gui} to player Można tak robić, ale jest to bardzo niepraktyczne, ponieważ w ten sposób powstanie bardzo dużo niepotrzebnego kodu. Warto dodać, że nie trzeba omijać slotów na przedmioty - wystarczy ustawić wszędzie szyby, a dopiero później dodać przedmioty, które zastąpią istniejące szyby na środku skrzynki. Pozdrawiam.

Aż tak precyzyjne informacje nie są potrzebne. Rozumiem, że autor wątku prosi o nakierowanie go na poprawną odpowiedź. Co do trzeciego pytania, 16 bloków od bloku to tworzenie regionu działania w kształcie koła o promieniu 16 bloków, co znacznie przekracza wymiary chunku (16x16). Po primo, aby sprawdzić nazwę stawianego bloku, należy sprawdzić nazwę bloku, który gracz trzyma w ręce. Jest to możliwe, ponieważ w momencie wywołania zdarzenia 'on place' blok jeszcze nie jest fizycznie postawiony. Tak więc, wyrażenie 'name of player's tool' okaże się tu przydatne. Po secundo, tworzenie pętli jest silnie uzależnione od tego czy pętla ma się wykonywać do momentu wyjścia gracza z obszaru chunku, czy też zawsze będzie działać gdy będzie tylko w obszarze chunku. Pierwszy scenariusz sugeruje użycie pętli 'while' sprawdzającej czy chunk w lokalizacji gracza ('chunk at player') jest taki sam jak w momencie rozpoczęcia pętli. Można go sobie zapisać przed rozpoczęciem pętli do zmiennej lokalnej i przyrównywać w każdej jej iteracji. Drugi scenariusz natomiast skłania do użycia tzw. 'periodical', czyli fragmentu kodu wykonującego się okresowo (co określony czas). Dopowiem, że jest drugi sposób na sprawdzanie czy gracz znajduje się w tym samym chunku - wystarczy sprawdzać współrzędne x i z chunku, które można obliczyć w prosty sposób (i jednocześnie najprostszy z punktu widzenia serwera): set {_chunkX} to floor({_x} / 16) set {_chunkZ} to floor({_z} / 16) # Na przykład: x = 28.339, y = 100.7, z = -11.21, wtedy: chunkX = floor(28.339 / 16) = 1, chunkZ = floor(-11.21 / 16) = -1 Rzecz jasna, współrzędna Y nie ma jakiegokolwiek wpływu na powyższe obliczenia. Ostatnią sprawą wartą poruszenia jest to, że sprawdzanie co 10 sekund czy gracz jest w obrębie chunku będzie za sobą niosło konsekwencję możliwości wyjścia z obszaru chunku i powrotu do niego przed upłynięciem wspomnianych 10 sekund. Na razie nie podaję żadnego kodu, ponieważ chcę sprawdzić czy moje wyjaśnienia i załączniki do dokumentacji przydały się jakkolwiek Panu. Pozdrawiam.

Lepiej będzie wykorzystać wykonywanie komendy. Swoją drogą, komenda /say nie służy do wykonywania komend, a do wysyłania wiadomości do wszystkich graczy. Nie ma najmniejszego problemu. W listenerze zdarzenia 'on inventory click' można nadpisać każdą komendę w wywołaniach funkcji execCommandCloseInv. options: GUIName: &6&lNazwa GUI local function execCommandCloseInv(p: player, t: text): close {_p}'s inventory make {_p} execute command {_t} on right click: player's tool is compass named "&6&lSerwery" set {_gui} to chest inventory with 3 rows named "{@GUIName}" set slot 12 of {_gui} to iron sword named "TEKST" with lore "LORE" set slot 13 of {_gui} to iron pickaxe named "TEKST" with lore "LORE" set slot 14 of {_gui} to diamond block named "TEKST" with lore "LORE" open {_gui} to player on inventory click: event-inventory is not player's inventory name of event-inventory is "{@GUIName}" cancel event if index of clicked slot is 12: executeCommandCloseInv(player, "/komenda1") else if index of clicked slot is 13: executeCommandCloseInv(player, "/komenda2") else if index of clicked slot is 14: executeCommandCloseInv(player, "/komenda3") Pozdrawiam.

Zlecenie zostało wykonane.

Proszę uprzejmie. Założyłem, że będzie to menu do zmiany trybów, więc zablokowałem dodatkowo wyciąganie przedmiotów z GUI. Na samej górze skryptu możliwe jest ustawienie nazwy okienka GUI. options: GUIName: &6&lNazwa GUI on right click: player's tool is compass named "&6&lSerwery" set {_gui} to chest inventory with 3 rows named "{@GUIName}" set slot 12 of {_gui} to iron sword named "TEKST" with lore "LORE" set slot 13 of {_gui} to iron pickaxe named "TEKST" with lore "LORE" set slot 14 of {_gui} to diamond block named "TEKST" with lore "LORE" open {_gui} to player on inventory click: event-inventory is not player's inventory name of event-inventory is "{@GUIName}" cancel event Pozdrawiam.

Co prawda zlecenie zostało wykonane i nie Pan je złożył, ale tak, można spokojnie wykorzystać również taki wariant, ponieważ są to synonimiczne instrukcje (patrz: dokumentacja). Przepraszam, założyłem, że komenda /amulety jest już zdefiniowana na serwerze. Poniżej wysyłam poprawiony kod. command /amulety [<text>]: executable by: players trigger: make player execute command "/gui open amulety" Pozdrawiam.

Proszę się upewnić, że pierwszy warunek jest spełniony, to znaczy wykopuje Pan odpowiednie bloki. Jeżeli gracz rzeczywiście wykopuje dobre bloki, problem może leżeć w tym, że te bloki posiadają w sobie jakieś dodatkowe informacje, co sprawia, że Skript uznaje ów warunek za niespełniony. Wtedy proszę zamienić 'event-block is' na 'type of event-block is', być może w tym sęk. Pozdrawiam.

Proszę bardzo. on command "/amulety": make player execute command "/gui open amulety" Pozdrawiam.

No cóż, możliwych przyczyn jest kilka. Zakładam, że błędów przy przeładowaniu skryptu nie ma, więc wymienię te przyczyny, które przychodzą mi do głowy. Zanim zacznę, prosiłbym, aby Pan przesłał dodatkowo kod, który Pan wypróbował na swoim serwerze. No dobrze, więc tak. Teleportacja tuż po dołączeniu jest niemożliwa, co miałoby sens, ponieważ wydarzenie 'on join' jak większość wydarzeń jest wywoływane przed faktycznym dołączeniem gracza na serwer. Rozwiązaniem jest wtedy dodanie opóźnienia przed teleportacją - 'wait 1 tick' przed teleportacją powinno wystarczyć. on join: wait 1 tick teleport player to location(100, 100, 100, world "world", 0, 0) Pan być może próbuje teleportować gracza do nieistniejącego świata. Proszę się upewnić, że świat o podanej nazwie istnieje. Funkcja location w Pana wersji Skripta może działać nieprawidłowo. Tutaj są dwa wyjścia (sugeruję te pierwsze): Pan poda mi wersję serwera, Skripta i dodatków do Skripta, a ja doradzę co należy dalej zrobić. Zmienimy użycie funkcji 'location' na użycie wyrażenia 'location at' jak poniżej. Minusem takiego rozwiązania jest to, że niemożliwe jest odpowiednie obrócenie gracza przy teleportacji. on join: wait 1 tick teleport player to location at (100, 100, 100) in world "world" Pozdrawiam.

Szczerze mówiąc, nie mam pojęcia, ponieważ twórca (ShaneBeee) nie zamieścił jakiejkolwiek informacji wskazującej na zakres kompatybilnych wersji serwera dla starszych wersji SkBee. Jedyne co mogę tutaj mądrego doradzić to wypróbowanie wersji SkBee 1.15.3, którą twórca polecił dla wersji serwera 1.16.5. Możliwe, że ta wersja nie zadziała (choć kto wie), wtedy będzie musiał Pan próbować z niższymi wersjami SkBee zaczynając od 1.15.2. Pozdrawiam.

Proszę bardzo. Pierwsze trzy parametry funkcji location to współrzędne x, y, z. Czwarty parametr to świat, do którego gracz ma zostać przeteleportowany. Ostatnie dwa parametry reprezentują kolejno 'yaw' i 'pitch', gdzie 'yaw' to obrót głowy lewo-prawo (wartości od -180 do 180, w stopniach), a 'pitch' to obrót głowy góra-dół (wartości od -90 do 90, w stopniach). on join: teleport player to location(100, 100, 100, world "world", 0, 0) Pozdrawiam.

Ten temat został przeniesiony.

Proszę uprzejmie. Skrypt nie był testowany. Na górze skryptu dodałem możliwość podstawowej konfiguracji skryptu. Trzecia opcja odpowiada za siłę przyciągania, należy ją dobrać metodą prób i błędów. Samą kuszę można otrzymać za pomocą komendy /kusza, która wymaga permisji w niej ustawionej - ją również można zmienić. options: crossbowName: "&bKusza przyciągająca" crossbowLore "&7Ta kusza jest w stanie przyciągać trafionych graczy do ciebie." and "&7Cooldown: &c60 sekund" pullForceAmplification: 1.0 on shoot: shooter is a player name of shooter's tool is {@crossbowName} lore of shooter's tool is {@crossbowLore} {pullingCrossbow::cooldown::%uuid of shooter%} is set: set {_cooldown} to 1 minute difference between {pullingCrossbow::cooldown::%uuid of shooter%} and now is smaller than {_cooldown} send "&6Cooldown kuszy jest aktywny &e(1 minuta)&6." to shooter stop set {pullingCrossbow::cooldown::%uuid of shooter%} to now on damage: projectile is an arrow set {_shooter} to shooter of projectile {_shooter} is a player set {_v} to vector from victim to {_shooter} push victim ({@pullForceAmplification} * {_v}) command /kusza [<text>]: permission: server.command.kusza permission message: &6Nie posiadasz wystarczających uprawnień do wykonania tej komendy. executable by: players trigger: give player crossbow named {@crossbowName} with lore {@crossbowLore} Pozdrawiam.

W porządku. Do poniższego skryptu wystarczy sam Skript. Pozdrawiam.

Problem raczej leży po stronie SkBee, a nie Skripta, ponieważ Skript ma zagwarantowane wsparcie dla wersji 1.13 i wzwyż. Proszę więc próbować z różnymi wersjami SkBee, aż Pan znajdzie wersję, która zadziała. Może Pan również spróbować z pierwszą wersją, którą sugerowałem. Pozdrawiam.

W takim razie można to inaczej rozwiązać. Przykład poniżej. command /komenda [<text="10">]: trigger: set {_numberArg} to arg parsed as integer {_numberArg} is set send "Podany argument jest liczbą całkowitą." to sender Ten fragment kodu wykorzystuje sztuczkę polegającą na tym, że wyrażenie 'parsed as' w przypadku niemożności przemianowania na inny typ nic nie zwraca, a więc zmienna {_numberArg} będzie pusta. Jeżeli jednak podany argument jest liczbą całkowitą, wiadomość zostanie wysłana. Pozdrawiam.

Zlecenie zostało wykonane.

Na dobry początek, warto zapoznać się z pluginem Skript i składnią używaną w jego skryptach. Oficjalnych źródeł do nauki poza samą dokumentacją tak właściwie nie ma, nauka głównie polega na rozglądaniu się po rozmaitych forach. Oczywiście, nie znaczy to, że nie powstały żadne kompendia wiedzy o Skript. Przykładem jest kategoria Skript na stronie wiki.skript.pl, która jest prowadzona przez te forum (ściślej mówiąc, była, ponieważ zamieszczone tam poradniki są już dość leciwe). Co do samego skryptu na generatory, w jaki sposób on ma działać? Pozdrawiam.

Proszę wytłumaczyć dokładnie na czym ten skrypt ma polegać. Możliwie dużo informacji przy wykonywaniu zlecenia to podstawa. Pozdrawiam.

Ten temat został przeniesiony.

Wystarczy określić jego typ jako 'integer', a nie 'text'. Proszę zwrócić uwagę, że to nie wykonujący komendę decyduje czy argument to będzie "40", czy też 40, a sama osoba tworząca komendę. To ona podejmuje taką decyzję poprzez określenie typu argumentu. Przykład poniżej. command /komenda <integer> <text>: trigger: # [...] W powyższym przykładzie argument nr 1 zawsze będzie typem całkowitym ('integer'), a argument nr 2 zawsze będzie typem tekstowym ('text'). Warto zauważyć, że dziedzina pierwszego argumentu (prościej mówiąc, liczba możliwych wartości) jest węższa niż dziedzina drugiego argumentu. Jeżeli użytkownik spróbuje podać jako pierwszy argument wartość inną niż liczba całkowita, wiadomość z pola 'usage' zostanie wysłana. Drugi argument natomiast przyjmie dowolną wartość i nie ma mowy o podaniu do niego niepoprawnej wartości. Co prawda nie wspomniałem o tym, ale oba argumentu muszą zostać podane przy wykonywaniu komendy, co objawia się brakiem nawiasów kwadratowych przy argumentach w definicji komendy. Po więcej informacji odsyłam do poradnika mojego przyjaciela, Pana Marudy: Odpowiadając szerzej na Pana pytanie, gdyby mieć pewną wartość o nieznanym typie zapisaną do zmiennej, możemy skorzystać z poniższego warunku. if {_myVar} is an integer: if {_myVar} is a text: if {_myVar} is a player: # [...] Tak jak zostało to wyżej powiedziane, nie jest to możliwe. Rozwiązanie już podał kolega wyżej. Pozdrawiam.

Ten temat został przeniesiony.

Rozumiem, że wersja SkBee 1.16.3 nie działa u Pana, tak? Zalecam odinstalować wszystkie dodatki do Skripta poza samym SkBee, a następnie sprawdzić czy ten problem występuje. Skrypt przy przeładowaniu wyświetlił tyle błędów, bo najprawdopodobnie część (lub cały) SkBee uległo wylączeniu. Chciałbym dodać, że WolvSK jest już nierozwijanym dodatkiem, którego wsparcie zakończyło się na wersji 1.16.1. Jeżeli Pan z niego nie korzysta, proszę go odinstalować. Co do skRayFall, posiada Pan nieaktualną wersję, ponieważ wersja 1.9.21 wspiera wersje serwera nie nowsze niż 1.16.1. Zalecam aktualizację do najnowszej wersji (tj. 1.9.28). Odnosząc się do błędów przy przeładowaniu skryptu, uświadomiłem sobie, że wiki SkBee może mieć konfliktową składnię z tą poprawną. Niemniej jednak, zanim będę wyciągał takie wnioski, trzeba doprowadzić dodatek do stanu używalności. Pozdrawiam.

Jak najbardziej da się, umożliwia to ten warunek. Nie znaczy to jednak, że nie można sprawdzać regionu, bo to też jest całkowicie poprawne, choć w dłuższej perspektywie niepraktyczne. A teraz pora na recenzję wykonania zlecenia, w której wymienię najpierw błędy, a później uwagi. Zacznijmy więc od błędów - składniowych i logicznych: if region at player contains {@itemRegions}: Podejrzewam, że powyższy warunek nie zadziała. Podejrzewam, ponieważ jego działanie jest poniekąd uzależnione od wersji Skripta, a w dodatku typ 'Region' nie ma ścisłej definicji w Skript'cie. Mogę tutaj tyle powiedzieć, że nigdy nie zawiodło mnie poniższe rozwiązanie. "%regions at player%" contains "myregion in world ""world""" Tak się nie tworzy cooldownów jak poniżej jest to pokazane. Zresztą, nie rozumiem dlaczego zmienna jest ustawiana na 30 skoro ta informacja nigdzie nie jest wykorzystywana, a cooldown i tak trwa 5 sekund. set {cd::%player%} to 30 wait {@itemCooldown} set {cd::%player%} to 0 Jeżeli serwer (lub sam Skript) zostanie zatrzymany w ciągu tego okresu {@itemCooldown}, cooldown nigdy nie zostanie wyzerowany. Jak więc należy to robić? Podam przykład. # [...] if {exampleCooldown::%uuid of player%} is set: difference between {exampleCooldown::%uuid of player%} and now is smaller than {@itemCooldown} send "&cOdczekaj chwilę." to player stop set {exampleCooldown::%uuid of player%} to now # [...] Dlaczego typ drugiego argumentu komendy to 'text', a nie 'player'? Dzięki takiej zmianie nie byłoby potrzeby dodawania dopełnień tabulatorem. Co więcej, w kodzie argument drugi jest naprzemiennie używany tak jakby był tekstem i tak jakby był obiektem gracza, co również jest błędem. Czy to aby na pewno zadziała? Mam szczere wątpliwości. if arg-1 is not set: send usage to the sender stop Mniejsza o to. Moim zdaniem, lepiej będzie po prostu uczynić pierwszy argument obowiązkowym. Tak więc, wystarczy usunąć nawiasy kwadratowe przy jego definicji. Jeżeli gracz nie poda go lub poda argument inny niż liczba całkowita, wiadomość w polu 'usage' zostanie wysłana. Taka jest jego rola. Teraz przejdźmy do uwag: Proszę zauważyć, że niepoprawnym jest założenie, iż w przypadku drugiego argumentu komendy może on przechowywać tylko gracza. Nic nie powstrzyma konsoli przed wykonaniem komend. Co gorsza, gdy konsola nie poda drugiego argumentu, komenda zadziała w dziwny sposób, ponieważ zmienna {_p} będzie zawierała '<none>' (odpowiednik 'null'), czego przyczyną jest niemożność przemianowania konsoli na gracza. Tutaj z pewnością przyda się opcja konfiguracyjna konsoli 'executable by'. Podam przykład pokazujący jak sprawić, aby tylko gracze mogli wykonać komendę. executable by: players Rozumiem, że poniższy kod ma sprawdzać czy wpisany gracz jest na serwerze. Jest to jednak źle napisany kod, ponieważ argument tekstowy jest porównywany z obiektem gracza, co jest de facto błędem. loop all players: add loop-player to {_g::*} if {_g::*} doesn't contain arg-2: send "{@prefix} &cxd" stop Powyższy fragment będzie zbędny po zamianie typu drugiego argumentu na 'player', ponieważ komenda będzie sprawdzała czy podany gracz jest na serwerze. 'stop' na samym końcu komendy nie ma jakiegokolwiek wpływu na jej działanie, więc jest całkowicie zbędny. Mam nadzieję, że Pan poprawi powyższe błędy i zastosuje się do moich uwag. Nie będę realizował tego zlecenia, bo chcę dać Panu szansę poprawienia swoich błędów. Pozdrawiam.

Problem został rozwiązany.