Kormic

Problem został rozwiązany.

Ten temat został przeniesiony.

Problem został rozwiązany.

Ten kod nie zadziała. W dokumentacji Paper API jest napisane, że PlayerArmorChangeEvent jest wywoływany tylko gdy gracz sam sobie zmieni zbroję. Co więcej, zdarzenie te w nowszych wersjach już nie jest wywoływane, co również jest napisane w dokumentacji. Nie wiem szczerze czy i jak zadziała ustawianie 'nick name' (nie mam jak tego sprawdzić). Wiem tyle, że w kodzie źródłowym Skripta nie wykonuje się jakikolwiek osobny kod dla takiego wariantu, więc podejrzewam, że jest to alias, który sprowadza się do ustawiania 'display name' lub 'tablist name'. Żeby rozwiązać ten problem, należy skorzystać z jakiegoś pluginu, który sam przechwyca zdarzenie zakładania i zdejmowania zbroi. Przykładowe pluginy to ten i ten. Wiem, wiem. Oba są zarchiwizowane, ale podejrzewam, że to nadal będzie poprawnie działało na najnowszych wersjach. Lepiej pewnie będzie skorzystać z tego drugiego, ponieważ był aktualizowany ostatnio 4 lata temu. Pozdrawiam.

Ostatnia możliwość, która przychodzi mi do głowy to problem z wykonywaniem komendy w tym samym ticku co zamykanie GUI. Absurdalne, ale powyższy kod powinien działać. Proszę spróbować podmienić funkcję 'execCommandCloseInv' na poniższą. local function execCommandCloseInv(p: player, t: text): close {_p}'s inventory wait 1 tick execute {_p} command {_t} Jeżeli powyższe nie zadziała to jestem niemalże pewien, że zwyczajnie na Pana serwerze występuje problem z wykonywaniem skryptów. Na dobry początek zalecam odinstalować wszystkie dodatki do Skripta i inne skrypty tak, aby zapewnić "czyste" środowisko pracy. Nadal nie usłyszałem czy GUI się w ogóle zamyka po kliknięciu, więc zakładam, że nie. Gdyby i to nie pomogło, warto sprawdzić czy gracz ma w ogóle permisje do wykonywania podanych w skrypcie komend oraz czy one są w ogóle zarejestrowane. Dobrym pomysłem byłoby zajrzenie do konsoli w poszukiwaniu ewentualnych błędów. Pozdrawiam.

No oczywiście, że tak. Rozwiązanie jest bardzo proste. Proszę wykorzystać listener zdarzenia 'on right click', sprawdzić narzędzie gracza i jeśli to jest ten przedmiot, skorzystać z wyżej wspomnianego efektu. Ot cała filozofia. Jeżeli Pan będzie całkiem zagubiony... podpowiem, że podobny mechanizm jest już wykorzystywany w powyższym skrypcie, który Pan podesłał. Po kliknięciu prawego przycisku myszy mając kompas w ręce, otwiera się graczowi GUI. Podstawa już jest, wystarczy tylko zmienić to co się dzieje po spełnieniu warunku. Pozdrawiam.

Jeśli dobrze zrozumiałem pytanie, tak. Można w tym celu wykorzystać ten efekt. Proszę nie mylić serwera od lobby z serwerem proxy (czyli serwerze, na którym jest zainstalowany Bungeecord). Ponadto, zalecam przejść na silnik Velocity, który jest lepszą alternatywą dla Bungeecorda. Przy przesiadce na Velocity przydatny może się okazać ten poradnik autorstwa @Helios1993. Co prawda nie jest on w 100% ukończony, jednakże przybliża większość kluczowych kwestii przy konfiguracji Velocity, a właściwie to konfiguracji serwera proxy. Pozdrawiam.

Nie ma problemu. Wcześniejszy błąd był związany z brakiem cudzysłowów. options: doubleDropPickaxe: type: diamond pickaxe name: kilof x2 command /doublepickaxe [<text>]: executable by: players permission: server.command.doublepickaxe permission message: &6Nie posiadasz wystarczających uprawnień do wykonania tej komendy. trigger: give player {@doubleDropPickaxe.type} named "{@doubleDropPickaxe.name}" on mine: type of player's tool is {@doubleDropPickaxe.type} name of player's tool is "{@doubleDropPickaxe.name}" cancel item drops loop 2 times: add (drops of event-block using player's tool) to player's inventory Pozdrawiam.

Proszę bardzo. Kilof można przywołać za pomocą komendy /doublepickaxe. Na górze skryptu znajduje się skromna sekcja konfiguracyjna pozwalająca na ustalenie typ i nazwę kilofu. Zaznaczam, że skrypt duplikuje jedynie przedmioty wypadające z bloku w oryginalnej wersji Minecrafta. Jeżeli jakiś skrypt lub blok dodaje przedmioty wypadające z bloku przy jego wykopaniu, nie jestem w stanie tego zmodyfikować. options: doubleDropPickaxe: type: diamond pickaxe name: kilof x2 command /doublepickaxe [<text>]: executable by: players permission: server.command.doublepickaxe permission message: &6Nie posiadasz wystarczających uprawnień do wykonania tej komendy. trigger: give player {@doubleDropPickaxe.type} named "{@doubleDropPickaxe.name}" on mine: type of player's tool is {@doubleDropPickaxe.type} name of player's tool is {@doubleDropPickaxe.name} drop (drops of event-block using player's tool) at event-block Pozdrawiam.

Ten temat został przeniesiony.

Ten temat został przeniesiony do kosza!

Proszę bardzo. Ograniczeniem skryptu jest to, że jako pierwszy argument można wpisać nie więcej niż jedno słowo. Gdyby była potrzeba dodania permisji, myślę, że Pan sam wie jak to zrobić (w końcu widział już Pan kilkadziesiąt skryptów). options: event: correctUsage: &cPoprawne użycie: &6/event <tekst (1 słowo)> <ON/OFF> local function sendActionBarForTimespan(ps: players, t: text, seconds: integer): loop {_seconds} times: send action bar {_t} to {_ps} wait 1 second send action bar "" to {_ps} command /event <text> <text>: usage: {@event.correctUsage} trigger: send title (coloured arg-1) to all players if arg-2 is "ON": set {keepInventoryForAllPlayers} to true sendActionBarForTimespan(all players, "KeepInventory - ON", 10) else if arg-2 is "OFF": clear {keepInventoryForAllPlayers} sendActionBarForTimespan(all players, "KeepInventory - OFF", 10) else: send "{@event.correctUsage}" to sender on death of player: {keepInventoryForAllPlayers} is set keep inventory Skrypt zawiera błąd - w trzecim warunku powinien być sprawdzany drugi argument, nie pierwszy. Jeszcze mam co do tego skryptu dwie uwagi: Dlaczego zamienia Pan tekst na tekst przy wysyłaniu title? Jest to zbędna operacja. Warto wspomnieć, że skrypt wymaga dodatku SkRayFall. Dlaczego argumenty są ustawione jako opcjonalne skoro są wymagane do poprawnego działania komendy? Pozdrawiam.

Już rozumiem. Na przyszłość proszę być dokładniejszym w swoim zleceniu, aby zleceniobiorca nie musiał się domyślać co autor wątku miał na myśli. Jeżeli całkowicie ma być zablokowane przesuwanie przedmiotów w ekwipunku gracza, wystarczy na początku listenera zdarzenia 'on inventory click' dodać kod sprawdzający warunek 'event-inventory is player's inventory'. Gdy warunek jest spełniony, należy anulować zdarzenie kliknięcia w ekwipunku (cancel event). Pozdrawiam.

Nie rozumiem. Przecież to właśnie skrypt robi. Proszę jeszcze raz opisać szczegółowo zlecenie, bo ciągłe dopisywanie kolejnych rzeczy nie ma sensu. Zanim Pan cokolwiek napisze, niech się Pan zastanowi czego potrzebuje i ubierze to ładnie w słowa. Pozdrawiam.

Zlecenie zostało wykonane.

Ależ to właśnie robi Pana skrypt. Jeżeli ten kod nie działa to jest kilka możliwości: serwer korzysta ze starej wersji Minecrafta, serwer korzysta ze starej wersji Skripta, serwer korzysta z przestarzałych dodatków do Skripta, na serwerze dochodzi do konfliktu i na przykład inny serwer lub plugin powoduje odwołanie anulowania zdarzenia 'inventory click'. Proszę podać wersję Skripta, wersje dodatków do niego i wersję serwera. Może Pan od razu przetestować skrypt bez obecności innych skryptów na serwerze, aby zapewnić "czyste" środowisko pracy. Pozdrawiam.

Proszę. command /czek <number>: executable by: players permission: server.command.czek permission message: &6Nie posiadasz wystarczających uprawnień do wykonania tej komendy. usage: &cPoprawne użycie: &6/czek <kwota> trigger: if arg <= 0: send "&6Wartość czeku musi być dodatnia." to player stop give player paper named "&bCzek na &6%arg% $" with lore "&7Kliknij PPM mając go w ręce, aby go zrealizować." on right click: type of player's tool is paper name of player's tool contains "&bCzek na" set {_split::*} to name of player's tool split at " " set {_money} to (uncoloured {_split::3}) parsed as number add {_money} to player's balance send "&aZrealizowałeś czek na &6%{_money}% $&a." to player remove 1 of player's tool from player's inventory Pozdrawiam.

Widzę trzy problemy w kodzie (z czego co do dwóch ostatnich nie jestem w stu procentach pewien): Minuty w listenerze zdarzenia 'on right click with paper' są określane na podstawie trzeciego słowa w nazwie kartki. Co tu jest błędem? Błędem jest to, że trzecim słowem jest "na", a nie ilość minut. Tak więc należy podmienić 3 na 4. Listener zdarzenia 'on right click on paper' możliwe, że w ogóle nie jest wywoływany, ponieważ zwykły papier z perspektywy Skripta nie jest tym samym co papier z nazwą i lore. Sugeruję więc zastąpić te zdarzenie zwykłym 'on right click'. Do tworzenia już od dawna nie stosuje się podwójnego pipe line'a (znaki '||'), ponieważ jest to naleciałość z dawnych czasów SkQuery gdy jeszcze Skript nie wspierał lore z wieloma liniami. W komendzie tworzącej kartkę proponuję poprawić linijkę dającą kartkę na poniższą. give player 1 paper named "&6&l✦ Latanie na %{_minutes}% minut ✦" with lore "&7Kliknij prawym aby aktywować latanie" and "&bUnikalny Kod: %random integer between 1000 and 9999%" Pomijam fakt braku unikalności losowanego kodu, bo nie ma żadnej gwarancji, że nigdy nie pojawią się dwa takie same kody. Nie rozumiem zresztą po co on jest generowany skoro ta informacja nigdzie nie jest używana. Możliwe, że przez ten podwójny pipe line warunek z lore przedmiotu w kodzie wykonywanym po kliknięciu PPM z kartką w ręce nie był spełniany. Mam jeszcze pewne uwagi. Typ argumentu komendy /giveflypaper to powinien być 'integer', a nie 'number', ponieważ pozwala to na podawanie liczb niecałkowitych, co spowoduje brak działania skryptu przy dodawaniu permisji na latanie, gdyż następuje w kodzie dalej próba przemianowania fragmentu nazwy papieru na liczbę całkowitą. Poza tym, raczej nikt nie będzie podawał niecałkowitej liczby minut, bo po co. Sprawdzanie czy argument nr 1 komendy /giveflypaper jest liczbą, nie ma sensu. Już sama komenda poprzez określenie typu argumentu jako 'number' to sprawdza. Ewentualny brak zgodności typu argumentu można wyświetlić za pomocą pola 'usage' w komendzie. Przykład poniżej. command /test <integer>: usage: &cPoprawne użycie: /test <liczba całkowita> trigger: # Dalszy kod... Pozdrawiam.

Dziwne. Przychodzą mi jedynie do głowy dwie rzeczy: albo przemnażanie wektora przez stałą nie działa tak jak powinno, albo też u Pana nie działa wyrażenie 'shooter of %projectile%' tak jak powinno. Co do pierwszego, proszę sprawdzić czy zamiana ostatniej linijki w listenerze zdarzenia 'on damage' na poniższą pomoże. push victim {_v} Jeżeli zadziała, proszę spróbować tak: on damage: projectile is an arrow set {_shooter} to shooter of projectile {_shooter} is a player set {_v} to vector from victim to {_shooter} set {_constV} to vector({@pullForceAmplification}, {@pullForceAmplification}, {@pullForceAmplification}) push victim ({_constV} * {_v}) Druga opcja jest taka, aby spróbować oprzeć mechanizm na metadata. 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 set metadata tag "projectileShooter" of projectile to shooter on damage: projectile is set set {_shooter} to metadata tag "projectileShooter" of projectile {_shooter} is set 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} Tutaj również proszę spróbować podmieniać ostatnią linijkę w listenerze zdarzenia 'on damage' jak wyżej. Pozdrawiam.

Zlecenie zostało wykonane.

Ach tak, niedopatrzenie z mojej strony. on death of player: loop all items in victim's inventory: chance of 35% remove loop-item from drops add loop-item to {keepInventoryChance::%uuid of victim%::*} on respawn: size of {keepInventoryChance::%uuid of player%::*} > 0 add {keepInventoryChance::%uuid of player%::*} to player's inventory clear {keepInventoryChance::%uuid of player%::*} Teraz powinno być już dobrze. Pozdrawiam.

Totem aktywuje się tylko jeśli gracz w momencie śmierci trzyma go w ręce, więc samo posiadanie w ekwipunku jest niewystarczającym warunkiem aktywacji. Do obsłużenia tego zdarzenia można wykorzystać listener 'on resurrect attempt'. Warto zwrócić uwagę na poniższy komentarz w dokumentacji. W dużym uproszczeniu - aby totem nigdy się nie aktywował, wystarczy anulować te zdarzenie (cancel event) na samym początku. Jeżeli jednak mamy zapisywać przedmioty zawsze gdy gracz posiada totem w ekwipunku (niekoniecznie w ręce), musimy zapisać wszystkie przedmioty w ekwipunku gracza do przypisanej do niego jakiejś globalnej listy zmiennych (na przykład {keepInventory::%uuid of entity%::*}), wręczać mu je w listenerze zdarzenia 'on respawn' i czyścić tę listę. Gdyby nie została ona wyczyszczona, z każdą śmiercią gracza z totemem będzie ona przechowywała więcej i więcej przedmiotów, a tego nie chcemy. Oczywiście, na początku zdarzenia 'on resurrection attempt' należy dodać warunek 'entity is a player', ponieważ te zdarzenie działa również na inne żywe byty. Pozdrawiam.

Patrząc na kod i analizując problem, łatwo zauważyć, że przyczyną jest te stałe przesunięcie o 1.2 bloku. Warto to powiązać jakoś z prędkością gracza tak, aby zachodziła tu propocjonalność - im większa prędkość chodu gracza, tym większe jest przesunięcie. Domyślna wartość 'walk speed' gracza to 0.2, a maksymalna to 1. Należy oczywiście jeszcze brać pod uwagę efekt mikstury szybkości i ewentualnie wektor prędkości (preferuję nazywać go wektorem prędkości bezwładnej (na przykład spadanie), bo nazwa może być myląca). Ale przecież skrypt nie modyfikuje atrybutu gracza. Skript wewnętrznie korzysta z metody Player#setWalkSpeed, co można sprawdzić w jego kodzie źródłowym. Jestem niemalże pewien, że ona nie wpływa na atrybut prędkości gracza. Tak długo jak na action barze pokazuje się wartość prędkości gracza z przedziału [-1; 1] (obustronnie domknięty, stąd nawiasy kwadratowe), wszystko jest w porządku. Wartości ujemne też są prawidłowe, oznaczają one odwrócenie kierunku poruszania się. Pozdrawiam.

Proszę. Skrypt nie był testowany. on death of player: loop all items in victim's inventory: chance of 35% add loop-item to {keepInventory::%uuid of victim%::*} on respawn: size of {keepInventory::%uuid of player%::*} > 0 add {keepInventory::%uuid of player%::*} to player's inventory clear {keepInventory::%uuid of player%::*} Pozdrawiam.

Zdarzenie 'portal enter' jest wywoływane w przypadku wejścia w portal do Netheru i portal do Kresu. Aby wykryć teleportację przy pomocy portalu, warto wykorzystać zdarzenie 'on teleport' wraz ze sprawdzeniem przyczyny teleportacji. Proszę. on teleport: teleport cause is end portal event-entity is a player teleport player to {loc::spawn::end} Pozdrawiam.