Kormic

Najprostszy sposób jaki przychodzi mi do głowy to nadanie każdemu z tych barwników unikalnych znaczników (tagów) NBT zawierających czas w nanosekundach wyznaczony względem pewnego arbitralnie ustalonego momentu (czasu). Nie będzie to widoczne dla gracza, a i unikamy nasłuchiwania do rozmaitych wariantów zdarzenia 'on inventory click'. Proszę bardzo. Skrypt był testowany i zdaje się, że wszystko działa tak jak powinno. Do jego poprawnego działania wymagane są dodatki skript-reflect i SkBee. Rzecz jasna, niemożliwym jest uczynienie wszystkich istniejących już na serwerze barwników na serwerze niestackowalnymi. Możemy jedynie przy pewnych zdarzeniach i tworzeniu nowych czynić je takimi. Ponadto, proszę sobie wyobrazić chociażby sytuację, w której gracz posiada setki tych barwników w skrzyni. Przy takiej podmianie albo by je stracił z tej skrzyni, albo zostałyby one wyrzucone na ziemię. Jak może Pan zauważyć, podmiana przedmiotu następuje tylko przy podnoszeniu przedmiotów. Wydaje mi się, że jest to wystarczające. Zresztą, gdybym miał podmieniać te przedmioty w ekwipunkach lub skrzyniach graczy, doszłoby do czarnego scenariusza, który opisałem wyżej. import: java.lang.System options: stackableItem: red dye named "&7test" function addUnstackableNBTTag(i: item) :: item: if tag "timeID" of nbt of {_i} is set: return {_i} set {_newTimeID} to System.nanoTime() add "{timeID:%{_newTimeID}%L}" to nbt of {_i} return {_i} pick up: 1 of event-item is {@stackableItem} tag "timeID" of nbt of event-item is not set cancel event delete event-dropped item set {_amount} to item amount of event-item loop {_amount} times: drop addUnstackableNBTTag({@stackableItem}) at event-player Na koniec dodam, że mogłem również to rozwiązać za pomocą modyfikacji CustomModelData lub PersistentDataContainer, ale nie zrobiłem tego w ten sposób, bo miałem ku temu pewne powody. Nie użyłem CustomModelData, gdyż blokuje to możliwość używania jakichkolwiek paczek zasobów (resource pack). Gdyby było tego mało, nie ma gwarancji, że już jakiś inny plugin nie wykorzystuje CustomModelData jako na przykład systemu ID. Nie wprowadzałem również danych do PersistentDataContainer, ponieważ użycie NBT w tym przypadku było zwyczajnie prostsze (ten sposób zajmuje mniej linijek). Gdyby coś było nie tak ze skryptem, proszę dać znać. Pozdrawiam.

Nic się nie stało. Proszę, oto skrypt. Co prawda testowałem go na samym sobie, ale z tego co widzę, powinien działać bezproblemowo. options: GUIName: &aSety command /sety: executable by: players trigger: set {_gui} to chest inventory with 4 rows named "{@GUIName}" set slots (integers from 27 to 35) of {_gui} to dark gray glass pane named "" set slot 31 of {_gui} to lime dye named "&a&lDodaj sety" open {_gui} to player inventory click: event-inventory is not player's inventory name of event-inventory is "{@GUIName}" index of clicked slot is between 27 and 35 cancel event index of clicked slot is 31 set {_items::*} to (slots (integers from 0 to 26) of player's top inventory) where [input is not air] close player's inventory if size of {_items::*} = 0: send "&6Nie włożyłeś jakichkolwiek przedmiotów do GUI." to player stop loop all players where [input is not player]: if loop-player has enough space for {_items::*}: send "&aOtrzymałeś &6%size of {_items::*}% &aróżnych przedmiotów od &b%player%&a." to loop-player continue send "&6Otrzymałeś &e%size of {_items::*}% &6różnych przedmiotów od &b%player%&6. Niestety, nie posiadasz na nie wystarczająco dużo miejsca w ekwipunku." to loop-player if player doesn't have enough space for {_items::*}: send "&6Niestety, nie posiadasz wystarczająco dużo miejsca w ekwipunku na przedmioty, które dałeś wszystkim graczom." to player give {_items::*} to all players send "&aWręczyłeś innym graczom &6%size of {_items::*}% &aróżnych przedmiotów." to player Gdyby wystąpiły jakieś błędy lub pojawiły się problemy z tym skryptem, proszę śmiało pisać. Pozdrawiam.

Chciałbym się upewnić czy dobrze zrozumiałem treść zlecenia. Więc tak: gracz może wsadzić dowolne elementy zbroi do tego GUI, a po kliknięciu barwnika GUI się zamyka (to sobie dopowiedziałem) i każdy z graczy otrzymuje tę zbroje. Pojawiają się więc dwa pytania: Czy gracz wkładający zbroję traci ją bezpowrotnie? Co jeśli któryś z graczy nie posiada miejsca w ekwipunku na zbroję? Jest ona wyrzucana na ziemi czy też po prostu nie jest dawana? A może coś innego się dzieje? Jeśli Pan może, proszę doprecyzować co skrypt dokładnie ma robić. Pozdrawiam.

@SphynxInc @Hiri12 Błąd wynikał z niepoprawnej kolejności wyrażeń w efekcie dającym przedmiot graczowi. Zaklęcie nakładane na przedmiot podajemy po typie przedmiotu i przed jego nazwą. Można sobie zapamiętać taką kolejność: give <gracz> [<ilość> [of]] <typ przedmiotu> [of <typ zaklęcia> <poziom zaklęcia>] [named "<nazwa>"] [with lore "<lore>"] Rzecz jasna, nawiasy kwadratowe oznaczają opcjonalność. Pozdrawiam.

No dobrze. W takim razie prosiłbym Pana, aby zmienił Pan tytuł wątku na taki związany z kolorowaniem tekstu na tęczowo od miejsca wystąpienia frazy "<rainbow>". Wracając do meritum, udostępniam Panu poniżej napisaną przeze mnie funkcję kolorującą dowolny tekst na tęczowo. function rainbowText(t: text) :: text: set {_k::*} to "4,c,6,e,a,2,9,d" split at "," set {_t::*} to {_t} split at "" set {_kIndex} to random integer between 1 and (size of {_k::*}) set {_colorText} to "" loop {_t::*}: if loop-value matches "\s": set {_colorText} to "%{_colorText}%%loop-value%" continue set {_s} to "&%{_k::%{_kIndex}%}%" set {_colorText} to "%{_colorText}%%{_s}%%loop-value%" if {_kIndex} = (size of {_k::*}): set {_kIndex} to 1 continue add 1 to {_kIndex} return coloured {_colorText} Oczywiście to nie całość, gdyż Pan chce, aby od miejsca wystąpienia wyżej wspomnianej frazy, tekst był kolorowany na tęczowo. Dlatego też przyda się jeszcze jedna funkcja wykrywająca ją (frazę) i interpretującą w odpowiedni sposób. function parseRainbowKeyword(t: text) :: text: {_t} doesn't contain "<rainbow>": return {_t} set {_rainbowIndex} to first index of "<rainbow>" in {_t} set {_textToColor} to {_t} replace all "<rainbow>" in {_t} with "" set {_subBasic} to first ({_rainbowIndex} - 1) characters of {_t} set {_subRainbow} to last ((length of {_t}) - {_rainbowIndex} + 1) characters of {_t} set {_colouredText} to "%{_subBasic}%%rainbowText({_subRainbow})%" return {_colouredText} Mając obie powyższe funkcje, wywołujemy drugą z nich ('parseRainbowKeyword') tam gdzie tego potrzebujemy. Przykłady poniżej. command /testrainbow [<text="Hello <rainbow>world!">]: trigger: send parseRainbowKeyword(arg) to sender on chat: set message to parseRainbowKeyword(message) Pozdrawiam.

Chciałbym dopytać, bo albo Pan źle sformułował zlecenie, albo też Pan, który podjął się go, źle zrozumiał jego treść. Czy tylko jedna litera ma być pokolorowana po każdorazowym wystąpieniu <nb>, czy też reszta wiadomości po tym słowie ma być w całości pokolorowana? Jeśli to drugie, zlecenie zostało dobrze wykonane i kod powinien działać bez zarzutu. Jeśli jednak chodziło o to pierwsze, kod trzeba będzie nieco zmodyfikować. Pozdrawiam.

Wedle mojej wiedzy Skript nie implementuje systemu atrybutów dla przedmiotów. Na tą chwilę możliwa jest jedynie modyfikacja atrybutów bytów. Możliwe jednak jest rozwiązanie tego problemu przy pomocy dodatku skript-reflect. Wystarczy zmodyfikować ItemMeta przedmiotu. Poniższy kod nie był testowany, proszę to mieć na uwadze. Pierwszy raz posługuję się klasą NamespacedKey, gdyż ostatni raz modyfikowałem atrybuty przedmiotów gdy jeszcze użycie UUID i dodatkowej nazwy w konstruktorze klasy AttributeModifier było na porządku dziennym. import: org.bukkit.NamespacedKey org.bukkit.attribute.AttributeModifier org.bukkit.attribute.AttributeModifier$Operation as AttributeModifierOperation org.bukkit.inventory.EquipmentSlotGroup org.bukkit.attribute.Attribute command /addattackspeed: executable by: players permission: server.command.addattackspeed trigger: player's tool is not air set {_item} to player's tool set {_itemMeta} to {_item}.getItemMeta() set {_nsKey} to new NamespacedKey(instance of plugin "Skript", UUID.randomUUID().toString()) set {_amount} to 1 set {_operation} to AttributeModifierOperation.ADD_NUMBER set {_eqSlot} to EquipmentSlotGroup.getByName("hand") set {_modifier} to new AttributeModifier({_nsKey}, {_amount}, {_operation}, {_eqSlot}) {_itemMeta}.addAttributeModifier(Attribute.GENERIC_ATTACK_SPEED, {_modifier}) {_item}.setItemMeta({_itemMeta}) Jeśli Pan chce, istnieje również drugi sposób. Mianowicie, może Pan dodać za pomocą dodatku obsługującego NBT (np. SkBee) znacznik (tag) opisujący atrybut, który chce Pan dodać. Więcej informacji o tym znajdzie Pan na wiki dodatku SkBee. Pozdrawiam.

Nie ma za co dziękować. Co do uwagi z ilością graczy - nic to nie zmienia, gdyż i tak skrypt nigdy nie wylosuje więcej niż 8 graczy (użycie funkcji 'min', która wybiera mniejszą liczbę spośród dwóch (lub więcej) podanych). Zauważyłem jednak, że kod napisany przeze mnie wygląda mało elegancko. Dlatego też poprawiłem niektóre jego elementy. W razie problemów proszę dać znać. Pozdrawiam.

Proszę uprzejmie. Napisałem Panu funkcję realizująca opisane wyżej losowanie. Gracze mają przypisane lokalizacje w zmiennej {randomizedSpawnLocations::%nazwa gracza%} (bądź UUID gracza, w zależności od ustawień w pliku konfiguracyjnym pluginu Skript). function assignSpawnsToPlayers(playersList: players, locationsList: locations): stop if size of {_playersList::*} != size of {_locationsList::*} loop {_playersList::*}: set {_randomLoc} to random element out of {_locationsList::*} set {randomizedSpawnLocations::%loop-value%} to {_randomLoc} remove {_randomLoc} from {_locationsList::*} Załączam również przykład jej wykorzystania. Dodałem komentarze dla łatwiejszego zrozumienia. Zaznaczam, że ani funkcja, ani poniższy kod ją wykorzystujący, nie były testowane. command /teleportacja: permission: server.command.teleportacja trigger: # Tworzenie 8 lokalizacji, do których gracze będą teleportowani set {_locList::1} to location at (100, 100, 100) in world "world" set {_locList::2} to location at (200, 100, 200) in world "world" set {_locList::3} to location at (300, 100, 300) in world "world" set {_locList::4} to location at (400, 100, 400) in world "world" set {_locList::5} to location at (500, 100, 500) in world "world" set {_locList::6} to location at (600, 100, 600) in world "world" set {_locList::7} to location at (700, 100, 700) in world "world" set {_locList::8} to location at (800, 100, 800) in world "world" # Ustawienie ilości losowanych graczy (zabezpieczenie przed losowaniem 8 graczy, # gdy na serwerze jest mniej niż 8) set {_numberOfRandomPlayers} to min(size of all players, 8) # Wybieranie nie więcej niż 8 losowych graczy na serwerze while size of {_plList::*} < {_numberOfRandomPlayers}: set {_randomPlayer} to random player out of all players {_plList::*} doesn't contain {_randomPlayer} add {_randomPlayer} to {_plList::*} # Wykorzystanie napisanej wyżej funkcji assignSpawnsToPlayers({_plList::*}, {_locList::*}) # Teleportacja graczy do przydzielonych im lokalizacji loop {_plList::*}: teleport loop-value to {randomizedSpawnLocations::%loop-value%} send "&aZostałeś przeteleportowany!" to loop-value W razie ewentualnych problemów, bądź pytań, proszę śmiało pisać. Chętnie pomogę. Pozdrawiam.

'&u' jest już zarezerwowane dla podkreślenia (alternatywa dla '&n', więcej informacji znajdzie Pan tutaj). Jeśli chodzi o włączenie interpretowania kolorów na czacie, można to zrobić w prosty sposób. Przykład poniżej. on chat: set message to coloured message W normalnym przypadku wszelkie kody kolorów nie są interpretowane. Po tej modyfikacji każdy będzie mógł używać dowolnych kolorów i stylów na czacie. Zalecam jednak zainteresować się jakimś pluginem obsługującym czat, w którym z pewnością będzie możliwość włączenia tej opcji. Pozdrawiam.

Proszę sprawdzić czy Pan ma ustawiony gamerule 'mobGriefing' na 'true'. Jeśli jest on ustawiony na 'false', wieśniacy nie mogą zbierać jedzenia i wykonywać pracy w polu. Pozdrawiam.

Twórca silnika Tuinity zakończył rozwój go w 2021 roku, co zresztą można stwierdzić po tym, że repozytorium na Githubie zostało zarchiwizowane. Powodem jest to, że wszelkie zmiany, które Tuinity wprowadzał, są od tego czasu obecne w silniku Paper. Można więc powiedzieć, że stracił on sens swojego istnienia. Można sobie zadać następujące pytanie: "Dlaczego twórca zarchiwizował te repozytorium i zablokował możliwość pobierania? Mógł je spokojnie zostawić". W mojej ocenie była to dobra decyzja, bo dzięki temu nie naraża mniej świadomych twórców serwerów na korzystanie z niewspieranego już silnika, który tym samym może zawierać błędy i stwarza zagrożenie wykorzystania ich w złych celach przez osoby trzecie. Podsumowując, proszę pobrać sobie najnowszą wersję silnika Paper dla Pana serwera. Będzie on oferował tyle samo, a pewnie i więcej niż odpowiadająca mu wersja Tuinity. Pozdrawiam.

W rzeczy samej ciekawe. Będąc szczerym, nie mam pojęcia dlaczego wykluczenie innych bloków poza wodą powoduje takie zachowanie. Z ciekawości, niech Pan sprawdzi co się dzieje gdy Pan wykluczy tylko lawę i wodę. Być może alias 'any leaves' w połączeniu z wodą jest przyczyną tego problemu. Wracając do meritum, myślę, że mam remedium na to. Wykorzystam instrukcję warunkową 'if any'. function getRandomLoc(xmin: integer=-1000, xmax: integer=1000, zmin: integer=-1000, zmax: integer=1000, world: text="world") :: location: while {_return} is not set: set {_x} to random integer between {_xmin} and {_xmax} set {_z} to random integer between {_zmin} and {_zmax} set {_loc} to location of highest solid block at location at ({_x}, 0, {_z}) in world {_world} if any: type of block at {_loc} = any leaves type of block at {_loc} = water type of block at {_loc} = lava then: stop add 1 to y of {_loc} type of block at {_loc} != lava type of block above block at {_loc} != lava set {_return} to {_loc} return {_return} Można również rozwiązać to za pomocą listy, która będzie zawierała zabronione typy bloków. function getRandomLoc(xmin: integer=-1000, xmax: integer=1000, zmin: integer=-1000, zmax: integer=1000, world: text="world") :: location: while {_return} is not set: set {_x} to random integer between {_xmin} and {_xmax} set {_z} to random integer between {_zmin} and {_zmax} set {_loc} to location of highest solid block at location at ({_x}, 0, {_z}) in world {_world} set {_forbiddenBlockTypes::*} to any leaves, water and lava if {_forbiddenBlockTypes::*} contains type of block at {_loc}: stop add 1 to y of {_loc} type of block at {_loc} != lava type of block above block at {_loc} != lava set {_return} to {_loc} return {_return} Oczywiście możliwym jest również zapętlenie listy {_forbiddenBlockTypes::*} i porównywanie w środku pętli 'loop-value' z 'type of block at {_loc}', ale powinny wystarczyć Panu powyższe dwa warianty. Pozdrawiam.

Zastanawia mnie to w jaki sposób Panu ten skrypt w ogóle zadziałał. Proszę zauważyć, że do zmiennej {_loc} zapisujemy informację o bloku (nie jego lokalizację!), a następnie używamy tej zmiennej tak jakby przechowywała informację o lokalizacji. Być może jest to jakaś specyfika Skript, ewentualnie twórcy dodali takie zabezpieczenie, aby mniej doświadczeni skrypterzy nie wyrywali sobie włosów, bo właściwie proszą o 'block at highest solid block at %location%...'. Druga sprawa to to, że nie musi Pan wypisywać wszystkich rodzajów liści. Wystarczy użyć aliasu 'any leaves' w celu porównania bloku. Proszę bardzo. Bazując na Pana poście, uznałem go jako zlecenie. Na następny raz proszę zwracać na to uwagę, gdyż ten post powinien się znaleźć w dziale "Skript > Zlecenia". Dział "Skript > Pytania i problemy" służy do odpowiedzi na pewne pytania bądź nakierowywania borykających się z problemami na poprawne odpowiedzi. Może Pan zauważyć, że dla bezpieczeństwa użyłem wyrażenia 'type of %block%'. Co prawda Skript jest w tej kwestii "inteligentny" i zrozumiałby porównanie bloku z typem bloku, jednakże w ten sposób dajemy sobie gwarancję poprawnego sprawdzenia zgodności typów bloków. Zaznaczam, że skrypt nie był testowany. function getRandomLoc(xmin: integer=-1000, xmax: integer=1000, zmin: integer=-1000, zmax: integer=1000, world: text="world") :: location: while {_return} is not set: set {_x} to random integer between {_xmin} and {_xmax} set {_z} to random integer between {_zmin} and {_zmax} set {_loc} to location of highest solid block at location at ({_x}, 0, {_z}) in world {_world} if type of block at {_loc} != any leaves or water or lava: add 1 to y of {_loc} type of block at {_loc} != lava type of block above block at {_loc} != lava set {_return} to {_loc} return {_return} Pozdrawiam.

Proszę bardzo. Skrypt był częściowo testowany - testowałem wędkę jedynie na samym sobie. Do działania skryptu wymagane są dodatek skript-reflect i silnik Paper (bądź dowolny jego fork). import: org.bukkit.event.player.PlayerFishEvent org.bukkit.event.player.PlayerFishEvent$State as PlayerFishEventState org.bukkit.event.entity.ProjectileHitEvent PlayerFishEvent: event.getState() is PlayerFishEventState.CAUGHT_ENTITY or PlayerFishEventState.REEL_IN or PlayerFishEventState.FAILED_ATTEMPT set {_caughtEntity} to event.getCaught() {_caughtEntity} is a player clear {caughtWithRod::disabledJump::%{_caughtEntity}%} ProjectileHitEvent: event.getEntity() is a fish hook set {_hitEntity} to event.getHitEntity() {_hitEntity} is a player set {caughtWithRod::disabledJump::%{_hitEntity}%} to true disconnect: {caughtWithRod::disabledJump::%player%} is set clear {caughtWithRod::disabledJump::%player%} player jump: {caughtWithRod::disabledJump::%player%} is set cancel event Pojawia się jeszcze kwestia ewentualnych bugów przy zbyt dalekim odejściu graczy od siebie lub wyjściu złapanego gracza z serwera. Mogę jedynie powiedzieć, że w przypadku pierwszego problemu stan REEL_IN może to rozwiązywać, a w przypadku drugiego nasłuchiwanie do zdarzenia 'disconnect' powinno pomóc. Pozdrawiam.

Przyczyny braku poprawnego działania skryptu są dwie. Wypiszę je Panu poniżej. Najważniejsze - wprowadzenie poziomu 1. do kodu na sztywno (chociażby przy sprawdzaniu nazwy w linijce 28.), co sprawiło, że ulepszanie działało do poziomu nie wyższego niż 2. Pobieranie informacji o poziomie pędzla (brusha) z lore przedmiotu pomimo faktu, iż jest on zapisany bezpośrednio w jego nazwie. Rozwiązaniem pierwszego problemu jest skorzystanie z wyrażeń regularnych (RegEx). Wystarczy napisać wzorzec sprawdzający czy w miejscu poziomu znajduje się jakakolwiek liczba całkowita nieujemna. Drugi problem to kwestia dzielenia nazwy na każdej spacji i wyciąganiu odpowiedniego jej fragmentu (w naszym przypadku czwarty fragment nazwy to poziom pędzla) w celu zapisania go jako poziom. Proszę bardzo. Skrypt nie był testowany. Pozdrawiam.

Proszę bardzo, skrypt był testowany. Niestety nie opisał Pan szczegółowo czym mają być wspomniane klucze, więc oparłem mechanizm nagradzania na wywoływaniu komendy przez konsole dającej przedmiot graczom. Najważniejszy kod znajdzie Pan w definicji komendy /nagrody i listenerze zdarzenia 'on inventory click'. Może Pan w tych miejscach dostosować skrypt do swoich potrzeb. W razie pytań służę pomocą. Pozdrawiam.

Skoro Pan prosi o poprawiony skrypt, rozumiem, że to jest zlecenie. Powinno się więc ono pojawić w dziale "Skript > Zlecenia". Proszę bardzo. Skróciłem Pana kod poprzez zastąpienie ustawiania szyb pojedynczo instrukcją zawierającą to wyrażenie. Poprawiłem również fragment z ustawianiem lore przedmiotu. Nie rozumiem jednak dlaczego Pan próbował korzystać z placeholderu Vaulta skoro Skript udostępnia równoważne wyrażenie. Na wszelki wypadek dopowiem, że jeśli chciałby Pan pobrać wartości istniejących placeholderów w innych skryptach, najprościej będzie skorzystać z dodatku skript-placeholders. command /me: executable by: players trigger: set {_gui} to chest inventory with 5 rows named "&bRangi" # Ustawianie szarych szyb set slot (integers from 0 to 44) of {_gui} to gray glass pane named "&8" # Ustawianie głowy gracza set {_head} to player's skull set name of {_head} to "&f%player's name%" add "&7Pieniądze: &a%player's balance%" to lore of {_head} add "&7Przegrany czas: &a%player's time played%" to lore of {_head} set slot 4 of {_gui} to {_head} open {_gui} to player on inventory click: name of clicked inventory is "&bRangi" event-inventory is not player's inventory cancel event Jeśli z jakiegoś powodu ustawianie lore nie zadziała, może Pan skorzystać z tego wyrażenia. Przykład poniżej. set line 1 of {_head}'s lore to "&7Pieniądze: &a%player's balance%" Pozdrawiam.

Proszę uprzejmie. on death of player: attacker is set attacker is not a player set death message to "&c%victim% &6został zabity przez &c%attacker%&6." W razie potrzeby można zamienić ustawianie 'death message' na wysyłanie wiadomości na czacie. Wystarczy zastąpić ostatnią linijkę instrukcją 'broadcast' lub 'send'. # Wysyłanie do wszystkich graczy i konsoli broadcast "&c%victim% &6został zabity przez &c%attacker%&6." # Wysyłanie do wszystkich graczy send "&c%victim% &6został zabity przez &c%attacker%&6." to all players Pozdrawiam.

Oczywiście można powyższy problem rozwiązać w ten sposób, jednak długoterminowo takie podejście nie jest wskazane. Proszę sobie wyobrazić sytuację, w której na serwerze jest dodane kilkanaście (jeśli nie kilkadziesiąt) kluczy. Z pewnością będzie to niewygodne. Również można rozwiązać to w ten sposób, ale autor pluginu ExcellentCrates udostępnił pewne narzędzia do obsługi (ściślej mówiąc, API) pluginu. Ręczna obsługa NBT jest jeszcze gorsza, proszę tak nie robić. W porównaniu do tego zapisywanie kluczy w zmiennych jest już zdecydowanie lepsze. Poniżej prezentuję przykładowe rozwiązanie Pana problemu. Do działania poniższego fragmentu kodu wymagany jest dodatek skript-reflect, który swoją drogą jest w mojej ocenie najbardziej uniwersalnym dodatkiem, gdyż otwiera przed twórcami możliwości bezpośredniej pracy z pluginami i bibliotekami Javy. # Import klasy CratesAPI udostępniającej najważniejsze metody do obsługi graczy, skrzynek, kluczy (najlepiej umieścić na samej górze skryptu) import: su.nightexpress.excellentcrates.CratesAPI # Poniższy kod wstawić w odpowiednie miejsce w skrypcie i skonfigurować wedle potrzeb set {_keyManager} to CratesAPI.getKeyManager() set {_yourKey} to {_keyManager}.getKeyById("ID klucza") Kod napisany na podstawie plików: https://github.com/nulli0n/ExcellentCrates-spigot/blob/master/src/main/java/su/nightexpress/excellentcrates/CratesAPI.java#L31 https://github.com/nulli0n/ExcellentCrates-spigot/blob/master/src/main/java/su/nightexpress/excellentcrates/key/KeyManager.java#L133 Jeśli Pan potrzebuje, dokumentację pluginu skript-reflect znajdzie Pan tutaj. Zmienna {_yourKey} od tego miejsca zawiera klucz o danym identyfikatorze. Myślę, że Pan będzie już wiedział jak dalej postępować. W razie pytań służę pomocą. Pozdrawiam.

Wedle narzuconych warunków, mechanizm sprowadza się do anulowania zdarzenia atakowania gdy ofiara (atakowany gracz) posiada permisję "bez.bicia". Proszę uprzejmie, skrypt udostępniam poniżej. on damage of player: attacker is a player victim has permission "bez.bicia" cancel event send "&cTen gracz nie może być atakowany." to attacker Pozdrawiam.

Z tą najlepszą społecznością Minecraft to mogę to lakonicznie podsumować w ten sposób: dawno i nieprawda. Proszę Pana, punkt widzenia zależy od punktu siedzenia. Pan odnosi się do widocznej dla gracza części owego systemu, ja natomiast mówię o implementacji go, działaniu "za kulisami". Wszystko zależy od tego ile i jakie Pan życzy sobie zadania. Ważne jest również to jakie nagrody ma gracz otrzymywać i co ma się dziać chociażby w przypadku gdy gracz nie będzie miał miejsca na nią w ekwipunku. Rzeczy do opisania jest wiele, proszę więc Pana o dokładne wytyczne. Co do wyceny - mogę Pana zapewnić, że jestem uczciwym człowiekiem i nie obedrę Pana z wszelkich funduszy. Niemniej jednak, tak jak powiedziałem wyżej, decydującym czynnikiem w tej kwestii jest to czego Pan ode mnie oczekuje. Pozdrawiam.

Proszę odinstalować wszystkie dodatki do Skript i sprawdzić czy problem nadal występuje. Jeśli tak, proszę usunąć cały folder "plugins/Skript" (oczywiście należy przed tym zapisać sobie gdzieś wszystkie skrypty, plik konfiguracyjny "config.sk", plik ze zmiennymi "variables.csv" i wszystkie inne ważne dla Pana pliki), a następnie zrestartować serwer. Skript utworzy na nowo cały folder, co powinno przywrócić poprawne ładowanie skryptów. Jest to mało prawdopodobne, ale jest szansa na to, że nawet ponowne wygenerowanie folderu przez Skript nie sprawi, że problem ustąpi. W takiej sytuacji sugeruję Panu odinstalować również wszystkie pluginy poza samym Skript i przetestować ładowanie skryptów. Dalsze problemy będą oznaką problemu z samym pluginem Skript, bądź z serwerem. Pozdrawiam.

Proszę uprzejmie. Zakładam, że Pan miał na myśli zmienną lokalną. command /losowanie: permission: server.command.losowanie trigger: set {_player} to random player out of all players Rzecz jasna zmienna taka utrzymuje w pamięci swoją wartość do momentu zakończenia wykonywania wyzwalacza komendy. Poza nim jej wartość już nie istnieje. Pozdrawiam.

Zakładam, że kod rzeczywiście znajduje się w jakimkolwiek wyzwalaczu (listenerze zdarzenia, wyzwalaczu komendy, periodicalu, itp.). Dwie uwagi. W przypadku Pana kodu nie ma sensu zapętlać wszystkich przedmiotów, gdyż warunek w trzeciej linijce jakkolwiek nie wykorzystuje zapętlanych przedmiotów. Warunek ten sprawdza tylko to czy gracz posiada wskazany przez Pana przedmiot. Efekt będzie taki, że dla każdego zapętlanego przedmiotu warunek ten będzie sprawdzany, co w sytuacji gdy gracz posiada ów telefon, sprawi, że dla n przedmiotów w ekwipunku gracza wiadomość zostanie wysłana n razy. Należy pamiętać o tym, że warunek sprawdza czy coś jest dokładnie tym przedmiotem. Nie może on więc posiadać różnic w nazwie, lore, zaklęciach, a nawet znacznikach NBT. Dla pewności może Pan do sprawdzenia wykorzystać poniższy kod. command /testitem: executable by: players trigger: player's tool is brick named "&7&lTelefon" with lore "test" send "&aWarunek został spełniony." to player Pozdrawiam.