Kormic

@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.

Ten temat został przeniesiony.

@lord90 Skrypt posiada dwa błędy logiczne i dwa błędy składniowe. Zacznę od wymienienia tych logicznych. Błędy logiczne: Wiadomości wysyłane do graczy przy rozpoczęciu walki powinny wykorzystywać stałą {@combat-time}, a nie nieistniejącą zmienną globalną {combat-time}. Niemożliwym jest anulowanie zdarzenia wyjścia. Gdyby było to możliwe, byłby to absurd. Należy zamiast tego zabić gracza, aby stracił wszystkie swoje przedmioty przy próbie ucieczki przed śmiercią. Błędy składniowe: Stała {@combat-time} jest liczbą, nie różnicą czasu (wartością typu timespan). W związku z tym, nie można od niej odjąć różnicy czasu, która jest właśnie typu timespan. Zachodzi tu niezgodność typów, co sprawia, że zmienna lokalna {_time-left} nie przyjmuje żadnej wartości. Użyty efekt do wyświetlenia cząsteczek z całą pewnością nie jest częścią składni Skripta. Ponadto, nie istnieje w Skript taki efekt wizualny jak redstone dust. Mam przeczucie graniczące z pewnością, że ten skrypt został wygenerowany przy pomocy sztucznej inteligencji. Regulamin forum zabrania publikowania wadliwych skryptów tego pochodzenia. Proszę mieć to z tyłu głowy. Pozdrawiam.

@TeZetYT Kod jest schludnie napisany, choć zauważyłem dwa podobne fragmenty, które skłaniają do rozważenia stworzenia dla nich funkcji. Mowa o podobieństwie w warunkach komend /register i /changepassword sprawdzających spełnienie wymagań ustawianego hasła. Skoro skrypt operuje na plikach .yml, co nie jest możliwe w samym Skript'cie. Warto byłoby wspomnieć o tym jakie dodatki są wymagane. Co do samej logiki skryptu, mam kilka uwag i pytań. Sekcja konfiguracyjna jest spora i pozwala na dostosowanie niemalże każdej wiadomości, to się ceni. Nie rozumiem jednak dlaczego wszystkie wymogi stawiane ustawiane hasłom, ilość prób, itd. są literałami, a nie stałymi w sekcji 'options'. Taki zabieg upiększyłby kod i również ułatwiłby jego rozwój w przyszłości. Jeśli martwisz się możliwością nieumyślnej ich zmiany przez osoby pobierające ten skrypt, nic nie stoi na przeszkodzie aby stworzyć na samym końcu kodu kolejną sekcję 'options' przeznaczoną tylko dla tych stałych, których wartości nie powinno się modyfikować. Dlaczego skrypt zapisuje dane logowania graczy w indywidualnych plikach .yml? Jaką to ma przewagę nad zapisem w zmiennych globalnych w Skript? Zakładam, że te wartości YAML nie są cache'owane w pamięci RAM, więc skrypt przy każdym pobieraniu wartości musi otworzyć plik (co jest wymagającą operacją w porównaniu do odczytu jednej wartości) aby wyjąć z niego jedną wartość i odrzucić resztę. Jak widać, nie jest to szczególnie wydajne podejście. Jeśli faktycznie chcemy korzystać z plików .yml nie ważne co, warto się pochylić nad dodatkiem skript-yaml, który pozwala na poprawną obsługę plików - to znaczy ładowanie ich do pamięci RAM i dalsze operowanie na nich w tej pamięci. Zauważyłem w kilku miejscach poniższą linijkę i zastanawiam się czy ona rzeczywiście działa: set yaml value "log" from file "spigot.yml" to false Wiem jakie jest jej zadanie - wyłączenie loggingu komend w konsoli i plikach .log serwera, co definitywnie zwiększa bezpieczeństwo haseł użytkowników. Niemniej jednak, w pliku spigot.yml ten węzeł nazywa się 'commands.log', więc podejrzewam, że może to nie działać. Co więcej, wątpię czy serwer na bieżąco śledzi zmiany w pliku spigot.yml, nie wiem czy skrypt był pod tym kątem testowany. Jedyne znane mi metody przeładowania pliku konfiguracyjnego Spigota to restart serwera (oczywiście jest to najlepsza metoda) lub użycie komendy /spigot reload. Tak jeszcze dodam, że jeśli ta linijka rzeczywiście działa, warto byłoby ustawiać przy wyłączeniu skryptu jej wartość na true, nie na false. Ponadto, przy loggingu komend myślę, że lepiej będzie usunąć prefix, jest to zbędne. W wiadomościach w sekcji konfiguracyjnej czytelniejsze byłoby użycie placeholderów takich jak {player}, {admin}, {hashedPassword}. {0} czy {1} niewiele mówią i wymuszają na użytkowniku szukanie ich znaczenia w kodzie skryptu. Z kryptologicznego punktu widzenia, dodawanie ciągu znaków "xyz01" przed hashowaniem hasła (nie szyfrowaniem!, to są dwie różne rzeczy, bo wszystko można odszyfrować przy znajomości szyfru; hashowanie jest operacją jednokierunkową) nie przyczynia się do zwiększenia bezpieczeństwa haseł. Jedyne z czym mi się to kojarzy to próbą implementacji dodawania soli do haseł. Sól jednak powinna być losowym ciągiem znaków, indywidualnym dla każdego gracza, najlepiej o długości takiej jak ilość bitów hashów danego algorytmu. W przypadku SHA-256 jest to rzecz jasna 256 bitów, czyli 32 bajty. Przy zapisie w systemie szesnastkowym, każdy bajt jest reprezentowany przez dwa znaki (256 dostępnych znaków to 16 * 16 - dwa znaki), więc z SHA-256 otrzymujemy ciągi znaków o długości 64. Warto dodawać sól do haseł przy hashowaniu, ale niestety, bez zewnętrznej biblioteki nie jest to możliwe, ponieważ skript-reflect ma bug niepozwalający na poprawne korzystanie z klasy SecureRandom. Dlatego nie przejmowałbym się tym, chciałem tylko naprostować parę spraw, wyprowadzić z błędu. EDIT: W ramach lektury polecam ten artykuł opisujący sposoby poprawnego użycia algorytmów hashowania. Pozdrawiam.