Kormic

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.

Proszę uprzejmie. Skrypt nie był przeze mnie testowany. W razie chęci konfiguracji myślę, że całość jest zrozumiała. Do działania skryptu wymagany jest skrypt pyraTOP REBORN autorstwa Pana Marudy. Artykuł opisujący ów skrypt znajduje się tutaj. options: topListSize: 5 on join: set {topStatistics::kills::%player%} to 0 if {topStatistics::kills::%player%} is not set set {topStatistics::deaths::%player%} to 0 if {topStatistics::deaths::%player%} is not set set {topStatistics::eatenEnchantedApples::%player%} to 0 if {topStatistics::eatenEnchantedApples::%player%} is not set set {topStatistics::minedStone::%player%} to 0 if {topStatistics::minedStone::%player%} is not set every 5 minutes: set {topList::kills::*} to createTop("topStatistics::kills", {@topListSize}, "&3[I]&7. &b[P]&7: &6[V]") set {topList::deaths::*} to createTop("topStatistics::deaths", {@topListSize}, "&3[I]&7. &b[P]&7: &6[V]") set {topList::eatenEnchantedApples::*} to createTop("topStatistics::eatenEnchantedApples", {@topListSize}, "&3[I]&7. &b[P]&7: &6[V]") set {topList::minedStone::*} to createTop("topStatistics::minedStone", {@topListSize}, "&3[I]&7. &b[P]&7: &6[V]") on death of player: add 1 to {topStatistics::deaths::%victim%} attacker is a player add 1 to {topStatistics::kills::%attacker%} on consume of enchanted golden apple: add 1 to {topStatistics::eatenEnchantedApples::%player%} on break of stone: add 1 to {topStatistics::minedStone::%player%} command /top: executable by: players trigger: set {_topGUI} to chest inventory with 3 rows named "&6&lRankingi graczy" set slot (integers between 0 and 26) of {_topGUI} to gray stained glass pane set slot (4, 13 and 22) of {_topGUI} to white stained glass pane set slot 11 of {_topGUI} to iron sword named "&cNajwięcej zabójstw" with lore {topList::kills::*} set slot 12 of {_topGUI} to skeleton skull named "&cNajwięcej śmierci" with lore {topList::deaths::*} set slot 14 of {_topGUI} to enchanted golden apple named "&cNajwięcej zjedzonych złotych jabłek" with lore {topList::eatenEnchantedApples::*} set slot 15 of {_topGUI} to iron pickaxe named "&cNajwięcej wykopanego kamienia" with lore {topList::minedStone::*} open {_topGUI} to player Jedna uwaga na koniec ode mnie. Na początku skrypt będzie wyświetlał jedną wielką listę zawierającą "<none>", jednakże wystarczy dać mu "popracować" przez 5 minut i rankingi po tym czasie powinny zostać utworzone.

Inne rozwiązanie to zapętlanie graczy w regionie obejmującym obszar AFK co jakiś czas. Wtedy Pan nie musi się przejmować zatrzymywaniem pętli gdy gracz jest offline. Jedyna i myślę, że duża wada tego rozwiązania jest taka, że wszyscy gracze będą otrzymywali klucze w tym samym momencie. Tak więc z pewnością będzie się Pan borykał z nadużyciami tej wady. Przykład: Jeden z graczy wie co ile i kiedy rozdawane są klucze, więc wchodzi do strefy AFK tuż przed momentem rozdania kluczy i zaraz po tym szybko z niej wychodzi. W ten sposób może normalnie grać i jednocześnie otrzymywać darmowe klucze. Jeśli Pan nie spodziewa się kilkuset graczy w strefie AFK, zwykły warunek sprawdzający co kilka sekund czy gracz jest na serwerze nie powinien być obciążający. Aha, jeszcze jedno. Jeśli Pan chce, może Pan stworzyć licznik. Na przykład będzie Pan wykonywał pętlę 'while' co 5 sekund, a chce Pan rozdawać klucze co 15 minut w strefie AFK. 15 minut to 900 sekund, a 900/5 = 180. Tak więc mógłby Pan przy każdej iteracji pętli zwiększać wartość licznika o 1 aż do 180, a gdy będzie ona równa 180, wręcza Pan graczowi klucz i zeruje licznik (ustawia na 0).

Można ten mechanizm zaimplementować za pomocą pętli while z warunkiem 'player is online'. W środku pętli doda Pan jakieś opóźnienie, ale nie co kilka minut (w zależności od tego co ile minut, a może i godzin chce Pan dawać klucze), bo jest szansa, że gracz będzie wracał. Powinien Pan więc odtwarzać tę pętlę co kilka sekund i jeśli gracz nie jest online, wychodzi Pan z niej (instrukcja 'exit loop'). Oczywiście samo dawanie kluczy to sprawa myślę, że trywialna - nie potrzebuje tutaj Pan mojej porady. Nie wykluczam, że moje rozwiązanie jest wadliwe. To jest rozwiązanie, które jako pierwsze przyszło mi do głowy. W razie pytań proszę się nie krępować, służę pomocą. Pozdrawiam.