TheMolkaPL

Nie rób logowania w Skript bo Skript nie potrafi po pierwsze hashować (jedynie md5, ale jest on dzisiaj już odwracalny). Nie jesteś w stanie zablokować wyświetlania logów w których będzie się znajdować hasło. Skrypt taki można łatwo, nawet przypadkiem wyłączyć jedną komenda, co jest bardzo niebezpieczne. Dodatkowo nie jesteś w stanie usunąć tego gracza z listy graczy online. Nie jesteś w stanie zablokować tego gracza do wejścia na serwer jeżeli wykonał dużą ilość prób logowań. Proszę zapoznać się z tym postem: Aby unieruchomość gracza wystarczy zespawnować niewidzialny armor-stand, oraz ustawić, aby dany gracz na nim siedział, ujeżdżał (ride). Dzięki temu zrobisz graczowi pole, w którym nie będzie się rzeczywiście mógł ruszyć. Musisz jeszcze nasłuchiwać eventu od wysiadania z entity. Jeżeli to się stanie, a gracz nie jest zalogowany (kliknie shift) to po prostu go ponownie sadzasz na armor standzie.

No ma bo zobacz jak to wygląda na GitHubie Nie jest ładne takie duże wcięcie. To moja opinia. Po prostu nie jest estetyczne, jest przesadzone.

Uzywajcie 4 spacji zamiast tabów Towarzyszu. Po prostu notatnik interpetuje po swojemu jeden tab (czasem 4, czasem 2 a czasem 8). Z tego względu tabów się unika, właśnie przez różne traktowane ich w edytorach. Używaj 4 spacji - dzięki temu wasze wcięcie będzie zawsze traktowane wszędzie tak samo. Pozdrawiam antykapitalistycznie!

Naah, jd-gui robi masakrycznie dużo błędów, przez co nie można nawet skompilować. Po drugie dodając CraftBukkita jako bibliotekę nie ma już potrzeby dodawania Bukkita, ponieważ CraftBukkit posiada już Bukkita. Nie do końca rozumiem o co chodzi z tymi package z pluginu. Po prostu dekompilujesz i eksportujesz, następnie wrzucasz do IDE i siedzisz nad poprawą błędów po dekompilacji. Co do tematu, to myślę, że w tym temacie wyraziłem się dosyć jasno.

Jest to prawdopodobnie zboczenie z tematu, aczkolwiek nie wiem co taki plugin zawiera, a może zawierać takie zliczanie ilości zniszczonych bloków cobblestone. Nie odstąpię więc od odpowiedzi. Pierwsze pytanie jakie sobie przede wszystkim zadamy to na jakiej licencji został stworzony plugin. Licencja jest warunkami korzystania z danego pluginu, lub jego części, możliwości zarobku na nim, edycji i co sobie w nim zażyczymy. Wiele pluginów, jak nie większość z nich, przynajmniej tych ze SpigotMC i BukkitDev jest open-source, to znaczy otwarte oprogramowanie, czyli takie które mają otwarty kod źródłowy. Otwarty kod źródłowy nie koniecznie mówi, że możemy sobie go od tak użyć, czy edytować. Przykładem jest plugin RedisBungee, które ma otwarty kod źródłowy, natomiast aby użyć go na serwerze publicznie dostępnym należy taki plugin wykupić. Ale do rzeczy - jeżeli mamy odpowiednią licencję pluginu, lub pisemne pozwolenie jego autora na edycję należy pobierać jego kod źródłowy. Należy go zdobyć z na przykład repozytorium Git, który może być hostowany na GitHubie, lub wysłać o niego prośbę do autora pluginu. Pamiętaj, że zdekompilowany kod nigdy nie będzie ten sam! Kod Javy kompilowany jest do bytecode wirtualnej maszyny, którą posiadasz na swoim komputerze. Powrót z bytecode do Javy nigdy nie będzie taki jaki był ten kod oryginalnie. Zależnie od dekompilatora mogą także wystąpić większe lub mniejsze przy tym błędy. Użycie zdekompilowanego kodu jest wyjściem ostatecznym, gdy licencja pozwala na jego edycję, a kod nie jest dostępny, natomiast do autora nie ma żadnej możliwości kontaktu. Kod źródłowy otwieramy w naszym IDE - tutaj Eclipse, edytujemy i kompilujemy. Tak o to wy edytowaliśmy plugin. Pamiętaj, że niektóre licencje mówią, że edytowany jego kod musi być publicznie dostępny. Takiej licencji - GPL-3.0 - używa przykładowo sławny plugin WorldEdit. Pozdrawiam Czerwono!

Choć zadanie jest niby proste, to jednak jej wykonanie już niekoniecznie bez gotowej architektury serwera. Jeżeli jest to nowy serwer to taką architekturę trzeba najpierw zbudować, co oczywiście nie jest tak prostym zadaniem. Zbudowanie architektury jest mocno uzależnione jaki serwer stawiamy, co na nim będzie się działo oraz jakie będzie miało on cechy. Nie ma możliwości zbudowania architektury idealnej. Każda jest uzależniona od trybu jaki prowadzimy. Architektury nie da się też wymyślić i zbudować w jeden dzień. To wszystko sprowadza się do kilka czołowych pytań waszego problemu. Gdzie to zapisać? Jak to zapisać? Kiedy to zapisać? Opowiadając na te pytania można zbudować niewielki system tego zapisu, aczkolwiek nikt nie gwarantuje, że będzie miał dobre możliwości przyszłej rozbudowy.

Witajcie Towarzyszu! Nie do końca rozumiem co macie na myśli. Domyślam się, że chcecie zliczać ilość wykopanych bloków cobblestona (?). Przy każdym zniszczeniu cobblestone chcesz dodawać 1 do liczby już wcześniej zniszczonych klocków. Taka liczba będzie liczbą normalną, bez przecinków. Można wybrać integer jako typ przechowywania danych. Największa liczba jaką można w nim zapisać to 231 - 1 - inaczej 2147483647 - dlaczego minus 1? - Bo w Javie, jak i innych językach programowania liczymy od 0. Na pierwszy rzut oka wygląda to okej - Na serwerze dla prawidłowego zliczenia statystyk można wykopać ponad 2 miliardy bloków cobblestone. Do waszej oceny pozostawiam czy w tej liczbie się zmieścicie, czy nie, natomiast myślę, że serwer, na którym statystyki nie będą nigdy resetowane może to nie wystarczyć. Wtedy należy użyć long - potrafi on zapisać dwa razy większą liczbę. No dobrze, wiemy jaki typ danych użyć do zapisu. Teraz trzeba to rzeczywiście zapisać - i powstaje pytanie jak to zrobić. Samo zapisanie zmiennej w pamięci zostanie z jej wymazane przy usunięciu obiektu w którym się znajduje (zrobi to za nas garbage collector wbudowany w wirtualną maszynę Javy - JVM). Restart serwera, czy jak to zrobimy, usunięcie obiektu gracza wymaże wszystkiego statystyki. Zmienne zapisywane są w pamięci podręcznej - RAM maszyny, na którym serwer został postawiony. Do przechowywania informacji o graczach (a pamiętajmy, że mogą to być ich ogromne ilość) należy użyć dysku twardego. Można to zrobić w pliku w na przykład "plugins/<your plugin>/players" - ma to jednak swoje wady. Po pierwsze występują trudności z backupowaniem danych. Nie zawsze istnieje potrzeba backupowania wszystkich plików serwera. Kolejną wadą jest uzależnienie działania serwera od działania tych danych. Jeżeli przypadkiem skończy nam się miejsce na dysku to nie dość, że popsuje nam się serwer, ale także i dane - nie będą koniecznie aktualne. Brak skalowalności - dane przypisane będą jedynie do jednej instancji serwera Minecraft, brak możliwości rozbudowy tych danych do większej ilości serwerów. Myślę, że najlepszym, najszybszym i najwygodniejszym rozwiązaniem będzie zapis tych informacji w bazie danych. Tutaj mamy ogromne pole do popisu - wybór między serwerami baz danych opartych o język SQL, oraz tzw. bazy danych no-SQL, które na tym języku nie pracują. Teoretycznie bazy danych no-SQL są szybsze, natomiast to zależy także od ich konfiguracji i przeznaczenia. Wiele serwerów no-SQL (na przykład popularne MongoDB) nie jest relacyjne, natomiast oparte o dokumenty - to ma swoje wady jak i zalety. To samo z bazami danych które są relacyjne - na przykład MySQL czy MariaDB. Wybór bazy danych jest trudnym pytaniem, które będzie mogło mieć ogromny, czy kluczowy wpływ na rozwój naszej aplikacji. Wybór bazy danych wybieram wam. Jeżeli sobie życzycie mogę wypisać zalety i wady jednego i drugiego serwera bazy danych jaki i modelu przechowywania informacji (relacyjność/dokument). Co tyczy się komendy /x wystarczy jedynie pobrać informacje z bazy danych oraz wydrukować je do gracza. Pozdrawiam Czerwono!

BungeeCord jest banalny w konfiguracji. https://www.spigotmc.org/wiki/bungeecord-configuration-guide/

Nie da się tego w Skript zrobić. Musicie zrobić swoją własną komendę, która ta dopiero wykona te dwie którą chcecie.

Takowy jest niepotrzebny, ponieważ posiada już to Spigot API.

I jest to wtedy tylko na jedną instancję Bungee. Jeżeli masz ich kilka to się to nie uda. Poza tym potrzebujesz napisać jeszcze swój plugin do tego.

Robisz jeden po drugim. execute player command "komenda1" execute player command "komenda2" execute player command "komenda3" execute player command "komenda4" execute player command "komenda5"

Trochę nieaktualne zrzuty, ale co tam...

Możesz to zrobić na dwa sposoby. Jeden to implementacja takiej funkcji w każdej komendzie, która ma być nasłuchiwana - tak jest w Essentials. Drugim sposobem będzie nasłuchiwanie eventu wykonywania komend oraz wysyłania jej (komendy) do administracji. Pamiętaj, że nie będziesz pewny, czy komenda która zostanie wysłana do administracji zostanie wykonana pomyślnie.

Czyli, że to jest obfuscator - zaciemniacz - tak? To jest akurat banalnie proste - szczególnie w takim mały projekcie (bo to jedynie kilka klas) i tak zależnym od zewnętrznych, niezaciemnionych bibliotek, tutaj Bukkit, czy samo API Javy. Czasem dochodzi Apache Commons i Guava, może Gson. Czyli wychodzi na to, że to i tak nie ma sensu

Z ItemStacka pobierasz ItemMeta. Tam możesz zdobyć getDisplayName().

Dla pewności autora - Javę 1.8, nie Minecrafta (choć ta jest przestarzała i niewspierana).

Dlaczego nie chcesz xamppa? XAMPP jest zbiorem aplikacji. Uruchom serwer MySQL (proces mysqld). Domyślnymi danymi logowania jest root oraz brak hasła. Podaj je w konfiguracji IPS/MyBB.

Oh my... jakie wy bugi znajdujecie. Przecież to zostało naprawione prawie półtora roku temu! XD Odpowiedź jest prosta - zaktualizuj WorldEdita bo musisz go mieć chyba jeszcze z bety, albo gorzej alphy. On nawet nie ma prawa działać xD A co dopiero wy bugi zgłaszacie do takiego przestarzałego softa xD Niedługo ktoś napisze, że mu nie działa Minecraft na win 98 https://github.com/sk89q/WorldEdit/commit/23d6fa7579566b0d92697548afc6a1e27c455a2f Banujesz na UUID - przecież nie ma nieskończoności kont. No chyba, że serwer piracki - to wtedy się nie da.

Logowanie graczy w Skript to jest jakaś paranoja. Gracz wchodzi na Twój lub kogoś serwer i jednocześnie ufa jemu właścicielowi, że jego dane są bezpieczne. Jego adres IP, wszelkie hasła, adresy e-mail i cokolwiek innego... Hasło powinno być hashowane, tak, aby nie dało się go rozszyfrować. Pamiętaj! Jak nie zabezpieczysz swojego SSH, bazy danych to zawsze jest ryzyko, że ktoś się włamie! Brute-force, dziury w aplikacjach trzecich (które są bezpośrednio połączone pod te dane, jak na przykład phpmyadmin) - nigdy nie ma pewności, że dane są bezpieczne. Nawet takie giganty jak Google trafiają atakiem ludzi, którzy dziurę znajdą wszędzie. Wszelkie informacje jakie zamieszczasz w sieci na publicznym serwerze mogą kiedyś wycieknąć. Hashowanie haseł (oczywiście takim hashem, który działa w jedną stronę) to podstawa przy zapisie takich informacji jak hasła. Pamiętaj, że bardzo wielu użytkowników używa tych samych haseł w różnych serwisach, tutaj także serwerów. Dodatkowo, dla większego bezpieczeństwa używa się też tak zwanej soli (po angielsku salt). Jest to losowy ciąg znaków często o długości ponad 60 znaków, który jest unikalny dla danego użytkownika w bazie danych. Dzięki soli hash hasła nie jest bezpośrednio zahashowanym hasłem, lecz "sklejką" dwóch różnych danych. Może to wyglądać na przykład tak "salt + hasło", np "eft4fe542fgh+haslo123". Dzięki temu nie da się wykryć, że wielu użytkowników używa tych samych haseł, ponieważ ich hashe są skrajnie różne. Dostęp do bazy danych w których takie hasła się znajdują powinien być jak najmocniej chroniony. To znaczy na przykład, że do bazy danych ma dostęp tylko wąska zaufana grupa osób. Ty zapisujesz hasła w czystym ciągu znaków, gdzie dosłownie każdy może podejrzeć wszystkie hasła użytkowników. Nie wspominam już o ewentualnym wycieku danych, wtedy rzeczywiście jesteś skopany. Gracze, którzy Ci zaufali, że ich dane są bezpieczne odkryli, że ty ich je***eś w pupe. Całkowicie nie interesowało cię ich bezpieczeństwo, ani ich dane! Wyobraź sobie, że nagle Facebook ma wyciek oraz okazuje się, że hasła nie były hashowane. Teraz okazuje się, że tego samego hasła używałeś jeszcze na YouTube, i jeszcze masie innych serwisów. Okazuje się, że ta cała baza danych jest publicznie dostępna, a w niej znajdują się wszystkie Twoje prywatne wiadomości ze znajomymi, cała lista znajomych, wszystkie Twoje posty, komentarze, liki, Twoje dane osobowe (imię i nazwisko to też dane osobowe). Więc jeszcze raz powtarzam, niehashowanie haseł jest skrajnym wywaleniem na bezpieczeństwo użytkowników Twojego serwisu. Ten skrypt powinien zostać jak najszybciej zniszczony i usunięty, żeby przypadkiem go ktoś nie użył...

Witam Czerwono Towarzysze! Proponuję na serwer creative dodać dynamiczną mapę. Obecnie praktycznie nie ma żadnej możliwości eksplorowania budowli i mapy serwera. Dynamiczna mapa byłaby rozwiązaniem tego problemu. Pozdrawiam Robotniczo!

Minecraft nigdy nie przekroczy 2 GB pamięci RAM. Mi do normalnej rozgrywki wystarcza bagatela 512 MB.

Śmiem Towarzyszu twierdzić, że w Skripcie nie da się tego prawidłowo zrobić. Jedyny event od logowania w Skript to "on connect" - jest to PlayerLoginEvent. Jest to event, który wykonuje synchronicznie w głównym wątku logiki serwera. Oznacza to, że nie można w nim wykonać "blocking operation" - operacji blokowania, którym zadanie input/output (lub odczytu/zapisu) właśnie jest. Nie można więc wykonać żadnej operacji zapisu/odczytu, aby zweryfikować gracza przy logowaniu. Powinno to zostać wykonane w PlayerPreLoginEvent, który jest asynchroniczny i gdzie takie zadanie może zostać wykonane. Oczywiście możesz wszystkie bany cachować (czyli zapisywać lokalnie w szybkiej pamięci podręcznej) przy starcie serwera, ale istnieje wtedy duże prawdopodobieństwo przestarzałych danych (gracz może zostać odbanowany lub zbanowany manualnie). Choć zapis wszystkich zbanowanych UUID oraz powodów (String) zajmie mało pamięci, to jednak nie powinno się zapisywać tak nielimitowanej ilości danych w pamięci podręcznej. Lepiej sprawdzi się do tego baza danych i/lub serwer cache (np Redis). Jest to znowu jednak zadanie input/output, które nie może zostać wykonane w PlayerLoginEvent jako weryfikacja gracza. Reasumując nie da się w Skript wykonać prawidłowej weryfikacji gracza przy jego logowaniu wymagającej zadania input/output ze względu na brak w nm AsyncPlayerPreLoginEvent. Robotnicze Pozdrowienia!