Kormic

Problem został rozwiązany.

Zegar i kompas to dwa różne przedmioty. Proszę się upewnić czy ten kompas różni się od najzwyczajniejszego kompasu jedynie tą ustawioną nazwą. Jeżeli posiada on jakikolwiek lore, bądź nałożone zaklęcia, a nawet różnice w NBT, skrypt nie zadziała. Jeżeli jednak Panu wystarczy samo sprawdzanie nazwy narzędzia gracza, można zamienić linijkę 'player's tool is compass named ...' na: name of player's tool is "&6&lSerwery" Pozdrawiam.

Funkcje lokalne różnią się od globalnych tym, że jak poniekąd sama nazwa wskazuje, mogą być używane tylko w skrypcie, w którym zostały zdefiniowane. Próba użycia ich poza plikiem, w którym są zdefiniowane, zakończy się błędem zwróconym przez Skripta. Druga różnica to to, że są one ładowane przed funkcjami globalnymi, czyli mają zagwarantowane pierwszeństwo w przypadku kolizji nazw. Można to łatwo pokazać przy pomocy kodu. Dla przykładu stworzymy dwa pliki skryptowe. # plik testfunkcji1.sk local function myFunction(): broadcast "local - Hello world!" command /test: trigger: myFunction() # plik testfunkcji2.sk function myFunction(): broadcast "global - Hello world!" Która funkcja zostanie wywołana przy wykonaniu komendy /test? Odpowiedź brzmi: lokalna funkcja myFunction (ta obecna w pliku testfunkcji1.sk). EDIT: Zapomniałem dopowiedzieć o możliwych zastosowaniach. W mojej ocenie lokalne funkcje są przydatne, ponieważ mamy pewność, iż to właśnie kod naszej funkcji zostanie wykonany. Zresztą, dwie globalne funkcje nie mogą być zdefiniowane jednocześnie, ponieważ Skript zwróci błąd przy przeładowaniu skryptu (bądź skryptów). Poza tym, jeżeli dana funkcja jest używana tylko w danym skrypcie, nie ma sensu udostępniać jej wszystkim skryptom załadowanym na serwerze. Jest to swego rodzaju higiena pracy, coś na zasadzie enkapsulacji w Javie (choć pojęcia funkcji lokalnej i enkapsulacji są dalekie od siebie, ale myślę, że analogia jest widoczna). Mam nadzieję, że wyjaśniłem co nieco. Jeżeli pojawią się jakieś pytania, śmiało. Pozdrawiam.

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.