GotoFinal

Huh, metod nauki jest masa i każdy woli co innego, ja np szybo się zniechęcam typowymi książkowymi przykadami i poradnikami i ktorych uczą jak napisać kalkulator w jedyne 2000 stron
Ja polecam poszukać dowolnego poradnika tekstowego który pokazuje jak stworzyć główną klasę, plugin.yml, komendę i listener, no i może taska. potem pobrać najlepsze dostępne IDE - Intellij (wersja community wystarczy) i zgodnie z jakimiś instrukcjami stworzyć nowy projekt javy (najfajniej by bylo od razu uczyć się mavena, no ale może ci sie wydawać zbyt skomplikowane)
I potem zwyczajnie bawić się z kodem, bo z pomocą dobrego ide i odrobiny angielskiego szybko odkryjesz co możesz stworzyć, np masz klasę Bukkit, wpisujesz w ide Bukkit. i masz wszystkie dostępne metody, np getOnlinePlayers, potem możesz zobaczyć co możesz robić na graczu, np setHealth itd.
Najważniejsze czego będziesz musiał się nauczyć to odpowiedniego zadawania pytań w google, bo jak będziesz szukać "bukkit how to make ban plugin" (szukaj po angielsku, latwiej) to znajdziesz lipne wyniki, lipne gotowce i nawet nie zrozumiesz o co chodzi, a mozesz zamiast tego zastanowić się co trzeba zrobić by istniał ban:
- Komenda /ban
- Jakiś sposób zablokowania wejscia gracza na serwer 
- Zapis tego do np pliku
I szukasz kolejno: Bukkit how to create command, bukkit how to disallow player join lub nawet od razu możesz skojarzyć że od tego są eventy i tylko poszukać eventu od wejścia gracza na serwer, mozesz to zrobić w google, lub nawet w ide, jak już sobie znajdziesz org.bukkit. to dalej tez ci IDE podpowieda, np org.bukkit.event.player.PlayerLoginEvent
Potem znowu szukasz czegoś o plikach, pod bukkita lub samą javę, bukkit ma np gotowe API od plików yaml, ale możesz zapisać samemu w jakimś pliku .txt, reszty się nauczysz później.
I na prawdę, zadawanie poprawnych pytań to podstawa, tak by na forum pytać się jak już się nie wie... Warto też przeglądać src jakiś dobrych pluginów jak już ogarniesz podstawy.
Dodatkowo jest dokumentacja z opisem wszystkich metod w API bukkita: Zarejestruj się lub zaloguj, aby zobaczyć ukrytą treść!
No i zostaje kwestia upubliczniania... nie wrzucaj tych początkowych pluginów ot-tak na forum, bo mamy juz pierdyliard 50 linijkowych pluignów na bany, motd i inne takie glupoty które na początku często się tworzy, ALE warto jak wrzucisz swój kod, najlepiej używając serwisu github tutaj na forum, np do tego działu, pytając się o ocenienie kodu, wtedy np ja czy inni użytkownicy możemy powiedzieć co możesz zrobić lepiej i na nauce czego się skupić.
A tak to warto zaleźć sobie coś co chcesz stworzyć, dla siebie na server np, i zacząć to pisać, na początku pewnie będzie szło słabo, ale jak już zobaczysz że coś zaczyna działać, to będziesz miał więcej motywacji by to kontynuować.
 
 
EDIT: a na skrypty nie marnuj czasu, to zbyt prymitywny język, nauczy cię masy złych praktyk z którymi będziesz potem walczyć.
 
 
EDIT2: no i oczywiście warto też po drodzę czytać coś o samej javie, np: Zarejestruj się lub zaloguj, aby zobaczyć ukrytą treść!
chyba że z samych przykładów z innych kodów i poradników ograniesz używanie podstawowych konstrukcji, jak klasy, metody, zmienne, pętle, pola itd.

aż wpadłem pomarudzić:
Zacznę od tego że bazują na API bukkita i chcąc zrobić API które będzie możliwe do zaimplementowania potem wygodnie w sponge już zrypaliście cały projekt co podobny bład popełniłem bawiąc się z diorite.
Jak widzicie jakieś rozwiązanie w bukkicie to na 90% jest to najgorsze z możliwych.
I coś co kamilkime napisał gdzieś indziej: jak już ktoś dobrze ogarnia kotlina to po co mu taki plugin? wygodniej i wydajniej będzie zwyczajnie napisać plugin w kotlinie.
Dodajecie masę narzutu swoją abstrakcją, bo abstrakcja niestety kosztuje, np każde pobranie graczy wymaga wrappowania ich w wasze obiekty, moglibyście takie wrappery cachować oczywiście, ale wtedy jak wszystko będziecie cachować to znowu sporo pamięci ucieknie. Podobnie pobierania gracza po nicku leci po pętli zamiast jakiś lookup mapą (no i gdzie po uuid? o.O, co to, 2010?)
Reprezentowanie entity klasami to niestety też problem, mojang co chwile coś psuje i zmienia i odwraca entity do góry nogami, powstają potem koszmarki jak w bukkcie że albo dana rzecz nie jest wspierana bo devi uznali że pewnie i tak się zmieni, albo masz kilka metod od tego samego bo zmieniało się API, tutaj lepiej brać trochę przykład z sponge.
Tutaj niestety zasada composition over inheritance się sprawdza, trudniej potem zrobić wygodne i szybkie API, ale tylko walcząc w ten sposób idzie zrobić coś co się nie popsuje w kolejnej wersji mc za mocno. Mając prosty system propertisów jest ten plus że można o danym ustawieniu zwyczajnie zapomnieć jeśli zostanie usunięte nie zasyfiając tak kodu, albo jak np dodadzą żę teraz każdy mob może się starzeć? musiecie zmieniać hierarchie wszystkich klas, tworzą się duplikaty metod itd. A mając tylko jakieś property: mob.set(Age, child) zmieniacie tylko wewnętrzną implementacje by od teraz nie ignorowała tej wartości dla wybranych modów. 
Dodatkowo korzystając z kotlina możecie dodawać klasy z extension methods które ludzie mogą importować dowolnie jak chcą i mieć dostępną metode mob.setAge kiedy chcą - co ułatwia użycie API nie wiążąc niczego z implementacją. 
A itemy tylko na stringach to też problem, a zrobienie BlockType na enum to już najgorsze co mogliście zrobić, enum z materialami to rzecz na którą każdy developer bukkita marudzi i mówi że to był największy bład jaki kiedykolwiek zrobili, na plus że rozdzieliliście tam jednak subid i wszystko jest na "płasko". Bloki się zmieniają a niektóre silniki wspierają mody i pluginy.
Enumy powinny być do rzeczy niezmiennych, szczególnie projektując API. 
No i github jest lepszy do publicznych projektów bo ktoś go odwiedza A robienie tego closed source jest jeszcze bardziej bez sensu - no chyba że to tylko jakiś bład, ale wali 404.
 

aż wpadłem pomarudzić:
Zacznę od tego że bazują na API bukkita i chcąc zrobić API które będzie możliwe do zaimplementowania potem wygodnie w sponge już zrypaliście cały projekt co podobny bład popełniłem bawiąc się z diorite.
Jak widzicie jakieś rozwiązanie w bukkicie to na 90% jest to najgorsze z możliwych.
I coś co kamilkime napisał gdzieś indziej: jak już ktoś dobrze ogarnia kotlina to po co mu taki plugin? wygodniej i wydajniej będzie zwyczajnie napisać plugin w kotlinie.
Dodajecie masę narzutu swoją abstrakcją, bo abstrakcja niestety kosztuje, np każde pobranie graczy wymaga wrappowania ich w wasze obiekty, moglibyście takie wrappery cachować oczywiście, ale wtedy jak wszystko będziecie cachować to znowu sporo pamięci ucieknie. Podobnie pobierania gracza po nicku leci po pętli zamiast jakiś lookup mapą (no i gdzie po uuid? o.O, co to, 2010?)
Reprezentowanie entity klasami to niestety też problem, mojang co chwile coś psuje i zmienia i odwraca entity do góry nogami, powstają potem koszmarki jak w bukkcie że albo dana rzecz nie jest wspierana bo devi uznali że pewnie i tak się zmieni, albo masz kilka metod od tego samego bo zmieniało się API, tutaj lepiej brać trochę przykład z sponge.
Tutaj niestety zasada composition over inheritance się sprawdza, trudniej potem zrobić wygodne i szybkie API, ale tylko walcząc w ten sposób idzie zrobić coś co się nie popsuje w kolejnej wersji mc za mocno. Mając prosty system propertisów jest ten plus że można o danym ustawieniu zwyczajnie zapomnieć jeśli zostanie usunięte nie zasyfiając tak kodu, albo jak np dodadzą żę teraz każdy mob może się starzeć? musiecie zmieniać hierarchie wszystkich klas, tworzą się duplikaty metod itd. A mając tylko jakieś property: mob.set(Age, child) zmieniacie tylko wewnętrzną implementacje by od teraz nie ignorowała tej wartości dla wybranych modów. 
Dodatkowo korzystając z kotlina możecie dodawać klasy z extension methods które ludzie mogą importować dowolnie jak chcą i mieć dostępną metode mob.setAge kiedy chcą - co ułatwia użycie API nie wiążąc niczego z implementacją. 
A itemy tylko na stringach to też problem, a zrobienie BlockType na enum to już najgorsze co mogliście zrobić, enum z materialami to rzecz na którą każdy developer bukkita marudzi i mówi że to był największy bład jaki kiedykolwiek zrobili, na plus że rozdzieliliście tam jednak subid i wszystko jest na "płasko". Bloki się zmieniają a niektóre silniki wspierają mody i pluginy.
Enumy powinny być do rzeczy niezmiennych, szczególnie projektując API. 
No i github jest lepszy do publicznych projektów bo ktoś go odwiedza A robienie tego closed source jest jeszcze bardziej bez sensu - no chyba że to tylko jakiś bład, ale wali 404.
 

aż wpadłem pomarudzić:
Zacznę od tego że bazują na API bukkita i chcąc zrobić API które będzie możliwe do zaimplementowania potem wygodnie w sponge już zrypaliście cały projekt co podobny bład popełniłem bawiąc się z diorite.
Jak widzicie jakieś rozwiązanie w bukkicie to na 90% jest to najgorsze z możliwych.
I coś co kamilkime napisał gdzieś indziej: jak już ktoś dobrze ogarnia kotlina to po co mu taki plugin? wygodniej i wydajniej będzie zwyczajnie napisać plugin w kotlinie.
Dodajecie masę narzutu swoją abstrakcją, bo abstrakcja niestety kosztuje, np każde pobranie graczy wymaga wrappowania ich w wasze obiekty, moglibyście takie wrappery cachować oczywiście, ale wtedy jak wszystko będziecie cachować to znowu sporo pamięci ucieknie. Podobnie pobierania gracza po nicku leci po pętli zamiast jakiś lookup mapą (no i gdzie po uuid? o.O, co to, 2010?)
Reprezentowanie entity klasami to niestety też problem, mojang co chwile coś psuje i zmienia i odwraca entity do góry nogami, powstają potem koszmarki jak w bukkcie że albo dana rzecz nie jest wspierana bo devi uznali że pewnie i tak się zmieni, albo masz kilka metod od tego samego bo zmieniało się API, tutaj lepiej brać trochę przykład z sponge.
Tutaj niestety zasada composition over inheritance się sprawdza, trudniej potem zrobić wygodne i szybkie API, ale tylko walcząc w ten sposób idzie zrobić coś co się nie popsuje w kolejnej wersji mc za mocno. Mając prosty system propertisów jest ten plus że można o danym ustawieniu zwyczajnie zapomnieć jeśli zostanie usunięte nie zasyfiając tak kodu, albo jak np dodadzą żę teraz każdy mob może się starzeć? musiecie zmieniać hierarchie wszystkich klas, tworzą się duplikaty metod itd. A mając tylko jakieś property: mob.set(Age, child) zmieniacie tylko wewnętrzną implementacje by od teraz nie ignorowała tej wartości dla wybranych modów. 
Dodatkowo korzystając z kotlina możecie dodawać klasy z extension methods które ludzie mogą importować dowolnie jak chcą i mieć dostępną metode mob.setAge kiedy chcą - co ułatwia użycie API nie wiążąc niczego z implementacją. 
A itemy tylko na stringach to też problem, a zrobienie BlockType na enum to już najgorsze co mogliście zrobić, enum z materialami to rzecz na którą każdy developer bukkita marudzi i mówi że to był największy bład jaki kiedykolwiek zrobili, na plus że rozdzieliliście tam jednak subid i wszystko jest na "płasko". Bloki się zmieniają a niektóre silniki wspierają mody i pluginy.
Enumy powinny być do rzeczy niezmiennych, szczególnie projektując API. 
No i github jest lepszy do publicznych projektów bo ktoś go odwiedza A robienie tego closed source jest jeszcze bardziej bez sensu - no chyba że to tylko jakiś bład, ale wali 404.
 

Nie używaj mysql bezpośrednio w komendach w głównym wątku serwera, ktoś może spamować komendą i znacznie spowolnić serwer. Do tego nie sprawdzasz czy połączenie dalej jest "żywe" jak serwer długo nic nie będzie robił to połączenie może dostać timeouta i wszystkie kolejne operacja wywalą błędem. Do tego łapiesz sobie SQLException ale nic z nim nie robisz, ot wypisujesz do konosli, a gracz co wpisał komendę nie widzi żadnego outputu i nie wie co się dzieje. Tak samo powinno się uniknąć używnaia MySQL w dowolnych eventach, chyba ze są Async - ale wtedy i tak zazwyczaj lepiej unikać.
No i po co aż 100 znaków na nick czy ip?
 
Np by zrobić GUI możesz po wpisaniu komendu rozpoczać task Async i w nim pobrać wszystkie potrzebne dane z MYSQL i je przygotować, i wtedy odpalić kolejny task już sync i otworzyć te EQ z już gotowymi danymi. I tak z każdą komendą co używa jakiejś bazy danych.
 

wat? xD
BungeeCord to proxy do serwerów minecrafta i to jest osobna aplkacja i wtedy musisz napisać plugin pod bungeecorda - nie jest to żaden silnik.
I tak samo bukkit jest silnikiem i osobną aplikacją pod którą można pisać pluginy.
Nie możesz sobie tak losowo łączyć obu API...

Poczytaj też o hash setach no i nie robi się takich operacji w konstruktorach bo to zła praktyka, możesz zrobić statyczną metodę w tych utilsach co tworzy obiekt RawBlock i dodaje do listy, ale nie w jego konstruktorze.
Nie ma też sensu sperawdzać czy obiekt jest w kolekcji by go usunąć, bo usunięcie i tak musi to sprawdzić jeszcze raz.
A w metodzie debug możesz po prostu przeiterować po całej liście a potem za pętlą ją wyczyścić metodą .clear, nie musisz też wtedy liczyć amount tylko zwrócić rozmiar listy przed wyczyszczeniem.
 
Bo nie można edytować listy po której się iteruje (no to dodatkowe zabezpieczenie javy przed nieprawidłowym używaniem wątków itd, są kolekcje co to wspierają większym kosztem pamięciowym/wydajnościpwym)
+ można to robić w szczególnych przypadkach, np klasa Iterator ma metod removę oraz można iterować po indexach

Poczytaj też o hash setach no i nie robi się takich operacji w konstruktorach bo to zła praktyka, możesz zrobić statyczną metodę w tych utilsach co tworzy obiekt RawBlock i dodaje do listy, ale nie w jego konstruktorze.
Nie ma też sensu sperawdzać czy obiekt jest w kolekcji by go usunąć, bo usunięcie i tak musi to sprawdzić jeszcze raz.
A w metodzie debug możesz po prostu przeiterować po całej liście a potem za pętlą ją wyczyścić metodą .clear, nie musisz też wtedy liczyć amount tylko zwrócić rozmiar listy przed wyczyszczeniem.
 
Bo nie można edytować listy po której się iteruje (no to dodatkowe zabezpieczenie javy przed nieprawidłowym używaniem wątków itd, są kolekcje co to wspierają większym kosztem pamięciowym/wydajnościpwym)
+ można to robić w szczególnych przypadkach, np klasa Iterator ma metod removę oraz można iterować po indexach

zmień kolegów.
 
Tak to rozwiązanie podałem. Ale możesz też mu dać osobną wersję która zadziala tylko na jego serwerze z jego IP.

takie zabezpieczenia mają mały sens, tylko utrudniają życie klientowi bo musi mieć połączenie z twoim serwerem gdzie to jest sprawdzane a nie zawsze się chce by dany serwer miał wgl dostęp do świata zewnętrznego tylko wszystko leciało przez sieć wewnętrzną, albo zwyczajnie żaden serwer nie ma 100% uptime. A usunięcie takiego zabezpieczenia to i tak tylko chwila.
No a tak to te proste polegają na prostym ifie który np wysyła zapytanie po http czy dany klucz licencji jest poprawny i wtedy od strony twojego serwera możesz tez monitorować czy tych serwerów z jednym kluczem nie jest za dużo i w razie czego wyłączyć dany klucz.

takie zabezpieczenia mają mały sens, tylko utrudniają życie klientowi bo musi mieć połączenie z twoim serwerem gdzie to jest sprawdzane a nie zawsze się chce by dany serwer miał wgl dostęp do świata zewnętrznego tylko wszystko leciało przez sieć wewnętrzną, albo zwyczajnie żaden serwer nie ma 100% uptime. A usunięcie takiego zabezpieczenia to i tak tylko chwila.
No a tak to te proste polegają na prostym ifie który np wysyła zapytanie po http czy dany klucz licencji jest poprawny i wtedy od strony twojego serwera możesz tez monitorować czy tych serwerów z jednym kluczem nie jest za dużo i w razie czego wyłączyć dany klucz.

Pewnie event wywołuje się więcej niż raz, np ze względu na to jak minecraft obsługuje obie ręce 
Zarejestruj się lub zaloguj, aby zobaczyć ukrytą treść!
Musisz sprawdzić czy użył głównej ręki.
 
A tak to nie ładuj plików w takich eventach przy każdym kliknięciu... wszystkie takie dane powinieneś załadować na starcie pluginów do odpowiedniej struktury obiektów - inaczej każde kliknięcie będzie zatrzymywać serwer na czas odczytu pliku.

Pewnie event wywołuje się więcej niż raz, np ze względu na to jak minecraft obsługuje obie ręce 
Zarejestruj się lub zaloguj, aby zobaczyć ukrytą treść!
Musisz sprawdzić czy użył głównej ręki.
 
A tak to nie ładuj plików w takich eventach przy każdym kliknięciu... wszystkie takie dane powinieneś załadować na starcie pluginów do odpowiedniej struktury obiektów - inaczej każde kliknięcie będzie zatrzymywać serwer na czas odczytu pliku.

bo klasa listenera musi implementować Listener i trzeba zarejestrować listener

nie da się zwiększyć tego limitu, ale można go obejść tworząc Scoreboard i Team i wtedy można dodać do team gracza i ustawić w jego team 16 znakowy prefix i suffix. Co daje ci 16 znaków + nick + 16 znaków, a jak postarasz się bardziej to można wykorzystać całość 48 znaków

ale to z czym dokładnie masz problem? Ogólnie pomyśl o gamemode spectatora, ułatwi sprawę.
1. Masz metodę .setInvulnerable lub możesz to zrobić tak samo jak 2. - lub spectator i samo dziala
2.Przecież jest Event EntityDamageEvent i EntityDamageByEntityEvent możesz tam sobie anulować wszelkie obrażenia, zadane lub otrzymane - lub spectator i samo dziala
3. średnio na jeża idzie to w pełni zrobic bez zabaw z NMS itd, ale możesz zmienić mu gamemode na spectatora - wtedy też rozwiążesz masę innych problemów jak to o zadawaniu obrażeń 
A tak to możesz dać collidable na false -  i samo dziala
4. no jest event ItemPickupEvent - lub spectator i samo dziala
5. Nie ma punkty piątego.
6. Tutaj musisz ręcznie wykryć kliknięcie na skrzynkę Eventem PlayerInteractEvent i jeśli to otwieranie skrzynki to anulować i otworzyć własne inventory z taką samą zawartością co skrzynka  - lub spectator i samo dziala
7. BlockBreakEvent i anulujesz co chcesz - lub spectator i samo dziala

github też nie ma 100% uptime i czasem pada na kilka chwil lub nawet godzin.
Można też pisać dla normalnych klientów co normlanie płacą i kupują razem z source code i mieć wszystko w dupie.

ale pamiętaj że ominięcie takiej licencji to zawsze tylko chwila roboty... a dodatkowo utrudniasz używanie zwykłemu użytkownikowi co kupił ten plugin... bo nikt nie ma 100% uptime, VPS ci padnie i nagle nie mogą używać produktu który kupili.

ale pamiętaj że ominięcie takiej licencji to zawsze tylko chwila roboty... a dodatkowo utrudniasz używanie zwykłemu użytkownikowi co kupił ten plugin... bo nikt nie ma 100% uptime, VPS ci padnie i nagle nie mogą używać produktu który kupili.

testuj to na czystym mc, bo z tego błędu trudno coś zrozumieć bo pozmieniali nazwy klas.
Ale wygląda na to że prefix ma więcej niż 16 znaków - a taki jest limit w mc.

Użyj klasy random, najlepiej tej nowszej bo wygodniej:
ThreadLocalRandom random = ThreadLocalRandom.current(); int i = random.nextInt(origin, bound); tylko zerknij na dokumentacje by nie zrypać zakresu
 

Tego inaczej niż "xD" skomentować się nie da. No i brak mavena ;/
 
a co jak 2 EQ mają takie same nazwy? i można [ciachować ("pożyczać")]/bugować itemki z gui. Do tego memory leak bo dodajesz wszystkie stworzone inventory do mapki i nigdy nie usuwasz. No i ogólnie bieda w opcje bo nie idzie tworzyć GUI pod gracza - trzeba by tworzyć kompletnie od zera dla każdego gracza - a to tylko pogorszy sprawę z memory leakem.
A nuli w kodzie to się unika, a nie dodaje jeszcze więcej: 
public static List<InventoryAutomalizer> getList() { if (inventoryList.size() == 0) { return null; } return inventoryList; } no i masa innych zasad złamana oczywiście, brakuje też wykrycia zamknięcia EQ i ogólnie wszystkiego.

no nie podałeś typu generycznego callbacku, new TimerCallback<Player>() {....

oczywiście że nie.

Klasy nazywa się z dużej litery ;/
 
A tak to w kodzie masa problemów: np jak ktoś w konfiguracji użyje złej nazwy itemu to dostanie dość słaby nic nie mówiąc błąd, do tego wszędzie używasz list i ręcznie w pętli szukasz pasującego elementu - np gracza po nicku - od tego są HashMapy.
No i zacznij używać mavena, bo tak to co z tego ze jest github jak nikt nie może tego projektu ot-tak otworzyć bo musi ręcznie dodawać wszelkie biblioteki.
 
A tak to ciekawi mnie to:  (i tylko po to tu odpisuje... :D)
{ public static boolean isInteger(String string) { return Pattern.matches("-?[0-9]+", string.subSequence(0, string.length())); } Skąd to masz, widzę ten idiotyczny kod już nie wiem który raz i zawsze mnie zastanawia skąd to jest... Po co jest te subSequence?  A tak to lepiej mieć metodę: 
public static Integer asInt(String str) { try { return Integer.parseInt(str); } catch (NumberFormatException e) { return null; } } i wtedy jak zwraca null to wiadomo że to na pewno nie integer, a jak nie-null to można już używać. Bo tak to twoja metoda np uzna że 9839853290848753204394754309584854 to integer - a tak nie jest.