Kormic

Dziwne. Powinno to działać. Prawdopodobnym winowajcą tutaj jest starsza lub niestabilna wersja (generalnie beta) Skripta, ewentualnie jakiś dodatek lub plugin powodujący taką niecodzienną kolizję. Już dawno nie widziałem, aby ktoś używał wyrażenia 'newline', ponieważ zdecydowana większość instrukcji w Skript jest w stanie operować na listach ciągów znaków. Najprostszym sposobem jest podwójne użycie instrukcji broadcast lub użycie listy ciągów znaków jak poniżej. broadcast "Linia nr 1", "Linia nr 2" and "Linia nr 3" Niemniej jednak, problem został rozwiązany, więc zamykam. Pozdrawiam.

Jak najbardziej. options: miningGoal: 10 on mine: event-block is coal ore or iron ore add 1 to {bloki::%player%::%location of event-block%} if {bloki::%player%::%location of event-block%} >= {@miningGoal}: execute console command "/say Gracz %player% zniszczył co najmniej {@miningGoal} bloków." clear {bloki::%player%::%location of event-block%} stop send "&aMusisz wykopać jeszcze %{@miningGoal} - {bloki::%player%::%location of event-block%}% bloków." to player Pozdrawiam.

Ten temat został przeniesiony.

Nie ma problemu. Proszę bardzo. Poprawiłem również dwie rzeczy w kodzie: bossbar będzie również pokazywał się graczom dołączającym na serwer w trakcie wydarzenia, blok w wylosowanej lokacji jest ustawiany jako diamentowy blok (mój błąd, zapomniałem to dodać). Pozdrawiam.

Proszę bardzo. Skrypt nie był testowany. Na górze skryptu dodałem możliwość konfiguracji miecza i cooldownu rzucania perłami, aby gracze nie mogli nimi rzucać bez przerwy. W samej komendzie można również zmienić permisję wymaganą do komendy /smoczymiecz. options: smoczyMieczType: netherite sword smoczyMieczName: &d&lSmoczy Miecz smoczyMieczCooldown: 3 seconds command /smoczymiecz: executable by: players permission: server.command.smoczymiecz permission message: &6Nie posiadasz wystarczających uprawnień do wykonania tej komendy. trigger: give player {@smoczyMieczType} named "{@smoczyMieczName}" on right click: type of player's tool is {@smoczyMieczType} name of player's tool is {@smoczyMieczName} if {smoczyMiecz::cooldown::%uuid of player%} is set: difference between {smoczyMiecz::cooldown::%uuid of player%} and now is smaller than {@smoczyMieczCooldown} send "&cOdczekaj chwilę." to player stop set {smoczyMiecz::cooldown::%uuid of player%} to now shoot ender pearl from player Pozdrawiam.

Zdaje się, że te wydanie powinno zadziałać na wersji 1.16.4. Jeśli jednak nie zadziała, proszę spróbować z tym. Pozdrawiam.

Ten temat został zamknięty.

Proszę uprzejmie. Skrypt nie był testowany. Do poprawnego działania wymagany jest dodatek SkBee. Na górze skryptu możliwa jest podstawowa konfiguracja jego opcji. Zakładam, że Pan sam się łatwo domyśli co do czego służy. Pozdrawiam.

Najpewniej przyczyną jest jakiś plugin zapobiegający temu. Możliwe, że przyczyną tego jest region stworzony w WorldGuard, który blokuje budowanie dla zwykłych graczy. W każdym bądź razie, musi Pan przejrzeć swoje pluginy (i skrypty, też mogą być przyczyną braku działania) i określić co jest przyczyną. W takim razie proszę bardzo. Na górze skryptu może Pan ustawić permisję, dzięki której skrypt nie dotyczy osób posiadających ją. options: bypassPermission: server.permission.placebreak on load: set {allowedBlocks::blockTypes::*} to dirt, cobblestone and obsidian on break: player doesn't have permission "{@bypassPermission}" {allowedBlocks::blockTypes::*} doesn't contain type of event-block cancel event send "&cNiszczenie tego bloku jest zabronione." to player on place: player doesn't have permission "{@bypassPermission}" {allowedBlocks::blockTypes::*} doesn't contain type of event-block cancel event send "&cStawianie tego bloku jest zabronione." to player Pozdrawiam.

Problem został rozwiązany.

Kilka uwag ode mnie. Utworzenie GUI to jedno, trzeba jeszcze je otworzyć graczom. W skrypcie brakuje sekcji 'options', która powinna zawierać ceny przedmiotów. Sprawdzanie ilości waluty w ekwipunku gracza przy pomocy 'has more than' jest błędem, ponieważ gracz nie będzie w stanie kupić przedmiotu gdy posiada dokładnie wymaganą ilość waluty. Indeksacja pięciowierszowego ekwipunku kończy się na indeksie równym 44, nie 45. Tworzenie zbędnych wcięć w kodzie warunkami jest złą praktyką. Zalecam korzystać z tzw. 'inline conditionals'. Przykład poniżej. Reszta zmian to zmiany według moich preferencji, więc proszę się tym nie przejmować. Podpinam się do prośby o sprecyzowanie zlecenia, to znaczy jakie przedmioty mają się znaleźć w sklepie. options: price1: 10 price2: 5 currency: emerald of unbreaking 10 named "&2Odłamek" command /sklep [<text>]: executable by: players trigger: set {_gui} to chest inventory with 5 rows named "&2Sklep za odłamki" set slot (integers from 0 to 44) of {_gui} to green stained glass pane named "&7" set slot 21 of {_gui} to diamond sword named "&aPrzykładowy item" with lore "{@price1} odłamków" set slot 23 of {_gui} to diamond named "&aDrugi przykładowy item" with lore "{@price2} odłamków" open {_gui} to player on inventory click: event-inventory is not player's inventory name of event-inventory is "&2Sklep za odłamki" cancel event if index of clicked slot is 21: player has {@price1} of {@currency} remove {@price1} of {@currency} from player's inventory give diamond sword to player else if index of clicked slot is 23: player has {@price2} of {@currency} remove {@price2} of {@currency} from player's inventory give diamond to player Pozdrawiam.

Będąc szczerym, nie sądziłem, że tutaj dojdzie do tak merytorycznej dyskusji. Taka wymiana zdań zawsze cieszy oko. Chapeau bas dla obu Panów. A teraz wrócę do meritum sprawy. @kerpson Cache'owanie to z pewnością dobra praktyka i po przejrzeniu biblioteki Caffeine mogę stwierdzić, że jest naprawdę sensownie napisana. Pytanie jednak brzmi - czy warto? A raczej - czy opłaca się? Wystarczy spojrzeć na ilość danych, na jakiej plugin będzie operował. Jeżeli założymy, że ta mapa (HashMap) będzie jedynym pojemnikiem na dane w pluginie, łatwo pokazać, że w normalnych warunkach pracy (patrz: programistyczni puryści, o których wspomniałem wyżej) nie będzie ona przechowywała więcej niż N wpisów, gdzie N to ilość graczy, która weszła na serwer od początku startu serwera. Zakładając, że mówimy o małym serwerze, który jest restartowany co 24 godziny w środku nocy, liczba graczy nie przekroczy 200-300 (mówimy ciągle o wszystkich unikalnych graczach liczonych od początku działania pluginu). Gdyby to był popularny serwer, z pewnością użycie tej czy innej biblioteki do cache'owania jest dobre. W tym przypadku jednak wydaje mi się, że to jest delikatny tzw. overkill, ponieważ przechowywanie kilkuset par UUID zajmie nie więcej niż kilkadziesiąt kilobajtów pamięci RAM. Swoją drogą, to co jest sensowne, jest w tym przypadku rzeczą względnie subiektywną. Jeden właściciel serwera faktycznie może uważać, że usuwanie danych od komendy /r powinno następować po 15 minutach. Drugi uzna, że nie musi czyścić tych danych, bo chce, aby gracze nawet po pójściu AFK na 30 minut mogli nadal odpisać swojemu koledze, a poza tym to na serwerze będzie w jednym momencie nie więcej niż 20 graczy. @opkarol Nie rozumiem ostatniej części z tą bazą danych. Można jaśniej? Też tak uważam. Pozdrawiam.

Jeżeli Pan stworzył własną komendę /działki, powinien Pan mieć gdzieś zmienne (ściślej mówiąc, listy zmiennych), na podstawie których można określić jak się nazywają działki danego gracza. Możliwe jest również to, że stworzył Pan spolszczenie pluginu dodającego działki (np. PlotSquared lub ProtectionStones), wtedy jedynym sensownym wyjściem będzie skorzystanie z API tego pluginu przy pomocy dodatku skript-reflect. Chciałbym zaznaczyć, że zdaję sobie sprawę z tego, iż to jest zlecenie, a nie pytanie. Problem w tym, że bez powyższych informacji mam związane ręce. Pozdrawiam.

Co oznacza "crystale"? Mowa o kryształach Kresu? Tych, które leczą smoka? Nie rozumiem również co oznacza "używać" w tym kontekście. Pozdrawiam.

Nie rozumiem w czym Pan widzi problem z zapisywaniem lokacji w zmiennej globalnej. Mam wrażenie, że Pan nawiązuje do mojej wypowiedzi, ale nie do końca zrozumiał jej przekazu. Przekaz był taki, aby nie nadużywać ich i czasem dwa razy zastanowić się czy nie da się danego problemu rozwiązać w inny sposób (na przykład za pomocą wyrażeń lub zmiennych lokalnych). Jeżeli chodzi o skrypt implementujący komendy /setspawn i /spawn, nie widzę nic złego w wykorzystaniu w kodzie zmiennej globalnej. Powiem więcej, trudno o inne rozwiązanie optymalne, ponieważ użycie zmiennej globalnej jest w tej sytuacji najlepsze. Tworzymy jedną informację, której wartość rzadko się zmienia (ale się zmienia, nie jest to stała) i wszyscy gracze z niej muszą korzystać. To aż się prosi o wykorzystanie zmiennej globalnej. Gdyby miał Pan jeszcze jakieś pytania, śmiało. Z miłą chęcią odpowiem. Pozdrawiam.

Generalnie tak, ale są pewne wyjątki od tej reguły. Czasem pojawia się chęć spolszczenia jakiegoś pluginu, a nieraz bywa tak, że wszystko w pluginie jest zaimplementowane w jednej komendzie, która posiada wiele możliwych do podania argumentów. Wtedy plik commands.yml staje się niewystarczający i trzeba się posiłkować pluginami lub Skriptem, ponieważ pozwala on jedynie na pobranie wpisanego argumentu, a nie przypisanie de facto aliasów do argumentów komend. Dobrym przykładem takiej "uber" komendy jest /lp od pluginu LuckPerms. Pozdrawiam.

Wystarczy dodać frazę 'of unbreaking 1' tuż po 'netherite sword', a przed frazą 'named [...]'. Po więcej informacji odsyłam do dokumentacji Skripta. EDIT: Zalecam również zmienić nazewnictwo zmiennych tak, aby zamiast kropek używać podwójnego dwukropka. Dzięki temu zmienna {cooldown::*} będzie traktowana jak lista, a zarządzanie listami jest o wiele wygodniejsze na dłuższą metę. Najprostszym przykładem jest możliwość czyszczenia całej listy (a więc w tym konkretnym przypadku wyczyszczenie cooldownów wszystkich graczy). clear {cooldown::*} Warto również zastanowić się nad zmianą nazwy samej listy tak, aby nie kolidowało to w przyszłości z innymi skryptami. Nazwa 'cooldown' może być często używana w innych skryptach. Pozdrawiam.

Proszę bardzo. Na górze skryptu można modyfikować listę zawierająca bloki, które gracze mogą stawiać i niszczyć. on load: set {allowedBlocks::blockTypes::*} to dirt, cobblestone and obsidian on break: {allowedBlocks::blockTypes::*} doesn't contain type of event-block cancel event send "&cNiszczenie tego bloku jest zabronione." to player on place: {allowedBlocks::blockTypes::*} doesn't contain type of event-block cancel event send "&cStawianie tego bloku jest zabronione." to player Pozdrawiam.

Kod wygląda w porządku. Pytanie o sekcję 'import' już padło i również wygląda w porządku (o ile sekcja 'import' znajduje się nad powyższym kodem), więc nie będę go ponawiał. Czy próbował Pan ustawić do zmiennej zwykłe buty, a dopiero po nadpisaniu ItemMeta i dodaniu enchantu zmienić nazwę i lore? Pokażę przykład poniżej. set {_boots} to diamond boots set {_meta} to {_boots}.getItemMeta() # [...] set name of {_boots} to "Nowa nazwa" set lore of {_boots} to "Linijka nr 1", "Linijka nr 2" and "Linijka nr 3" Szczerze mówiąc, to jedyne co mi przychodzi do głowy. Moim zdaniem lepiej jest zmienić ItemMeta bazując na "czystym" wariancie przedmiotu. To akurat nie ma najmniejszego znaczenia. Nazwa zmiennej nie ma na nic wpływu tak długo jak jest taka sama w obrębie całego kodu. Pozdrawiam.

Nie powiedziałbym "można, ale "nawet trzeba", tak więc dziękuję za uwagę. Skupiłem się na tłumaczeniu mechanizmu i samej idei (o czym zresztą wspomniałem), przez co zapomniałem o takiej prostocie, która może być groźna na dłuższą metę. Dla mniej świadomych, już tłumaczę dlaczego. W przypadku chęci zapisu zawartości mapy na dysku wymagałoby to serializacji danych, a przy odczycie deserializacji. Jeżeli zapiszemy samo UUID, problem ten się rozwiązuje, a pobranie obiektu gracza na jego podstawie jest trywialne. Używanie UUID nie jest jakkolwiek gorsze względem używanie obiektu gracza. Poza tym, łatwiej jest zarządzać mapą de facto ciągów znaków (nie w dosłownym sensie) niż mapą złożonych obiektów, które w następnym ticku już nie muszą być idealnym odzwierciedleniem (np. lokalizacja może być inna). Obiekt Player ulega ciągłym modyfikacjom, szczególnie między ponownymi dołączeniami do serwera. Przy wychodzeniu, ponownym wchodzeniu i pisaniu wiadomości najprawdopodobniej tworzyłoby się wiele obiektów gracza wskazujących na tego samego gracza, z czego poprzednie byłyby już nieaktualne, a więc zostawałyby w tej mapie do restartu serwera, co w konsekwencji doprowadziłoby do wycieku pamięci. Co prawda nie byłby on drastyczny, ale każdy wyciek pamięci należy traktować z powagą. Mogę się jednak mylić i nawet po ponownym dołączeniu stary obiekt Player będzie w pełni poprawny - wtedy proszę o poprawienie mnie. Programistyczni puryści z pewnością jeszcze pokusiliby się o dalsze zabezpieczenia, aby zapobiec wyciekowi w przypadku zmiany nazwy gracza na serwerze w trybie offline, bo trzeba pamiętać, że na serwerach offline UUID jest generowane na podstawie nazwy gracza. Pozdrawiam.

Tak. Należy na początku listenera dodać warunek sprawdzający zniszczony blok. Ponadto, mam uwagę do kodu napisanego przez Pana wyżej. Wiem, błąd czeski, ale nierówność była źle skonstruowana. W oryginalnej wersji kodu komenda wykonuje się 10 razy po wykopaniu, ponieważ za 11-tym razem warunek będzie już niespełniony. on mine: event-block is coal ore or iron ore add 1 to {bloki::%player%::%location of event-block%} {bloki::%player%::%location of event-block%} >= 10 execute console command "/say Gracz %player% zniszczył co najmniej 10 bloków." Pozdrawiam.

Pytanie dotyczy tworzenia pluginu, nie skryptu interpretowanego przez plugin Skript. Co prawda twórca pluginów ze mnie żaden, ale powiem Panu jak ja to widzę. Moim zdaniem, najprostszym rozwiązaniem będzie stworzenie mapy (HashMap) przechowującej pary graczy, gdzie klucz to gracz odbierający, a wartość to gracz wysyłający. Mapa ta będzie używana jednocześnie przez komendy /msg i /r. HashMap<Player, Player> replyMap = new HashMap<>(); Komenda /msg przy wysyłaniu wiadomości będzie uzupełniała mapę o parę <gracz odbierający, gracz wysyłający>. W ten sposób można łatwo w kodzie komendy /r wykorzystać poniższą linijkę, która zwróci gracza, do którego ma zostać wysłana odpowiedź. Player receiver = replyMap.get(player); Naturalnie, po wysłaniu odpowiedzi za pomocą komendy /r należy ponownie uzupełnić mapę tak samo jak w przypadku komendy /msg. Proszę tylko pamiętać, że tutaj role się zamieniają - gracz wysyłający wiadomość przy pomocy komendy /msg staje się odbierającym, a gracz wysyłający odpowiedź staje się wysyłającym. Pominąłem czysto techniczne kwestie takie jak chociażby sprawdzanie czy gracz, do którego wysyła się wiadomość/odpowiedź, jest obecny na serwerze, czy też sprawdzanie czy gracz może komukolwiek odpowiedzieć za pomocą komendy /r (posiada gracza mu przypisanego w mapie). Moim celem nie było dokładne pokazanie jak należy zaimplementować ten mechanizm. Chciałem jedynie pokazać samą ideę. Pozdrawiam.

Proszę bardzo. Skrypt nie był testowany. Komenda '/blockwithhp <liczba całkowita>' służy do ustawienia pożądanej ilości punktów życia bloku, na który spogląda osoba wykonująca komendę w danej chwili. W definicji pierwszej komendy w polu 'permission' może Pan sobie ustawić permisję wymaganą do jej wykonania. Co do kodu wykonywanego przy zniszczeniu bloku, może Pan sobie zmienić szanse procentowe możliwych przedmiotów wypadających przy zniszczeniu go oraz ustawić ilość wypadających punktów doświadczenia. command /blockwithhp <integer>: executable by: players permission: server.command.blockwithhp permission message: &6Nie posiadasz wystarczających permisji do wykonania tej komendy. usage: &cPoprawne użycie: /blockwithhp <punkty życia> trigger: if targeted block is not set: send "&6Musisz spoglądać na jakiś blok, aby móc wykonać tę komendę." to player stop if arg <= 0: send "&6Blok nie może mieć mniej niż 1 punkt życia." to player stop set {blocksWithHP::locations::%location of targeted block%} to arg send "&aPomyślnie ustawiono &6%arg% &apunktów życia bloku." to player on break: set {_healthPoints} to {blocksWithHP::locations::%location of event-block%} {_healthPoints} is set if {_healthPoints} > 1: cancel event subtract 1 from {blocksWithHP::locations::%location of event-block%} send action bar "&6Blok posiada jeszcze &c%{_healthPoints} - 1% &6punktów życia." to player stop send action bar "&aBlok został zniszczony. Gratulujemy!" to player set {_blockDrops::*} to diamond, gold ingot and iron ingot set {_percentageChances::*} to 10, 40 and 85 loop {_percentageChances::*}: chance of (loop-value)%: drop {_blockDrops::%loop-index%} at event-block drop 10 xp at event-block clear {blocksWithHP::locations::%location of event-block%} W skrypcie brakuje anulowania zdarzenia 'on break', co sprawi, że po pierwszym wykopaniu blok zniknie bezpowrotnie. Ponadto, w kodzie brakuje nagród, o które poprosił Zleceniodawca. Pozdrawiam.

Jak najbardziej. Wystarczy przyrównać wartość wyrażenia 'click type' do jednego z możliwych typów kliknięć. Przykład poniżej ze sprawdzeniem czy użyto prawego przycisku myszy. on inventory click: click type is rmb send "&aUżyto prawego przycisku myszy." to player Pozdrawiam.

Ten temat został przeniesiony do kosza!