Ranking

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

Po co tak cudować? Wystarczy użyć PlayerMoveEvent używająć addonu skript-reflect import: org.bukkit.event.player.PlayerMoveEvent on PlayerMoveEvent: send "chodzisz" to event.getPlayer()