Ranking

Co na celu ma pętla while z "wait 14 day"? Pomijając fakt, że fajnie by było odmienić słowo day na liczbę mnogą, to jaki jest tego cel? Nikt nie będzie siedzieć na serwerze 2 tygodnie i czekać na kolejną wiadomość xd, niepotrzebna pętla tylko.

Tak masz racje, nie zauważyłem. Ale czy zamiast robić nową zmienną nie lepiej użyć już wykorzystywanej zmiennej last attacker? on join: if {kills::%player%} is not set: set {kills::%player%} to 0 on death of player: last attacker of victim is a player add 1 to {kills::%last attacker of victim%} on chat: if {kills::%player%} >= 5: stop cancel event send "&cNie mozesz pisac na chacie, musisz zabic 5 osob"

Drugie rozwiązanie odpada, ponieważ będzie też to samo do marchewek, ziemniaków itd. a one nie mają swojego odpowiednika tak jak pszenica. Co do pierwszego napewno skorzystam i dzięki za pomoc. Temat do zamknięcia.

@xAxee Jeśli się nie mylę przyjacielu, użycie %attacker% (po sprawdzeniu czy typ ostatnio atakującego to gracz) nie ma sensu, gdyż może zwrócić <none> przy chociażby śmierci od upadku z wysokości. Zamiast tego należałoby zapisywać do zmiennej przypisanej do ofiary (atakowanego gracza) ostatnio atakującego gracza. on join: {kills::%player%} is not set set {kills::%player%} to 0 on damage of player: attacker is a player set {lastAttacker::%victim%} to attacker on quit: clear {lastAttacker::%player%} on death of player: last attacker of victim is a player {lastAttacker::%victim%} is set add 1 to {kills::%{lastAttacker::%victim%}%} on chat: {kills::%player%} < 5 cancel event send "&cNie mozesz pisac na chacie, musisz zabic 5 osob" to player

Rozwiązanie Axee'a jest jak najbardziej poprawne, jednak można je napisać krócej i bardziej przyszłościowo - to znaczy z myślą o ewentualnym dodawaniu kolejnych przyrostków. function convertNumber(n: number) :: text: set {_exponents::*} to 12, 9, 6 and 3 set {_suffixes::*} to "t", "b", "m" and "k" loop {_exponents::*}: {_n} >= 10^(loop-value) set {_value} to round({_n} / 10^(loop-value - 1)) / 10 return "%{_value}%%{_suffixes::%loop-index%}%" return "%{_n}%"

Sugeruję zapętlić wszystkie przedmioty w ekwipunku użytkownika (a więc 'loop all items in player's inventory') i sprawdzać w każdej iteracji pętli czy dany przedmiot to pszenica, która posiada odpowiednią nazwę. Dodatkowo przyda się tutaj wyrażenie 'item amount', gdyż każdy slot może zawierać nie więcej niż 64 sztuki danego przedmiotu, więc trzeba będzie to jakoś sprawnie zliczać. Drugie rozwiązanie, które jest moją propozycją zmiany pomysłu owej "giga pszenicy" - zrobić tak, aby ona była blokiem (snopem) siana. Wtedy Skript będzie w stanie spokojnie na podstawie samego typu przedmiotu poprawnie określić co może zabrać z ekwipunku, a co nie.

function convertNumbers(n: number) :: text: if {_n} >= 10^12: set {_a} to round({_n} / 10^11) / 10 return "%{_a}%t" if {_n} >= 10^9: set {_a} to round({_n} / 10^8) / 10 return "%{_a}%b" if {_n} >= 10^6: set {_a} to round({_n} / 10^5) / 10 return "%{_a}%m" if {_n} >= 10^3: set {_a} to round({_n} / 10^2) / 10 return "%{_a}%k" return "%{_n}%"

on join: if {kills::%player%} is not set: set {kills::%player%} to 0 on death of player: attacker is a player add 1 to {kills::%attacker%} on chat: if {kills::%player%} >= 5: stop cancel event send "&cNie mozesz pisac na chacie, musisz zabic 5 osob"

Nie zgodzę się z tym stwierdzeniem. Funkcje hashujące z rodziny SHA-2 są bezpieczne, ale tak długo jak są użytkowane w prawidłowy sposób. To samo tyczy się wszystkich innych dostępnych algorytmów. Ewentualny brak bezpieczeństwa wynika z winy osoby projektującej mechanizm logowania, nie z winy samej funkcji. Oczywiście wyjątkiem od tej zasady są wadliwie skonstruowane algorytmy jak chociażby wyżej przywołany przeze mnie MD5. Wiem, że jest to czepianie się z mojej strony, ale nie istnieje taki termin jak "odhashowanie", bo sugerowałoby to istnienie funkcji odwrotnej do funkcji hashującej. Zauważyłem, że nie napisałem o dorzucaniu soli do hasła przed hashowaniem. Mój błąd i dziękuję za poprawienie nie wprost. Do Pana piszącego ten skrypt - w dużym skrócie sól to szereg losowo wygenerowanych przy rejestracji (w kryptologicznie bezpieczny sposób) znaków, które są dodawane do hasła tuż przed hashowaniem. Wtedy w bazie danych (w Pana przypadku jest to plik variables.csv) przechowywana jest sól i hash. Jakie jest uzasadnienie użycia soli przy hashowaniu? Największym zagrożeniem dla bazy z hasłami jest niemałe ryzyko występowania takich samych haseł. Nietrudno sobie wyobrazić grupę użytkowników, którzy z lenistwa ustawią sobie hasło "123456789". Jeśli ktoś nieupoważniony ze złymi zamiarami i głową na karku dostanie się do bazy, przy odnalezieniu faktycznego hasła dla jednego hashu od razu uzyskuje dostęp do kont wszystkich użytkowników z tym samym hasłem. Dlatego sól jest ważna, bo dzięki niej mamy przynajmniej pewność, że pary (sól, hash hasła) są unikalne, co zdecydowanie zwiększa bezpieczeństwo. Dodam, że sól powinna być możliwie długa - ponieważ wynikiem algorytmu SHA-256 jest 32-bitowy ciąg znaków (a więc po prostu 32 znaki), zaleca się dodawanie soli zbudowanej również z 32 znaków. Dodatkowo, nie powinna być ona generowana poprzez zwykły generator losowych liczb (znaków). Do tego zadania sprawdzi się klasa 'java.security.SecureRandom', która dokłada wszelkich starań, aby wygenerowany ciąg bajtów (znaków) był unikalny. Jeśli mowa o spowolnieniu poszukiwań oryginalnego hasła, zysk w tym przypadku jest niewielki. Istnieją lepsze sposoby, aby tego dokonać. Na końcu mojego postu załączę artykuł, z którego swego czasu się uczyłem o hashowaniu i są tam zaprezentowane możliwe rozwiązania tego problemu. Kończąc mój wywód, Skript sam w sobie nie nadaje się do przechowywania haseł. Przykładem tego jest chociażby brak wsparcia dla generowania soli, o której notabene sami twórcy wspominają w dokumentacji. Oczywiście da się to napisać, jednak pojawiają się tutaj przez to dodatkowe trudności. Udostępniam również link do artykułu, o którym wspomniałem: https://crackstation.net/hashing-security.htm Pozdrawiam.