Kormic

Sposobów jest kilka, ale skupię się na najprostszym.
Do odczytu czasu rzeczywistego (dokładniej, czasu systemowego) można wykorzystać wyrażenie now w połączeniu z tym wyrażeniem. Przykład poniżej.
every 1 second: set {_currentTime::*} to (now formatted as "HH:mm:ss") split at ":" {_currentTime::2} and {_currentTime::3} are "00" broadcast "&aWybiła godzina &6%{_currentTime::1}%:00&a." W Twoim przypadku wystarczy co sekundę lub co minutę (w zależności od tego jakiej dokładności wymagasz) sprawdzać czy sformatowany czas to "18:00:00" (lub "18:00" dla "HH:mm").
EDIT:
Dzień tygodnia można sprawdzić za pomocą formatu "u" lub "E". Do tego również załączam przykład:
command /test: trigger: send (now formatted as "u") send (now formatted as "E") send (now formatted as "EEEE") [11:18:04 INFO]: 5 [11:18:04 INFO]: pt. [11:18:04 INFO]: piątek Implementacyjnie przyjemniejsza jest wersja z liczbą (u), ponieważ format tekstowy (E) jest zależny od lokalizacji językowej.
Cały wachlarz dostępnych formatów dat został opisany tutaj.
Pozdrawiam.

@Ytes
Kryształ Endu jest bytem, nie blokiem, dlatego zdarzenie on place of end crystal: nie jest wywoływane. Należy więc wykrywać kliknięcia prawym przyciskiem myszy z nim w ręce. Ponadto, należy sprawdzić czy blok, na którym stawiany jest kryształ Endu, to bedrock lub obsydian.
Ostatni pokazany sposób z nasłuchiwaniem do zdarzenia on spawn of ender crystal: również jest poprawny, ale nie pozwala on na połączenie go z graczem, który postawił ten kryształ. Oczywiście, można próbować zapętlać graczy w promieniu 5 bloków, ale takie nieeleganckie rozwiązanie zadziałałoby tylko w przypadku wykrycia jednego gracza.
Pozdrawiam.

@hiperk
Nie. Gracze również są bytami (entities). Hierarchia dziedziczenia dla graczy, zaczynając od najbardziej ogólnego typu, jest następująca:
byty (entities; gracze, moby, wyrzucone przedmioty, wystrzelone strzały, obrazy, itd.). byty żywe (living entities; gracze, zwierzęta, potwory, itd.). byty ludzkie (human entities; zwykle tylko gracze, ale też np. NPC z Citizens). gracze (players). @mrocznycienYT
Należy pamiętać, że tool odnosi się do przedmiotu trzymanego w dominującej ręce (u zdecydowanej większości graczy jest to prawa ręka). Przedmiot w drugiej, niedominującej ręce to offhand tool.
Czy sprawdziłeś działanie skryptu dla totemu trzymanego w lewej i prawej ręce? Warto również zweryfikować czy totem w ręce gracza jest wierną kopią tego opisanego w sekcji options.
Pozdrawiam.

@block18c
W tej sytuacji lepszym będzie wykorzystanie pierwszego sposobu i zapętlenie łącznie 41 slotów o indeksach od 0 do 40.
loop 41 times: slot (loop-iteration - 1) of player's inventory is diamond set {_n} to item amount of slot (loop-iteration - 1) of player's inventory set slot (loop-iteration - 1) of player's inventory to {_n} of gold ingots Nie rozumiem dlaczego gracz miałby mieć sztabki złota jako zbroję, ale Minecraft na to pozwala. Jeśli jednak miałeś na myśli zamianę zbroi diamentowej na złotą, niestety jedynym rozwiązaniem jest zamiana wszystkich jej części po kolei.
player's helmet is a diamond helmet set player's helmet to golden helmet Pozdrawiam.

@melon_PL
A to przepraszam najmocniej, już się poprawiam.
on place: model data of player's tool is 20 set {_l} to location of event-block set {_c1} to {_l} ~ vector(1, 2, 0) set {_c2} to {_l} ~ vector(-1, 0, 0) set blocks within {_c1} and {_c2} to event-block Warto jednak zauważyć, że ta ściana zawsze będzie zwrócona w tym samym kierunku. Jeśli ma ona osłaniać gracza, należy wykorzystać jego kierunek patrzenia.
on place: model data of player's tool is 20 set {_x} to 1 set {_z} to 0 if player's horizontal facing is east or west: set {_x} to 0 set {_z} to 1 set {_l} to location of event-block set {_c1} to {_l} ~ vector({_x}, 2, {_z}) set {_c2} to {_l} ~ vector({_x}*-1, 0, {_z}*-1) set blocks within {_c1} and {_c2} to event-block Pozdrawiam.

@TeZetYT
Skript pozwala na definiowanie domyślnych wartości dla argumentów funkcji, co można potraktować jako implementację ich opcjonalności. Podam prosty przykład poniżej.
function testFunc(text: string = "Test"): broadcast {_text} command /test [<text>]: trigger: testFunc() testFunc("Test nr 2") Jeżeli argument text nie zostanie podany, przyjmie on domyślnie wartość "Test". W innym przypadku przyjmie on określoną wartość.
Istnieje również możliwość zapewnienia pełnej opcjonalności, gdzie opcjonalny argument, którego wartość nie została określona, nie przyjmie żadnej. Tutaj najprostszym sposobem jest wykorzystanie sztuczki ze zdefiniowaniem domyślnej wartości jako nieistniejącej zmiennej.
function testFunc(text: string = {_}): broadcast {_text} command /test [<text>]: trigger: testFunc() testFunc("Test nr 2") Na czacie ukaże się tylko wiadomość "Test nr 2", ponieważ efekt broadcast nie wyświetli na czacie czegoś, co nie zostało określone (nie istnieje).
Pozdrawiam.

@Freesh
Pierwszy raz widzę tę składnię na oczy. Nie rozumiem dlaczego nie używasz samego blockdata wspieranego przez Skript.
Po kilku drobnych zmianach twój kod działa. Pokażę co zrobiłem.
command /test [<text>]: trigger: set {_loc} to location under player set {_oldData} to blockdata of block at {_loc} wait 5 seconds set block at {_loc} to cobblestone stairs wait 1 tick set blockdata of block at {_loc} to {_oldData} Pozdrawiam.

@melon_PL
Jak najbardziej. Wystarczy nie blokować opcji przekładania przedmiotów w tym GUI. Przykład poniżej.
command /admin [<text>]: executable by: players permission: server.commands.admin trigger: set {_g} to chest inventory with 3 rows named "Bierz ile chcesz!" set slot 0 of {_g} to iron sword set slot 1 of {_g} to diamond chestplate open {_g} to player Pozdrawiam.

@RESTTTT
Proszę.
options: modelData: 65535 poisonEffect: percentageChance: 15 tier: 1 duration: 4 seconds command /getsword [<text>]: executable by: players trigger: set {_item} to iron sword named "&aZatruty miecz" set {_item}'s model data to {@modelData} give {_item} to player send "&7Otrzymałeś %{_item}'s name%&7!" to player on damage: projectile is not set model data of attacker's tool is {@modelData} chance of {@poisonEffect.percentageChance}% apply poison {@poisonEffect.tier} to victim for {@poisonEffect.duration} replacing existing effect Pozdrawiam.

Proszę.
command /pocisk [<text>]: executable by: players trigger: shoot snowball from player at speed 3 Pozdrawiam.

@Fquido_Games
Z tego co wyczytałem tutaj, PlaceholderAPI będzie wspierało sieci serwerów oparte na BungeeCord (zapewne też na Velocity, mam nadzieję) dopiero od wersji 3.0.
Najprostszym rozwiązaniem jest skorzystanie z tzw. plugin messaging channels, które są wykorzystywane często do komunikacji między serwerami w sieci.
Alternatywnym rozwiązaniem byłoby stworzenie bazy danych, z której korzystałyby wszystkie serwery w sieci i za jej pośrednictwem cyklicznie wymieniały się wartościami placeholderów z PAPI. Rzecz jasna, należy zwrócić uwagę na potencjalne problemy z synchronizacją tej wymiany, ale będąc szczerym, nie jest to jakkolwiek krytyczny mechanizm, więc można przymknąć oko na to.
Pozdrawiam.

@TomiTom___
Warto tu skorzystać z dodatku skript-placeholders. Tutaj można znaleźć przykład pobierania wartości placeholderu w Skript'cie.
Pozdrawiam.

@Ytes
Zakładam, że jest to niedopatrzenie, ale proszę zauważyć, że niemożliwe jest dodawanie do siebie zmiennej przechowującej (tak podejrzewam) liczbę i tekstu. Typ argumentu trzeciego to właśnie 'text', a nie 'number' lub 'integer'.
Ponadto, kod niepotrzebnie wykorzystuje zmienną globalną '{podmiot}'. Wystarczy w nazwach zmiennych wstawić wyrażenie 'arg 3' (lub dowolny inny prawidłowy wariant, na przykład: 'arg-3', '3rd argument', 'last arg', 'number-argument', itd.), które zwróci trzeci argument, który wprowadził wysyłający komendę (gracz lub konsola).
Pozdrawiam.

@mefku
Należy użyć wyrażenia 'indices of' które zwraca listę indeksów (w Pana przypadku jest to lista numerycznych ID).
Pozdrawiam.

Nie widzę jakiejkolwiek potrzeby, aby zapisywać dane w plikach .yml gdy Skript również je przechowuje. Dodam, że jeśli dodatek obsługujący YAML nie buforuje tych plików (lub Pan sam nie robi tego poprawnie), jest to obciążające dla serwera i w przypadku większej ilości zapisanych danych może powodować na serwerze lagi.
Co do samego umieszczania wartości zmiennej na scoreboardzie, wystarczy zarejestrować własny placeholder z użyciem PlaceholderAPI i dodatku skript-placeholders.
Pozdrawiam.

Wyrażenie 'all players...' zwraca listę graczy, a więc możemy sprawdzić jej rozmiar (a więc ilu jest graczy w danym świecie) za pomocą tego wyrażenia i łatwo określić czy możemy kontynuować wykonywanie kodu.
size of (all players in "Anni") <= 1 # [...] Zalecam nie zagnieżdżać warunków z wcięciami, ponieważ zmniejsza to czytelność kodu. Proszę sobie porównać dwa poniższe kody.
if arg 1 is 1: if arg 2 is 2: if arg 3 is 3: if arg 4 is 4: # Lepsze podejście: arg 1 is 1 arg 2 is 2 arg 3 is 3 arg 4 is 4 Widać różnicę, prawda?
Na koniec dodam, że można połączyć pierwszy warunek z samym zdarzeniem.
on death of player: # [...] Pozdrawiam.

Problem został rozwiązany.

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.

Co prawda problem został już rozwiązany na serwerze Discord SkUnity, ale powiem co było przyczyną. Dla pocisków należy korzystać z wyrażenia 'last shot %entity%'. W tym przypadku więc jest to 'last shot arrow'.
Pozdrawiam.
 

Nie zdziwiłbym się gdyby pojawienie się problemu było częściowym (jeśli nie całościowym) następstwem używania PlugMana (rzecz jasna, mówimy również o PlugManX). Dla samego sprawdzania proszę go odinstalować i zrestartować serwer. Jeśli to nie pomoże, należy szukać dalej. Warto również sprawdzić czy wszystkie wtyczki (pluginu) są aktualne dla wersji Pana serwera.
PlugMan jeśli już to powinien być wykorzystywany do przeładowywania małych pluginów, które zazwyczaj się samodzielnie tworzy (choć i tu nie jest niemożliwe, że coś pójdzie nie tak w trakcie tego procesu), a nie do takich kobył jak Skript. Nie bez powodu większość wtyczek posiada własne komendy przeładowujące chociażby pliki konfiguracyjne.
W ramach ciekawostki mogę zdradzić, że w wersji Skripta 2.10 może zostać wprowadzone ostrzeganie przez Skripta przy każdorazowym użyciu czy to PlugMana, czy to komendy /reload. Właśnie odbywa się rozmowa na ten temat na serwerze Discord SkUnity. I dobrze.
Pozdrawiam.

Tak jak napisałem, oba te zdarzenia wykorzystują zdarzenie 'PlayerMoveEvent', które pochodzi z Bukkit API (w dużym skrócie, z tego korzystają wszystkie wtyczki (pluginy)), więc są one porównywalne. Warto jednak zauważyć, że zdarzenie 'on region enter' wiąże się z potencjalnym sprawdzaniem wielu informacji ze strony pluginu zarządzającego regionami, co skłania raczej ku użyciu zdarzenia 'on player move' jeżeli nie ma potrzeby wykorzystania regionów przy tym problemie.
Jeszcze jedno. Proszę się nie bać korzystania ze zdarzenia 'on player move', ponieważ dla każdego gracza jest ono wywoływane nie więcej niż 20 razy na sekundę. Tego typu zdarzenia mają złą reputację przez to, że wielu twórców pluginów i skryptów (zwłaszcza tych drugich) ma tendencję do dodawania dziesiątek linijek kodu do listenerów tego zdarzenia. Kod, który Pan pokazał, nie będzie obciążający dla serwera.
Swoją drogą, istnieją zdarzenia, które są znacznie częściej wywoływane. Dobrym przykładem jest zdarzenie 'on physics', które jest powiązane z każdą zmianą stanu bloku, która może być spowodowana przez jakikolwiek byt lub być następstwem naturalnych procesów zachodzących w grze. Na serwerach z większą ilością graczy zdarzenie te jest wywoływane czasem tysiące razy na sekundę (a więc niejednokrotnie kilkaset razy na tick).
Pozdrawiam.

Ten kod jest niepoprawny, ponieważ każde przeładowanie skryptu będzie wiązało się z utworzeniem nowej pętli 'while', a taką pętlę można przerwać w Skript'cie tylko wewnątrz niej lub poprzez zrestartowanie serwera. W konsekwencji może powstać wiele pętli, które będą się na siebie nakładały swoim działaniem, co sprawi nieprzewidywalne ustawianie wartości zmiennej '{animation.welcome}'.
Rozwiązanie powinno więc korzystać z okresowo wykonującego się fragmentu kodu (ang. 'periodical'), co zapobiegnie powstaniu równolegle działającym pętlom 'while'.
every 10 ticks: set {_welcomeMessages::*} to "&aW&6ITAJ", "&6W&aI&6TAJ", "&6WI&aT&6AJ", "&6WIT&aA&6J" and "&6WITA&aJ" set {welcomeMessageIndex} to 1 if {welcomeMessageIndex} is not set set {animatedWelcomeMessage} to {_welcomeMessages::%{welcomeMessageIndex}%} if {welcomeMessageIndex} >= (size of {_welcomeMessages::*}): set {welcomeMessageIndex} to 1 else: add 1 to {welcomeMessageIndex} on placeholderapi placeholder request for prefix "sk": if identifier is "welcome": set result to {animatedWelcomeMessage} Pozdrawiam.

Jak najbardziej można ją skrócić i w sumie to naprawić. Nietrudno zauważyć, że w każdym przypadku zachodzi mnożenie przez liczbę o 1 większą od poziomu zaklęcia szczęścia na kilofie, więc najkrótszym rozwiązaniem byłoby użycie poziomu zaklęcia powiększonego o 1.
Najlepszym rozwiązaniem natomiast byłoby sprawdzenie czy kilof gracza posiada w ogóle zaklęcie szczęścia. Jeśli tak, wykonujemy mnożenie przez (poziom zaklęcia + 1). Dlaczego najlepszym? Dlatego, że bardziej eleganckim wyjściem jest uprzednie sprawdzenie czy przedmiot jest zaklęty niż opieranie kodu na tym, że wyrażenie zwróci 0 jeśli przedmiot nie jest zaklęty.
Co więcej, każdy warunek kończy się wręczeniem graczowi monet, a wystarczy tę instrukcję wykonać raz na samym końcu funkcji.
Dlaczego powiedziałem "naprawić"? Proszę zauważyć, że warunki te będzie spełniał kilof z zaklęciem szczęścia, ale bez nazwy, lore i wszelkich innych informacji. Dlatego też nie należy porównywać narzędzia gracza, a sprawdzać jedynie poziom zaklęcia szczęścia.
Proszę się samemu zastanowić jak można to rozwiązać. Dokumentacja Skripta z pewnością się przyda.
Jeśli i ona nie pomoże, zostawiam swoją propozycję rozwiązania w spoilerze poniżej.
Pozdrawiam.

Tak. Można w tym celu użyć dodatku SkBee, który oferuje taką możliwość. Po więcej informacji odsyłam do wiki dodatku. Przykładów tam jest pod dostatkiem.
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.