Skocz do zawartości

Kormic

Zasłużony
  • Ilość zawartości

    11015
  • Rejestracja

  • Ostatnia wizyta

  • Wygrane w rankingu

    231

Treść opublikowana przez Kormic

  1. Kormic

    Skrypt na logowanie

    Ten temat został przeniesiony.
  2. Kormic

    Skrypt na antylogout

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

    zetLogin [1.20.4]

    @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.
  4. Ten temat został przeniesiony.
  5. Ten temat został zamknięty.
  6. @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.
  7. Kormic

    Pytanie

    Jest to błąd w zapisie struktury, ponieważ w Skript nie ma zdefiniowanego typu npc. Zamiast tego należy użyć entity (dowolny byt na serwerze, można również zacieśnić do living entity) i sprawdzić czy kliknięty byt (event-entity) posiada metadata tag "NPC". W ten sposób Citizens (rozumiem, że mowa o NPC z tego pluginu) oznacza NPC. Od tego momentu mamy pewność, że mamy do czynienia z NPC z Citizens, o ile nie nadaliśmy sami ten tag innemu bytowi. Dalej możemy chociażby sprawdzić display name tego NPC, aby zweryfikować czy operujemy na konkretnym NPC, o którego nam chodzi. Pozdrawiam.
  8. Kormic

    ukrywanie

    Jest to możliwe. Można stworzyć własny filtr przy pomocy frameworku Log4j, co zresztą zdaje się, że robi większość pluginów obsługujących autentykację. Wystarczy przechwycić logger serwera i dodać do niego filtr będący rozszerzeniem klasy AbstractFilter. Należy zwrócić szczególną uwagę na słowo "klasy". Dodatek skript-reflect nie pozwala na tworzenie klas rozszerzających inne klasy, nawet abstrakcyjne. Wykracza to więc poza możliwości klas proxy i zmusza do skorzystania z dodatku Hippo pozwalającego na tworzenie własnych klas. W tym momencie warto się zastanowić czy nie lepszym rozwiązaniem będzie napisanie własnego pluginu. Jako przykład podsyłam kod źródłowy pluginu LoginSecurity. Jedyne dwie interesujące nas rzeczy to ten fragment z metody onEnable() dodający filtr do loggera i definicja samego filtru. Pozdrawiam.
  9. Kormic

    ukrywanie

    @CoFFeIN04 Anulowanie wydarzenia 'on command' nie zapobiega wyświetlaniu wiadomości o wykonaniu komend w konsoli. @TeZetYT Ponieważ logging komend jest wprowadzony na poziomie silnika, najprostszym rozwiązaniem byłoby wyłączenie logów komend w pliku spigot.yml i własna implementacja logów komend, które można wyświetlać w konsoli. Na przykład coś takiego jak poniżej. on command: sender is not console {nonLoggableCommands::*} doesn't contain command send "%sender% executed command /%full command%" to console Jeśli jednak zależy nam na eleganckim rozwiązaniu, należy przejrzeć kod źródłowy któregokolwiek z sensownych pluginów wprowadzających mechanizm autentykacji (logowania) na serwerze. Mogę jedynie podejrzewać, że jest to rozwiązane za pomocą anulowania konkretnych pakietów. Pozdrawiam.
  10. @iZee Zdaje się, że jedyne dwie permisje używane w skrypcie są wymienione w sekcji 'options' na górze kodu. Pozdrawiam.
  11. @kumpela6 Nie ma potrzeby pozostawania na tak starej wersji Skripta. Sugeruję zaktualizować serwer i Skripta do najnowszej wersji, a SkQuery usunąć, ponieważ już nie jest rozwijane. Jeśli jednak nie ma takiej możliwości, warto przynajmniej rzucić okiem na również już porzucony projekt o nazwie Skript-1.8 autorstwa Matocolotoe, który oferuje wiele nowych elementów składni, w tym chociażby wspomniane wyświetlanie action bar. Plugin można pobrać na stronie jego repozytorium na GitHub. Może też być taka sytuacja, że na przykład sam hosting (chociażby Aternos ze względu na swoją politykę) nie pozwala na pobranie innej wersji Skripta. W tym przypadku zalecam zastanowić się nad innym hostingiem. Co do samego skryptu, warto poszukać na forum istniejących kodów. Na pewno coś przypadnie do gustu. Samo wyświetlanie action bar jest banalnie proste, co można zobaczyć w dokumentacji Skripta. Pozdrawiam.
  12. @smafiii Tutaj może pomóc dodatek SkBee, ponieważ zależy nam tutaj na sprawdzeniu czy znacznik 'waterlogged' w block data bloku jest ustawiony na 'true'. Co prawda Skript również pozwala na ustawianie i sprawdzanie znaczników block data, ale jest to rozwiązanie skrajnie nieelastyczne, bo wymaga to podawania typu bloku. Wracając, można zamienić warunek 'loop-block is water or lava' na poniższy: if any: loop-block is water or lava block data tag "waterlogged" of loop-block is true then: # Dalszy kod Pozdrawiam.
  13. @Fquido_Games Twoje rozwiązanie sprawdza czy argument jest tekstową reprezentacją liczby, a nie czy tekst zawiera cyfry, więc to nie jest rozwiązanie opisanego problemu. @TeZetYT Warto tu się wspomóc wyrażeniami regularnymi. Przykład poniżej: if arg partially matches "\d": send "Argument zawiera co najmniej jedną cyfrę." to sender Jeżeli chodzi o wyszukiwanie wielkich liter i znaków specjalnych, jest to proste. Do pierwszego wystarczy wzorzec '[A-Z]', a w przypadku drugiego można sprawdzić czy tekst nie jest alfanumeryczny. Pozdrawiam.
  14. Problem został rozwiązany.
  15. Problem został rozwiązany.
  16. Łatwiej będzie pomóc i wytłumaczyć błędy na podstawie kodu, bo teraz trudno odnieść się do istoty problemu. Pozdrawiam.
  17. Istnieje znacznie prostszy sposób niż definiowanie osobnej komendy w Skript'cie. Wystarczy zdefiniować alias w pliku commands.yml. Przykład poniżej: aliases: examplealias: - "somecommand" Po zapisaniu aliasu (pliku) i ponownym uruchomieniu serwera /examplealias stanie się aliasem komendy /somecommand. Pozdrawiam.
  18. Ten temat został przeniesiony.
  19. Proszę pokazać tę drugą wersję.
  20. Ten temat został przeniesiony.
  21. Ten temat został przeniesiony.
  22. Ten temat został przeniesiony.
  23. Problem został rozwiązany.
  24. No dobrze. W zasadzie jedynie przyda Ci się ten artykuł z wiki dodatku skript-placeholders, którego należy użyć do zarejestrowania własnego placeholderu w Skript'cie. Zdecydowana większość rzeczy jest tam opisana i jak wspomniałem, są tam załączone przykłady. Jeżeli chodzi o samo zrozumienie składni tego dodatku, a właściwie to Skripta, nie obędzie się bez zrozumienia tego co oznaczają dane elementy we wzorcach wszystkich elementów składni, które można przeczytać w dokumentacjach Skripta i wszystkich dodatków, na przykład wzorzec struktury rejestrowania placeholdera w skript-placeholders: (placeholder[ ]api|papi) placeholder (with|for) [the] prefix %*string% Teraz opiszę w skrócie co oznaczają te tajemnicze nawiasy i procenty: coś - wymagany element wzorca, trzeba go napisać, [coś] - opcjonalny element wzorca, (coś|coś) - wybór, należy wybrać jeden z elementów w nawiasie, %coś% - wyrażenie danego typu. Warto jeszcze zwrócić uwagę na modyfikator wyrażenia "*". Oznacza on, że podane wyrażenie musi być literałem - najprościej mówiąc, w tym przypadku musi to być napisany "z palca" tekst w cudzysłowie (na przykład "skript"). Zmienne z tekstem i inne wyrażenia są niedopuszczalne. Istnieją jeszcze inne modyfikatory wyrażeń jak chociażby "~" (ten jest przeciwieństwem gwiazdki, nie może to być literał), ale nie będę ich opisywał. Pozdrawiam.
×
×
  • Dodaj nową pozycję...