Kormic

Do nasłuchiwania do zdarzenia niszczenia bloków należy użyć listenera zdarzenia 'on break'. Może Pan w nim sprawdzić narzędzie gracza. Mimo wszystko jeśli Pan używa regionów z WorldGuard, sugeruję ustawienie w nim flagi blokującej niszczenie bloków. Pozdrawiam.

Prosiłem, aby Pan poprawił poprzedni post i zamiast tamtego kodu wstawił link. No ale dobrze, mniejsza o to. Linijki te pobierają wartości zapisane w zmiennych: {cashblock::config::drop-cash-from-stone-message-type}, {cashblock::messages::drop-cash-from-stone-title-message}, {cashblock::messages::drop-cash-from-stone-subtitle-message}. Zawierają one odpowiednio wartości z pliku YAML: ? (nie mogę znaleźć w skrypcie gdzie jest zapisywana wartość pierwszej zmiennej przechowującej typ wiadomości) {cashblock::messages::drop-cash-from-stone-title-message} {cashblock::messages::drop-cash-from-stone-subtitle-message} Pominąłem zmienną zawierającą format z Vaulta, gdyż jest ona pomijalna dla tego problemu. Jeśli Pan pokazał mi cały skrypt, brak odczytu wartości typu wiadomości (w pliku YAML: "drop-cash-from-stone-message-type") jest najpewniej powodem niepoprawnego działania skryptu, ponieważ zmienna ta zwraca <none>. Musiałby Pan dodać w sekcji 'on load' i funkcji przeładowującej konfigurację skryptu poniższą linijkę (oczywiście w sekcji gdzie jest załadowany odpowiedni plik konfiguracyjny). set {cashblock::config::drop-cash-from-stone-message-type} to yaml value "drop-cash-from-stone-message-type" from "cashblock-drop.config" W razie dalszych problemów będziemy się zastanawiać. Pozdrawiam.

Zakładam, że serwer działał wcześniej w trybie offline, więc nie ma mowy o weryfikacji użytkownika na podstawie UUID, gdyż jest ono generowane właśnie na podstawie jego nazwy. Jeśli Pan zmienił nazwę, serwer postrzega Pana już jako całkowicie innego gracza. W takiej sytuacji musi Pan odszukać swój plik w folderze playerdata, jego nazwą będzie Pana poprzednie UUID na serwerze. Należy zmienić nazwę pliku na Pana obecne UUID, wtedy wszystko powinno wrócić do normy. Pan nie ma prawa pamiętać swojego UUID, więc może Pan skorzystać z dowolnej strony generującej UUID na podstawie nazwy gracza. Przykładową stronę znajdzie Pan tutaj. Pozdrawiam.

Niech Pan doda do listy {commandCopy::forbiddenItems::*} ten miecz. Przykład poniżej. set {commandCopy::forbiddenItems::*} to diamond named "Test" and wooden sword of sharpness 1 named "&6Test" with lore "Line 1", "Line 2" and "Line 3" Pozdrawiam.

Ale co konkretnie nie działa Panu? Proszę mówić jaśniej.

Taki był mój zamiar. Pan nic nie wspomniał wcześniej o duplikowaniu, jedynie o kopiowaniu. Poniżej skrypt z poprawką, którą Pan sobie zażyczył. Proszę uprzejmie. on load: set {commandCopy::forbiddenItems::*} to ender chest, diamond named "&6Test" and wooden sword of sharpness 3 named "&bTest" with lore "Test" set {commandCopy::forbiddenItemsTypes::*} to bedrock, diamond sword, diamond helmet, diamond chestplate, diamond leggings and diamond boots command /kopiuj [<text>]: executable by: players cooldown: 5 seconds cooldown message: &cOdczekaj chwilę przed ponownym wykonaniem tej komendy. permission: server.command.kopiuj permission message: &cNie posiadasz wystarczających uprawnień do wykonania tej komendy. trigger: if player's tool is air: send "&cAby komenda zadziałała poprawnie, należy trzymać jakiś przedmiot w ręce." to player cancel cooldown stop if any: {commandCopy::forbiddenItems::*} contains player's tool {commandCopy::forbiddenItemsTypes::*} contains type of player's tool then: send "&cDuplikowanie tego przedmiotu jest zabronione. Spróbuj ponownie trzymając inny przedmiot w ręce." to player cancel cooldown stop set {_n} to amount of player's tool in player's inventory if player doesn't have enough space for {_n} of player's tool: send "&cNie posiadasz wystarczająco miejsca w ekwipunku, aby móc zduplikować przedmiot trzymany w ręce." to player cancel cooldown stop add {_n} of player's tool to player's inventory send "&aPomyślnie zduplikowano przedmiot trzymany w ręce." to player W razie ewentualnych problemów proszę dać znać. Pozdrawiam.

Metoda "tam działało, więc i tu zadziała" jest co najmniej nieprawidłowa. Odradzam myśleć w ten sposób przy pisaniu skryptów, gdyż wszystko zależy od tego co dany skrypt robi. Co więcej, taki tok myślenia tylko pokazuje, że Pan tak właściwie nie rozumie składni Skripta i co oznacza wyrażenie 'loop-player'. Otóż oznacza ono gracza aktualnie zapętlanego w pętli (np. 'loop all players'). Poprzez dziwne konstrukcje i składnie mam na myśli to, że są one niezgodne ani z angielską gramatyką (choć nie zawsze Skript jest zgodny z nią), ani tym bardziej ze składnią Skripta. Podpowiem Panu które konkretnie wyrażenia/efekty/sekcje należy sprawdzić w dokumentacji. Nadawanie efektów mikstur. Pobieranie zawartości danego slota ekwipunku gracza, skrzyni, itp. Nakładanie ochrony przed obrażeniami na dany okres czasu. Teleportowanie. Pętla 'loop'. Wychodzenie z (zakańczanie) pętli. Dodatkowo, proszę się zastanowić nad tym czy Pana kod aby przypadkiem nie zawiera niepotrzebnych zmiennych. Może Pan w ich miejsce po prostu użyć wyrażenia.

Mam kilka próśb/pytań. Proszę wstawić skrypt do serwisu code.skript.pl, a następnie zedytować post i zamiast całego kodu wkleić link do niego. To wystarczy. O który dokładnie Panu title chodzi? Skąd Pan wziął ten skrypt? Będzie mi wtedy łatwiej poznać całą mechanikę skryptu. Czy ten plik konfiguracyjny może mieć wpływ na działanie skryptu w kontekście wyświetlania wiadomości na ekranie? Nie udostępnił Pan go, dlatego pytam.

Proszę zapoznać się z dokumentacją Skripta. Tam znajdzie Pan odpowiedź na to jak należy zapisać Pana kod. Niestety nie podał Pan jakie są błędy, ale widzę co najmniej kilka powielonych: użycie wyrażenia 'loop-player' poza jakąkolwiek pętlą iterująca po liście graczy (nie wiem dlaczego Pan zresztą tu próbuje użyć 'loop-player'), dziwna konstrukcja wyrażenia dającego efekt mikstury graczom, dziwna składnia przy teleportacji gracza, dziwna składnia przy pobieraniu slota o danym indeksie w ekwipunku gracza. Pozdrawiam.

Proszę czytać błędy ze zrozumieniem. Funkcja ma w nagłówku 4 parametry, a Pan podał ich w sumie 5. Usunąłem wcześniej parametr {_c} typu 'number', gdyż był zbędny do wyżej wspomnianych testów. Jeśli Pan go potrzebuje (a z tego co widzę to Pan go potrzebuje), proszę go sobie ponownie dodać. Pozdrawiam.

Jak najbardziej. Jest to niewielka modyfikacja. Tak jak już mówiłem wcześniej, skrypt nie był testowany. Co prawda strona code.skript.pl nie jest w stanie poprawnie pokolorować składni w przypadku występowania "grupowego" warunku 'if any', ale proszę się tym nie przejmować. W razie problemów ze skryptem proszę dać mi znać. Pozdrawiam.

@M3w_Q Po kilku testach stwierdzam, że ustawianie bloku po przesłaniu informacji o nim do funkcji staje się nieco bardziej uciążliwe. Mianowicie, Skript zachowuje się tak jakby tracił część informacji o klikniętym bloku. Niech Pan skorzysta z poniższego fragmentu kodu i doda do niego resztę skryptu. function upgradeGen(p: player, upgen: item type, genup: item type, lb: location): block at {_lb} is {_upgen} set block at {_lb} to {_genup} send "&aUlepszono." to {_p} on right click: clicked block is set player is sneaking upgradeGen(player, hay block, coal block, 50, location of clicked block) Jak widzi Pan, zamiast przesyłać blok jako parametr, przesyłam jego lokalizację. Pozdrawiam.

Proszę uprzejmie. Skrypt nie był testowany. Przyjąłem założenie, że Pan korzysta z pluginu Citizens. Skrypt napisałem zgodnie z dokumentacją API udostępnioną przez autorów pluginu. Można ją znaleźć tutaj. Do poprawnego działania skryptu wymagany jest dodatek skript-reflect. Pozdrawiam.

Rozumiem. W takim razie proszę użyć poniższego skryptu. Nie był on testowany, więc proszę, aby Pan go przetestował i w razie problemów dał znać. Proszę zwrócić uwagę na pierwsze trzy linijki skryptu (listener zdarzenia 'on load'): Lista {commandCopy::forbiddenItems::*} zawiera dokładne przedmioty, które mają być blokowane. Jeśli przedmiot gracza będzie różnił się choćby jedną literą w nazwie czy lore lub będzie miał inne zaklęcie od tego w liście, skrypt nie zablokuje kopiowania. Lista {commandCopy::forbiddenItemsTypes::*} zawiera typy przedmiotów, które mają być blokowane. Tak więc ta lista sprawdzi tylko czy przedmiot na przykład jest drewnianym mieczem, nie sprawdzi jego nazwy, itd. on load: set {commandCopy::forbiddenItems::*} to ender chest, diamond named "&6Test" and wooden sword of sharpness 3 named "&bTest" with lore "Test" set {commandCopy::forbiddenItemsTypes::*} to bedrock, diamond sword, diamond helmet, diamond chestplate, diamond leggings and diamond boots command /kopiuj [<text>]: executable by: players cooldown: 5 seconds cooldown message: &cOdczekaj chwilę przed ponownym wykonaniem tej komendy. permission: server.command.kopiuj permission message: &cNie posiadasz wystarczających uprawnień do wykonania tej komendy. trigger: if player's tool is air: send "&cAby komenda zadziałała poprawnie, należy trzymać jakiś przedmiot w ręce." to player cancel cooldown stop if any: {commandCopy::forbiddenItems::*} contains player's tool {commandCopy::forbiddenItemsTypes::*} contains type of player's tool then: send "&cKopiowanie tego przedmiotu jest zabronione. Spróbuj ponownie trzymając inny przedmiot w ręce." to player cancel cooldown stop if player doesn't have enough space for 1 of player's tool: send "&cNie posiadasz wystarczająco miejsca w ekwipunku, aby móc skopiować przedmiot trzymany w ręce." to player cancel cooldown stop add 1 of player's tool to player's inventory send "&aPomyślnie skopiowano przedmiot trzymany w ręce." to player Pozdrawiam.

Czym jest gamma i w czym ma być napisana (Skript, Java, itd.)? Proszę mówić jaśniej. Pan/i sobie sam/a odpowiedział/a na swoje pytanie. Skrypty nie zadziałają bez pluginu Skript.

W takim razie proszę sobie zmienić w moim skrypcie linijkę drugą tak jak pokazuję poniżej. on load: set {commandCopy::forbiddenItems::*} to bedrock, diamond sword, diamond helmet, diamond chestplate, diamond leggings and diamond boots Można ją również zapisać w skróconej formie. Gwarancji działania nie daję, ale powinno zadziałać. on load: set {commandCopy::forbiddenItems::*} to bedrock, diamond sword and diamond armor W razie wątpliwości proszę pytać. EDIT: Dodałem diamentowy miecz do zablokowanych przedmiotów. Zaznaczam, że skrypt sprawdza dokładny przedmiot, nie jego typ. Tak więc kopiowanie najprawdopodobniej się powiedzie jeśli przedmiot ma jakąś nazwę. Wtedy należy w drugim warunku (sprawdzanie zawartości listy) zamienić wyrażenie 'player's tool' na 'type of player's tool'. Warto zauważyć, że wtedy tracimy możliwość blokowania konkretnych przedmiotów (z nazwą, lore, itd.). Jeśli Pan chce abym dodał taką funkcjonalność, proszę dać znać. Pozdrawiam.

Wszystko zależy od tego czy i jak Pan zmienił kod funkcji. Proszę go pokazać, sprawdzę w czym rzecz.

Prawda jest taka, że skrypt nie jest wystarczająco złożony w swym działaniu, aby dowodzić tego czy jest Pana dziełem, czy też nie. Wiele takich skryptów na czat już powstało. Tak więc przejmowanie się takimi komentarzami odradzam Panu, a dalszą dyskusję uważam za bezowocną. Nie sposób stwierdzić czy Pan faktycznie napisał go od zera, więc rzucanie oskarżeń jest bezzasadne. Jeśli jednak chce Pan utrzeć nosa niedowiarkom, sugeruję rozwinąć skrypt w taki sposób, aby faktycznie dawał powiew świeżości. Przykłady podam dwa: dodanie osobnego czatu dla osób z permisją (np. czat VIP), zezwolenie moderacji na pisanie na czacie. Oczywiście nie są to jedyne możliwości, wszystko zależy od Pana. Pozdrawiam.

Proszę uprzejmie. Skrypt był testowany. W listenerze zdarzenia 'on load' (zdarzenie następujące przy każdorazowym załadowaniu/przeładowaniu skryptu) dodałem listę trzech przykładowych przedmiotów, których nie można kopiować. Może Pan śmiało ją modyfikować według swoich potrzeb. Myślę, że Pan będzie w stanie rozszyfrować działanie każdej linijki w przypadku chęci modyfikacji samego skryptu. Niemniej jednak, w razie pytań proszę się nie krępować. on load: set {commandCopy::forbiddenItems::*} to ender chest, diamond named "&6Test" and diamond sword of sharpness 3 named "&bTest" command /kopiuj [<text>]: executable by: players cooldown: 5 seconds cooldown message: &cOdczekaj chwilę przed ponownym wykonaniem tej komendy. permission: server.command.kopiuj permission message: &cNie posiadasz wystarczających uprawnień do wykonania tej komendy. trigger: if player's tool is air: send "&cAby komenda zadziałała poprawnie, należy trzymać jakiś przedmiot w ręce." to player cancel cooldown stop if {commandCopy::forbiddenItems::*} contains player's tool: send "&cKopiowanie tego przedmiotu jest zabronione. Spróbuj ponownie trzymając inny przedmiot w ręce." to player cancel cooldown stop if player doesn't have enough space for 1 of player's tool: send "&cNie posiadasz wystarczająco miejsca w ekwipunku, aby móc skopiować przedmiot trzymany w ręce." to player cancel cooldown stop add 1 of player's tool to player's inventory send "&aPomyślnie skopiowano przedmiot trzymany w ręce." to player @Kamateo Pan nie dodał cooldownu i listy przedmiotów, których kopiowanie jest zablokowane. @xAxee Przyjacielu, głupi błąd i rozumiem, że wynika on z pośpiechu, ale zapomniałeś porównać przedmiot trzymany w ręce z listą przedmiotów, których nie można kopiować. Pozdrawiam.

Właśnie coś sobie uświadomiłem. Jeśli chcemy podać 'hay bale' jako wartość typu 'block', musimy podać jak ten blok jest ustawiony (to znaczy jaka jest jego orientacja, na przykład góra-dół). Oczywiście sprawdzanie tego nie ma sensu, bo ta informacja jest zbędna z naszego punktu widzenia. Tak więc niech Pan spróbuje zmienić typy parametrów 2 i 3 z 'block' na 'item type'. Efekt końcowy powinien być taki jak poniżej. # Nagłówek funkcji function upgradeGen(p: player, upgen: item type, genup: item type, c: number, b: block): # Przykładowe wywołanie upgradeGen(player, hay block, coal block, 50, clicked block) Rzecz jasna sam kod funkcji wymaga kilku poprawek, bo powyższa zmiana może nieco namieszać, ale myślę, że Pan da sobie radę. W razie problemów pomogę. Pozdrawiam.

Odpowiedziałem wczoraj Panu na te pytanie. Proszę nie powielać wątków, bo to zaśmieca forum. Co prawda zazwyczaj się to tak robi, ale te rozwiązanie ma jedną wadę - dowolny region o nazwie "spawn" w każdym świecie będzie spełniał powyższy warunek. W przypadku WorldGuard wyrażenie 'region[s] at player' zwraca listę nazw regionów wraz ze światami, w których się znajdują (przynajmniej zawsze to tak działało, być może coś się zmieniło w najnowszej wersji). Tak więc warunek powinien wyglądać tak jak poniżej. if "%regions at player%" contains "spawn in world spawn_world": # Dalszy kod... Warunek będzie spełniony tylko dla regionu o nazwie "spawn" znajdującego się w świecie "spawn_world". Pozdrawiam.

Wedle mojej wiedzy istnieją dwa rozwiązania tego problemu. O pierwszym z nich (teams) już Pan powiedział i nie chce Pan go zastosować. Drugim rozwiązaniem jest wyłączenie kolizji graczy w pliku konfiguracyjnym Papera poprzez ustawienie wartości 'enable-player-collisions' na false. Być może istnieją inne rozwiązania tego problemu (na przykład skorzystanie z pakietu NMS), jednak nie słyszałem o nich.

Przeczytałem, że są tam w pętli jakieś warunki sprawdzające każdego zapętlanego gracza. Przepraszam za niedopatrzenie z mojej strony. W takim wypadku różnica jest, ale na niekorzyść pętli while (a więc na korzyść periodicalu). Oczywiście wydajniejszym rozwiązaniem jest 1 zadanie obsługujące x graczy niż x zadań obsługujących indywidualnie każdego gracza. Zapomniałem również dopisać, że w mojej ocenie najlepsze będzie zapisywanie graczy spełniających warunek do listy zmiennych, którą później zapętlamy wewnątrz periodicalu 'every x'. Wtedy unikamy sprawdzania wartości zmiennej dla wszystkich graczy. Dlatego właśnie zaproponowałem to w przypadku sprawdzania wielu warunków, co pozwala na równomierny rozkład obciążenia serwera (przy założeniu, że czasy dołączania graczy można opisać rozkładem prostokątnym) i zakończenie pętli w przypadku gdy przynajmniej jeden z warunków jest niespełniony.

Nikt nie ma obowiązku wykonywać Pana zleceń, wszyscy to robią jedynie z własnych chęci (nie zaoferował Pan jakiegokolwiek wynagrodzenia). Proszę więc być grzeczniejszym. Wracając do meritum, oto skrypt. Nie był on testowany. command /boss: executable by: players permission: op trigger: spawn zombie at player set {_boss} to last spawned zombie set display name of {_boss} to "&6Piniata" set knockback resistance attribute of {_boss} to 1 set movement speed attribute of {_boss} to 0 set max health of {_boss} to 200 heal {_boss} add "Piniata Boss" to scoreboard tags of {_boss} while {_boss} is alive: send action bar "&cPiniata&7: &6%health of {_boss}%&7/&6%max health of {_boss}%" to all players wait 2 seconds on damage: if attacker has scoreboard tag "Piniata Boss": cancel event attacker is a player victim has scoreboard tag "Piniata Boss" set damage to 1

Nie ma za co Pan przepraszać, ponieważ skrypt wygląda całkiem dobrze. Niemniej jednak mam dwie uwagi dotyczące optymalizacji skryptu. Zapętlanie wszystkich graczy w jednej chwili czasu co sekundę nie jest dobrym rozwiązaniem. Dlaczego? Proszę zwrócić uwagę na to, że Pan wykonuje dla wszystkich graczy operację w jednym konkretnym momencie, co może być powodem większego obciążenia na serwerze. Zamiast tego powinien Pan rozłożyć je równomiernie w czasie. Jak tego dokonać? Niech Pan przy każdorazowym dołączeniu gracza na serwer (listener zdarzenia 'on join') rozpoczyna pętlę 'while' z warunkiem 'player is online'. W jej środku może Pan dodać wysyłanie wiadomości na action bar i opóźnienie. Nie ma potrzeby wysyłania wiadomości na action bar co sekundę, gdyż wyświetla się ona przez co najmniej 2 sekundy (dokładnego czasu nie znam). Niech więc Pan zmieni opóźnienie na dwie sekundy - dzięki temu kod będzie się wykonywał 2 razy rzadziej. Pozdrawiam.