Kormic

@Nusv Nie. Zastosowałem every 1 minute, ponieważ skrypt sprawdza co minutę czy minuta w czasie rzeczywistym to "00". Dzięki temu, o każdej pełnej godzinie kod zostanie wykonany. Nie będzie to na przykład o 16:00:00, bo nie sprawdzam sekundy (co wymagałoby też zastosowania every 1 second), więc opóźnienie zawsze będzie wynosiło mniej niż 60 sekund. Czas opóźnienia jest zależny od tego, w której sekundzie Skript załaduje ten skrypt. Przykładowo: jeśli skrypt zostanie załadowany o godzinie 12:31:51, powyższy kod będzie się wykonywał o godzinach 12:31:51, 12:32:51, 12:33:51, i tak dalej. Jeśli jest potrzebna dokładność co do sekundy, po zmianie okresu na 1 second, można użyć poniższego warunku: now formatted as "mm:ss" is "00:00" Należy również pamiętać o wcięciach w kodzie, są one kluczowe dla poprawnego działania skryptów. Wstawiłem je w Twoim kodzie. Co do samej komendy rozdawania kluczy, zakładam, że powinno być coś tam wstawione zamiast "<klucze>". Poza wspomnianymi wyżej błędami, wygląda to w porządku. Pozdrawiam.

@Felif_PL Najprostszym rozwiązaniem byłoby utworzenie jakiejś listy (na przykład HashSet), która przechowywałaby UUID graczy będących w trakcie sprawdzania. Dalej, należałoby utworzyć listener zdarzenia PlayerCommandPreprocessEvent, w którym sprawdzalibyśmy czy UUID wykonującego komendę jest obecne w tej liście. Jeśli tak, anulujemy wykonanie komendy, co zablokuje mu możliwość ucieczki z miejsca, w którym jest przetrzymywany. Oczywiście, po zakończeniu sprawdzania należy usunąć UUID sprawdzanego z listy. W przypadku gdy proces sprawdzania nie jest przerywany wyłączeniem lub restartem serwera, czyli informacja o sprawdzaniu jest gdzieś zapisywana na dysku (chociażby w bazie danych pluginu), należy również zapisać gdzieś zawartość tej listy, aby nie doszło do utraty informacji o tym kto jest sprawdzany. Alternatywnie, jeśli plugin posiada jakąś metodę lub chociaż pole pozwalające na zweryfikowanie czy ktoś jest sprawdzany, wystarczy sam wyżej wspomniany listener. Pozdrawiam.

Ten temat został przeniesiony.

@Nusv Proszę bardzo. every 1 minute: now formatted as "mm" is "00" make console execute "time set day" Dodam, że ostatnią linijkę można - a nawet warto - zastąpić efektem: set time in world "nazwa świata" to 7:00 Może nasunąć się pytanie: dlaczego? Dlatego, że dzięki temu zabiegowi unikamy zaśmiecania konsoli informacjami o wykonywaniu komendy. W konsoli należy wyświetlać tylko ważne informacje, aby w przypadku jakiegoś problemu można było łatwo się w niej odszukać. Na koniec dopowiem, że w Skript ustawienie czasu świata na 6:00 i użycie komendy /time set day (czy też /time set 1000) ma dokładnie takie same skutki. Doba w Minecraft'cie trwa 24000 ticków (na każdą sekundę przypada 20 ticków, więc sumarycznie odpowiada to 20 minutom czasu rzeczywistego), a więc możemy łatwo policzyć, że na każdą godzinę w Minecraft'cie przypada 1000 ticków = 50 sekund, stąd ustawienie czasu na godzinę 7:00. Pozdrawiam.

@Grzybcios Jeśli dobrze zrozumiałem, nałożenie jakiegokolwiek zaklęcia w stole do zaklinania (enchanting table) na 2. poziomie ma być możliwe tylko wtedy jeśli na przedmiocie jest już 8 zaklęć, tak? Analogicznie, zaklęcie 3. poziomu wymagałoby 16 zaklęć. Pozdrawiam.

Polecam sprawdzić dodatek skript-placeholders, który pozwala na rejestrowanie własnych placeholderów w PlaceholderAPI. Wiki dodatku można znaleźć tutaj. Pozdrawiam.

Ten temat został przeniesiony do kosza!

Zlecenie zostało wykonane.

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

Nie rozumiem, bo kod wskazuje na coś całkiem innego. Dodam, że niemożliwym jest zareagowanie na informację o najechaniu kursorem na przedmiot w ekwipunku, ponieważ klient nigdy nie wysyła jej do serwera. Jedynym rozwiązaniem jest stworzenie modyfikacji dla klienta lub stworzenie własnego. Pozdrawiam.

Ten temat został przeniesiony.

Ten temat został przeniesiony.

@DevDavEd_zQ Proszę. command /krzyk [<text>]: executable by: players trigger: if arg is not set: send "Należy podać wiadomość." to player stop broadcast "&7&l[KRZYK] &f%player% %arg%" in player's world on chat: set chat recipients to (all players in radius 30 of player) size of chat recipients <= 1 send "&cNikt cię nie usłyszał." to player Pozdrawiam.

@DevDavEd_zQ Typy przedmiotów w Skript nie zawierają podkreślników w nazwach. Po ich usunięciu Skript nie powinien już zwracać błędów. Pozdrawiam.

Ten temat został przeniesiony.

@NotDanix Jest to błąd składniowy. Należy skorzystać z tego wyrażenia w Skript. Ponadto, nie ma potrzeby zamiany go na tekst, ponieważ wystarczy porównać cursor slot of player z jakimś przedmiotem. Pozdrawiam.

Ten temat został przeniesiony.

Ten temat został przeniesiony.

@xSebixx1 Ten skrypt w ogóle nie wykorzystuje składni z SkBee, do której podałem link. Ponadto, widzę, że napisała go sztuczna inteligencja. Linijka ustawiająca granicę świata nie ma ani logicznego, ani składniowego sensu. Nie ma zabezpieczenia przed wielokrotnym rozpoczynaniem pętli 'while'. Należy zacząć od ustawienia wirtualnej granicy świata gracza i dalej modyfikować jej szczegóły. Jest to pokazane w przykładach załączonych do wyżej wspomnianego wyrażenia z SkBee. Pozdrawiam.

@xSebixx1 Mogę ewentualnie pomóc, ale muszę zobaczyć treść wspomnianego błędu. Bez tego mam związane ręce.

Można w tym celu wykorzystać dodatek SkBee. Posiada on składnię pozwalającą na ustawianie granicy świata dla wybranych graczy. Reszta problemu to w zasadzie kwestia śledzenia ruchu graczy (zdarzenie on player move) i sprawdzanie czy są wewnątrz danej granicy oraz ukrywanie graczy nad przed sobą na podstawie tego. Pozdrawiam.

@Hiri12 Słuszna uwaga, ale tutaj była mowa o wyczyszczaniu wszystkich zmiennych, więc zachodziła utrata już zapisanych na dysku zmiennych. Wyłączenie serwera poprzez zwolnienie zasobów (dla niewtajemniczonych, przycisk z symbolem "x") w Skript poskutkuje utratą co najwyżej 999 zmian, ponieważ rozmiar kolejki operacji na zmiennych wynosi 1000 może poskutkować utratą nieograniczonej ilości buforowanych operacji zapisu zmiennych, ponieważ, owszem, rozmiar kolejki wynosi 1000, ale trzeba również pamiętać o tym, że opróżnianie jej odbywa się co 5 minut. @kerpson Odpowiadając na uwagę do bezpieczeństwa, racja. Dość dziwnym będzie chociażby tworzenie backupów w sytuacji, gdzie każdy gracz ma wydzielony dla siebie plik. Co do czasu uruchamiania serwera, on się nie zmieni w jakkolwiek zauważalnym stopniu, ponieważ te pliki z danymi nie są w ogóle ładowane do pamięci. Jeszcze odnosząc się do zapisu dla nazwy gracza, w przypadku serwera w trybie offline (a zakładam, że właśnie z takim mamy do czynienia) nie ma to absolutnie żadnego znaczenia. Warto jednak zauważyć, że gdyby dwóch graczy zamieniło się nazwami, mogą de facto wymienić się całym postępem na serwerze, co jest niewątpliwie największym zagrożeniem tego trybu pracy. Pozdrawiam.

@xSebixx1 To jest mechanika Minecrafta. Cooldown ustawiony na złote jabłko będzie obowiązywał dla wszystkich złotych jabłek. Bez modyfikacji gry nie ma na to rady. Można dodać sam cooldown dla konkretnego przedmiotu, bez animacji, ale wnioskując po twoim problemie, właśnie ta animacja jest dla Ciebie ważna. Pozdrawiam.

@_MicX_ A na co jest potrzebny w tym kodzie skript-reflect? Nie wykorzystuje on w jakikolwiek sposób kolejkowania zadań z Bukkit, pomimo tego co sugeruje sekcja import. Ponadto, jakie zastosowanie w tym kodzie ma instrukcja cancel all tasks? Jest ona częścią składni wprowadzonej przez SkBee, a skrypt nie tworzy jakichkolwiek opóźnianych zadań. @TeZetYT Nieważne z którego rozwiązania się skorzysta, różnice w wydajności dla przeciętnego zjadacza chleba są marginalne. Jeśli ktoś mi nie wierzy, proszę samemu sprawdzić i ewentualnie spróbować mnie wyprowadzić z błędu. Pokażę rozwiązanie wykorzystujące pętlę while wykorzystującą generowanie UUID, co zapobiega powstawaniu wielu instancji pętli działających jednocześnie. command /test: trigger: set {-whileLoopUUID} and {_localLoopUUID} to random uuid set {_countdown} to 10 send "While loop has started!" to console while {_countdown} > 0: if {_localLoopUUID} != {-whileLoopUUID}: send "While loop has been stopped!" to console stop send "%{_countdown}%..." to console wait 1 second subtract 1 from {_countdown} send "End of countdown!" to console Nadmienię, że wykorzystuję tzw. memory variables (czy też RAM variables), czyli zmienne, które są przechowywane tylko w pamięci RAM i nie są zapisywane kiedykolwiek na dysku (najczęściej definiowane w pliku konfiguracyjnym Skript jako te zaczynające się myślnikiem). Tym samym, przy wyłączeniu serwera ich wartości są tracone. W naszym przypadku jest to pożądane działanie, bo nie potrzebujemy tej informacji między kolejnymi uruchomieniami serwera. Bez ustawienia odpowiedniego wzorca zapisywanych zmiennych w pliku variables.csv (baza danych default w pliku config.sk) Skript ostrzeże nas o zarezerwowaniu myślnika na początku nazw zmiennych, a sam myślnik nie będzie miał żadnego wpływu na zapis na dysku. Dlatego też powinien on wyglądać jak niżej: default: # The default "database" is a simple text file, with each variable on a separate line and the variable's name, type, and value separated by commas. # This is the last database in this list to catch all variables that have not been saved anywhere else. # You can modify this database freely, but make sure to know what you're doing if you don't want to loose any variables. type: CSV pattern: (?!-).* file: ./plugins/Skript/variables.csv backup interval: 2 hours backups to keep: -1 Pozdrawiam.

@TeZetYT 2. Hmm... dziwne. Trochę czasu już pracuję w Skript'cie i miałem okazję rozmawiać z wieloma osobami również korzystającymi z niego. Nigdy jednak nie słyszałem o tym, aby komuś zmienne znikały bez powodu. Mnie to wygląda na jakiś błąd w kodzie lub problem z konfiguracją serwera. Zalecam przejść na zwykłe zmienne, dzięki temu kod będzie wydajniejszy, a też nie będą potrzebne żadne dodatki do poprawnego działania skryptu. 3. W wersji 1.20.4 (wnioskuję po tytule, że jej użyłeś do testów) opcja 'log' była częścią węzła 'commands'. Tak samo jest w wersji 1.21.4. commands: tab-complete: 0 send-namespaced: true silent-commandblock-console: false log: false spam-exclusions: - /skill replace-commands: - setblock - summon - testforblock - tellraw Odniesienie się do samego klucza "log" nic nie da, wyrażenie niczego nie zwróci. Należy odnieść się do "commands.log". 4. Warto to zmienić, bo placeholdery powinny samą swoją nazwą tłumaczyć do czego służą, niezależnie od tego czy kontekst ma sens logiczny, czy nie. 5. Każdy kiedyś zaczynał naukę, doskonale to rozumiem. Co do użycia tej samej soli dla każdego gracza, należy zwrócić na to uwagę, że jeśli mówimy o zapewnieniu bezpieczeństwa haseł, które jest ostatnią linią obrony, osoba włamująca się na pewno już będzie miała dostęp do skryptu i zauważy, że do wszystkich haseł przed hashowaniem należy dodać ciąg znaków "xyz01". To samo tyczy się jednorazowego wygenerowania soli i używania jej dla wszystkich, ponieważ też trzeba będzie gdzieś ją zapisać, a więc można już uznać w tej sytuacji sól za nietajną i tym samym całkowicie nieefektywną. Właśnie z tego powodu sól powinna być losowa dla każdego gracza. Tylko wtedy ona ma sens, bo gwarantuje unikalny hash dla każdego hasła (nawet jeśli wielu użytkowników używa tego samego; te same hasło u różnych użytkowników ze stałą solą nadal po przepuszczeniu przez algorytm daje ten sam hash), co zapobiega chociażby atakom słownikowym. Pozdrawiam.