Od zera do Bukkit's plugin developera

Andret · 9 Sierpnia 2013

INFORMACJA DLA ADMINISTRACJI I MODERACJI:

Poradnik pomimo swojej leciwości, zawiera rzetelną i poprawną treść.

Jako autor poradnika, bardzo proszę o to, by nie ulegał on archiwizacji, ponieważ nigdy nie przestałem nad nim pracować.

Stan na dzień 14 kwietnia 2022 roku.

PORADNIK

Witam Cię serdecznie, drogi czytelniku, w moim poradniku o tym, jak rozpocząć swoją przygodę z pisaniem pluginów pod Bukkit/Spigot. Jestem świadom, że można znaleźć kilka innych poradników, jednak kiedy ja zaczynałem swoją podróż tą drogą, w każdym z pozostałych czegoś mi brakowało. Z tego powodu postanowiłem zadbać o to, żeby ten poradnik przedstawił najważniejsze aspekty tworzenia pluginów w sposób przystępny każdemu.

Na wstępie chciałbym zaznaczyć, że chcę Cię nauczyć nie „jakkolwiek”, a najlepiej, jak potrafię. Dlatego też na samym kodzie się nie skończy: pod koniec każdego tematu znajdziesz zadanie domowe, które sprawdzi, czy opanowałeś wiedzę w nim zawartą. Jego poprawność natomiast zweryfikuje życie, czynność opisana w zadaniu powinna po prostu działać poprawnie.

Temat #1: Środowisko pracy

Tak... to jest najżmudniejsza, najnudniejsza, i nic nowego do Twojej głowy nie wnosząca część. Niestety, musisz ją przeboleć, wybacz...

Na początek pobierz JDK czyli Java Runtime Environment (środowisko uruchomieniowe java) stąd oraz to potem zainstaluj. Ważne, żeby wersja javy była 1.7 bądź 1.8 (taka sama jak ta, gdzie działa serwer), bo to pod nie będzie kompilował program, a już o jeden wcześniejsza (1.6) powoduje błędy. Oczywiście wersję pod którą nasz plugin jest kompilowany można łatwo mzienić w ustawieniach projektu.

Dobra! Kiedy już zainstalowałeś środowisko pozostaje edytor z kompilatorem. Nie rozumiesz? Kompilator to taki tłumacz. Tłumaczy to co napisaliśmy na kod maszynowy, czyli działanie. Czyli skleja nasze znaczki w działanie pluginu. Już wiesz co pobierasz ^^ Ja będę tłumaczył pod program Eclipse, którego można poprać tutaj.

Potrzeba jeszcze działającego bukkita... Ale jak wiadomo są problemy... Polecam pobrać spigota. Pomimo niego klasy dalej są Bukkitowe i to nie wpływa na jakikolwiek kolejny element, nie martwić się!

Brawo! Możesz już pluginować!

Jeszcze mała wzmianka o czymś takim jak javadocs, czyli dokumentacja. Otóż ja nie pisałem bukkita, więc nie znam wszystkich klas (no bo któż poza twórcami zna?) a mimo to czasem trzeba z bardzo dziwnych klas skorzystać. Tutaj właśnie z pomocą przychodzą nam javadocs pod bukkit. To właśnie na tej stronie większość z nas szuka klas, ich użycia, metod, wszytkiego czego nie znamy a jest z bukkita. Jest to bardzo dobre rozwiązanie ze strony bukkita, jeśli nauczycie się z niego korzystać (a nie jest to wielka filozofia) nie będziecie pytali na prawo i lewo "A jak zrobić to?", "A jak użyć tego?", "A ile tu argumentów?", bo na te i wiele innych pytań odpowiedź znajdziecie właśnie tam. Sam korzystam i polecam też Wam.

Temat #2: Nowy projekt

No dobra! Czas na pierwsze uruchomienie programu! Cykorek? U mnie też... No ale trzeba... 3... 2... 1... Uruchomiony! W polu tekstowym podajemy ścieżkę do miejsca roboczego (z ang. Workspace) i teraz ta opcja. "Use this as the default and do not ask again" czyli "Używaj tego jako domyślnego i nie pytaj ponownie". Po co ta opcja? Jeśli jesteś początkującym, możesz ją zaznaczyć. To się przydaje kiedy aktywnie zmieniasz Workspace, co Tobie w przypadku nauki nie grozi. Oczywiście bezpośrednio z programu też można to zmieniać i to tak samo bezproblemowo, więc sam zdecyduj 🙂

Potem się ładuje i ku naszym oczom powstaje taki oto widok:

To w tym czymś będziemy pisali.

Wybierz File -> New -> Java Project. Project Name może być dowolny, ale dobrze, żeby był taki sam jak nazwa pluginu, który tworzysz. Nie jest to konieczne, ale pomoże w rozpoznaniu. Zatwierdzamy i już coś widzimy w Package Explorer. Rozwiń gałąź koło nowo utworzonego projektu (czarna strzałeczka), kliknij prawym na folder src i daj New -> Package, a jako nazwę wpisz swoją domenę internetową od tyłu dodając do tego nazwę pluginu, czyli jeżeli moja domena to www.andret.eu to nazwa paczki to eu.andret.testowy. Jednak wiem, że nie każdy domenę posiada, ale nie ma się co martwić. Wpisz po prostu swój adres e-mail również od końca. Gdybym użył swojego gmaila [email protected], wpisałbym com.gmail.andret2344.testowy. Czemu takie zamieszanie z nazwami? Po prostu tak się przyjęło w JAVIE, takie nazewnictwo nie jest niezbędne do życia, plugin zadziała, jak inaczej nazwiemy paczki, ale tak jest ładniej i czytelniej, bo jest to ogólnie przyjęta norma (zwana konwencją języka).
Następnie prawym na tę paczkę, New -> Class. To jest klasa, czyli to, w czym już będziemy pisali. Jej nazwa może być dowolna, ale musisz ją zapamiętać. Nazwy klas zwykle piszemy z wielkich liter. Najlepiej jednak klasę główną nazwać tak samo jak się nazywa plugin, czyli u mnie Testowy.

Definicja:
klasa główna - Jest to klasa, która ładuje inne klasy, oraz mówi serwerowi, co się ma dziać.

Po utworzeniu widzimy już w edytorze coś takiego:

To jest ukryta treść, proszę

Pisać już możemy, ale jeszcze jedno. Pamiętasz pobranego spigota? Daj go w bezpieczne, nieużywane miejsce. Następnie znowu kilknij prawym na src, ale tym razem wybierz Build Path -> Configure Build Path. Pojawi się nowe okno. Wybierz zakładkę Libraries. Tam przycisk Add External JARs. Po kliknięciu wskazujemy mu pobranego spigota i wszystko akceptujemy. GOTOWE! Żadnych więcej ustawień! Piszmy!

Temat #3: Pierwsza reakcja

No i dobra, kodzimy! Na początek wzmianka o klamrach "{" i "}". One są nazywane "słowami kluczowymi", a to co między nimi jest to podprogram czyli taki kod, który w nich się wykona, a poza nimi już się nie wykona w tym podprogramie, ewentualnie wykona się po nim. Nie rozumiesz? W przyszłości Ci wyjaśnię, teraz pamiętaj, że każdą otwarą "{" trzeba zamknąć "}", a każdy otwarty "(" trzeba zamknąć ")" oraz każdy otwarty "[" trzeba zamknąć "]". Jeżeli coś pokopiesz w tym, eclipse podkreśli i w sposób w miarę zrozumiały wyjaśni. Tyle. Kodzimy bo się do tego nigdy nie zabierzemy!

Mamy coś takiego:

To jest ukryta treść, proszę

Czyli wszystko, co jest między "{" i "}" należy do klasy Testowy. Na początek, kiedy piszę "W KLASIE" to na pewno musi to być w tych najbardziej zewnętrznych klamrach. Na początek po nazwie klasy dodajmy extends JavaPlugin. Teraz podkreśla "JavaPlugin" na czerwono. Więc najedź myszką i poczekaj, aż pojawi się okno z podpowiedziami i wybierz tam "import org.bukkit.plugin.java.JavaPlugin". Najczęściej wybieraj org.bukkit lub java.utils. Czyli mamy:

package eu.andret.testowy;

import org.bukkit.plugin.java.JavaPlugin;

To jest ukryta treść, proszę

Teraz w klasie Testowy dopiszmy 2 rzeczy:

To jest ukryta treść, proszę

(nie chcesz pamiętać? korzystaj z podpowiedzi - Ctrl + Spacja w pustym miejscu!)
Teraz kilka opisów...

Definicja:
public - Jest to jeden z typów widoczności składnika klasy, po prostu dajemy użytkownikowi "z zewnątrz" pełną władzę do tego co publiczne, a żeby je przed nieporządanym działaniem zamknąć używamy "private".

Definicja:
void - To oznacza, że metoda nic nie zwraca. Zwykle metoda zakończona jest instrukcją return x; gdzie x to wartość, którą metoda zwraca. metoda typu void tego nie wymaga, co wiecej, jak damy return x; w metodzie typu void, kompilator się zbuntuje, bo to błąd. Natomiast pusta instrukcja rturn; zadziała TYLKO w mtodzie typu void

Definicja
Metoda - No właśnie... ja tak mówię i mówię o tych metodach, a co to ta metoda? Metoda to zamknięty kawałek programu. Posiada typ, nazwę, opcjonalne argumenty no i ciało. Metody na początku ułatwiają czytelność kodu, a potem jak się przekazuje argumenty, skracają kod.

Metoda onEnable - jak nazwa mówi, tu są instrukcje, które się wykonają na uruchomienie pluginu, a analogicznie onDisable na jego wyłączenie. No to co? Niech się coś dzieje! Piszemy na konsole! W metodzie onEnable można wpisać, że nasz plugin jest załądowany korzystajac z zapisu

To jest ukryta treść, proszę

ale konsola, tak czy siak, nam to wywali, więc jeśli chcecie mnożyć byt, że 2 razy różnymi sposobami konsola wypisze, ze plugin załadowano, proszę bardzo. onDisable analogicznie, można, ale nie trzeba:

To jest ukryta treść, proszę

Chciałoby się zobaczyć co zrobi server z naszym pluginem, ale wywali błąd. Czemu? Nie ma pliku plugin.yml! Więc klikamy prawym na src -> New -> File, podajemy nazwę Z ROZSZERZENIEM "plugin.yml" i zakończ tworzenie. Otworzył się zewnętrznym edytorem? ZAMKNIJ! I przeciągnij go tu gdzie pisałeś metody, niech tam się otworzy. Narazie wpisz do niego to:

To jest ukryta treść, proszę

To i tak nie koniec...

Możnaby tu przetestować, ale napiszmy tą komendę, to nie dużo kodu. Więc... ją wykodźmy!

Po staremu, nowa klasa, nazwij jak chcesz, ja nazwę po prostu Komenda. Więc po nazwie klasy dodajmy implements CommandExecutor. CommandExecutor odkreśla na czerwono? Najedź myszką i napraw przez "import [...]". Podkresla nazwę klasy i nie ma "import [...]"? Spokojnie zaraz się naprawi samo ^^
moja klasa Komenda.java wygląda tak:

To jest ukryta treść, proszę

Dobra! to piszemy w klasie Komenda takie coś:

To jest ukryta treść, proszę

(ponownie, nie chcesz pamiętać? Podpowiedzi!)
O, popacz... błąd zniknął! Zmień false na true. Czemu? Jeżeli jest return false to wypisze to co napiszemy w plugin.yml jako usage. WTF is plugin.yml? Czytaj dalej.

Definicja:
boolean - Typ danej, typ logiczny, czyli posiada dwie wartości. True lub false, czyli prawda/fałsz. Analogicznie zajmuje najmniej miejsca w pamięci.

Dobra, sprawdźmy czy komenda sie zgadza. Więc dopiszmy przed return false;

To jest ukryta treść, proszę

Tłumaczymy... jeżeli komenda, znaczy jej nazwa, z pominięciem wielkości znaków jest równa tekstowi "komenda", to do osoby wykonującej komendę wyślij wiadomość "Wpisales komende! Zabije Cie za to!".

Dobra, już PRAWIE koniec! Uwierz mi! Wiem, że Cię męczę! Ale otwórz z powrotem plugin.yml, zrób linijkę przerwy i dopisz to:

To jest ukryta treść, proszę

czyli cały plugin.yml wygląda u mnie tak:

To jest ukryta treść, proszę

No i ostatnie... Bo plugin nie widzi jeszcze komendy, więc musimy ją zarejestrować w klasie głównej. Więc w metodzie onEnable wpisz:

To jest ukryta treść, proszę

!!UWAGA!!
PLUGIN.YML NIE MOŻE ZAWIERAĆ; TABULATORÓW! UŻYWAJ SPACJI!

Klasa główna:

To jest ukryta treść, proszę

klasa z komenda:

To jest ukryta treść, proszę

File -> Export..., wybierz JAR file (W "Global" lub jeżeli masz inną wersję Eclipse to w "Java"), dalej wybierz Twój projekt oraz ścieżkę, najlepiej wskazać od razu folder /plugins w folderze z serwerem. podaj nazwę pluginu, TAK, wielkość liter ma znaczenie! Finish i uruchom serwer!
Efekt:

a tu w grze:

Zadanie domowe:

Napisz nową komendę "siema", po wpisaniu której w konsoli pojawi się napis "On wpisał komendę" a Tobie wyświetli się "Po co to wpisujesz?"

Temat #4: Argumentujemy!

No dobra. Umiesz już napisać komendę, która wyświetli tekst. A co z tym co po komendzie? No właśnie... argumenty.

Definicja:
argument - To każdy ciąg tekstowy po komendzie rozdzielony od innego spacją.

Co to znaczy? Jeśli wpiszemy

/komenda jeden 2 3trzy 6 kilometr

to argumentami są kolejno ciągi: "jeden", "2", "3trzy", "6", "kilometr".

No dobra, ale jak dostać te argumenty w komendzie? One tam są, tylko z nich nie korzystałeś/-aś. Pamiętasz linijkę

To jest ukryta treść, proszę

? Wytłumaczę Ci to co jest w nawiasie. Otóż w Javie jak i w C/C++/C# i zapewne w paru innych językach zmienne tworzy się jako

TYP_ZMIENNEJ NAZWA_ZMIENNEJ

A to co do ku*wy nędzy oznacza? Już Ci mówię.

Definicja:
typ zmiennej - To jest coś co mówi zmiennej: "Hey, Ty, słuchaj, Ty przechowujesz takie i takie wartości!"

Lista najbardziej podstawowych typów z krótkim opisem tutaj:

boolean - Zmienna logiczna, czyli przechowuje tylko wartość true lub false. Zajmuje najmniej miejsca w pamięci.
int - najbardziej podstawowy typ, przechowuje liczby całkowite z zakresu -2 147 483 648 — +2 147 483 647. Nazwa typu pochodzi on słowa Integer.
short - pochodna int. Zachowuje sie tak samo tylko ma mniejszy zakres.
long - podobnie jak wyżej, tylko zakres jest większy.
float - liczba rzeczywista (z KROPKĄ dziesiętną) o precyzji 7 miejsc "po przecinku".
double - jak wyżej, ale precyzja jest większa (więcej liczb).
String - typ tekstowy. Pochodny od char, ale char sie nie używa. Jemu wartość podaje się poprzez "", co jest wykluczone w przypadku innych typów.
Jeszcze pozostaje sprawa czym się różni Float od float. Otóż pisane z wielkiej litery to klasy a z małej to typy. Czym się różni jedno od drugiego? To co z klasy to obiekt, który ma jakiś tam właściwości, to co storzone jako typ ma tą jedna wartość którą modyfikujemy. Co więcej obiekty mają większe możliwości czyli to co się pojawi jak damy "zmienna." na tej liście. Te kilka typów pisanych z małej litery to typy domyślne nie tylko chakakterystyczne dla jednego jezyka (w tym wypadku JAVY) ale też np. int czy float widać w C/C++ czy C#.

i jeszcze...

Definicja:
zmienna - To takie cuś w każdym programie co przechowuje wartość, którą można modyfikować i ją wykorzystywać.

skoro już jest zmienna to jeszcze dla równowagi...

Definicja:
stała - To jest z kolei coś podobnego do zmiennej, z tą różnicą, że można to jedynie odczytywać, nie można tego zmodyfikować po utworzeniu. Więc po co nam to? A np. jak piszemy w jakimś języku i mamy ścieżkę dostępu jako np. "D:/Dane/Tomek/pliki/prywatne/zdjecia" to łatwiej utorzyć niemodyfikowalną stałą

To jest ukryta treść, proszę

i potem z niej korzystać. UWAGA! Tylko w JAVIE stałe oznacza się słówkiem "final", normalnie jest to słowo "const".

Dobra, rozpisałem się, a Wy dalej nic nie wiecie... Już, już... wracając do linijki onCommand to tam widać coś jak String[]. Co to jest? To jest tablica.

Definicja:
tablica - Najprościej to taka zmienna, która przechowuje wiele danych jednego typu, w tym wypadku String.

Chcąc stworzyć tablicę standardowo to piszemy

TYP[] NAZWA = new TYP[iLOSC_MIEJSC]

to stworzy tablice jednowymiarową.
Więcej o tablicach:

Więc to co napisałem stworzy tablicę jednowymiarową. Realny przykład to

int[] tab1 = new int[10];

co stworzy jednowymiarową, 10-elementową tablicę "tab1" typu liczb integer. Jendowymiarową? Tak! Komputer może stworzyć tablice nawet 20-wymiarowe. W Javie jedno [] oznacza jeden wymiar. Czyli np. stwórzmy tablicę

String[][][][][] tabliczka = new String[5][6][7][8][9]

co stworzy pięciowymiarową tablicę "tabliczka" o wymiarach 5x6x7x8x9. Nasz mózg nie jest w stanie stworzyć graficznego obrazu tego, ale faktycznie ta tablica zawiera 15120 elementów.

No umiemy już stworzyć tablicę, może z niej skorzystamy? nic prostszego!

tabliczka[0][0]0][0][0] = 1;

czyli za pierwszy element tablicy podstawimy 1.

!!UWAGA!!
NIE MOŻNA SIĘ ODWOŁAĆ DO NIE ISTNIEJĄCEGO INDEKSU! WYWALI BŁĄD! (wiem, wiem, wyjątek. Nazwijmy go błędem na chwilę)

Czyli jak mamy tę tablicę tabliczka to NIE można się odwołać np.

tabliczka[5][0][0][0][0] = 1;

bo w pierwszych nawiasach kwadratowych przy deklaracji podaliśmy 5, a My, programiści jesteśmy dziwni, więc liczymy od 0, więc jest 0, 1, 2, 3, 4. To właśnie 4 jest piątym i ostatnim indeksem pierwszego wymiaru tablicy. Jeśli byśmy tak zrobili i nie wywali błędu edytor to po kompilacji będzie można się dopatrzyć błędu ArrayIndexOutOfBoudns. Dobrze, żebyście wiedzieli co oznacza.

Warto też wspomnieć, że można stworzyć tablicę z elementami bez określenia ich ilości. po prostu wpisujemy to w klamrach. tak np.

int[] tab = {0, 1, 2, 3, 4, 5, 6};

nie podałem ile miejsc a tablica jest poprawna. jednak to juz wypełnienie. Czy da się stworzyć pustą tablicę bez ustalonej liczby miejsc? Hm... a próbowaliście po prostu nie podawać ilości miejsc?
To nie próbujcie. To błąd, bo to dynamika. O tym kiedyś tam.

No dobra... może coś tak bardziej z pluginów! Więc wracając do linijki onCommand, tam w nawiasie jest String[] args. Tablica ta więc ma taki rozmiar ile podamy argumentów.

Czyli pisząc

/komenda a 3 b 6

to odpowiednio:
args[0]="a";
args[1]="3";
args[2]="b";
args[3]="6";

No to co? Piszemy własne tp? Do dzieła!
Co już mamy? Mamy to:

To jest ukryta treść, proszę

Dobra... usuńmy wiadomość do gracza. zamiast tego sprawdźmy może, czy osoba wykonująca komendę to gracz a nie konsola serwera. Więc dopiszmy to:

To jest ukryta treść, proszę

Oczywiście Player importujemy. Pierwsza linijka sprawdza czy sender, osoba wykonująca komendę to gracz, jeśli tak, to tworzy zmienną "player" typu Player (typ wzięty z bukkita, kórego na początku importowaliśmy), a jej wartość to sender zamieniony w Playera. else oznacza mniej więcej "Jeżeli nie, to...". Dobra, mamy już playera zamiast sendera. Teraz sprawdźmy czy gracz podał 3 argumenty. innymi słowy sprawdźmy czy tablica args[] zawiera 3 elementy. Czyli wszystko się dzieje kiedy sender jest Playerem czyli piszemy to przed linijką

} else {

A co piszemy? No Warunek!

To jest ukryta treść, proszę

Na razie tyle, za chwilę dopiszemy resztę. Czemu napisałem "=="? Bo tak się sparwdza warunek równości, niezależnie od tego gdzie jest, jeśli dam "=" to to jest instrukcja przypisania, czyli daje nowa wartość.
Więcej warunków:

== jest równe
>= większe lub równe
> większe
< mniejsze
<= mniejsze lub równe
!= różne od

Czyli wiemy, że użytkownik podał 3 argumenty. Czyli zróbmy teraz z nich wartości double, bo mogą być z przecinkiem. Więc odpowiednio:

To jest ukryta treść, proszę

Dobra, brakuje nam świata gdzie gracz jest, więc pobierzmy też świat przez:

To jest ukryta treść, proszę

Oczywiście import. Pozostaje nam jeszcze stworzyć lokalizację oraz przenieść naszego gracza na nią. Więc...

To jest ukryta treść, proszę

Zaimportuj Location ale z org.bukkit! Teraz wyeksportuj. Moja klasa wygląda tak:

To jest ukryta treść, proszę

A efekt:

i

Zadanie domowe:

Napisz nową komendę lub zmodyfikuj juz istniejącą tak, by po wpisaniu 6 argumentów gracz został przeniesiony na x o wartości trzeciego z nich, na y o wartości piątego z nich i na z o wartości drugiego z nich.

Temat #5: Łapiemy wyjątki!

A więc dobra. Ten temat ma dużo teorii a mało wniesie do wiedzy na temat pluginowania, ale powinieneś/powinnaś go przeczytać chociażby po to, żeby umieć wyłapywać wyjątki i im zaradzać. No ale tego... mówię o tych wyjątkach, a co to ten wyjątek?

Definicja:
Wyjatek - po prostu błąd, który zwraca serwer przy używaniu pluginu.

Dobry programista powinien pisać kod tak, żeby błędów (wyjatków) nie było, ale czasem konieczne jest wyłapanie takiego błędu, chociażby uniemożliwiając użytkownikowi niepoprawne użycie.

Za takie wyłapanie błędu odpowiada dyrektywa try - catch. No na polski: próbuj - złap. W kodzie:

try {
    //to probuj robić
} catch (NazwaWyjątku1 oznaczenie1) {
    //to jeśli wyjątek złapany
} catch (NazwaWyjątku2 oznaczenie2) {
    //to jeśli wyjątek złapany
}

Lista wyjątków które mnie się udało zaliczyć:

NullPointerException - Mamy obiekt o wartości null i go wykorzystujemy
ArrayIndexOutOfBounds - Opisany wyżej, odwołujemy się do nieistniejącego miejsca w tablicy
IndexOutOfBounds - Jak wyżej, tylko dotyczy List, nie tablic.
NumberFormatException - Oczekiwano liczby, otrzymano co innego
IOException - Błąd wejścia/wyjścia (In/Out) czyli odczytu danych
ClassNoDefFoundException - nie znalazł klasy a ja z niej korzystam (w przypadku np. literówki w pliku plugin.yml)

To co jest wyżej opisane zaliczyć można jako NazwaWyjątku, więc co to oznaczenie? To informacja dla programisty, może się zachować jak zmienna, czyli małe, duże litery, tylko nie zaczynająca się od cyfry i pozbawiona znaków specjalnych.

No dobra, może trochę praktyki! Mając naszą tepającą komendę liczymy na inteligencję użytkownika, że jako argument nie poda tekstu tylko liczbę. Ale może się zdarzyć wypadek, i przypadkowo poda tekst. Jeśli nic nie zmienimy w naszej klasie to w takim wypadku na konsoli pojawi nam się mniej więcej takie coś:

17:39:02 [iNFO] Andret issued server command: /komenda 400 100 400a
17:39:02 [sEVERE] null
17:39:02 [sEVERE] org.bukkit.command.CommandException: Unhandled exception executing command 'komenda' in plugin testowy v0.1
    at org.bukkit.command.PluginCommand.execute(PluginCommand.java:46)
    at org.bukkit.command.SimpleCommandMap.dispatch(SimpleCommandMap.java:191)
    at org.bukkit.craftbukkit.v1_6_R2.CraftServer.dispatchCommand(CraftServer.java:523)
    at net.minecraft.server.v1_6_R2.PlayerConnection.handleCommand(PlayerConnection.java:962)
    at net.minecraft.server.v1_6_R2.PlayerConnection.chat(PlayerConnection.java:880)
    at net.minecraft.server.v1_6_R2.PlayerConnection.a(PlayerConnection.java:837)
    at net.minecraft.server.v1_6_R2.Packet3Chat.handle(SourceFile:49)
    at net.minecraft.server.v1_6_R2.NetworkManager.b(NetworkManager.java:296)
    at net.minecraft.server.v1_6_R2.PlayerConnection.e(PlayerConnection.java:116)
    at net.minecraft.server.v1_6_R2.ServerConnection.b(SourceFile:37)
    at net.minecraft.server.v1_6_R2.DedicatedServerConnection.b(SourceFile:30)
    at net.minecraft.server.v1_6_R2.MinecraftServer.t(MinecraftServer.java:590)
    at net.minecraft.server.v1_6_R2.DedicatedServer.t(DedicatedServer.java:226)
    at net.minecraft.server.v1_6_R2.MinecraftServer.s(MinecraftServer.java:486)
    at net.minecraft.server.v1_6_R2.MinecraftServer.run(MinecraftServer.java:419)
    at net.minecraft.server.v1_6_R2.ThreadServerApplication.run(SourceFile:582)
Caused by: java.lang.NumberFormatException: For input string: "400a"
    at sun.misc.FloatingDecimal.readJavaFormatString(Unknown Source)
    at java.lang.Double.parseDouble(Unknown Source)
    at andret.testowy.Komenda.onCommand(Komenda.java:19)
    at org.bukkit.command.PluginCommand.execute(PluginCommand.java:44)
    ... 15 more

Po drodze jest taka linijka:

Caused by: java.lang.NumberFormatException: For input string: "400a"

Czyli błąd NumberFormatException! Mówiłęm o nim 😄

Trzeba więc go wyłapać i poinformować sendera, że coś jest źle. Więc wchodząc pod te wszystkie if'y mamy kod:

double x = Double.parseDouble(args[0]);
double y = Double.parseDouble(args[1]);
double z = Double.parseDouble(args[2]);
World w = player.getWorld();
double x = Double.parseDouble(args[0]);
Location location = new Location(w, x, y, z);
player.teleport(location);
sender.sendMessage("Tepam Cie na " + x + ", " + y + ", " + z + "!");

a ja jako args[2] podałem "400a" i się wysypał. Więc to wszystko musi SPRÓBOWAĆ zrobić, a jeśli mu się nie uda to wyłapuje wyjątek NumberFormatException. Więc to wygląda tak:

try {
    double x = Double.parseDouble(args[0]);
    double y = Double.parseDouble(args[1]);
    double z = Double.parseDouble(args[2]);
    World w = player.getWorld();
    Location location = new Location(w, x, y, z);
    player.teleport(location);
    sender.sendMessage("Tepam Cie na " + x + ", " + y + ", " + z + "!");
} catch (NumberFormatException e) {
    sender.sendMessage("Koles!" + ChatColor.RED + " Podales mi argument, ktory nie jest liczba! Pier*ole, nie tepam!");
}

ChatColor zmienia kolor tekstu, zaimportuj.

Efekt:

A konsola wolna od błędów!

Czemu napisałem NumberFormatException e? Skąd to e? bo mi tak wygodnie, Ty sobie wpisz "pupa", "nalesnik", "ziemnior87567", to też zadziała ^^

Temat #6: Kto co może i dlaczego nie?

Hm... zróbmy tak, że tylko osoba, która posiada permisje np. "testowy.komendy.komenda" może wywołać komendę /komenda. Więc... Hm... może niech plugin wcale nie pracuje, jak player nie ma permisji? sprawdźmy je więc zaraz po linijce:

Player player = (Player) sender;

No czyli co? WARUNEK! Czyli sprawdzenie wygląda tak:

if (player.hasPermission("permisja")) {
    // co jesli ma
} else {
    // co jesli nie ma
}

a nasz obecny kod to

package eu.andret.testowy;

import org.bukkit.ChatColor;
import org.bukkit.Location;
import org.bukkit.World;
import org.bukkit.command.Command;
import org.bukkit.command.CommandExecutor;
import org.bukkit.command.CommandSender;
import org.bukkit.entity.Player;

public class Komenda implements CommandExecutor {
    @Override
    public boolean onCommand(CommandSender sender, Command cmd, String label, String[] args) {
        if (cmd.getName().equalsIgnoreCase("komenda")) {
            if (sender instanceof Player) {
                Player player = (Player) sender;
                if (args.length == 3) {
                    try {
                        double x = Double.parseDouble(args[0]);
                        double y = Double.parseDouble(args[1]);
                        double z = Double.parseDouble(args[2]);
                        World w = player.getWorld();
                        Location location = new Location(w, x, y, z);
                        player.teleport(location);
                        sender.sendMessage("Tepam Cie na " + x + ", " + y + ", " + z + "!");
                    } catch (NumberFormatException e) {
                        sender.sendMessage("Koles!" + ChatColor.RED + " Podales mi argument, ktory nie jest liczba! Pier*ole, nie tepam!");
                    }
                } else {
                    sender.sendMessage("Za malo argumentow, podaj /komenda [x] [y] [z]");
                }
            } else {
                sender.sendMessage("Wybacz konsolo, ale ta komenda jest dla gracza!");
            }
            return true;
        }
        return false;
    }
}

a po zmainie, po wprowadzeniu sparwdzenia permisji wygląda tak:

package eu.andret.testowy;

import org.bukkit.ChatColor;
import org.bukkit.Location;
import org.bukkit.World;
import org.bukkit.command.Command;
import org.bukkit.command.CommandExecutor;
import org.bukkit.command.CommandSender;
import org.bukkit.entity.Player;

public class Komenda implements CommandExecutor {
    @Override
    public boolean onCommand(CommandSender sender, Command cmd, String label, String[] args) {
        if (cmd.getName().equalsIgnoreCase("komenda")) {
            if (sender instanceof Player) {
                Player player = (Player) sender;
                if (player.hasPermission("testowy.komendy.komenda")) {
                    if (args.length == 3) {
                        try {
                            double x = Double.parseDouble(args[0]);
                            double y = Double.parseDouble(args[1]);
                            double z = Double.parseDouble(args[2]);
                            World w = player.getWorld();
                            Location location = new Location(w, x, y, z);
                            player.teleport(location);
                            sender.sendMessage("Tepam Cie na " + x + ", " + y + ", " + z + "!");
                        } catch (NumberFormatException e) {
                            sender.sendMessage("Koles!" + ChatColor.RED + " Podales mi argument, ktory nie jest liczba! Pier*ole, nie tepam!");
                        }
                    } else {
                        sender.sendMessage("Za malo argumentow, podaj /komenda [x] [y] [z]");
                    }
                } else {
                    sender.sendMessage("Stary! Lamiesz prawo! Podam Cie!");
                }
            } else {
                sender.sendMessage("Wybacz konsolo, ale ta komenda jest dla gracza!");
            }
            return true;
        }
        return false;
    }
}

no tak. to już! Efektu Wam chyba nie trzeba pokazywać, każdy wie co sięstanie 😛

A teraz wróćmy do dawno nieużywanego plugin.yml. Więc otwórzmy go poprzez przeciągnięcie go na środek. Pamiętamy co tam jest, mniej więcej to:

name: testowy
main: eu.andret.testowy.Testowy
version: 0.1
author: Andret

commands:
  komenda:
    description: Opis
    usage: /<command>

Znowu zróbmy linijkę odstępu i dopiszmy:

permissions:
  testowy.*:
    children:
      testowy.komendy.*:
        children:
          testowy.komendy.komenda: true

czyli dziedziczenie. pod testowy.* kryje się testowy.komendy.* a pod tym z kolei testowy.komendy.komenda. Idę o stówę, że PEXa znacie, to chyba wam tego nie muszę szczegółowiej wyjaśniać 🙂 dobra, Export i cieszcie się permisjami ^^

Zadanie domowe:

Napisz nową prostą komendę i zrób pięciopoziomowe permisje, czyli
jeden.*
jeden.dwa.*
jeden.dwa.trzy.*
jeden.dwa.trzy.cztery.*
jeden.dwa.trzy.cztery.piec

Temat #7: Nasłuchujemy serwera

No więc nasłuchujemy wydarzeń na serwerze. Do tego posłuży nam listener (z ang. nasłuchiwacz)

Definicja
Listener - Jest to coś takiego, co cały czas kiedy serwer działa obserwuje go i sprawdza czy jakieś wydarzenie nie nastąpiło.

Do tego potrzebna jest nam nowa klasa, ja nazwę swoją HealthRegen (bo to będzie robiła). Teraz jak w przypadku klasy z komendą pisaliśmy

implements CommandExecutor

tak tutaj zamiast tego dopiszemy

implements Listener

Oczywiście Import. Listenery nie są typu boolean jak komendy tylko typu void. Ogólnie listenery wyglądają tak:

public void nazwaListenera(wydarzenie nazwa) {
    //co sie dzieje kiedy listener dziala
}

więc ja skorzystam z listenera onEntityDeath, czyli no... co się wydarzy na śmierć entity (entity to zarówno mob jak i player). Więc ja dopisuję w klasie:

@EventHandler
public void onEntityDeath(EntityDeathEvent event) {
}

dobra, teraz całe wydarzenie jest pod nazwą event. Weźmy sobie, że killerem jest player, a zabijanym mob, czyli piszemy tak:

LivingEntity entity = event.getEntity();
Player player = entity.getKiller();

czyli... entity - umierajacy, killer - zabójca. No to sprawdzamy, czy entity jest Monsterem, a nie Animalem lub Playerem. więc:

if (entity instanceof Monster) {
}

Teraz po prostu dodajmy killerowi 2 hp (1 serduszko). Czyli z killera robimy playera, bierzemy jego hp, 2 razy inkrementujemy i mu ustawiamy. A w praktyce

int hp = player.getHealth() + 2;
player.setHealth(hp);

I już działa. Ale można to skrócić do jednej linijki w ten sposób:

player.setHealth(player.getHealth() + 2);

to dokłanie to samo. Pozostaje jeszcze jak w przypadku komendy zarejestrować to w klasie głównej. Listenery nie wymagają żadnego executora, więc wystarczy w metodzie onEnable() dopisać taką linijkę:

getServer().getPluginManager().registerEvents(new NazwaKlasy(), this);

czyli w moim wypadku:

getServer().getPluginManager().registerEvents(new HealthRegen(), this);

I jeszcze na koniec macie moją pełną klasę HealthRegen, jakbyście się gdzieś zgubili:

package eu.andret.testowy;

import org.bukkit.entity.LivingEntity;
import org.bukkit.entity.Monster;
import org.bukkit.entity.Player;
import org.bukkit.event.EventHandler;
import org.bukkit.event.Listener;
import org.bukkit.event.entity.EntityDeathEvent;

public class HealthRegen implements Listener {
    @EventHandler
    public void onEntityDeath(EntityDeathEvent event) {
        LivingEntity entity = event.getEntity();
        LivingEntity killer = entity.getKiller();
        if (entity instanceof Monster) {
            Player player = (Player) killer;
            player.setHealth(player.getHealth() + 2);
        }
    }
}

Do dzieła!

Zadanie domowe:

Stwórz nową klasę z wydarzeniem onPlayerJoin(PlayerJoinEvent event) (dołączenie gracza do serwera), żeby za każdym razem regenerowało mu 3 hp (1,5 serduszka).

Temat #8: Alternatywa dla wielowarunkowego if'a i METODY!

No dobra, a co jeśli w zależności od zabitego moba chcemy dać różną ilość hp? Więc po kolei...

najpierw zamknijmy dodawanie hp w metodzie. Czyli zaraz nad ostatnią zamykającą klamrą w klasie napiszmy

public void healPlayer() {
}

i z góry przenieśmy linijkę

player.setHealth(player.getHealth() + 2);

wprost do tej metody. Podkreśliło playera, nie? To normalne, oczywiste, że player w tej metodzie nie istnieje... Nie nie tworzymy go. W końcu się dowiesz po co są nawiasy () przy nazwie funckji. Przy tej metodzie w tych nawiasach wpisz np. Player pl. to stworzy coś co nazywa się zmienną lokalną, ale nietypową, potem się dowiesz po co. Teraz każdego podkreślonego playera zamień na to pl (to pl może byc inne w zależności od tego co sobie sam(a) napiszesz ). Czyli zamiast tego co było powinniście mieć

public void healPlayer(Player pl) {
    pl.setHealth(pl.getHealth() + 2);
}

No ale nie zbyt fajnie, bo to zawsze da to 2 hp, a ja chcę móc to modyfikować. Więc po pl dajemy przecinek i "int hp;" (no zmienna typu int) i to ją, a nie 2 dodajemy. I może poinformujmy gracza ile odstał hp. Czyli dopisujemy co trzeba i mamy

public void healPlayer(Player pl, int hp) {
    pl.sendMessage("Dostajesz " + hp + " hp!");
    pl.setHealth(pl.getHealth() + hp);
}

Emmm... po kilku testach sprawdziłem, że graczowi nie można dać wiecej niż 20hp, bo pojawia się błąd IllegalArgumentException, więc sobie to wyłap, znaczy całe ciało metody daj do try{ }, alternatywnie dajmy mu pełne HP, no bo 18+4 = 20, nie? Czyli mamy gotową metodę

public void healPlayer(Player pl, int hp) {
    try {
        pl.sendMessage("Dostajesz " + hp + " hp!");
        pl.setHealth(pl.getHealth() + hp);
    } catch (IllegalArgumentException e) {
        pl.setHealth(20);
    }
}

Jakbyśmy teraz skompilowali, to nic się nie stanie, bo metoda jest nie wywoływana. Czyli stamtąd gdzie usunęliśmy dodawanie hp wpiszemy po prostu

healPlayer(player, 2)

To co jest w nawiasie to parametry. To co podajemy w nawiasie przy wywołaniu funkcji na czas jej wykonania jest zamienione na to co podaliśmy przy jej tworzeniu. No dobra, myślę, że metody pomocnicze umiesz stworzyć, teraz co z tym if'em? Jest takie coś jak switch() { }. Ale po kolei, powiedzmy, że za zabicie Creepera chcę 2hp a za zabicie Kostka chcę 3hp, za resztę nic. Czyli możemy napisać najpierw

EntityType type = entity.getType();

Dzięki temu w zmiennej type mamy typ zabitego entity. Teraz normalnie napisalibyśmy

if (type.equals(EntityType.CREEPER)) {
    healPlayer(player, 2);
} else if (type.equals(EntityType.SKELETON)) {
    healPlayer(player, 3);
}

Ale to jest nieładne bardzo. zastąpmy takiego if'a instrukcją switch. Jej składnia to:

switch (x) {
    wartość1: działania;
    wartość2: działania;
    ...
}

Tak więc my piszemy

switch (type) {
    case CREEPER: healPlayer(player, 2);
    case SKELETON: healPlayer(player, 3);
}

Lepiej nie? Dobra, eksportujemy, zabijamy creepera i... widzimy takie coś:

Zostawiłem dla pewności wyświetlona nazwę. Czemu dodało i za creepera i za kostka? Bo tak działa switch. Od danego miejsca wykona WSZYSTKO w dół do napotkania instrukcji break; lub wyjscia ze switch'a. Napiszmy ją więc po każdej opcji w switch. Efekt w kodzie:

switch (nazwa) {
    case CREEPER:
        healPlayer(player, 2);
        break;
    case SKELETON:
        healPlayer(player, 3);
        break;
}

Teraz działa jak powinno, jakby się ktoś zgubił pełna klasa:

package eu.andret.testowy;

import org.bukkit.entity.LivingEntity;
import org.bukkit.entity.Monster;
import org.bukkit.entity.Player;
import org.bukkit.event.EventHandler;
import org.bukkit.event.Listener;
import org.bukkit.event.entity.EntityDeathEvent;
public class HealthRegen implements Listener {
    @EventHandler
    public void onEntityDeath(EntityDeathEvent event) {
        LivingEntity entity = event.getEntity();
        Player killer = entity.getKiller();
        if (entity instanceof Monster) {
            EntityType type = entity.getType();
            switch (type) {
                case CREEPER:
                    healPlayer(player, 2);
                    break;
                case SKELETON:
                    healPlayer(player, 3);
                    break;
            }
        }
    }

    public void healPlayer(Player pl, int hp) {
        try {
            pl.sendMessage("Dostajesz " + hp + " hp!");
            pl.setHealth(pl.getHealth() + hp);
        } catch (IllegalArgumentException e) {
            pl.setHealth(20);
        }
    }
}

Zadanie domowe:

Tak przebuduj kod, by był on jak najkrótszy, czyli nie dawaj fukcji tam gdzie to jest zbędne, aby za zabicie:
Pająka dostawał 4hp
Zombie dostawał 4hp
Endermana dostawał 3hp
Slime'a dostawał dostawał 2hp
Magma Cube'a dostawał 3hp

Temat #9: Zmieniamy to co widać (i to, czego nie też!)

No dobra, mamy już nagrodę w postaci hp za zabicie moba ale może... powiedzmy, że jak zabijemy moba to w miejscu jego śmierci pojawi się ruda diaxu!

Więc musimy pobrać lokalizację śmierci 🙂 u nas zabitym jest "entity" więc np. pod switchem dajmy to

Location location = entity.getLocation();

Location importujemy z org.bukkit!
ok, mamy lokalizację i co teraz? Trzeba pobrać blok z tej lokalizacji, więc pod tą linijką napiszmy to pobranie bloku!

Block block = location.getBlock();

sam być się nie domyślił nie? 😄
No i teraz zmieniamy ID tegoż bloku. Niestety Mojangowi znudizły się ID i od 1.7 są deprecjonowane, dlatego w moim poradniku już poradzimy sobie bez nich. Oczywście możesz eksperymentować, ale wyskakują setki warningów. Aby zmienić blok używamy

block.setType(X);

gdzie X to Material.NAZWA_BLOKU (itemu też, ale to wtedy musi być item, to nie na teraz). Ehh... No tak, nic nie rozumiesz... Popacz na kod:

block.setType(Material.DIAMOND_ORE);

Już rozumiesz? Wiedziałem!

To tyle... Chyba...
Jednak zanim skompilujemy i sprawdzimy... Pobawmy się jeszcze ekwipunkiem 🙂
Dobra, więc stwórzmy zmienną ekwipunkową równą ekwipunkowi zabijającego.
Czyli? no właśnie, czyli:

Inventory inv = player.getInventory();

Czemu player a nie killer?
Killer to jeszcze Entity, player to już Player, wyżej była linijka zamieniająca killera ("entity") na playera ("player") która wyglądała tak:

Player player = (Player) killer;

Dobra, mamy już ekwipunek gracza. Teraz stwórzmy ItemStacka
Co to ItemStack? Nazwa mówi, zetaw itemów. ItemStackiem jest np. patyk, 10 desek, 64 bloki złota 🙂
Mój itemstack będzie zawierał 3 szmaragdy:

ItemStack is = new ItemStack(Material.EMERALD, 3);

No i dobra... Mamy sobie ekwipunek gracza, mamy itemstacka... Co dalej? Hm... Do ekwipunku trzeba dodać ItemStacka... Hm... "inv.addItem(is);"? Działa! CUD! xD No i już! TEST! I co? Działa? DZIAŁA! Trudne? NIE!
Tutaj macie moją klasę:

package eu.andret.testowy;

import org.bukkit.Location;
import org.bukkit.Material;
import org.bukkit.block.Block;
import org.bukkit.entity.LivingEntity;
import org.bukkit.entity.Monster;
import org.bukkit.entity.Player;
import org.bukkit.event.EventHandler;
import org.bukkit.event.Listener;
import org.bukkit.event.entity.EntityDeathEvent;
import org.bukkit.inventory.Inventory;
import org.bukkit.inventory.ItemStack;

public class HealthRegen implements Listener {
    @EventHandler
    public void onEntityDeath(EntityDeathEvent event) {
        LivingEntity entity = event.getEntity();
        Player killer = entity.getKiller();
        if (entity instanceof Monster) {
            Player player = (Player) killer;
            EntityType type = entity.getType();
            switch (type) {
                case CREEPER:
                    healPlayer(player, 2);
                    break;
                case SKELETON:
                    healPlayer(player, 3);
                    break;
            }
            Location location = entity.getLocation();
            Block block = location.getBlock();
            block.setType(Material.DIAMOND_ORE);
            Inventory inv = player.getInventory();
            ItemStack is = new ItemStack(Material.EMERALD, 3);
            inv.addItem(is);
        }
    }

    public void healPlayer(Player pl, int hp) {
        try {
            pl.sendMessage("Dostajesz " + hp + " hp!");
            pl.setHealth(pl.getHealth() + hp);
        } catch (IllegalArgumentException e) {
            pl.setHealth(20);
        }
    }
}

Niestety mamy sporo kodu w

Location location = entity.getLocation();
Block block = Location.getBlock();
block.setType(Material.DIAMOND_ORE);
Inventory inv = player.getInventory();
ItemStack is = new ItemStack(Material.EMERALD, 3);
inv.addItem(is);

Może więc to skróćmy. Najpierw pierwsze dwie linijki... Mamy:

Location location = entity.getLocation();
Block block = location.getBlock();

co zamieniamy na krószy zapis:

Block block = entity.getLocation().getBlock();

Następnie mamy takie linijki:

Block block = entity.getLocation().getBlock();
block.setType(Material.DIAMOND_ORE);

To z kolei zamienimy na

entity.getLocation().getBlock().setType(Material.DIAMOND_ORE);

Tym sposobem mamy mniej kodu ^^ Ekwipunek i ItemStack tak samo i mamy:

entity.getLocation().getBlock().setType(Material.DIAMOND_ORE);
player.getInventory().addItem(new ItemStack(Material.EMERALD, 3));

Prościej ^^
Zadanie domowe:

Tak przebuduj klasę by:

- Szkielet pojawiał rudę węgla i dodawał 3 kości do ekwipunku

- Magma Cube pojawiał lawę i dodawałdo ekwipunku wiaderko z wodą

- Slime pojawiał Slime block i dawał 3 Slimeball'e

- Zombie pojawiał blok ziemii i dodawałdo ekwipunku 3 bloki trawy

Temat #10: Stary "nowy" item?

UWAGA! Ten temat jest aktualny jedynie dla wersji serwera 1.11.2 i wcześniejszych! Jeśli chcesz pisać dla wersji 1.12 i wyzej, omiń ten temat i poczekaj na jego aktualizację!

No dobra, dotychczas wykorzystywaliśmy to co już jest. Nie, nie stworzę tego co nie ma, to nie Forge, ale zmodyfikujemy to co jest i bedzie to czego nie ma (F**K LOGIC). Mniejsza, że nie wiesz o co chodzi, chodzi mi o nowe właściwości istniejących itemów. Ja sobie stworzę diaxową zbroję, ale nową!

Tak więc w metodzie onEnable(); (oczywiście można w dowolnej innej w całym pluginie, po komendzie, na listenera, kiedy chcecie) stworzymy nowego ItemStack'a

ItemStack is = new ItemStack(Material.DIAMOND_CHESTPLATE);

Teraz mamy zwykłą diamentową klatę. Dobra, dostańmy się głębiej, do MetaDaty tego itemu! Czyli:

ItemMeta im = is.getItemMeta();

Ok, teraz w zmiennej "im" mamy wszystkie dane o tej klacie. Zmieńmy co trzeba. Najpierw nazwa:

im.setDisplayName("§5Healing diamond chestplate");

Użyłem tutaj znaczku '§', on zastępuje jakby '&' jeżeli codzi o kolory, bo to '§' rozpoznaje Bukkit (znaczek '&' [czyli AMPERSAND] jest zastępowany przez np. Essentials na '§' [czyli PARAGRAF]). Ok, teraz dodajmy opis przedmiotu.

im.setLore(Arrays.asList("Makes heal", "from damage!"));

Występuje tu jakieś dziwne "Arrays.asList", co to jest? Metoda "setLore" wymaga Listy, My w biegu możemy stworzyć tylko tablicę, więc musimy zamienić tak stworzoną tablicę na listę. Oczywiście można by na zewnątrz stworzyć listę, do niej dodać co trzeba i wstawić bez zamiany przez "Arrays", ale to zrobimy później. Jeden ze stringów oddzielonych przecinkami to jedna linijka, może ich być wiele. I na koniec każemy mu zapamiętać to co zapisaliśmy dla naszego ItemStacka, czyli:

is.setItemMeta(im);

Dobra, nowy itemek, teraz musi się go dać stworzyć, ja użyję ShapedRecipe, czyli craftingu, gdzie ułożenie itemów ma znaczenie. To co napiszę to będzie zwykła diamentowa klata w środku i dookoła po sztabce złota. Najpierw tworzymy pustą recepturę:

ShapedRecipe hrecipe = new ShapedRecipe(is);

Teraz plugin ma powiedziane, że jakas tam receptura itemu pod nazwą "is" będzie, ale nie ma podanych konkretów. Więc mu je podajmy. Najpierw kształt:

hrecipe.shape("@@@", "@#@", "@@@");

Tutaj każdy jeden string odpowiada jednej linijce. Może się składać z maksymalnie 3 znaków, są zawsze w kolejności od lewej do prawej. Można to zapisać jako
@@@
@#@
@@@
Tu coś widać, prawda? Na szczęście dla pluginu nie ma znaczenia czy zapiszemy

hrecipe.shape("@@@", "@#@", "@@@");

czy raczej

hrecipe.shape("@@@","@#@","@@@");

byleby były przecinki, cudzysłownia, nawiasy, wszystko musi być, wtedy jest ok. Teraz dajmy mu lekcje jaki znak (ZNAK czyli zmienna typu char, którą podaje się w ' ' a nie jak stringa w " ") odpowiada jakiemu itemowi z Minecrafta. Czyli takie linijki:

hrecipe.setIngredient('@', Material.GOLD_INGOT);
hrecipe.setIngredient('#', Material.DIAMOND_CHESTPLATE);

Czyli to o czym mówiłem, serwer wie, że w mojej recepturze @ oznacza sztabkę złota a # oznacza diamentową klatę. I na końcu wepchnijmy tę recepturę do serwera.

Bukkit.getServer().addRecipe(hrecipe);

I już. Jest gotowa receptura. Mała wzmianka teraz o ShapelessRecipe, czyli recepturze, w której ukłąd nie ma znaczenia a liczą się jedynie itemy. Kod jest bardzo podobny, wygląda tak:

ShapelessRecipe hrecipe = new ShapelessRecipe(is);
hrecipe.addIngredient(Material.GOLD_INGOT, 8);
hrecipe.addIngredient(Material.DIAMOND_CHESTPLATE, 1);
Bukkit.getServer().addRecipe(hrecipe);

Jednak jest to zdeprecjonowane. Ja zostanę przy mojej ShapedRecipe.
Teraz stwórz nową klasę, ja swoją nazwę ChestplateEffect. Dodaj jej "implements Listener". Teraz jakiś event, czyli np.

public void attack(EntityDamageByEntityEvent e) {
}

Pytanie, czemu napisałem "attac" a nie np. "onEntityDamageByEntity"? Bo mogę. Ta nazwa jest dla nas, tak na wszelki wypadek, gdybyśmy musieli wywołać tą metodę ręcznie a nie listenerem. Wpisz sobie "lubiePlackiATy" i też zadziała. I drugie pytanie, czemu "e" a nie"event"? to samo. Bo mogę, to moja zmienna i ja decyduję jak ja nazwać, a, ze jestem leniwy... Używam stosunkowo krótkich nazw, żeby się nie męczyć.
Dobra, rozgadałem się, teraz pobieramy z eventu osobę otrzymującą i zadającą dmg.

Entity en = e.getEntity(); //odnoszący obrażenia
Entity dm = e.getDamager(); //zadający obrażenia

Dobra, teraz mój listener wywoła sie tylko kiedy zarówno "en" jak i "dm" to playerzy. Jeżeli chcesz, żeby np. zbroja chroniłą nie tylko przed graczami ale też przed mobami to sprawdź czy "dm" to LivingEntity, a nie - jak ja sprawdzę - Player. U mnie to wyglada tak:

if (en instanceof Player && dm instanceof Player ){
}

A skoro juz na tym etapie wiemy, że "en" to player to go zamieńmy siłą w playera.

Player player = (Player) en;

Teraz na chwilę wróćmy do klasy głównej. Przede wszystkim zarejestrujmy w onEnable(); naszego dopiero co utworzonego listenera (błędu z niedziałaaniem szukałem 1h, prze tą głupią linijkę!)

getServer().getPluginManager().registerEvents(new ChestplateEffect(), this);

Teraz tam mamy co prawda naszego ItemStacka, ale tak cholernie lokalnego, że bardziej się już nie da. A klasa ChestplateEffect musi mieć do niego dostęp. Więc nad "@Override" wyrzucamy stworzenie ItemStacka:

ItemStack is;

a w onEnable(); linijka ze stworzeniem ItemStacka zmienia się w

is = new ItemStack(Material.DIAMOND_CHESTPLATE);

Teraz na samym dole, ale przed ostatnią klamrą zamykającą sworzymy metodę. Publiczną. Statyczną. Typu ItemStack. O nazwie "getItem". Czyli:

public static ItemStack getItem() {
}

Teraz używajac jej ona ma nam zawsze zwrócić naszego "is" czyli w niej piszmy "return is;", ma wyglądać tak:

public static ItemStack getItem() {
    return is;
}

A teraz wracajac do tworzenia ItemStacka na samą góre zróbmy go prywatnym. No i statycznym.

private static ItemStack is;

Teraz moja klasa główna wygląda tak:

package eu.andret.testowy;

import java.util.Arrays;
import org.bukkit.Bukkit;
import org.bukkit.Material;
import org.bukkit.inventory.ItemStack;
import org.bukkit.inventory.ShapedRecipe;
import org.bukkit.inventory.meta.ItemMeta;
import org.bukkit.plugin.java.JavaPlugin;

public class Testowy extends JavaPlugin {
    private static ItemStack is;

    @Override
    public void onEnable() {
        getCommand("komenda").setExecutor(new Komenda());
        getServer().getPluginManager().registerEvents(new HealthRegen(), this);
        getServer().getPluginManager().registerEvents(new ChestplateEffect(), this);
        is = new ItemStack(Material.DIAMOND_CHESTPLATE);
        ItemMeta im = is.getItemMeta();
        im.setDisplayName("§5Healing diamond chestplate");
        im.setLore(Arrays.asList("Makes heal", "from damage!"));
        is.setItemMeta(im);
        ShapedRecipe hrecipe = new ShapedRecipe(is);
        hrecipe.shape("@@@", "@#@", "@@@");
        hrecipe.setIngredient('@', Material.GOLD_INGOT);
        hrecipe.setIngredient('#', Material.DIAMOND_CHESTPLATE);
        Bukkit.getServer().addRecipe(hrecipe);
    }

    public static ItemStack getItem() {
        return is;
    }
}

Dobra, teraz wracamy do ChestplateEffect i tam zostaniemy do końca. Tworzymy 2 ItemStacki. Jeden to to co nasz atakowany ma na sobie, a drugie to to co stworzyliśmy w klasie głównej. Czyli:

ItemStack in = player.getInventory().getChestplate();
ItemStack is = Testowy.getItem();

Jak widać druga z tych linijek używa metody, którą napisaliśmy. Czemu tak lepiej, niż tak jak było i dostać się przez "Testowy.is"? Bo wówczas mamy pełne prawo do modyfikacji, czyli również możemy to nieumyślnie zepsuć. W ten sposób ten tam stworzony ItemStack jest dla tej klasy tylko do odczytu, wiemy co tam jest, ale nie możemy tego zmienić, czyli jest bezpieczne. Jeżeli wiemy co robimy nie jest to konieczne, ale np. taki bukkit tak ma sporo rzeczy, to są właśnie tzw. gettery i settery. Getter otrzymuje dane, setter je ustawia, ale ustawia tylko te, które mu wolno. Nie dostaje obiektu do ręki, bo mógłby go zepsuć.
Jak ja lubię się rozpisywać, dobra, dalej. Sprawdzimy teraz czy wyświetlane nazwy są takie same, jeśli tak - wykonujemy zdarzenie. Jednak to jest słabe zabezpieczenie, bo ktoś sobie stworzy skórzaną klatę z taką nazwą przez kowadło i też zadziała więc w tym ifie powinno być sporo znaczków "&&" oznaczających logiczne "AND" i po kolei sprawdzać czy nazwa, opis (Lore) oraz material są takie same, wówczas się tego nie da podrobić, bo gracz z poziomu gry nie podrobi wszystkiego naraz. U mnie to wygląda tak:

if (in.getItemMeta().getDisplayName().equals(is.getItemMeta().getDisplayName())) {
}

(drobna uwaga, if nie moze byc odwrotnie!) Ale jeżeli chcecie pełne zabezpieczenie o którym mówię to powinno wygladać tak:

if (in.getItemMeta().getDisplayName().equals(is.getItemMeta().getDisplayName())
        && in.getItemMeta().getLore().equals(is.getItemMeta().getLore()) &&in.getType().equals(is.getType())) {
}

Zabezpieczenie gwarantowane. Teraz kiedy wiemy, że nasz atakowany ma na sobie naszą zbroję wszystko się dzieje. Ja ustawię, że ta zbroja dodaje 2x mniej hp niż gracz powinien dostać dmg. Najpierw tworzę zmienna zawierajacą ilość dmg, podzieloną na 2, by potem się nie mylić, czyli:

double dmg = e.getDamage()/2;

Teraz anulujemy zdarzenie, by nie dostał realnego dmg

e.setCancelled(true);

Oraz dodajemy mu to hp jak w przypadku klasy HealthRegen (razem z try catch, bo dalej ten sam błąd)

try {
    player.setHealth(player.getHealth() + dmg);
} catch (IllegalArgumentException ex) {
}

I jeszcze jedna uwaga. Jak na zarejestrowanie listenera straciłem godzinę, tak 2 straciłem na zorientowanie się, że brakuje @EventHandler. Dodajcie to nad eventem. Czyli finalnie klasa wyglada tak:

package eu.andret.testowy;

import org.bukkit.entity.Entity;
import org.bukkit.entity.Player;
import org.bukkit.event.EventHandler;
import org.bukkit.event.Listener;
import org.bukkit.event.entity.EntityDamageByEntityEvent;
import org.bukkit.inventory.ItemStack;

public class ChestplateEffect implements Listener {
    @EventHandler
    public void attack(EntityDamageByEntityEvent e) {
        Entity en = e.getEntity(); //odnoszący obrażenia
        Entity dm = e.getDamager(); //zadający obrażenia
        if (en instanceof Player && dm instanceof Player) {
            Player player = (Player) en;
            ItemStack in = player.getInventory().getChestplate();
            ItemStack is = Testowy.getItem();
            if (in.getItemMeta().getDisplayName().equals(is.getItemMeta().getDisplayName())) {
                double dmg = e.getDamage() / 2;
                e.setCancelled(true);
                try {
                    player.setHealth(player.getHealth() + dmg);
                } catch (IllegalArgumentException ex) {
                }
            }
        }
    }
}

Zadanie domowe:

Dodaj nowy Crafting, którego układ to

@S@
@P@
PGP

gdzie @ to sztabka żelata, P to piórko, G złoto a S to szkło, co da buty zelazne, ktore kiedy nosi je gracz nie może on biegać bez sprinta (pl.setSprinting(true))

Temat #11: Może jakiś config?

No dobra, więc mamy sobie item, ale popatrzcie... Jego nazwa jest w pluginie. Opis też. Czyli jeżeli damy użytkownikowi (gdzie użytkownik to np. administrator, który pobiera nasz plugin na swój serwer) tak stworzony plugin to on nie może tego zmienić. Ułatwmy mu to! Pozwólmy mu ustalić w pliku config.yml nazwe i opis naszego itemu. Można to dodawać ręcznie, ale jest lepszy sposób. Tak jak tworzyliśmy plik plugin.yml, tak teraz dokładnie tak samo tworzymy plik config.yml. I do niego wpisz to co chcesz by się wygenerowało w configu. Ponieważ ja chcę name i lore chestplate'a, to to wpiszę:

chestplate:
  name: '&5Healing diamond chestplate'
  lore: "Makes heal\rfrom damage!"

Użyłem jakiegoś dziwnego "\r", co to znaczy? To nic nie znaczy. Ja sobie sam decyduję, że u mnie taki znaczek to przejscie do nowej linii. oczywiście nim nie jest, więc muszę to obsłużyć. A czemu zamiast "§" dałem "&"? Bo w configu userowi łatwiej wpisać & niż § a plugin dzięki nam (to za chwilę) sobie z tym poradzi. Teraz trzeba kazać pluginowi to zapisać jako domyślna konfiguracja. Teraz trzeba zapisać ten domyslny config metodą:

saveDefaultConfig();

I tym sposobem się wygeneruje config. Jednak ja dorobię zmienną config typu FileConfiguration na wszelki wypadek, nie musicie, mozęcie w kółko korzystać z metody getConfig(), niewielka to różnica. Teraz wpiszmy dane pobrane z configa jako dane naszego itemu. Czyli usuwamy

im.setDisplayName("§5Healing diamond chestplate");
im.setLore(Arrays.asList("Makes heal", "from damage!"));

Teraz piszemy

im.setDisplayName(config.getString("chestplate.name").replace("&", "§"));
im.setLore(Arrays.asList(config.getString("chestplate.lore").replace("&", "§").split("\r")));

Metoda "replace" dla stringa zamienia pierwszy argument z drugim i zwraca z zamienionym, czyli u nas zamienia & z §, żeby plugin to przeczytał jako zmiana koloru. W drugiej linijce to samo, zastępujemy w razie konieczności & z §, a potem mamy split, split dzieli stringa na tablicę po stringu, który damy w nawiasie. Przykład:

String a = "abcdefg";
String[] b = a.split("cd");

b[0] jest równe "ab" a b[1] jest równe "efg". No i tak, to już, sprawdźmy to. W configu mam:

chestplate:
  name: '&5Healing diamond chestplate'
  lore: "Makes heal\rfrom damage!"

W grze się nic nie zmieniło, jak zmienicie to zadziała. No i pozostaje jeszcze jedno czyli przeładowanie configa. Czyli jak go zmienię to żebym nie musiał reloadować całego serwera tylko ten jeden plugin. Metodę dasz radę dopisać, metoda odpowiadająca za przełądowanie pliku to:

reloadConfig();

Jedna mała uwaga, config ma takie metody jak getDouble, ale jeżeli użytkownik przypadkowo poda stringa to plugin się wysypie, polecam zawsze pobierać stringa i próbować parsować (np. Double.parseDouble()) używajac try catch, jest bezpieczniej. Moja klasa główna:

package eu.andret.testowy;

import java.util.Arrays;
import org.bukkit.Bukkit;
import org.bukkit.Material;
import org.bukkit.configuration.file.FileConfiguration;
import org.bukkit.inventory.ItemStack;
import org.bukkit.inventory.ShapedRecipe;
import org.bukkit.inventory.meta.ItemMeta;
import org.bukkit.plugin.java.JavaPlugin;

public class Testowy extends JavaPlugin {
    private static ItemStack is;
    
    @Override
    public void onEnable() {
        FileConfiguration config = getConfig();
        saveDefaultConfig();
        getCommand("komenda").setExecutor(new Komenda());
        getServer().getPluginManager().registerEvents(new HealthRegen(), this);
        getServer().getPluginManager().registerEvents(new ChestplateEffect(), this);
        is = new ItemStack(Material.DIAMOND_CHESTPLATE);
        ItemMeta im = is.getItemMeta();
        im.setDisplayName(config.getString("chestplate.name").replace("&", "§"));
        im.setLore(Arrays.asList(config.getString("chestplate.lore").replace("&", "§").split("\r")));
        is.setItemMeta(im);
        ShapedRecipe hrecipe = new ShapedRecipe(is);
        hrecipe.shape("@@@", "@#@", "@@@");
        hrecipe.setIngredient('@', Material.GOLD_INGOT);
        hrecipe.setIngredient('#', Material.DIAMOND_CHESTPLATE);
        Bukkit.getServer().addRecipe(hrecipe);
    }

    public static ItemStack getItem() {
        return is;
    }
}

Zadanie domowe:

Do zadania domowego z poprzedniej lekcji dorób configa, który umozliwi zmianę nazwy lub lore.

Temat #12: Co się dzieje gdy nas nie ma, czyli plik logów.

Umiesz już stworzyć domyślny plik konfiguracyjny. Ale co w momencie, gdy chcesz plik logów, którego na ogół nie powinno się edytować? Tutaj trzeba ręcznie stworzyć plik i dopisać do niego dane. Zacznijmy od napisania prostej metody w klasie głównej. Publicznej, statycznej, nic nie zwracajacej. Ja swoją nazwę log, bo bedzie zapisywała do logów. Więc tak:

public static void log(String message) {
}

Moje "message" będzie wiadomością, która zostanie zapisana w logach. No dobra, fajnie, że zapisze w logach. A w jakim pliku? Nie, nie stworzy go sobie sam, musimy mu go na siłę stworzyć, najlepiej w metodzie onEnable, ale niekoniecznie, możecie gdzie chcecie. Ale najpierw musimy mu pokazać w ogóle GDZIE ma stworzyć ten plik, bo możemy sobie wygenerować własną strukturę katalogów. Ja jednak pozostanę w głównym folderze pluginu. Więc gdzieś na górze tworzymy nowe pole (od teraz używam nazwy "pole" zamiast "zmienna")

private static File dataFolder;

a w onEnable dajemu temu czemuś wartość:

dataFolder = getDataFolder();

Ok, mamy już folder. Znaczy... mamy dane o folderze. Na wypadek gdyby nie istniał trzeba go stworzyć czyli:

if(!dataFolder.exists()) {
    dataFolder.mkdir();
}

Dobra, mamy juz folder, fizycznie go mamy. Teraz można tam pakować pliki. Więc teraz już w naszej metodzie log piszemy

File saveTo = new File(dataFolder, "logs.log");

Czyli tłumacząc tworzymy nowy plik w ścieżce zdefiniowanej w dataFolder o nazwie logs i rozszerzeniu log. Roszerzenie możemy sobie tutaj wymyślić własne, jakiekolwiek, i tak dane będą tam odczytywalne. Teraz to samo co w przypadku folderu - jeżeli nie istnieje, tworzymy go.

if (!saveTo.exists()) {
    saveTo.createNewFile();
}

Na tym poziomie linijka "saveTo.createNewFile();" ma problem, bo może się pliku nie udać stworzyć. Jak to możliwe? Np. serwer nie bedzie miał praw, to nie stworzy. Więc naprawmy mu błąd "Surround with try/catch", i mamy coś takiego

try {
    File saveTo = new File(dataFolder, "list.tmp");
    if (!saveTo.exists()) {
        saveTo.createNewFile();
    }
} catch (IOException e) {
    e.printStackTrace();
}

To co jest w catchu (czyli w klamrach { } a nie w nawiasach ()) to wyrzucenie na konsolę treści błędu, ale ładniej, jeżeli nie chcemy wiedzieć jaki jest problem, lub chcemy podjąć własne kroki - można tę linijkę usunąć. Ja zmienię sobie zmienną błędu z "e" na "ex". Czyli teraz mój kod wygląda tak:

try {
    File saveTo = new File(dataFolder, "list.tmp");
    if (!saveTo.exists()) {
        saveTo.createNewFile();
    }
} catch (IOException ex) {
    ex.printStackTrace();
}

Teraz cały czas pozostając w bloku try, jednak już pod ifem - majac pewność, że plik istnieje można brać się w końcu do zapisywania jakichkolwiek danych. Czyli piszemy:

FileWriter fw = new FileWriter(saveTo, true);
PrintWriter pw = new PrintWriter(fw);

Pierwsza linijka jakby umożliwia pisanie w pliku. Pierwszy argument "saveTo" decyduje który plik jest wybrany, drugi argument boolean decyduje czy piszemy na końcu pliku czy na początku. "true" - na końcu, "false" - na poczatku. Druga już otwiera plik i umozliwia bezpośrednie pisanie w pliku. Więc dopiszmy do pliku naszą wiadomość

pw.println(message);

Mogłem oczywiście napisać

pw.print(message);

Czym to się różni? "print" po prostu dopisze, "println" dopisze w nowej linii. Teraz musimy zwolnić pamięć z tego pliku czyli:

pw.flush();

Oraz następnie zamknąć plik:

pw.close();

Metoda jest gotowa, teraz wystarczy jej użyć gdzie i jak chcemy. Powiedzmy, że chcemy mieć w pliku dane kto, gdzie użył komendy "/komenda". Więc w pliku z komendą pod wysłaniem wiadomości do sendera dostajemy się do naszej metody log. Ja dla przykładu napiszę

Testowy.log(sender.getName() + " teleportowal sie na coordy " + x + ", " + y + ", " + z + " w swiecie " + ((Player) sender).getWorld());

Czyli do loga zapisujemy, że osoba wykonujaca komendę tepnęła się na coordy x y z w danym świecie. Czemu zapisałem jakieś dziwne "((Player) sender).getWorld()"? Ponieważ sam sender nie ma metody getWorld(), bo to MOŻE być konsola. Ale wyżej sprawdziliśmy, że sender to nie konsola to zamieniamy sendera w playera tylko na czas wykonania metody getWorld(); którą ma player. Oczywiście można napisać player.getWorld(); bo mamy wyżej stworzonego playera, ale warto i ten sposób znać, by zabierać mniej pamięci. To tyle, sprawdzamy czy działa. Pełna klasa główna:

package eu.andret.testowy;

import java.io.File;
import java.io.FileWriter;
import java.io.IOException;
import java.io.PrintWriter;
import java.util.Arrays;
import org.bukkit.Bukkit;
import org.bukkit.Material;
import org.bukkit.configuration.file.FileConfiguration;
import org.bukkit.inventory.ItemStack;
import org.bukkit.inventory.ShapedRecipe;
import org.bukkit.inventory.meta.ItemMeta;
import org.bukkit.plugin.java.JavaPlugin;

public class Testowy extends JavaPlugin {
    private static ItemStack is;
    private static File dataFolder = null;
        @Override    public void onEnable() {
        FileConfiguration config = getConfig();
        config.addDefault("chestplate.name", "&5Healing diamond chestplate");
        config.addDefault("chestplate.lore", "Makes heal\rfrom damage!");
        config.options().copyDefaults(true);
        saveConfig();
        getCommand("komenda").setExecutor(new Komenda());
        getServer().getPluginManager().registerEvents(new HealthRegen(), this);
        getServer().getPluginManager().registerEvents(new ChestplateEffect(), this);
        is = new ItemStack(Material.DIAMOND_CHESTPLATE);
        ItemMeta im = is.getItemMeta();
        im.setDisplayName(config.getString("chestplate.name").replace("&", "§"));
        im.setLore(Arrays.asList(config.getString("chestplate.lore").replace("&", "§").split("\r")));
        is.setItemMeta(im);
        ShapedRecipe hrecipe = new ShapedRecipe(is);
        hrecipe.shape("@@@", "@#@", "@@@");
        hrecipe.setIngredient('@', Material.GOLD_INGOT);
        hrecipe.setIngredient('#', Material.DIAMOND_CHESTPLATE);
        Bukkit.getServer().addRecipe(hrecipe);
        dataFolder = getDataFolder();
        if(!dataFolder.exists()) {
            dataFolder.mkdir();
        }
    }

    public static ItemStack getItem() {
        return is;
    }

    public static void log(String message) {
        try {
            File saveTo = new File(dataFolder, "list.tmp");
            if (!saveTo.exists()) {
                saveTo.createNewFile();
            }
            FileWriter fw = new FileWriter(saveTo, true);
            PrintWriter pw = new PrintWriter(fw);
            pw.println(message);
            pw.flush();
            pw.close();
        } catch (IOException ex) {
            ex.printStackTrace();
        }
    }
}

Temat #13: Dane towarzyszące graczom

Trochę z innej beczki, chcemy np. żeby nasz plugin przechowywał ilości zabić oraz śmierci każdego gracza. No trochę kodzenia będzie, ale najpierw nieco teorii. Żeby to miało ręce i nogi wykorzystamy HashMapy. Co to takiego HashMapa? To jest podobne do tablicy, tak samo układa dane, ale nie ma indexu i wartości, tylko ma klucz i wartość. I tu niespodzianka: naszym kluczem może byc wszystko, jeden warunek: klucze nie mogą się powtarzać. Druga różnica: Jest dynamiczna, nie musimy z góry stwierdzić ile ma miejsc. Trzecia i ostatnia różnica którą zauważymy, ma inne metody niż tablica. No dobra, a co to znaczy? Jedziemy do praktyki! Najpierw trzeba te Mapy stworzyć. Więc

w klasie głównej:

private Map<String, Integer> deads = new HashMap<>();
private Map<String, Integer> kills = new HashMap<>();

Co tu jest ważnego? Po pierwsze po lewej jak i po prawej stronie znaku '=' w nawiasach <> muszą się znaleźć 2 te same typy w takiej samej kolejności. Po drugie musimy użyć klasy Integer, a nie typu int, bo mapa operuje na klasach, nie na typach. Więc jeżeli chcielibyśmy to nie 'float' tylko 'Float', nie 'double' tylko 'Double'. Ten kawałek kodu wyzej dajemy do zmiennych w klasie głównej, czyli gdzies tam nad "@Override". Dobra, teraz stworzymy listenera i będziemy na jednym operować, po prostu zabicie entity. Więc klasa, moja się nazwie Kill. Dodajemy tam event, nie zapominamy o "@EventHandler" oraz zarejestrowaniu go w klasie głównej i pobieramy z niego entity i killer, czyli to mamy tak:

package eu.andret.testowy;

import org.bukkit.entity.LivingEntity;
import org.bukkit.event.EventHandler;
import org.bukkit.event.Listener;
import org.bukkit.event.entity.EntityDeathEvent;
public class Kill implements Listener {
    @EventHandler
    public void kill(EntityDeathEvent e) {
        LivingEntity entity = e.getEntity();
        LivingEntity killer = entity.getKiller();
    }
}

Potem troche if'owania, żeby wszystko ułożyć:

if (entity instanceof Player) {
    if (killer instanceof Player) {
        // jeżeli player zabija playera
    } else {
        // jeżeli entity zabija playera
    }
} else if (killer instanceof Player) {
    // jeżeli player zabija entity
}

Teraz tak, mamy 2 mapy, zabicia i śmierci. Jeżeli player zabije playera trzeba w obu dodać pewną wartość, konkretnie zinkrementować

Definicja
inkrementacja - zwiekszenie wartości zmiennej dokładnie o 1

Definicja
dekrementacja - zmniejszenie wartości dokładnie o 1

No fajnie, trzeba zinkrementować, ale co? Wartość w mapie. A ile ona jest równa dla gracza? NULL. Czemu? Bo nie dodaliśmy tej wartości do mapy. Nie ma klucza, którego wartość powinniśmy zinkrementować. Czyli co? No wiadomo, w mapie musi się pojawić jakiś klucz. Najprościej go stworzyć kiedy gracz dołączy do serwera. A jak, skoro mapa prywatna? GETTERY!

public Map<Player, Integer> getDeadsMap() {
    return deads;
}

public Map<Player, Integer> getKillsMap() {
    return kills;
}

Teraz używamy!

@EventHandler
public void join(PlayerJoinEvent e) {
    if (!Testowy.getInstance().getKillsMap().containsKey(e.getPlayer().getName())) {
        Testowy.getInstance().getDeadsMap().put(e.getPlayer().getName(), 0);
        Testowy.getInstance().getKillsMap().put(e.getPlayer().getName(), 0);
    }
}

A ponieważ jest w klasie, która jest juz zarejestrowana jako Event drugi raz nie musimy tego robić. Pamiętacie jak parę tematów temu tworzyliśmy fukcję pośrednią żeby ręcznie nie modyfikować obiektów? Wówczas takie coś jak tu widać nie było możliwe. Jeszcze odpowiedź na pytanie czemu po przecinku 0? Bo muszę podać jakiegoś Integera, a zazwyczaj po wejściu pierwszy raz na serwer nie ma się na nim zabić. Czemu sprawdzam, czy mapa już tego nie zawiera? Bo inaczej by mi ja czyścił za każdym razem, gracz wchodzi, zabija 2 graczy, wychodzi, wchodzi kolejny raz, ma 0 zabić... Bezsens, nie? Dobra, a wracając do naszych if'ów... Dopisałem sobie miejscami rzutowanie, żeby to już były playery, bo LivingEntity nie ma getName() a player juz ma. Po tej drobnej zmianie:

@EventHandler
public void kill(EntityDeathEvent e) {
    LivingEntity entity = e.getEntity();
    LivingEntity killer = entity.getKiller();
    if (entity instanceof Player) {
        Player en = (Player) entity;
        if (killer instanceof Player) {
            Player k = (Player) killer;
            //jeżeli player zabija playera
        } else {
            //jeżeli entity zabija playera
        }
    } else if (killer instanceof Player) {
        Player k = (Player) killer;
        //jeżeli player zabija entity
    }
}

I teraz cały silnik... Czyli jeżeli player zabija playera trzeba zinkrementować wartości w obu mapach ale uwaga na klucze! Czyli tam piszemy:

Testowy.getInstance().getKillsMap().put(k.getName(), Testowy.getInstance().getKillsMap().get(k.getName()) + 1);

Trochę długie ale znaczy tyle:
"Zrób update wartości gdzie kluczem jest nick zabijającego, ustaw wartość równą tej wartości + 1".
I drugie tak samo, czyli:

Testowy.getInstance().getDeadsMap().put(en.getName(), Testowy.getInstance().getDeadsMap().get(en.getName()) + 1);

Trzeba teraz tylko te linijki pokopiować i powklejć w odpowiednie miejsca w strukturze ifów. Na koniec, mamy coś takiego:

if (entity instanceof Player) {
    Player en = (Player) entity;
    if (killer instanceof Player) {
        Player k = (Player) killer;
        // jeżeli player zabija playera
        Testowy.getInstance().getKillsMap().put(k.getName(), Testowy.getInstance().getKillsMap().get(k.getName()) + 1);
        Testowy.getInstance().getDeadsMap().put(en.getName(), Testowy.getInstance().getDeadsMap().get(en.getName()) + 1);
    } else {
        // jeżeli entity zabija playera
        Testowy.getInstance().getDeadsMap().put(en.getName(), Testowy.getInstance().getDeadsMap().get(en.getName()) + 1);
    }} else if (killer instanceof Player) {
    Player k = (Player) killer;
    // jeżeli player zabija entity
    Testowy.getInstance().getKillsMap().put(k.getName(), Testowy.getInstance().getKillsMap().get(k.getName()) + 1);
}

No fajnie, mam sobie wartość, ona fajnie działa, wszystko zwiększa, dogrywam sobie inny plugin, reloaduję serwer... I mi sie wszystkie dane resetują. I mam... wszędzie 0. "Ale głupie to programowanie", nie? "Trzeba o wszytkim myśleć". Tak, owczem, na tym to polega. No trudno, zabawa z plikami, chyba, że wam to nie potrzebne bo po reloadzie dane się mają resetować. Więc wracamy do klasy głównej. Zróbmy 2 metody, save() i load(), pierwsza będzie zapisywała dane z map do plików, druga z nich odczytywała. Chociaż w sumie metodę save() można stworzyć duplikując naszą metodę log(String message). Czyli kopiujemy to:

public static void log(String message) {
    try {
        File saveTo = new File(dataFolder, "logs.log");
        if (!saveTo.exists()) {
            saveTo.createNewFile();
        }
        FileWriter fw = new FileWriter(saveTo, true);
        PrintWriter pw = new PrintWriter(fw);
        pw.println(message);
        pw.flush();
        pw.close();
    } catch (IOException ex) {
        ex.printStackTrace();
    }
}

wklejamy i zmieniamy dane, ja zmieniłem na takie:

public static void save(String message) {
    try {
        File saveTo = new File(dataFolder, "data.tmp");
        if (!saveTo.exists()) {
            saveTo.createNewFile();
        }
        FileWriter fw = new FileWriter(saveTo, true);
        PrintWriter pw = new PrintWriter(fw);
        pw.println(message);
        pw.flush();
        pw.close();
    } catch (IOException ex) {
        ex.printStackTrace();
    }
}

Teraz metoda load(). Więc znowu, jak wiadomo, skoro zabawa z plikami wymagany jest try - catch, teraz wszystko piszemy w bloku try. Tworzymy zmienną naszego pliczku

File file = new File(getDataFolder(), "data.tmp");

Nie tworzymy pliku kiedy go nie ma, po prostu sprawdzamy czy jest, jeżeli jest to wykonujemy operacje, jezeli nie to zosatwiamy go w spokoju

if (file.exists()) {
}

Teraz taka stosunkowo długa linijeczka, ale no, żeby czytać z pliku to musi tak być

BufferedReader reader = new BufferedReader(new FileReader(new File(getDataFolder(), "data.tmp")));

Nasza zmienna "reader" to już praktyczna zawartość pliku. Teraz stwórzmy sobie zmienna typu String, zainicjalizowaną pustym Stringiem, czyli:

String line = "";

I teraz nastąpi coś dziwnego. Otóż dotychczas uczyliśmy się tylko pętli for, która wykona się dokładnie tyle razy ile potrzeba. Pod warunkiem, że znamy tę wartość. A co jeżeli nie wiemy ile razy ma się wykonać tylko ma się wykonać aż jakiś warunek przestanie być spełniany? Są takie 2 pętle. Pętla While i pętdla Do-while. Niby podobne, ale maja drobną różnicę. Pętla while wygląda tak:

while (warunek) {
    //najpierw jest sprawdzony warunek, jeżeli true to to tutaj się wykona, jeżeli nie to nie
}

natomiast pętla Do-while maluje się w ten sposób

do {
    // to się najpierw wykona 1 raz i sprawdzi czy warunek pełniony, jezeli true - wykona się kolejny, jeżeli nie - wyjscie stąd
} while (warunek);

Różnica jest w tym, że w pętli do-while całość MUSI się przynajmniej raz wykonać, przy While - nie musi. Warunek to wyrażenie, więc może być bardzo skomplikowane, byle zwracało boolean. Co do naszego kodu to u nas taka pętelka:

while((line = reader.readLine()) != null) {
}

Czyli za line podstawiamy reader.getLine() i sprawdzamy, czy to jest różne od null, jeżeli tak, warunek spełniony, robimy pętlę. A co w tej pętli? Narazie to zostawmy tak jak jest, wróćmy do naszej medoty save(String message). Trzeba w pliku tekstowym zapisać nick gracza, jego zabicie i śmierci, taki zestaw danych musi być w jednej linijce dla jednego gracza. Wydaje mi się, że można użyć dwukropków jako separatorów danych na zasadzie:

nick:kills:deads

teraz to jest o tyle bezpieczne, że w obu mapach na 100% mamy tyle samo danych. Logicznie dedukujemy, kiedy zapisujemy dane? W onDisable(). Czyli teraz dopiero będzie dziwna pętla. Bo znacie pętle for, która wyglada tak:

for (definicja zmiennych; warunek; wyonanie co obiek petli) {
    //wykonanie
}

Przykładowo:

for (int i=0; i<args.length; i++) {
    System.out.print(args[i]);
}

Ale w JAVIE jest też pętla zwana pętlą foreach (czyt. "foricz"). Czyli wykonaj coś dla WSZYSTKICH elementów kolekcji. Np. mapy. Taka pętla wygląda tak:

for (deklaracja : kolekcja) {
    //wykonanie
}

Wyglada na proste. Niestety mapy to zaawansowane struktury, więc musimy sobie komplikować życie do czegoś takiego:

for (Entry<String, Integer> entry : deads.entrySet()) {
    // entry to jedna para tekstu i liczby
}

Czemu deads a nie kills? To zmień na kills i rób odwrotnie, to całkowicie bez znaczenia.
Teraz w tej pętli do Stringa trzeba zlepić nasze dane. Najpierw rozbiję je na kilka, czyli o tak:

String nick = entry.getKey();
int d = entry.getValue();

No i teraz trzeba się dostać do drugiej mapy w tej pętli, klucz taki sam, wiec:

int k = kills.get(entry.getKey());

I teraz lepimy w jednego Stringa:

String msg = nick + ":" + k + ":" + d;

i wykonujemy metodę:

save(msg);

czyli metoda onDisable() wygląda tak:

@Override
public void onDisable() {
    for (Entry<String, Integer> entry:deads.entrySet()) {
        String nick = entry.getKey();
        int d = entry.getValue();
        int k = kills.get(entry.getKey());
        String msg = nick + ":" + k + ":" + d;
        save(msg);
    }
}

Ok, możemy wrócić do metody load, czemu teraz? By nie zapomnieć w jakiej formie są zapisane w pliku. I jak jesteśmy w pętli while i dzielimy linię po dwukropkach:

String nick = line.split(":")[0];
int k = Integer.parseInt(line.split(":")[1]);
int d = Integer.parseInt(line.split(":")[2]);

Musimy użyć Integer.parseInt() bo nie da się inaczej zrzutować string -> int. No i teraz dodajemy te dane do map:

kills.put(nick, k);
deads.put(nick, d);

Po pętelce zamykamy plik i można go usunać, by nie łudzić się, ze można ręcznie usunąć dane, polecam usunąć plik. Czyli:

reader.close();
file.delete();

no i wykonajmy load() w onEnable na samym końcu. FINITO!! Tutaj macie całą klasę:

package eu.andret.testowy;

import java.io.BufferedReader;
import java.io.File;
import java.io.FileReader;
import java.io.FileWriter;
import java.io.IOException;
import java.io.PrintWriter;
import java.util.Arrays;
import java.util.HashMap;
import java.util.Map;
import java.util.Map.Entry;
import org.bukkit.Bukkit;
import org.bukkit.Material;
import org.bukkit.configuration.file.FileConfiguration;
import org.bukkit.inventory.ItemStack;
import org.bukkit.inventory.ShapedRecipe;
import org.bukkit.inventory.meta.ItemMeta;
import org.bukkit.plugin.java.JavaPlugin;

public class Testowy extends JavaPlugin {
    private static ItemStack is;
    private static File dataFolder;
    public static Map<String, Integer> deads = new HashMap<>();
    public static Map<String, Integer> kills = new HashMap<>();

    @Override
    public void onEnable() {
        FileConfiguration config = getConfig();
        config.addDefault("chestplate.name", "&5Healing diamond chestplate");
        config.addDefault("chestplate.lore", "Makes heal\rfrom damage!");
        config.options().copyDefaults(true);
        saveConfig();
        getCommand("komenda").setExecutor(new Komenda());
        getServer().getPluginManager().registerEvents(new HealthRegen(), this);
        getServer().getPluginManager().registerEvents(new ChestplateEffect(), this);
        getServer().getPluginManager().registerEvents(new Kill(), this);
        is = new ItemStack(Material.DIAMOND_CHESTPLATE);
        ItemMeta im = is.getItemMeta();
        im.setDisplayName(config.getString("chestplate.name").replace("&", "§"));
        im.setLore(Arrays.asList(config.getString("chestplate.lore").replace("&", "§").split("\r")));
        is.setItemMeta(im);
        ShapedRecipe hrecipe = new ShapedRecipe(is);
        hrecipe.shape("@@@", "@#@", "@@@");
        hrecipe.setIngredient('@', Material.GOLD_INGOT);
        hrecipe.setIngredient('#', Material.DIAMOND_CHESTPLATE);
        Bukkit.getServer().addRecipe(hrecipe);
        dataFolder = getDataFolder();
        if(!dataFolder.exists()) {
            dataFolder.mkdir();
        }
        load();
    }

    @Override
    public void onDisable() {
        for (Entry<String, Integer> entry : deads.entrySet()) {
            String nick = entry.getKey();
            int d = entry.getValue();
            int k = kills.get(entry.getKey());
            String msg = nick + ":" + k + ":" + d;
            save(msg);
        }
    }

    public static ItemStack getItem() {
        return is;
    }

    public static void log(String message) {
        try {
            File saveTo = new File(dataFolder, "logs.log");
            if (!saveTo.exists()) {
                saveTo.createNewFile();
            }
            FileWriter fw = new FileWriter(saveTo, true);
            PrintWriter pw = new PrintWriter(fw);
            pw.println(message);
            pw.flush();
            pw.close();
        } catch (IOException ex) {
            ex.printStackTrace();
        }
    }

    public static void save(String message) {
        try {
            File saveTo = new File(dataFolder, "data.tmp");
            if (!saveTo.exists()) {
                saveTo.createNewFile();
            }
            FileWriter fw = new FileWriter(saveTo, true);
            PrintWriter pw = new PrintWriter(fw);
            pw.println(message);
            pw.flush();
            pw.close();
        } catch (IOException ex) {
            ex.printStackTrace();
        }
    }

    public static void load() {
         try {
            File file = new File(dataFolder, "list.tmp");
            if (file.exists()) {
                BufferedReader reader = new BufferedReader(new FileReader(file));
                String line = "";
                while ((line = reader.readLine()) != null) {
                    String nick = line.split(":")[0];
                    int k = Integer.parseInt(line.split(":")[1]);
                    int d = Integer.parseInt(line.split(":")[2]);
                    kills.put(nick, k);
                    deads.put(nick, d);
                }
                reader.close();
                file.delete();
            }
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

Oraz listenerki:

package eu.andret.testowy;

import org.bukkit.entity.LivingEntity;
import org.bukkit.entity.Player;
import org.bukkit.event.EventHandler;
import org.bukkit.event.Listener;
import org.bukkit.event.entity.EntityDeathEvent;
import org.bukkit.event.player.PlayerJoinEvent;

public class Kill implements Listener {
    @EventHandler
    public void kill(EntityDeathEvent e) {
        LivingEntity entity = e.getEntity();
        LivingEntity killer = entity.getKiller();
        if (entity instanceof Player) {
            Player en = (Player) entity;
            if (killer instanceof Player) {
                Player k = (Player) killer;
                // jeżeli player zabija playera
                Testowy.getInstance().getKillsMap().put(k.getName(), Testowy.getInstance().getKillsMap().get(k.getName()) + 1);
                Testowy.getInstance().getDeadsMap().put(en.getName(), Testowy.getInstance().getDeadsMap().get(en.getName()) + 1);
            } else {
                // jeżeli entity zabija playera
                Testowy.getInstance().getDeadsMap().put(en.getName(), Testowy.getInstance().getDeadsMap().get(en.getName()) + 1);
            }
        } else if (killer instanceof Player) {
            Player k = (Player) killer;
            // jeżeli player zabija entity
            Testowy.getInstance().getKillsMap().put(k.getName(), Testowy.getInstance().getKillsMap().get(k.getName()) + 1);
        }
    }

    @EventHandler
    public void join(PlayerJoinEvent e) {
        if (!Testowy.getInstance().getKillsMap().containsKey(e.getPlayer().getName())) {
            Testowy.getInstance().getDeadsMap().put(e.getPlayer().getName(), 0);
            Testowy.getInstance().getKillsMap().put(e.getPlayer().getName(), 0);
        }
    }
}

Zadanie domowe:

Dorób kolejną daną towarzyszącą każdemu graczowi, niech to bedzie ilość zepsutych w trakcie używania narzędzi (PlayerItemBreakEvent)

Temat #14: Coś naszego bardziej w kodzie

No fajnie, ok, mamy 2 mapy, zabicia i deady gracza, tego jest mało, więc nie przeszkadza, ale dodajmy więcej statystyk jak np. scraftowanych itemów, zaenchanotwanych itemów, zniszczonych itemów, zniszczonych bloków, postawionych bloków. I co, i dla każdego mam tworzyć osobną mapę i w końcu mieć ich 200? No nie, kiepski pomysł. Nie opłaca się. Stworzymy więc coś nowego, coś do czego nie potrzebny jest bukkit, ale to może być przydatne do bukkita. Mówię tutaj o własnej KLASIE. Innej niż dziedziczącej z JavPlugin, nie implementującej ani Lintener ani CommandExecutor. Po prostu nasza własna, luźna klasa. Mało danych bukkita, ale ułatwia pracę. Do dzieła. Tworzymy nową klasę, ja swoją nazwę "Stat". I jak pisałem, niczego nie dopisujemy, nie rozszerzamy, nie implementujemy, zostajemy przy defaulcie:

package eu.andret.testowy;

public class Stat {
}

Teraz tak, dobrze byłoby, żeby klasa miała coś co się nazywa KONSTRUKTOR. Konstruktor co specjalna metoda. Ona nie ma typu, ponieważ sama jest typem. Tutaj spore znaczenie ma ustalenie co jest publiczne a co prywatne. Konstruktory powinny być publiczne. Użyłem liczby mnogiej? Nie zrobiłem błędu, może ich być wiele, jeden warunek: muszą się różnić listą argumentową (zawartością nawiasu). Ale po cholerę nam jakiś konstruktor? Konstruktor umożliwia nam stworzenie obiektu naczej klasy. Żeby łatwiej było Wam zrozumieć, np. tworzymy lokację:

Location loc = new Location(w, x, y, z);

pierwsze "Location" to klasa, "loc" to obiekt tej klasy (zmienna tego typu), "new" to informacja, że tworzymy go (formalnie nazywa się to "operator wskaźnikowy new"), "Location(w, x, y, z)" to właśnie konstruktor tej klasy. Ale gdybyśmy napisali po prostu "new Location()" też by przyjął. To są 2 konstruktory, które się różnią zawartością nawiasu. Jeden warunek: Nazwa konstruktora MUSI być taka sama jak nazwa klasy. No inaczej to nie konstruktor. Narazie stwórzmy pusty:

public Stat() {

}

Teraz musimy się zastanowić... Jeżeli każdemu graczowi będzie przypisany taki jeden obiekt to wszystkie statystyki muszą byc polami. Co to pole? Zmienna. Dla każdej własności dodajemy pole, typu int bo to właśnie bedziemy liczyli ilość.

public int kills;
public int deads;
public int enchants;
public int crafted;
public int placed;
public int broken;
public int destroyed;

Teraz każdy obiekt tej klasy ma każdą z tych własności. Jeszcze trzeba to skojarzyć z graczem, czyli ostatnie pole. Ok, teraz ważne słówko kluczowe: this. Ono pokazuje na naszą klasę. Zaraz się rozjaśni, dodajmy do naszego konstruktora właśnie playera. Moim zdaniem lepiej cały czas trzymać nick gracza, bo potem są niepotrzebne błędy z tym czy player jest Online czy Offline. Więc jako argument konstruktora dajemy zmienną typu String. Nazwa MOŻE być taka sama jak stworzonego na górze pola. Właśnie tak zróbmy, żeby uzyć this-a. Czyli mamy w końcu:

package eu.andret.testowy;

public class Stat {
    public int kills;
    public int deads;
    public int enchants;
    public int crafted;
    public int placed;
    public int broken;
    public int destroyed;
    public String player;

    public Stat(String player) {
    }
}

Za obiekt klasy nazwany "player" powinniśmy podstawić argument "player". Jak zrobimy player = player to napisze, że robimy bezsensowną operację. Czemu? Który player jest którym? Oba playery są tym samym - najbliższym. Bo on nie wie jak je rozpoznać. Więc musimy za playera z naszej klasy podstawić tego z argumentu. Czyli

this.player = player;

i nie ma warninga. Jednak teraz wszystkie inne pola są zerami. Czyli mój konstruktor wygląda tak:

public Stat(String player) {
    this.player = player;
}

Dobra, masz wszystkie pola publiczne, średnio to dobre, bo z dowolnego miejsca poza klasą można po chamsku zrobić np.

Stat.kills = 37846836437;

To raczej nie najlepsze rozwiązanie. Zamień wszystkie pola (konstruktora nie dotykaj!) na private. Zacznie wywalać warningi, nie naprawiaj ich, zaraz same się naprawią. Teraz myślimy, jeżeli mamy gdzieś stworzony obiekt to powinniśmy móc z niego dostać poszczególne informacje jak np. zabicia. Zróbmy osobną metodę, właściwie gettera. Co to znaczy? To znaczy, że po prostu zrwóci informację, ale nie pozwoli nam jej zmodyfikować. Warto nazywać gettery jako "getWlasciwosc()" a settery (do ustawiania) "setWlasciwosc()". Moja metoda to getKills(); i zwraca wartość kills. Czyli:

public int getKills() {
    return kills;
}

Warto, żeby gettery i settery były pubiczne, chyba, że coś bardziej ambitngo planujemy, to pożna zrobić prywatne i po swojemu używać. My zrobimy prosto. W ten sposób zróbmy gettery wszystkich własności obiektu. Po krótkim kopiowanku mamy:

public int getKills() {
    return kills;
}

public int getDeads() {
    return deads;
}

public int getEnchants() {
    return enchants;
}

public int getCrafted() {
    return crafted;
}

public int getPlaced() {
    return placed;
}

public int getBroken() {
    return broken;
}

public int getDestroyed() {
    return destroyed;
}

public String getPlayer() {
    return player;
}

Ok, możemy już otrzymać dane, trzeba je jeszcze jakoś ustawić. Najpierw mamy pewnosć, że playera, jako naszą niezmienną "kotwicę" czyli coś co dla obiektu się nie zmienia nie potrzebuje być ustawiane - settera playera nie ma. Ba, dodaj do deklaracji zmiennej słówko "final", czyli coś stałego. Inicjalizowane raz i koniec. cyzli mamy

private final String player;

Teraz tak, można w jednym momencie zniszczyć 30 narzędzi? Można rozbić 400 bloków? Można naraz zaenchantować 24 zbroje? No nie można. Więc teraz mamy prosty wybór: albo pozwalamy użytkownikowi (znaczy osobie która pisze w innej klasie korzystając z naszej klasy) ręcznie zwiększać wartości np. o 100, 200, albo bardziej restrykcyjnie, pozwolić mu po prostu zwiększyć o 1 lub zmniejszyć o 1. Albo najlepiej tylko zwiększyć o 1, no bo te wartości raczej nigdy nie zmaleją. Ja zrobię po 1 metodzie oboma sposobami, Ty wybierzesz który Cię bardziej satysfakcjonuje i skopiujesz i wkleisz go 7 razy i zmienisz dane. Najpierw to gdzie można więcej. Najczęściej settery są typu void, chociaż czasami bardziej zaawansowane settery są typu boolean, żeby zrwóciły true/false czy udało się ustawić czy nie. Ja jednak pozostanę przy void. Czyli tak, setter w luźniejszej wersji musi przyjać argument o ile ma się zwiększyć dana własność, dajmy na to kills. Czyli

public void setKills(int count) {
    kills += count;
}

I to w sumie tyle. W bardziej restrykcyjnej wersji nie podajemy argumentu bo zawsze zwiększamy o 1, czyli:

public void addKill() {
    kill++;
}

No i to tyle. Ja wolę drugi sposób, żeby przypadkiem czegoś nie zepsuć. Więc znowu, kopiuj - wklej - zmień dane. Czyli mamy:

public void addKill() {
    kills++;
}

public void addDeads() {
    deads++;
}

public void addEnchats() {
    enchants++;
}

public void addCrafted() {
    crafted++;
}

public void addPlaced() {
    placed++;
}

public void addBroken() {
    broken++;
}

public void addDestroyed() {
    destroyed++;
}

Ja zawsze tak na wszelki wypadek tworzę sobie metodę equals, która porównuje klucze moich obiektów. Wyglada ona mniej więcej tak:

@Override
public boolean equals(Stat Stat) {
    return this.player.equals(Stat.player);
}

Oczywiscie na potrzeby Waszego pluginu możecie dopisać sobie metody takie jak np. "equalsKills", "equalsDeads" (wóczas bez "@Override") itd co porówna konkretne wartości. To już zależy od tego jak chcecie to wykorzystać. Dobra, klasę mamy, w niej myślę, tyle. Moja pełna wygląda tak:

package eu.andret.testowy;
public class Stat {
    private int kills;
    private int deads;
    private int enchants;
    private int crafted;
    private int placed;
    private int broken;
    private int destroyed;
    private String player;
    public Stat(String player) {
        this.player = player;
    }

    public int getKills() {
        return kills;
    }

    public int getDeads() {
        return deads;
    }

    public int getEnchants() {
        return enchants;
    }

    public int getCrafted() {
        return crafted;
    }

    public int getPlaced() {
        return placed;
    }

    public int getBroken() {
        return broken;
    }

    public int getDestroyed() {
        return destroyed;
    }

    public Player getPlayer() {
        return player;
    }

    //=====

    public void addKill() {
        kills++;
    }
 
   public void addDeads() {
        deads++;
    }

    public void addEnchats() {
        enchants++;
    }

    public void addCrafted() {
        crafted++;
    }

    public void addPlaced() {
        placed++;
    }

    public void addBroken() {
        broken++;
    }

    public void addDestroyed() {
        destroyed++;
    }

    public boolean equals(Stat Stat) {
        return this.player.equals(Stat.player);
    }
}

Ok, teraz chodźmy do klasy głównej gdzie były 2 mapy. Jedną usuńmy a w drugiej zamienimy Integera na naszą klasę Stat, czyli mamy coś takiego:

public static Map<String, Stat> list = new HashMap<>();

i mamy kilka błędów, które trzeba naprawić. Zajmijmy się najpierw klasą Kill, bo tam jest łatwiej. Pierwszy błąd, linijka:

Testowy.getInstance().getKillsMap().put(k.getName(), Testowy.getInstance().getKillsMap().get(k.getName()) + 1);

Do śmieci. No bo tak, my nie wkładamy do mapy nowej wartości zwięksoznej o 1, my musimy uzyć jednej z naszych funkcji na już istniejącym obiekcie. Czyli z mapy pobieramy nasz obiekt po nicku gracza. Najpierw zmieniamy nazwę mapy, bo teraz mamy jedną wspólną, potem trzeba pobrać ten obiekt:

Testowy.getInstance().getList().get(k.getName());

Proste? Na tym używamy jednej z naszych fukcji, w tym wypadku addKill (chyba, ze Twoja jest nazwana inaczej). Czyli mamy:

Testowy.getInstance().getList().get(k.getName()).addKill();

Myślę, ze kazdą z kolejnych linijek tutaj, która wywala podobny błąd sobie dasz radę naprawić. Chodźmy do naszego drugiego listenera, gdzie w warunku zmieniamy nazwę listy, potem z bloku wyrzucamy jedna linijkę, bo tylko jedna się przyda i ją przerabiamy. Ponownie zmieniamy nazwę listy by nie tworzyła błędów, oraz zamiast 0 piszemy

new Stat(e.getPlayer());

Czyli cała ta klasa wygląda tak:

package eu.andret.testowy;

import org.bukkit.entity.LivingEntity;
import org.bukkit.entity.Player;
import org.bukkit.event.EventHandler;
import org.bukkit.event.Listener;
import org.bukkit.event.entity.EntityDeathEvent;
import org.bukkit.event.player.PlayerJoinEvent;

public class Kill implements Listener {
    @EventHandler
    public void kill(EntityDeathEvent e) {
        LivingEntity entity = e.getEntity();
        LivingEntity killer = entity.getKiller();
        if (entity instanceof Player) {
            Player en = (Player) entity;
            if (killer instanceof Player) {
                Player k = (Player) killer;
                Testowy.getInstance().getList().get(k.getName()).addKill();
                Testowy.getInstance().getList().get(en.getName()).addDeads();
            } else {
                Testowy.getInstance().getList().get(en.getName()).addDeads();
            }
        } else if (killer instanceof Player) {
            Player k = (Player) killer;
            Testowy.getInstance().getList().get(k.getName()).addKill();
        }
    }

    @EventHandler
    public void join(PlayerJoinEvent e) {
        if (!Testowy.getInstance().getList().containsKey(e.getPlayer().getName())) {
            Testowy.getInstance().getList().put(e.getPlayer().getName(), new Stat(e.getPlayer().getName()));
        }
    }
}

Teraz to dopiero bedzie zabawa, bo potrzebujemy w klasie drugi kostruktor. Tak jak pisałem, ich meże byc wiele, warunek? Maja się różnić listą argumentową. Teraz potrzebny jest taki konstruktor, z takimi danymi, który wpisze wszystkie dane, a nie wypełni zerami. Bez dłuższych wstępów:

public Stat(String player, int broken, int crafted, int deads, int destroyed, int enchants, int kills, int placed) {
    this.player = player;
    this.broken = broken;
    this.crafted = crafted;
    this.deads = deads;
    this.destroyed = destroyed;
    this.enchants = enchants;
    this.kills = kills;
    this.placed = placed;
}

to oczywiście w naszej klasie.
No i najciekawsza część czyli naprawa błędów w klasie głównej - zapis i odczyt plików. Ale ułatwimy sobie życie i NADPISZEMY pewną metodę w klasie. Więc chodźmy do naszej klasy Status i zróbmy metodę toString(). Ponieważ taka metoda domyślnie jest w każdym obiekcie musimy ją opatrzeć adnotacją "@Override". Teraz co ta metoda ma robić? Zamieniać wszystko w stringa. Czyli jak mamy

@Override
public String toString() {
}

On się rzuca, że albo damy mu return-a albo zmienimy typ na void. Tym się nie przejmujmy, możesz mu dać return ""; jeżeli Cię denerwuje błąd. W tej metodzie po prostu zwracamy dane ułożone w stringa. Ustalmy sobie kolejność, myślę, że najbardziej charakterystyczną jest alfabetyczna. Więc po kolei lepimy każdą własność obiektu z innymi po dwukropku i mamy coś takiego:

@Override
public String toString() {
    String s1 = this.player.getName() + ":";
    String s2 = String.valueOf(this.broken) + ":";
    String s3 = String.valueOf(this.crafted) + ":";
    String s4 = String.valueOf(this.deads) + ":";
    String s5 = String.valueOf(this.destroyed) + ":";
    String s6 = String.valueOf(this.enchants) + ":";
    String s7 = String.valueOf(this.kills) + ":";
    String s8 = String.valueOf(this.placed);
    return s1 + s2 + s3 + s4 + s5 + s6 + s7 + s8;
}

Skoro tak zapisujemy potrzebujemy też metodę działającą w drugą stronę - z konwencji JAVY wynika, że metoda ta to valueOf(String);. Ona musi z podanego stringa zrobić dane naszego statusu. Zaczniemy od zrobienia sobie tablicy:

String[] v = value.split(":");

Potem tworzymy nową zmienną:

String p = v[0];

Teraz dalej, jak zrobimy

int br = v[1];

On się rzuca, że nie można za inta podstawić stringa. I ma rację, bo trzeba to zamienić. Czyli używamy do tego Integer.parseInt();

int br = Integer.parseInt(v[1]);

To juz powielamy. Na końcu zwracamy nową statystykę, czyli z tymi danymi wykonujemy konstruktor:

public static Stat valueOf(String value) {
    String[] v = value.split(":");
    String p = v[0];
    int br = Integer.parseInt(v[1]);
    int cr = Integer.parseInt(v[2]);
    int dd = Integer.parseInt(v[3]);
    int dy = Integer.parseInt(v[4]);
    int en = Integer.parseInt(v[5]);
    int kl = Integer.parseInt(v[6]);
    int pl = Integer.parseInt(v[7]);
    return new Stat(p, br, cr, dd, dy, en, kl, pl);
}

Teraz już będzie z górki. Musimy przerobić metodę onDisable, zacznijmy od zlikwidowania błędów. Zamiana nazw. Potem zostawiamy tylko ostanią wartość, której na końcu dopisujemy ".toString()". I na tym wykonujemy save.

@Override
public void onDisable() {
    for (Entry<String, Stat> entry : list.entrySet()) {
        String s = list.get(entry.getKey()).toString();
        save(s);
    }
}

Natomiast w metodzie load usuwamy 5 linijek:

String nick = line.split(":")[0];
int k = Integer.parseInt(line.split(":")[1]);
int d = Integer.parseInt(line.split(":")[2]);kills.put(nick, k);
deads.put(nick, d);

i na ich miejsce tak: najpierw przekształcamy linię w zmienną typu Stat, potem ją dodajemy do listy. Czyli:

Stat s = Stat.valueOf(line);
list.put(line.split(":")[0], s);

Ufff! Działa! Teraz wystarczy podpiąć pod maszyne sortującą i mamy statystyki 🙂 eśli ktoś się po drodze pogubił kod klas:

Klasa Testowy

package eu.andret.testowy;

import java.io.BufferedReader;
import java.io.File;
import java.io.FileReader;
import java.io.FileWriter;
import java.io.IOException;
import java.io.PrintWriter;
import java.util.Arrays;
import java.util.HashMap;
import java.util.Map;
import java.util.Map.Entry;
import org.bukkit.Bukkit;
import org.bukkit.Material;
import org.bukkit.configuration.file.FileConfiguration;
import org.bukkit.inventory.ItemStack;
import org.bukkit.inventory.ShapedRecipe;
import org.bukkit.inventory.meta.ItemMeta;
import org.bukkit.plugin.java.JavaPlugin;

public class Testowy extends JavaPlugin {
    private static ItemStack is;
    private static File dataFolder;
    public static Map<String, Stat> list = new HashMap<>();

    @Override
    public void onEnable() {
        FileConfiguration config = getConfig();
        config.addDefault("chestplate.name", "&5Healing diamond chestplate");
        config.addDefault("chestplate.lore", "Makes heal\rfrom damage!");
        config.options().copyDefaults(true);
        saveConfig();
        getCommand("komenda").setExecutor(new Komenda());
        getServer().getPluginManager().registerEvents(new HealthRegen(), this);
        getServer().getPluginManager().registerEvents(new ChestplateEffect(), this);
        getServer().getPluginManager().registerEvents(new Kill(), this);
        is = new ItemStack(Material.DIAMOND_CHESTPLATE);
        ItemMeta im = is.getItemMeta();
        im.setDisplayName(config.getString("chestplate.name").replace("&", "§"));
        im.setLore(Arrays.asList(config.getString("chestplate.lore").replace("&", "§").split("\r")));
        is.setItemMeta(im);
        ShapedRecipe hrecipe = new ShapedRecipe(is);
        hrecipe.shape("@@@", "@#@", "@@@");
        hrecipe.setIngredient('@', Material.GOLD_INGOT);
        hrecipe.setIngredient('#', Material.DIAMOND_CHESTPLATE);
        Bukkit.getServer().addRecipe(hrecipe);
        dataFolder = getDataFolder();
        if (!dataFolder.exists()) {
            dataFolder.mkdir();
        }
        load();
    }

     @Override
    public void onDisable() {
        for (Entry<String, Stat> entry:list.entrySet()) {
            String s = list.get(entry.getKey()).toString();
            save(s);
        }
    }

    public static ItemStack getItem() {
        return is;
    }

    public static void log(String message) {
        try {
            File saveTo = new File(dataFolder, "logs.log");
            if (!saveTo.exists()) {
                saveTo.createNewFile();
            }
            FileWriter fw = new FileWriter(saveTo, true);
            PrintWriter pw = new PrintWriter(fw);
            pw.println(message);
            pw.flush();
            pw.close();
        } catch (IOException ex) {
            ex.printStackTrace();
        }
    }

    public static void save(String message) {
        try {
            File saveTo = new File(dataFolder, "data.tmp");
            if (!saveTo.exists()) {
                saveTo.createNewFile();
            }
            FileWriter fw = new FileWriter(saveTo, true);
            PrintWriter pw = new PrintWriter(fw);
            pw.println(message);
            pw.flush();
            pw.close();
        } catch (IOException ex) {
            ex.printStackTrace();
        }
    }

    public static void load() {
         try {
            File file = new File(dataFolder, "data.tmp");
            if (file.exists()) {
                BufferedReader reader = new BufferedReader(new FileReader(file));
                String line = "";
                while ((line = reader.readLine()) != null) {
                    Stat s = Stat.valueOf(line);
                    list.put(line.split(":")[0], s);
                }
                reader.close();
                file.delete();
            }
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

Klasa Kill

package eu.andret.testowy;

import org.bukkit.entity.LivingEntity;
import org.bukkit.entity.Player;
import org.bukkit.event.EventHandler;
import org.bukkit.event.Listener;
import org.bukkit.event.entity.EntityDeathEvent;
import org.bukkit.event.player.PlayerJoinEvent;

public class Kill implements Listener {
    @EventHandler
    public void kill(EntityDeathEvent e) {
        LivingEntity entity = e.getEntity();
        LivingEntity killer = entity.getKiller();
        if (entity instanceof Player) {
            Player en = (Player) entity;
            if (killer instanceof Player) {
                Player k = (Player) killer;
                Testowy.getInstance().getList().get(k.getName()).addKill();
                Testowy.getInstance().getList().get(en.getName()).addDeads();
            } else {
                Testowy.getInstance().getList().get(en.getName()).addDeads();
            }
        } else if (killer instanceof Player) {
            Player k = (Player) killer;
            Testowy.getInstance().getList().get(k.getName()).addKill();
        }
    }

    @EventHandler
    public void join(PlayerJoinEvent e) {
        if (!Testowy.getInstance().getList().containsKey(e.getPlayer().getName())) {
            Testowy.getInstance().getList().put(e.getPlayer().getName(), new Stat(e.getPlayer().getName()));
        }
    }
}

Klasa Stat

package eu.andret.testowy;

public class Stat {
    private int kills;
    private int deads;
    private int enchants;
    private int crafted;
    private int placed;
    private int broken;
    private int destroyed;
    private String player;

    public Stat(String player) {
        this.player = player;
    }

    public Stat(String player, int broken, int crafted, int deads, int destroyed, int enchants, int kills, int placed) {
        this.player = player;
        this.broken = broken;
        this.crafted = crafted;
        this.deads = deads;
        this.destroyed = destroyed;
        this.enchants = enchants;
        this.kills = kills;
        this.placed = placed;
    }

    public int getKills() {
        return kills;
    }

    public int getDeads() {
        return deads;
    }

    public int getEnchants() {
        return enchants;
    }

    public int getCrafted() {
        return crafted;
    }

    public int getPlaced() {
        return placed;
    }

    public int getBroken() {
        return broken;
    }

    public int getDestroyed() {
        return destroyed;
    }

    public String getPlayer() {
        return player;
    }

    //============================

    public void addKill() {
        kills++;
    }

    public void addDeads() {
        deads++;
    }

    public void addEnchats() {
        enchants++;
    }

    public void addCrafted() {
        crafted++;
    }

    public void addPlaced() {
        placed++;
    }

    public void addBroken() {
        broken++;
    }

    public void addDestroyed() {
        destroyed++;
    }

    public boolean equals(Stat Stat) {
        return this.player.equals(Stat.player);
    }

    @Override
    public String toString() {
        String s1 = this.player + ":";
        String s2 = String.valueOf(this.broken) + ":";
        String s3 = String.valueOf(this.crafted) + ":";
        String s4 = String.valueOf(this.deads) + ":";
        String s5 = String.valueOf(this.destroyed) + ":";
        String s6 = String.valueOf(this.enchants) + ":";
        String s7 = String.valueOf(this.kills) + ":";
        String s8 = String.valueOf(this.placed);
        return s1 + s2 + s3 + s4 + s5 + s6 + s7 + s8;
    }

    public static Stat valueOf(String value) {
        String[] v = value.split(":");
        String p = v[0];
        int br = Integer.parseInt(v[1]);
        int cr = Integer.parseInt(v[2]);
        int dd = Integer.parseInt(v[3]);
        int dy = Integer.parseInt(v[4]);
        int en = Integer.parseInt(v[5]);
        int kl = Integer.parseInt(v[6]);
        int pl = Integer.parseInt(v[7]);
        return new Stat(p, br, cr, dd, dy, en, kl, pl);
    }
}

Btw, tak wiem, że jest więcej statystyk, ale wpisanie własnego listenera na 3 linijki np. na uderzenie chyba nie wymaga tak wiele?

Zadanie domowe

Do całej klasy dodaj składnik, odpowiadajacy za uderzenie w jakieś żyjątko i obsłuż to zapisem, odczytem, getterem, setterem i listenerem 🙂

Temat #15: By nie pamiętać, co oznacza jaka wartość zmiennej...

Na pewno każdy z Was, albo przynajmniej większość zna plugin mcmmo. Tam da się levelować. ale nie tym się zajmiemy, czymś podobnym. Zrobimy klasy dla graczy w zależnosci od ilości zaenchantowanych itemów. I nie, nie mówię tutaj o levelach 1, 2, 3 itd. Z reszta zobaczycie. To wyjatkowo krótki i prosty dział. Stwórzmy najpierw nowego enuma. Nie klasę. Znaczy Enum to taka inna klasa. W każdym razie Pclick -> New -> Enum.

package eu.andret.testowy;

public enum Enchanter {
}

W klamrach napiszmy to jakie będą te stopnie, oddzielamy przecinkami, konwencje javy: pisać je wielkimi literami. Ja sobie wymyśliłem tak:

public enum Enchanter {
    BABY_ENCHANTER,
    YOUNG_ENCHANTER,
    MEDIUM_EXPERIENCED_ENCHANTER,
    EXPERIENCED_ENCHANTER,
    ENCHANT_MASTER
}

To nie koniec, cały czas jesteśmy w tym "enum" i koło każdej wartości dodajmy nawias i jakąś wartość do środka, może ona oznaczać - jak ja zdecydowałem - minimalna ilosć dokonanych enchantów by awansować na dany level. Więc zamieniamy to na np.:

public enum Enchanter {
    BABY_ENCHANTER(0),
    YOUNG_ENCHANTER(100),
    MEDIUM_EXPERIENCED_ENCHANTER(250),
    EXPERIENCED_ENCHANTER(1000),
    ENCHANT_MASTER(2500);
}

Wszystko wywala błędy, no wywala, bo brakuje mu konstruktora. Pamiętacie? Mówiłem o nim w poprzednim temacie. Kompilator za nas dopisze jedynie konstruktor domniemany, czyli bezargumentowy. U nas taki na nic się zda, bo wartości mamy, więc nie wychodząc z enuma piszemy:

Enchanter(int value) {
}

Zanim to uzupełnimy to tak jak w przypadku zwykłej klasy, enum też może przechowywać wartości. stwórzmy pole, prywatne, int:

private int value;

Teraz w konstruktorze za to value podstawiamy to z nawiasu:

this.value = value;

Czemu konstuktor bez oznacznika widoczności? Bo jest błędem, bo wyobrażacie sobie prywatny konstruktor? Bo ja nie. Ok, jeszcze kilka metod. Najpierw taka, która wyciągnie tę wartość value, czyli wiadomo, getValue:

public int getValue() {
    return value;
}

Potem trochę bardziej zaawansowana, metoda next(), zwracająca kolejnego enuma niż aktualny. Najpierw pusta metoda:

public Enchanter next() {
    return null;
}

Jest coś takiego jak ordinal() czyli aktualnie wybrany, dokładniej jego index. "oridinal()" jest tym co mam wybrane, nie wiem co to jest, ale wiem, że to jest wybrane. Mamy też metodę values() dla enuma, to tablica. Index tego co chcemy jako następny, nie może wyjść poza tą tablicę, czyli cokolwiek się dzieje, jeżeli obecny jest mniejszy niż ostatni w tablicy, czyli:

if (ordinal() < Enchanter.values().length - 1) {
}

A tutaj, jeżeli tak to zwracamy wartość kolejną

return Enchanter.values()[ordinal() + 1];

Else'a nie dajemy, bo nie trzeba, no bo nic nie zwracamy, efekt:

public Enchanter next() {
    if (ordinal() < Enchanter.values().length - 1) {
        return Enchanter.values()[ordinal() + 1];
    }
    return null;
}

Tu narazie tyle. Macie oczywiście listenera na enchanty, nie?

@EventHandlerpublic void enchant(EnchantItemEvent e) {
    Testowy.getInstance().getList().get(e.getPlayer().getName()).addEnchats();
}

Wróćmy jednak do klasy Stat. Stwórzmy nowe pole typu naszego typu wyliczeniowego:

private Enchanter enchantStatus;

Zróbmy gettera tego czegoś.

public Enchanter getEnchantStatus() {
    return enchantStatus;
}

Oraz settera:

public void setEnchantStatus(Enchanter e) {
    enchantStatus = e;
}

Ok, teraz w pierwszym konstruktorze ustawmy mu po chamsku pierwszy status:

enchantStatus = BABY_ENCHANTER;

a do drugiego konstukrota dodajemy kolejny argument typu Enchanter, np. "Enchanter status" i go ustawiamy:

enchantStatus = status

To wywala kilka błędów, narazie się tym nie przejmuj. Teraz chwila myślenia, to też trzebaby zapisać do pliku, bo zrobimy reload i dpokóki on tego nie zaenchantuje to będzie miał ten status BABY_ENCHANTER. No to co, zapisujemy status do pliku, nie? NIE. Przecież mamy wskaźnik! Mamy ilość enchantów, brakuje tylko metody, która to rozpozna! Wracamy do enuma i tworzymy metodę, ja stworzę getLevel(int), o tak:

public static Enchanter getLevel(int value) {
}

i teraz sprzawdzamy kolejno, czy jest wieksze od największego jak tak to najwyższy status, jak nie to to samo dla jednego niżej, a, że mamy metodę next() to jej użyjemy
Oraz metoda get(int) czyli:

public static Enchanter get(int value) {
}

teraz żaby łatwiej się sprawdzało odwróćmy listę

Enchanter[] tmp = values();
ArrayUtils.reverse(tmp);

Dlaczego tablica tymczasowa? Bo reverse modyfikuje faktyczna tablicę a nie jej kopię, więc po pierwszym odwrocie byłąby od tyłu, po drugim normalnie. No dobra, lecimy for'em po wszytkich values, a że są odwrócone ruszymy od końca:

for (Enchanter e : tmp) {
}

Sprawdzamy kolejno czy level następnika danego poziomu enchantera jest wiekszy niż podany, jeżeli tak, zwracamy wybrany, czyli:

if (e.next().value > value) {
    return e;
}

Może się zdarzyć, że wylecimy poza zakres, więc trzeba się zabezpieczyć try - catch.

try {
    if (e.next().value>value) {
        return e;
    }
} catch (NullPointerException ex) {
}

Jako, że on dalej ma problem, bo to ma szansę nic nie zwrócić, więc po całej pętelce zwracamy mastera.

return ENCHANT_MASTER;

Czyli pełna metoda:

public static Enchanter getLevel(int value) {
    for (Enchanter e : values()) {
        if (e.next().value > value) {
            return e;
        }
    }
    return ENCHANT_MASTER;
}

Nie jest to jakoś trudna metoda. Wracamy do Statów, tam na dole jest błąd, bo konstruktor wymaga nowego agrumentu, musimy go skombinować, więc przed returnem tworzymy:

Enchanter es = Enchanter.getLevel(en);

i dodajemy to "es" jako kolejny argument, czyli mamy teraz metodę:

public static Stat valueOf(String value) {
    String[] v = value.split(":");
    String p = v[0];
    int br = Integer.parseInt(v[1]);
    int cr = Integer.parseInt(v[2]);
    int dd = Integer.parseInt(v[3]);
    int dy = Integer.parseInt(v[4]);
    int en = Integer.parseInt(v[5]);
    int kl = Integer.parseInt(v[6]);
    int pl = Integer.parseInt(v[7]);
    Enchanter es = Enchanter.getLevel(en);
    return new Stat(p, br, cr, dd, dy, en, kl, pl, es);
}

Wreszcie ten upragniony, z dawna oczekiwany listener! Jak mamy proste obliczenia:

@EventHandler
public void enchant(EnchantItemEvent e) {
    String nick = e.getEnchanter().getName();
    Testowy.getInstance().getList().get(nick).addEnchats();
}

Stworzę sobie zmienną pomocniczą, żeby nie pisać w kołko "Testowy.getInstance().getList().get(nick)" więc piszę:

Stat s = Testowy.getInstance().getList().get(nick);

Oczywiście tego nie musisz, możesz pisać tę dlugą formułę 😜 Teraz sprawdzamy czy nasza ilość enchantów zrównała się lub przekroczyłą próg na wyższy niżobecny level:

if (s.getEnchants() >= s.getEnchantStatus().next().getValue()) {
}

jeśli tak niech gracz awansuje:

s.setEnchantStatus(s.getEnchantStatus().next());

No tak, to już. Możesz mu tam wysłać jaką wiadomość w stylu "Gratulacje, awansowałeś!". Teraz tak, w jednej klasie może być kilka enumów, ale robi się śmietnik, jeśli chcesz - nie ma problemu. Teraz tu gdzie majstrowałem:

EnumEnchanter:

package eu.andret.testowy;

public enum Enchanter {
    BABY_ENCHANTER(0),
    YOUNG_ENCHANTER(100),
    MEDIUM_EXPERIENCED_ENCHANTER(250),
    EXPERIENCED_ENCHANTER(1000),
    ENCHANT_MASTER(2500);

    private int value;

    Enchanter(int i) {
        value = i;
    }

    public int getValue() {
        return value;
    }

    public Enchanter next() {
        if (ordinal() < Enchanter.values().length - 1) {
            return Enchanter.values()[ordinal() + 1];
        }
        return ENCHANT_MASTER;
    }

    public static Enchanter getLevel(int value) {
        for (Enchanter e : values()) {
            if (e.next().value > value) {
                return e;
            }
        }
        return ENCHANT_MASTER;
    }
}

Kill:

package eu.andret.testowy;

import org.bukkit.entity.LivingEntity;
import org.bukkit.entity.Player;
import org.bukkit.event.EventHandler;
import org.bukkit.event.Listener;
import org.bukkit.event.enchantment.EnchantItemEvent;
import org.bukkit.event.entity.EntityDeathEvent;
import org.bukkit.event.player.PlayerJoinEvent;

public class Kill implements Listener {
    @EventHandler
    public void kill(EntityDeathEvent e) {
        LivingEntity entity = e.getEntity();
        LivingEntity killer = entity.getKiller();
        if (entity instanceof Player) {
            Player en = (Player) entity;
            if (killer instanceof Player) {
                Player k = (Player) killer;
                Testowy.getInstance().getList().get(k.getName()).addKill();
                Testowy.getInstance().getList().get(en.getName()).addDeads();
            } else {
                Testowy.getInstance().getList().get(en.getName()).addDeads();
            }
        } else if (killer instanceof Player) {
            Player k = (Player) killer;
            Testowy.getInstance().getList().get(k.getName()).addKill();
        }
    }

    @EventHandler
    public void join(PlayerJoinEvent e) {
        if (!Testowy.getInstance().getList().containsKey(e.getPlayer().getName())) {
            Testowy.getInstance().getList().put(e.getPlayer().getName(), new Stat(e.getPlayer().getName()));
        }
    }

    @EventHandler
    public void enchant(EnchantItemEvent e) {
        String nick = e.getEnchanter().getName();
        Testowy.getInstance().getList().get(nick).addEnchats();
        Stat s = Testowy.getInstance().getList().get(nick);
        if (s.getEnchants() >= s.getEnchantStatus().next().getValue()) {
            s.setEnchantStatus(s.getEnchantStatus().next());
        }
    }
}

Stat:

package eu.andret.testowy;

public class Stat {
    private int kills;
    private int deads;
    private int enchants;
    private int crafted;
    private int placed;
    private int broken;
    private int destroyed;
    private String player;

    public Stat(String player) {
         this.player = player;
    }

    public Stat(String player, int broken, int crafted, int deads, int destroyed, int enchants, int kills, int placed) {
         this.player = player;
         this.broken = broken;
         this.crafted = crafted;
         this.deads = deads;
         this.destroyed = destroyed;
         this.enchants = enchants;
         this.kills = kills;
         this.placed = placed;
     }

     public int getKills() {
         return kills;
     }

     public int getDeads() {
         return deads;
     }

     public int getEnchants() {
         return enchants;
     }

     public int getCrafted() {
         return crafted;
     }

     public int getPlaced() {
         return placed;
     }

     public int getBroken() {
         return broken;
     }

     public int getDestroyed() {
         return destroyed;
     }

     public String getPlayer() {
         return player;
     }

     //============================

     public void addKill() {
         kills++;
     }

     public void addDeads() {
         deads++;
     }

     public void addEnchats() {
         enchants++;
     }

     public void addCrafted() {
         crafted++;
     }

     public void addPlaced() {
         placed++;
     }

     public void addBroken() {
         broken++;
     }

     public void addDestroyed() {
         destroyed++;
     }

     public boolean equals(Stat Stat) {
         return this.player.equals(Stat.player);
     }

     @Override
     public String toString() {
         String s1 = this.player + ":";
         String s2 = String.valueOf(this.broken) + ":";
         String s3 = String.valueOf(this.crafted) + ":";
         String s4 = String.valueOf(this.deads) + ":";
         String s5 = String.valueOf(this.destroyed) + ":";
         String s6 = String.valueOf(this.enchants) + ":";
         String s7 = String.valueOf(this.kills) + ":";
         String s8 = String.valueOf(this.placed);
         return s1 + s2 + s3 + s4 + s5 + s6 + s7 + s8;
     }

     public static Stat valueOf(String value) {
         String[] v = value.split(":");
         String p = v[0];
         int br = Integer.parseInt(v[1]);
         int cr = Integer.parseInt(v[2]);
         int dd = Integer.parseInt(v[3]);
         int dy = Integer.parseInt(v[4]);
         int en = Integer.parseInt(v[5]);
         int kl = Integer.parseInt(v[6]);
         int pl = Integer.parseInt(v[7]);
         return new Stat(p, br, cr, dd, dy, en, kl, pl);
     }
}

Zadanie domowe:

Po prostu dodaj podobne levele dla kopacza.

Temat #16: Może tak połączymy się z bazą danych?

W kółko słyszymy o bazach danych, o zestawieniach i instrukcjach bazodanowych, a co to jest tak naprawdę? Baza danych to po trochu excel. Zbiera w tabelach dane. Z tą różnicą, że w bazie danych da się te dane bardziej powiązać ze soba niż pozwala na to tradycyjny arkusz kalkulacyjny. Polecam pobawić się Microsoft Office Access, poczytać tutoriale, potem nauczyć się Accessowskiej składni SQLa a potem przenieść się do phpMyAdmina i używać składni MySQLa. Jeżeli zobaczę, że Wam na tym zależy napiszę osobny poradnik korzystania z zapytań MySQL, tutaj jedynie opiszę jak je wykonać w JAVIE (tak, nie ma błędu polecenia MySQL sie wykonuje).

No dobra, jeżeli ktoś nie ma serwera z bazą danych, polecam program "xampp", on postawi bazę danych na phpMyAdmin, lokalnie. Ja właśnie na takowej będę operował. Jeżeli nie bawiliscie się ustawieniami to ip to "localhost", login to "root" a hasło puste. No dobra, ale po do nam ta baza? Najprostszy przykład, który z reszta wykonamy, to nasze staytystyki chcemy mieć w bazie danych, by następnie (znając php) na stronie je wylistować. I odrazu to widać. Oczywiście nie bedę tutaj pokazywał jak zdobyć dane php na stronie, zajmiemy się wysłaniem ich z pluginu do bazy.

Dobra, koniec pieprzenia jak stara przekupa na targu. Myślimy. Kiedy co ma się zdarzyć. Zacznijmy od tego, by plugin przygotował sobie strukturę. Czyli jak damy komus plugin, ten ktoś nie musi się niczym martwić, bo nasz plugin sam sobie stworzy bazę danych, tabele i wszystko cacy. No dobra, ale co w kodzie? Myślę, że dobrym pomysłem jest to zrobić kiedy ktoś będzie próbował wykonać akcję na bazie danych. Będzie sporo zmian. Najpierw stworzymy takie cudo jak konstruktor statyczny klasy (inaczej statyczny blok inicjalizacji danych klasy) PlayerManager. Wygląda on tak:

static {
}

A kiedy się wywoła? Za pierwszym razem kiedy cokolwiek w tej klasie zostanie użyte. I wykona się DOKŁADNIE 1 raz w czasie życia pluginu (od start do stop/reload). Zróbmy więc składnik, który będzie tym naszym połączeniem. Więc w klasie PlayerManager

private static Connection sql;

W statycznym konstruktorze inicjalizujemy o w ten sposób:

sql = DriverManager.getConnection("jdbc:mysql://localhost", "root", "");

I to nam zaczyna krzyczeć. Niestety to wymaga try - catch, więc dajemy to rozwiązanie.Ale najpierw musimy wiedzieć jaka będzie nazwa bazy danych oraz tabeli. O ile nazwę bazy danych używa się raz (przy tworzeniu) to nazwę tabeli używa się w kółko. Więc teraz zrobimy nową klasę, ja ją nazwę Data. Ona będzie przechowywała tylko dane, żadnego działania. Więc mam tak:

public class Data {
    public static final String tablename = "stats";
}

Teraz tak, wykonujemy polecenia na statemencie, czyli sql.createStatement() a potem w zależności od tego czy oczekujemy wyniku czy nie co innego. Najpierw to bez wyniku. No bo jaki wynik zwraca tworzenie?

Statement stat = sql.createStatement();
stat.execute("CREATE DATABASE IF NOT EXISTS testowy");

Ale to wymaga try - catcha. Więc go dajmy juz tu.

To polecenie tworzy bazę danych. Potem mówimy mu z której ma korzystać. No z tej utworzonej.

stat.execute("USE testowy");

Ok, więc teraz tworzymy tabelę. Zastanówmy się. Jakie pola i jakiego typu? Dokładnie tak samo jak w klasie Stats. Tylko zacznijmy od nicku gracza. No po kolei. A żeby nie pisać na sztywno nazwy tabeli, ja uzyję tej z klasy Data. Po to jest.

stat.execute("CREATE TABLE IF NOT EXISTS " + Data.tablename + "(nick VARCHAR(64) PRIMARY KEY, kills INT, deads INT, enchants INT, crafted INT, placed INT, broken INT, destroyed INT)");

Śliczne, nie? 😄 Nie bedę pisał wszędzie, bo tak naprawdę kod to kopiuj - wklej, zmień dane, napiszę jeden przykład i resztę sobie sami dopiszecie, bo to analogicznie. Ale dobra, najpierw jak gracz wbije na serwer wciepmy go do naszej tabeli, o ile nie istnieje, z zerowymi statystykami. Właśnie, o ile nie istnieje. Trzeba sprawdzić czy istnieje. Gdzie? Ha, no niestety w bazie danych. Zapytanie napiszemy w momencie kiedy ktoś chce takiego playera z klasy PlayerManager. Czyli gdzie? W getLocalPlayer() wykonujemy zapytanie. Jakie? Sprawdzamy czy ktoś o tym nicku jest w bazie.

PreparedStatement stat = sql.prepareStatement("SELECT * FROM " + Data.tablename + "  WHERE `nick` = ?;");

Co to jakieś dziwne "PreparedStatement" i pytajnik? To zapobiega tzw. SQLInjection. Polecam poczytać. Trzeba zastąpić pytajnik naszym graczem

stat.setString(1, player.getName());

Już tłumaczymy. W przygotowanym zapytaniu zastępujemy pierwszy pytajnik (wyjątkowo liczymy od 1) Stringiem, którego wartość jest równa player.gatName(). Wykonujemy zapytanie

ResultSet rs = stat.executeQuery();

Dlaczego poprzednio execute() a teraz executeQuery()? samo execute() wykonuje polecenie ale nie daje wyniku. executeQuery zwraca wynik (własnie ResultSet) na którym można pracować. No a sprawdzenie to właśnie pobranie wyniku, więc chyba się przyda. Teraz na tym sprawdzamy czy nie ma żadnego rekordu

if (!rs.next()) {
}

rs.next() przenosi wskaźnik o 1 rekord do przodu i zwraca prawdę jeśli sie udało, lub false, jeśli nie ma gdzie przenieść, bo jest po ostatnim. Jak nie ma żanego, to jest po ostatnim, bo przed nim nie ma żadnego. Więc jeśli nie ma następnego rekordu a wskaźnik jest przed pierwszym, znaczy, ze nie ma żadnego. Więc tutaj wpisujemy nowy rekord.

PreparedStatement stat1 = new PreparedStatement("INSERT INTO " + Data.tablename + " VALUES(?, 0, 0, 0, 0, 0, 0, 0)");stat1.setString(1, player.getName());

Jak widać wszystko wywala błędy. Zróbmy jednego duzego try catch. I ostatecznie metoda ta wygląda tak o:

public static final LocalPlayer getLocalPlayer(Player player) {
    if (!players.containsKey(player)) {
        players.put(player, new LocalPlayer(player.getName()));
    }
    try {
        PreparedStatement stat = sql.prepareStatement("SELECT * FROM " + Data.tablename + "  WHERE `nick` = ?;");
        stat.setString(1, player.getName());
        ResultSet rs = stat.executeQuery();
        if (!rs.next()) {
            PreparedStatement stat1 = new PreparedStatement("INSERT INTO " + Data.tablename + " VALUES(?, 0, 0, 0, 0, 0, 0, 0)");
            stat1.setString(1, player.getName());
            stat1.execute();
        }
    } catch (SQLException e) {
        e.printStackTrace();
    }
    return players.get(player);
}

A kiedy musimy puścic aktualizację? Np. na addKill() dla LocalPlayera. Pytanie, dla jakiego klucza? No własnie. Nie mamy go. Najłatwiej bedzie posiadać w LocalPlayer pole z nazwą użytkownika, tylko w celu obsługi bazy danych. Więc je dodajmy. Do konstruktora też.

private String nick;

public LocalPlayer(String nick) {
    this.nick = nick;
}

Spójrzcie... musimy zrobić update, ale nie mamy sql... Można oczywiscie zrobić gettera, ale jest lepszy sposób. Dodajmy Connection jako składnik klasy LocalPlayer i to też dodajmy do konstuktora (w PlayerManager przy new LocalPlayer też!). Czyli PlayerManager wygląda tak:

public static final LocalPlayer getLocalPlayer(Player player) {
    if (!players.containsKey(player)) {
        players.put(player, new LocalPlayer(player.getName(), sql));
    }
    try {
        PreparedStatement stat = sql.prepareStatement("SELECT * FROM " + Data.tablename + "  WHERE `nick` = ?;");
        stat.setString(1, player.getName());
        ResultSet rs = stat.executeQuery();
        if (!rs.next()) {
            PreparedStatement stat1 = new PreparedStatement("INSERT INTO " + Data.tablename + " VALUES(?, 0, 0, 0, 0, 0, 0, 0)");
            stat1.setString(1, player.getName());
            stat1.execute();
        }
    } catch (SQLException e) {
        e.printStackTrace();
    }
    return players.get(player);
}

Natomiast początek (bo więcej nie zmienialiśmy) klasy LocalPlayer tak:

package eu.andret.testowy;

import java.sql.Connection;
import java.sql.SQLException;
import java.sql.Statement;
import java.util.HashMap;
import java.util.Map;
import eu.andret.testowy.EnchantLevel;

public class LocalPlayer {
    private int kills;
    private int deads;
    private int enchants;
    private int crafted;
    private int placed;
    private int broken;
    private int destroyed;
    private EnchantLevel enchantLevel = EnchantLevel.BABY_ENCHANTER;
    private String nick;
    private Connection sql;

    public LocalPlayer(String nick, Connection sql) {
        this.nick = nick;
        this.sql = sql;
    }

    //.................
}

I teraz weźmy pierwszego settera z brzegu, addKill. Tam zmienimy kille na o 1 więcej.

public void addKill() {
    kills++;
    try {
        PreparedStatement stat = sql.prepareStatement("UPDATE " + Data.tablename + " SET kills=kills+1 WHERE `nick` = ?");
        stat.setString(1, player);
        stat.executeUpdate();
    } catch (SQLException e) {
        e.printStackTrace();
    }
}

Nie ma wielkiej filozofii. executeUpdate() pozwala na aktualizację danych a nie tylko ich wpisanie. W innych setterach tak samo. Tak dla równowagi, nie bedę z tego korzystał, ale polecenie, żeby pobrac np. ilość killi to

To jest ukryta treść, proszę

Ostatecznie, po zmianach moja klasa LocalPlayer wygląda tak:

To jest ukryta treść, proszę

Zadanie domowe:

Pozwól każdemu graczowi na sprawdzenie swoich statystyk w bazie danych (komendą)

Temat #17: Update checker, miło go mieć!

Ten jak i kolejny temat wymagają, by plugin był na serwisie bukkit dev. Ponieważ używam sposobu na łączenie sie własnie z nimi, bukkit ma własne sposoby. No tak, no tak, łączenie się, sposoby, a co to ten update checker? Angielski się kłania. Update checker to takie narzędzie, które sprawdza czy pojawiła się nowa wersja pluginu na bukkicie i w razie potrzeby informuje o tym. Na pozór łatwe. Tylko na pozór... Zacznijmy od kawałka teorii. Użyjemy tutaj czegoś co się zwie JSON. Czyli JavaScript Object Notation. To nic innego jak stworzone na potrzeby javascriptu sposób zapisu danych, jednak stał się on na tyle uniwersalny, że bardzo dużo (przynajmniej tych najpopularniejszych) języków z tego korzysta. Ponieważ ułatwia on wymianę danych w sieci pomiędzy językami.

No dobra, stwórzmy sobie nową klasę, ja swoją nazwę UpdateChecker. I w niej publiczbą, logiczną, statyczną metodę. Nazwę ją needUpdate(). Czyli mamy

public static boolean needUpdate() {    }

Zróbmy od razu try - catcha, złapmy pokemonowo wszystkie wyjątki i po całości return false; czyli

try {   } catch (Exception ex) {    ex.printStackTrace();}

do tego nad metodą stwórzmy pola

private static URL fileFeed;private static String version, link;

Teraz zabawa w lokalizowanie pluginu. Tutaj jest teoria

http://wiki.bukkit.org/ServerMods_API

którą Wam wyjaśnię. Tam z resztą widać przykład JSON. Dobra, ale mamy link

https://api.curseforge.com/servermods/projects?search=worldedit

Na końcu widać "?search=worldedit" (jeśli ktoś zna php to widzi tutaj zapytanie GET). A my zamiast worldedita chcemy nasz plugin, nie? więc wpisujemy nazwę naszego pluginu. WSZYSTKO MAŁYMI LITERAMI. Ja tego pluginu testowego tam nie uploadowałem ale posłużę się moim pluginem, który juz tam jest: atsHelp. więc mój link wygląda tak:

https://api.curseforge.com/servermods/projects?search=atshelp

Wpisuję to i co widzę? To:

[{"id":75635,"name":"atsHelp","slug":"atshelp","stage":"mature"}]

Dostajemy info o pluginie. Możecie wpisać np. "helpme" - wiem, ze wtedy macie dużo wyników. Jeżeli się zdarzy, że mamy właśnie kilka wyników to szukamy naszego pluginu. On ma jakieś id, w moim przypadku 75635. Więc wykonując drugie zapytanie:

https://api.curseforge.com/servermods/files?projectIds=33921

czyli wyszukujemy plugin po id. Ja wpisuję swoje ID i mam taki link:

https://api.curseforge.com/servermods/files?projectIds=75635

Mam już wszytskie dane na temat moich wszystkich plików, ja widzę coś takiego:

[{"downloadUrl":"http:\/\/servermods.cursecdn.com\/files\/777\/259\/atsHelp.jar","fileName":"atsHelp.jar","fileUrl":"http:\/\/www.curseforge.com\/files\/777259","gameVersion":"CB 1.7.2-R0.3","md5":"31db298dd2a7304f192e1719ce9b35c7","name":"atsHelp v1.0","projectId":75635,"releaseType":"release"},{"downloadUrl":"http:\/\/servermods.cursecdn.com\/files\/778\/467\/atsHelp.jar","fileName":"atsHelp.jar","fileUrl":"http:\/\/www.curseforge.com\/files\/778467","gameVersion":"CB 1.7.2-R0.3","md5":"6a06e5722a51d00ff96d29c8b2fff876","name":"atsHelp v1.1","projectId":75635,"releaseType":"release"},{"downloadUrl":"http:\/\/servermods.cursecdn.com\/files\/779\/537\/atsHelp.jar","fileName":"atsHelp.jar","fileUrl":"http:\/\/www.curseforge.com\/files\/779537","gameVersion":"CB 1.7.2-R0.3","md5":"936c37d66cdea16e0c29fceb7a3ba138","name":"atsHelp v1.2","projectId":75635,"releaseType":"release"},{"downloadUrl":"http:\/\/servermods.cursecdn.com\/files\/779\/790\/atsHelp.jar","fileName":"atsHelp.jar","fileUrl":"http:\/\/www.curseforge.com\/files\/779790","gameVersion":"CB 1.7.2-R0.3","md5":"bc4bc728ab7591eb3019904fe29f367c","name":"atsHelp v1.3","projectId":75635,"releaseType":"release"},{"downloadUrl":"http:\/\/servermods.cursecdn.com\/files\/780\/461\/atsHelp.jar","fileName":"atsHelp.jar","fileUrl":"http:\/\/www.curseforge.com\/files\/780461","gameVersion":"CB 1.7.2-R0.3","md5":"6dd441c2540e0fecab8612b901fa0484","name":"atsHelp v1.4","projectId":75635,"releaseType":"release"},{"downloadUrl":"http:\/\/servermods.cursecdn.com\/files\/780\/485\/atsHelp.jar","fileName":"atsHelp.jar","fileUrl":"http:\/\/www.curseforge.com\/files\/780485","gameVersion":"CB 1.7.2-R0.3","md5":"4c43ed83c7b993cb208d8b855a5ad6a5","name":"atsHelp v1.5","projectId":75635,"releaseType":"release"},{"downloadUrl":"http:\/\/servermods.cursecdn.com\/files\/782\/954\/atsHelp.jar","fileName":"atsHelp.jar","fileUrl":"http:\/\/www.curseforge.com\/files\/782954","gameVersion":"CB 1.7.2-R0.3","md5":"d7b11f8b496b75046dde4cdde7a90219","name":"atsHelp v1.6","projectId":75635,"releaseType":"release"},{"downloadUrl":"http:\/\/servermods.cursecdn.com\/files\/783\/650\/atsHelp.jar","fileName":"atsHelp.jar","fileUrl":"http:\/\/www.curseforge.com\/files\/783650","gameVersion":"CB 1.7.2-R0.3","md5":"2828c1350b29a5d2c500560202006ff0","name":"atsHelp v1.6.1","projectId":75635,"releaseType":"release"},{"downloadUrl":"http:\/\/servermods.cursecdn.com\/files\/783\/940\/atsHelp.jar","fileName":"atsHelp.jar","fileUrl":"http:\/\/www.curseforge.com\/files\/783940","gameVersion":"CB 1.7.2-R0.3","md5":"3c88c71dd249cb104eefacff83f5b10d","name":"atsHelp v2.0","projectId":75635,"releaseType":"release"},{"downloadUrl":"http:\/\/servermods.cursecdn.com\/files\/784\/834\/atsHelp.jar","fileName":"atsHelp.jar","fileUrl":"http:\/\/www.curseforge.com\/files\/784834","gameVersion":"CB 1.7.2-R0.3","md5":"a4ef5a6cb792a1cdcabeddd63fd854ae","name":"atsHelp v2.1","projectId":75635,"releaseType":"release"},{"downloadUrl":"http:\/\/servermods.cursecdn.com\/files\/784\/870\/atsHelp.jar","fileName":"atsHelp.jar","fileUrl":"http:\/\/www.curseforge.com\/files\/784870","gameVersion":"CB 1.7.2-R0.3","md5":"207f5e7a0be09771dbd33d4506173c2d","name":"atsHelp v2.1.1","projectId":75635,"releaseType":"release"},{"downloadUrl":"http:\/\/servermods.cursecdn.com\/files\/785\/40\/atsHelp.jar","fileName":"atsHelp.jar","fileUrl":"http:\/\/www.curseforge.com\/files\/785040","gameVersion":"CB 1.7.2-R0.3","md5":"402faeeb7e5f8f3c366008e7e80f0c69","name":"atsHelp v2.1.2","projectId":75635,"releaseType":"release"},{"downloadUrl":"http:\/\/servermods.cursecdn.com\/files\/785\/751\/atsHelp.jar","fileName":"atsHelp.jar","fileUrl":"http:\/\/www.curseforge.com\/files\/785751","gameVersion":"CB 1.7.2-R0.3","md5":"6d8b18c86cc5c71cf34abdb0bb1588f6","name":"atsHelp v2.2","projectId":75635,"releaseType":"release"}]

Niewiele widać nie? Dobra, zostawmy to, ten ostatni link z ID będzie Ci potrzebny, resztę możesz powyłączać. I teraz wracamy do eclipse i wszystko piszemy w try. Czyli wykonujemy konstruktor zmiennej typu URL własnie na nasz link z id, czyli

fileFeed = new URL("https://api.curseforge.com/servermods/files?projectIds=75635");

Następnie otwieramy połączenie i odrazu umożliwiamy przepływ informacji

InputStream input = fileFeed.openConnection().getInputStream();

Tutaj mała uwaga, ponieważ teraz korzystamy z rzeczy które mają dużo różnych importów to używamy tylko importów:
java.net
java.io
java.json
nie innych. Dobra, mamy otwarte połączenie, mamy przepływ informacji... teraz odpowiedź. Czyli

String response = new BufferedReader(new InputStreamReader(input)).readLine();

Czyli czytamy wszystko i czytamy, i dostajemy pierwsza linie z góry. Ale, że w tej linii jest wszystko to mamy dosłownie wszytkie dane w jednej linii... bardzo nieeleganckie. Teraz tworzymy tablicę JSON-a, czyli pomagamy mu ułożyć te dane, bo obecnie mamy stringa i ręczne ukłądanie danych... Jak chcesz - możesz.

JSONArray array = (JSONArray) JSONValue.parse(response);

Tak, musimy zrzutować, ale mamy pewność, że się powiedzie, ponieważ właśnie tak zostałą przygotowana serwerowa odpowiedź na bukkicie. A nawet jeśli nie to mamy try - catch i złapie nam wyjątek Teraz, jako, że najnowszy plik jest na samym dole, bierzemy obiekt z tej tablicy o ostatnim ID... Tyle... Tyle, że go nie znamy... Ale nie bój boja, mamy size tablicy! Nic prostszego

JSONObject latest = (JSONObject) array.get(array.size() - 1);

Dobra, jesteśmy już w ostatnim pliku. Teraz bierzemy jego name i używajac RegEx-a pozbywamy się wszystkiego pozostawiając jedynie wersję. (Chcesz się dowiedzieć więcej na temat RegEx-a? Pisz do mnie!)

version = ((String) latest.get("name")).replaceAll("[a-zA-Z ]", "");

Oraz bierzemy jego url do pobrania, zeby dać go userowi.

link = (String) latest.get("downloadUrl");

I teraz jeżeli nasz plugin ma takie same wersje, czyli np. wszystkie są 3 cyfrowe to łatwo prównać, natomiast kiedy ilości cyfr się mieszają... Musicie sobie sami opracować algorytm sprawdzania wersji. No, zeby sprawdzić czy ta na bukkicie nie jest aby nowsza od tej obecnie używanej. Ja dam swój, ale bez wyjaśnienia i dalej nie gwarantuję, że na bardzo zróżnicowanych działa.

double updateVersion = Double.parseDouble(version.replace(".", ""));double currentVersion = Double.parseDouble(Testowy.getInstance().getDescription().getVersion().replace(".", ""));while (String.valueOf(updateVersion).length() != String.valueOf(currentVersion).length()) {    if (String.valueOf(updateVersion).length() > String.valueOf(currentVersion).length()) {        currentVersion *= 10;    } else if (String.valueOf(updateVersion).length() < String.valueOf(currentVersion).length()) {        updateVersion *= 10;    }}

Trochę liczenia jest, ale działa... prawie Mnie zadawala, nie wiem jak się zachowa np. w przypadku wersji 2.12.3 i 2.2... Chcesz mieć pewnosć, że działą opracuj własny!
Teraz porównujemy czy jest wieksza ta na bukkicie, jeśli jest - zwracamy prawdę

if (updateVersion > currentVersion) {    return true;}

i to tyle. Dodajmy jeszcze na końcu dwie metody

public static String getVesion() {    return version;}public static String getLink() {    return link;}

Jesteśmy więc w klasie głównej. Bukkit od nas wymaga, by sprawdzanie update'ów administrator serwera korzystajacy z naszego pluginu mógł wyłączyć. Czyli opcja w configu. Więc do naszego pliku config.yml dodajmy:

update-checking: true

Więc sprawdzamy czy w configu dalej jest true, czy nikt nie zmienił na false. Jeśli zmienił to update checker się nie wykona.

if (getConfig().getBoolean("update-checking")) { }

oraz w tym sprawdzamy czy update checker znalazł nowszą wersję.

if (UpdateChecker.needUpdate()) {       }

I tutaj informujemy konsolę, że jest nowa wersja.

System.out.print("[Testowy] A newer version of plugin is available at: " + UpdateChecker.getLink());

Więc jakby ktoś się pogubił

Update checker:

package eu.andret.testowy; import java.io.BufferedReader;import java.io.InputStream;import java.io.InputStreamReader;import java.net.URL; import org.json.simple.JSONArray;import org.json.simple.JSONObject;import org.json.simple.JSONValue; public class UpdateChecker {    private static URL fileFeed;    private static String version, link;        public static boolean needUpdate() {        try {            fileFeed = new URL("https://api.curseforge.com/servermods/files?projectIds=75635");            InputStream input = fileFeed.openConnection().getInputStream();            String response = new BufferedReader(new InputStreamReader(input)).readLine();            JSONArray array = (JSONArray) JSONValue.parse(response);            JSONObject latest = (JSONObject) array.get(array.size() - 1);            version = ((String) latest.get("name")).replaceAll("[a-zA-Z ]", "");            link = (String) latest.get("downloadUrl");            double updateVersion = Double.parseDouble(version.replace(".", ""));            double currentVersion = Double.parseDouble(Testowy.getInstance().getDescription().getVersion().replace(".", ""));            while (String.valueOf(updateVersion).length() != String.valueOf(currentVersion).length()) {                if (String.valueOf(updateVersion).length() > String.valueOf(currentVersion).length()) {                    currentVersion *= 10;                } else if (String.valueOf(updateVersion).length() < String.valueOf(currentVersion).length()) {                    updateVersion *= 10;                }            }            if (updateVersion > currentVersion) {                return true;            }        } catch (Exception ex) {            ex.printStackTrace();        }        return false;    }        public static String getVesion() {        return version;    }        public static String getLink() {        return link;    }}

Klasa główna:

package eu.andret.testowy; import java.io.BufferedReader;import java.io.File;import java.io.FileReader;import java.io.FileWriter;import java.io.IOException;import java.io.InputStream;import java.io.PrintWriter;import java.util.Arrays;import java.util.HashMap;import java.util.Map;import java.util.Map.Entry; import org.bukkit.Bukkit;import org.bukkit.Material;import org.bukkit.configuration.file.FileConfiguration;import org.bukkit.configuration.file.YamlConfiguration;import org.bukkit.inventory.ItemStack;import org.bukkit.inventory.ShapedRecipe;import org.bukkit.inventory.meta.ItemMeta;import org.bukkit.plugin.java.JavaPlugin; public class Testowy extends JavaPlugin {      private static ItemStack is;    private static File dataFolder;    private static Testowy instance;    public static Map<String, Stat> list = new HashMap<String, Stat>();        @Override    public void onEnable() {        instance = this;        FileConfiguration config = getConfig();        saveDefaultConfig();        getCommand("komenda").setExecutor(new Komenda());        getServer().getPluginManager().registerEvents(new HealthRegen(), this);        getServer().getPluginManager().registerEvents(new ChestplateEffect(), this);        getServer().getPluginManager().registerEvents(new Kill(), this);        is = new ItemStack(Material.DIAMOND_CHESTPLATE);        ItemMeta im = is.getItemMeta();        im.setDisplayName(config.getString("chestplate.name").replace("&", "§"));        im.setLore(Arrays.asList(config.getString("chestplate.lore").replace("&", "§").split("\r")));        is.setItemMeta(im);        ShapedRecipe hrecipe = new ShapedRecipe(is);        hrecipe.shape("@@@", "@#@", "@@@");        hrecipe.setIngredient('@', Material.GOLD_INGOT);        hrecipe.setIngredient('#', Material.DIAMOND_CHESTPLATE);        Bukkit.getServer().addRecipe(hrecipe);        dataFolder = getDataFolder();        if (!dataFolder.exists()) {            dataFolder.mkdir();        }        load();        if (config.getBoolean("update-checking")) {            if (UpdateChecker.needUpdate()) {                System.out.print("[Testowy] A newer version of plugin is available at: " + UpdateChecker.getLink());            }        }    }     @Override    public void onDisable() {        for (Entry<String, Stat> entry:list.entrySet()){            String s = list.get(entry.getKey()).toString();            save(s);        }    }        public static ItemStack getItem(){        return is;    }        public static void log(String message){        try {            File saveTo = new File(dataFolder, "logs.log");            if (!saveTo.exists()) {                saveTo.createNewFile();            }            FileWriter fw = new FileWriter(saveTo, true);            PrintWriter pw = new PrintWriter(fw);            pw.println(message);            pw.flush();            pw.close();        } catch (IOException ex) {            ex.printStackTrace();        }    }        public static void save(String message){        try {            File saveTo = new File(dataFolder, "data.tmp");            if (!saveTo.exists()) {                saveTo.createNewFile();            }            FileWriter fw = new FileWriter(saveTo, true);            PrintWriter pw = new PrintWriter(fw);            pw.println(message);            pw.flush();            pw.close();        } catch (IOException ex) {            ex.printStackTrace();        }    }        public static void load(){         try {            File file = new File(dataFolder, "data.tmp");            if(file.exists()) {                BufferedReader reader = new BufferedReader(new FileReader(file));                String line = "";                while((line = reader.readLine()) != null) {                    Stat s = Stat.valueOf(line);                    list.put(line.split(":")[0], s);                }                reader.close();                file.delete();            }        } catch (Exception e) {            e.printStackTrace();        }    }     public static Testowy getInstance() {        return instance;    }}

Temat #18: Jak już wiemy o aktualizacji, to może ją pobierzmy?

Noo więc dobra, mamy pewność, że aktualizacja jest lub nie. Ale niektóre pluginy za zgodą administratora serwera mogą wręcz same takiego update'a pobrać. I to właśnie tutaj zrobimy. No więc mamy klasę UpdateChecker wyglądającą tak:

public class UpdateChecker {    private static URL fileFeed;    private static String version, link;        public static boolean needUpdate() {        try {            fileFeed = new URL("https://api.curseforge.com/servermods/files?projectIds=75635");            InputStream input = fileFeed.openConnection().getInputStream();            String response = new BufferedReader(new InputStreamReader(input)).readLine();            JSONArray array = (JSONArray) JSONValue.parse(response);            JSONObject latest = (JSONObject) array.get(array.size() - 1);            version = ((String) latest.get("name")).replaceAll("[a-zA-Z ]", "");            link = (String) latest.get("downloadUrl");            double updateVersion = Double.parseDouble(version.replace(".", ""));            double currentVersion = Double.parseDouble(Testowy.getInstance().getDescription().getVersion().replace(".", ""));            while (String.valueOf(updateVersion).length() != String.valueOf(currentVersion).length()) {                if (String.valueOf(updateVersion).length() > String.valueOf(currentVersion).length()) {                    currentVersion *= 10;                } else if (String.valueOf(updateVersion).length() < String.valueOf(currentVersion).length()) {                    updateVersion *= 10;                }            }            if (updateVersion > currentVersion) {                return true;            }        } catch (Exception ex) {            ex.printStackTrace();        }        return false;    }        public static String getVesion() {        return version;    }        public static String getLink() {        return link;    }}

Więc dopiszemy kolejną metodę. O tak o:

public static void getFile(String link) {    }

I wszystko na temat pobierania plikó będzie w niej. Jeszcze pytanie co do argumentu, używam go, bo jest łatwiej, ale oczywiście możeszie poeksperymentować i korzystać z tego co tam macie w środku klasy i wtedy juz bez argumentu. Mnie tak lepiej.
Dobra, więc... Tak jak w metodzie needUpdate() tak i w getFile(String) bedzie jeden duży try-catch. I narazie łapmy pokemonowo wyjątki.

public static void getFile(String link) {    try {     } catch (Exception ex) {        ex.printStackTrace();    }}

I dalej wszystko bedziemy pisali w bloku try. Wiec teraz z podanego stringa tworzymy URLa, czyli

URL url = new URL(link);

A następnie otwieramy połączenie ze wskazanym URLem

BufferedInputStream in = new BufferedInputStream(url.openStream());

Na tym etapie mamy mniej więcej ustablizowane połączenie. Teraz bawimy się lokalnie, czyli... Czyli. Trzeba gdzieś pacnąć tego pobranego update'a. Ja preferuję w folderze z serwerem zrobić folder /update i tam to zrobić. A jak? Hahaha, no trochę zabawy.

File file = new File(Testowy.getInstance().getDataFolder().getAbsolutePath() + "/update");

"Testowy.getInstance().getDataFolder().getAbsolutePath()" znaczy, że bierzemy ścieżkę bezwzględną na dysku do miejsca gdzie znajduje się serwer. Potem tylko dodajemy nasz folder. Następnie go tworzymy jesli nie ma

if (!file.exists()) {    file.mkdirs();}

Wiec mamy juz pewność, że folder istnieje. Teraz tworzymy nasz plik, który pobierzemy. On będzie właśnie w tym foldersze, tylko bedzie miał swoją nazwę, Czyli

File download = new File(file + "/atsHelp v" + version + ".jar");

W efekcie czego dostanę np. plik "atsHelp v2.2.jar". No i oczywiście wszystko dalej działa kiedy tego pliku update nie ma, czyli prosty if

if (!download.exists()) {}

No bo jak jest to po co pobierać? Teraz zamieniamy zmienną download w miejsce zapisu

BufferedOutputStream outputStream = new BufferedOutputStream(new FileOutputStream(download), 1024);

Oraz pobieramy całość. Najpierw tworzymy tablicę pomocniczą

byte data[] = new byte[1024];

(typ byte jest pierwszy w kolejności rozmiaru po boolean) a następnie pentelką go pobieramy

while (in.read(data, 0, 1024)>=0) {    outputStream.write(data);}

Na końcu zamykamy zapis

outputStream.close();

Po ifie zamykamy odczyt

in.close();

W efekcie czego metoda jest taka:

public static void getFile(String link) {    try {        URL url = new URL(link);        BufferedInputStream in = new BufferedInputStream(url.openStream());        File file = new File(Testowy.getInstance().getDataFolder().getAbsolutePath() + "/update");        if (!file.exists()) {            file.mkdirs();        }        File download = new File(file + "/atsHelp v" + version + ".jar");        if (!download.exists()) {            BufferedOutputStream outputStream = new BufferedOutputStream(new FileOutputStream(download), 1024);            byte data[] = new byte[1024];            while (in.read(data, 0, 1024)>=0) {                outputStream.write(data);            }            outputStream.close();        }        in.close();    } catch (Exception ex) {        ex.printStackTrace();    }}

Jednak jak w przypadku sprawdzania, tak w przypadku pobierania update'ów, administrator serwera MUSI mieć możliwość wyłączenia tego. Wiec w klasie głównej się pobawimy! O ile dobrze pamiętam, mamy ifa

if (config.getBoolean("check-updates")) {    if (UpdateChecker.needUpdate()) {        System.out.print("[Testowy] A newer version of plugin is available at: " + UpdateChecker.getLink());    }}

Wiec go rozbudujemy. Ale najpierw, w pliku, dodamy do configa kolejną opcję

auto-download-update: true

Ok, wracając do ifa, zanim wypiszemy, że nowa wersja jest dostępna sprawdźmy czy mamy prawo (z configa) ją pobrać, a napiszmy, że jest dostępna dopiero kiedy nie. Czyli zamiast naszego System.out.print'a napiszemy ifa:

if (config.getBoolean("auto-download-update")) {    UpdateChecker.getFile(UpdateChecker.getLink());} else {    System.out.print("[Testowy] A newer version of plugin is available at: " + UpdateChecker.getLink());}

Czyli jeżeli sprawdzanie updateów jest włączone i pobeiranie pliku jest włączone, pobierze go. Jeśli sprawdzanie jest włączone a pobieranie wyłączone - napisze o tym. A co jeśli sprawdzanie jest wyłączone a pobieranie włączone? Administrator to debil, ale i na to trzeba coś poradzić. Czyli do najbardziej zewnętrznego ifa dopisujemy else-if'a, który to sprawdzi.

} else if (config.getBoolean("auto-download-update")) {    System.out.print("[testowy] To download an update You must turn on the update checking!");}

Czyli cały ten if wygląda tak oto:

if (config.getBoolean("check-updates")) {    if (UpdateChecker.needUpdate()) {        if (config.getBoolean("auto-download-update")) {            UpdateChecker.getFile(UpdateChecker.getLink());        } else {            System.out.print("[Testowy] A newer version of plugin is available at: " + UpdateChecker.getLink());        }    }} else if (config.getBoolean("auto-download-update")) {    System.out.print("[testowy] To download an update You must turn on the update checking!");}

Temat #19: Cykl powtarza się cyklicznie, jak to cykl

No dobra, cykle, no jak wiadomo cykl to coś co wykonuje się cyklicznie. No czyli w kółko. No ale bukkit jest na tyle miły, że dał nam 2 możliwości. Albo przesunięcie wydarzenia w czasie, albo odtwarzanie tego samego co określona ilość czasu. Tak czy tak w obu przypadkach najlepiej jest użyć nowej klasy, ale oczywiście, jako, że java (dla wtajemnoczonych) posiada klasy anonimowe, jeśli się nie pogubisz, możesz bez nowej klasy. Ja wyjaśnię na nowej klasie, bo to łatwiej widać. Więc startujemy. Tworzymy nową klasę, i w oknie tworzenia, wiadomo nazwa, ale nie bedziemy po stworzeniu ręcznie nic dopisywać. Narazie nie zamykaj kreatora. Ja swoją klasę nazwę Curse, zobaczycie co bedzie robiła

Teraz, widzisz na dole okienko "Superclass"? Jest w nim wpisane domyślnie to: "java.lang.Object". Bo twórcy javy sobie wymyślili, że wszystko co stworzysz dziedziczy z obiektu, czyli WSZSTKO poza domyslnymi typami jest obiektem i ma wszystkie metody... typu Object. a typ Object... to każdy typ. W tym przechowasz wszystko. A jako, że WSZSYTKO z tego dziedziczy można tego nie pisać, dlatego nigdy nie było widać. Dobra, tutaj byś wybierał(a) gdybyś chciał(a) dopisac extends. Ale my chcemy implementować interfejs, więc w okienku niżej mamy "Interfaces", tutaj przycisk "Add", pacnij go i wpisz "Runnable", wybierz pierwsze co Ci się pokaże (dla pewności: "java.lang.Runnable"), zatwierdź i teraz finish. Jak widać ładnie się wygenerowało:

package eu.andret.testowy; public class Curse implements Runnable {     @Override    public void run() {        // TODO Auto-generated method stub     } }

Ale to cholernie rozbite, aż mi się źle patrzy, po lekkim czyszczeniu mamy ładniejszy kod:

package eu.andret.testowy; public class Curse implements Runnable {     @Override    public void run() {     }}

Znacznie lepiej. Teraz uwaga. To co mamy w metodzie run ro się wykona "co krok", to taka samowyzwalajaca się metoda. Więc w niej zabierzmy playerowi 2 hp (1 serce). No dobra, fajnie, a jakiemu playerowi, jak tu żadnego nie mam? Klasa jak każda inna ma prawo mieć swój konstruktor. I składniki. To zachowuje się na zwykła klasa z tą różnicą, że jest uruchamiana. Więc na chwile w klasie zapamiętamy sobie naszego playera, więc tworzymy składnik typu Player. Oczywiscie prwaytny

private Player player;

No... i konstruktor całej klasy

public Curse(Player player) {    this.player = player;}

Teraz wystarczy w metodzie run zastosować tę naszą akcję, zabranie mu hp.

player.setHealth(player.getHealth()-2);

Ale ja nie chce go zabć...

if (player.getHealth()>2) {    player.setHealth(player.getHealth()-2);} else if (player.getHealth()==2) {    player.setHealth(player.getHealth()-1);}

No i wyślijmy mu na końcu wiadomość. Żeby prościej było i mniej kodu daj to na początek, jak nie rozumiesz to daj do kazdego ifa

if (player.getHealth()>1) {    player.sendMessage("A masz!");}

To była ta trudniejsza szczęść. Teraz tylko uruchomienie tego cuda. Zróbmy może event na... Rzut jajkiem! więc w klasie Kill

@EventHandlerpublic void event(PlayerEggThrowEvent e) {    }

Teraz używamy schedulera. Czyli

Bukkit.getScheduler().

Na tym etapie mamy kilka opcji. Właściwie sporo, ale nas interesujate zaczynajace się od "schedule", i tutaj mamy ich 6, ale jako, że asynchroniczne są zdeprecjonowany, pisząc dalej "Sync" mamy 3 z których można skorzystać, ale nas interesują 2 dolne. DelayedTask i RepeatingTask. Najpierw to pierwsze, czyli uruchomienie zdarzenia jeden raz po uplynieciu okreslonego czasu. Wybieramy i mamy:

Bukkit.getScheduler().scheduleSyncDelayedTask(arg0, arg1, arg2);

On chce jakieś Plugin, jakieś Runnable i jakieś long. Co do pluginu - pamiętacie instancję? Skorzystajcie z niej. Drugi argument to Runnable, czyli musimy dać konstruktor naszej klasy Runnable. Ale... on wymaga argumentu typu player. To na tym playerze stosuje swoja "klatwę". więc pobieramy playera z eventu. I na końcu long, czyli jak długo ma się na te akcję czekać od jej wywołania. Podawany w tickach, czyli 20 to sekunda. Dajmy 60, 3 sekundy. No i mamy linijeczkę:

Bukkit.getScheduler().scheduleSyncDelayedTask(Testowy.getInstance(), new Curse(e.getPlayer()), 60);

Sprawdź.
Teraz zróbmy drugiego Eventa, np... Mało ambitne, zabicie.

@EventHandlerpublic void someEvent(EntityDeathEvent e) {    }

Tak, wiem, że już taki mamy, ale co, nie mam prawa mieć innego? Żeby nie śmiecić, bo to całkowicie co innego? Nie ma z tym problemu. No dobra, więc pobieramy z eventa co potrzebne, killera i zabitego

LivingEntity entity = e.getEntity();LivingEntity killer = entity.getKiller();

Sprawdzamy czym są. Zastosujmy tylko gdy... Hm... Gdy player zabił kurczaczka. Więc

if (entity.getType().equals(EntityType.CHICKEN) && killer instanceof Player) {}

Teraz linijka podobna jak poprzednio tyle, że zmieniamy "delayed" na "repeating" i... eclipse krzyczy. Bo Delayed wymaga 2 lub 3 argumentów (my wczesniej użylismy 3), a Repeating aż 4. Po co 4? na końcu zamiast jednego longa są 2. Pierwszy działa bez zmian, decydujemy jak późno od uruchomienia wykona się pierwszy raz. Drugi określa ile trwa przerwa miedzy jednym a kolejnym. Ja wybrałem 20 i 40, czyli sekundę i dwie. No i nie mamy e.getPlayer() więc zamieniamy killera w Playera

Bukkit.getScheduler().scheduleSyncRepeatingTask(Testowy.getInstance(), new Curse((Player)killer), 20, 40);

Czyli całe dwa eventy wyglądają tak:

@EventHandlerpublic void event(PlayerEggThrowEvent e) {    Bukkit.getScheduler().scheduleSyncDelayedTask(Testowy.getInstance(), new Curse(e.getPlayer()), 60);}@EventHandlerpublic void someEvent(EntityDeathEvent e) {    LivingEntity entity = e.getEntity();    LivingEntity killer = entity.getKiller();    if (entity.getType().equals(EntityType.CHICKEN) && killer instanceof Player) {        Bukkit.getScheduler().scheduleSyncRepeatingTask(Testowy.getInstance(), new Curse((Player)killer), 20, 40);    }}

Teraz jeszcze jedno pytanie. Bo nie chcemy, żeby player miał obniżane hp w nieskończoność lub do reloadu. Chcemy mu raz zjechać hp do pół serduszka i koniec. Więc trzeba takiego schedulera zatrzymać. Problem, jak? A tu niespodzianka. Wiecie co zwracają scheduleSyncRepeatingTask i scheduleSyncDelayedTask? Inta. Który jest jakby ich id. Wiec wystarczy odpowiednie id zatrzymać. Znowu pieprzenie się w globalne zmienne, ale inaczej tylko więcej roboty. Więc w klasie Kill robimy prywatną zmienną int.

private static int id;

Naszego scheduleSyncRepeatingTask podstawiamy za to id, czyli mamy

id = Bukkit.getScheduler().scheduleSyncRepeatingTask(Testowy.getInstance(), new Curse((Player)killer), 20, 40);

Dobra, teraz tylko zróbmy metodę zatrzymującą.

public static void disableScheduler() {    Bukkit.getScheduler().cancelTask(id);}

Teraz wystarczy to wykonać po stronie klasy wykonawczej. Mamy to:

if (player.getHealth()>1) {    player.sendMessage("A masz!");}if (player.getHealth()>2) {    player.setHealth(player.getHealth()-2);} else if (player.getHealth()==2) {    player.setHealth(player.getHealth()-1);}

W sumie mamy taki kod, że nie ma znaczenia w którym damy else, bo i tak się wykona w tym samym momencie. Mamy więc

if (player.getHealth()>1) {    player.sendMessage("A masz!");}if (player.getHealth()>2) {    player.setHealth(player.getHealth()-2);} else if (player.getHealth()==2) {    player.setHealth(player.getHealth()-1);} else {    Kill.disableScheduler();}

Już. Ta-Da

Zadanie domowe:

Stwórz nowy cykl, który uruchomi się przy zniszczeniu piecyka i będzie co minutę dawał temu, kto zniszczył 1 usmażonego steka. W sumie da ich 64, niezależnie czy jadł czy nie.

Temat #20: A nie chciałbyś własnego eventa?

No więc własne eventy. Co tu wiele opisywać, w temacie 7 nasłuchiwaliśmy eventów, teraz stworzymy własne, ktore możemy albo nasłuchiwać, albo zostawić "potomnym" (tym co uzyją naszego pluginu jako swój resource w Build Path). To raczej bedzie krótki temat, ale no cóż... Stwórzmy nową klasę, np... O wiem, pamietacie temat 15, w ktzm korzystaliśmy z enumów? Zeventujmy awans! Więc klasa PlayerEnchantAdvanceEvent, a w okienku tworzenia tam gdzie mamy Superclass daj "Browse", wpisz "Event" i weź tego, z org.bukkit.event. No ok, i Finish. I mamy to:

public class PlayerEnchantAdvanceEvent extends Event {     @Override    public HandlerList getHandlers() {        // TODO Auto-generated method stub        return null;    } }

Co jest cholernie brzydkie, wiec szybciutki reformat kodu i odrazu lepszy layout

public class PlayerEnchantAdvanceEvent extends Event {     @Override    public HandlerList getHandlers() {        return null;    }}

Będzie tego troche. Więc mamy coś jak HandlerList, wiec musimy taką zmienną stworzyć.

private static final HandlerList handlers = new HandlerList();

Czym ona jest? To lista wszystkiego co nasłuchuje naszego eventa. Czemu tak?
prywatne - zeby nam z zewnatrz nie zmodyfikowali
statyczne - bo dotyczy całej klasy a nie instancji
finalne - zeby i tak nawet w klasie tego nie zmienic
Teraz to zwrócimy w metodzie

public HandlerList getHandlers() {    return handlers;}

No i żeby nie było problemu zrobimy jeszcze niemal identyczną metodę, wszytsko to samo, tylko dodamy modyfikator "static". I nasza klasa teraz wyglada tak:

public class PlayerEnchantAdvanceEvent extends Event {    private static final HandlerList handlers = new HandlerList();        @Override    public HandlerList getHandlers() {        return handlers;    }        public static HandlerList getHandlerList() {        return handlers;    }}

No ok, teraz jak to zwykle w klasach bywa przyda się konstruktor, narazie pusty. No i teraz pomyślmy, co ma nasz event? Napewno playera, który awansował. No i level na który awansował. Więc takie pola tworzymy

private Player player;private Enchanter enchanter;

Teraz to co prostsze czyli gettery obu wartości

public Player getPlayer() {    return player;} public Enchanter getEnchantLevel() {    return enchanter;}

No i teraz w konstruktorze inicjalizujemy te dwie wartości.

public PlayerEnchantAdvanceEvent(Player player, Enchanter enchanter) {    this.player = player;    this.enchanter = enchanter;}

z tej klasy to tyle, pozostaje teraz tylko zawołać eventa. Ta klasa w łęni wyglada tak:

package eu.andret.testowy;import org.bukkit.entity.Player;import org.bukkit.event.Event;import org.bukkit.event.HandlerList; public class PlayerEnchantAdvanceEvent extends Event {    private static final HandlerList handlers = new HandlerList();    private Player player;    private Enchanter enchanter;        public PlayerEnchantAdvanceEvent(Player player, Enchanter enchanter) {        this.player = player;        this.enchanter = enchanter;    }        @Override    public HandlerList getHandlers() {        return handlers;    }        public static HandlerList getHandlerList() {        return handlers;    }     public Player getPlayer() {        return player;    }        public Enchanter getEnchantLevel() {        return enchanter;    }}

Teraz lecim do klasy Kill gdzie mamy eventa na enchantowanie:

@EventHandlerpublic void enchant(EnchantItemEvent e) {    String nick = e.getEnchanter().getName();    Testowy.getInstance().getList().get(nick).addEnchats();    Stat s = Testowy.getInstance().getList().get(nick);    try {        if (s.getEnchants() >= s.getEnchantStatus().next().getValue()) {            s.setEnchantStatus(s.getEnchantStatus().next());            e.getEnchanter().sendMessage("Gratulacje, wlasnie awansowales na " + s.getEnchantStatus() + "!");        }    } catch (NullPointerException ex) { }}

I teraz zamiast wysłania wiadomości zawołamy eventa linijką

Bukkit.getServer().getPluginManager().callEvent(Event);

Tylko, że tego "Event" trzeba zrobić naszym eventem, czyli

Bukkit.getServer().getPluginManager().callEvent(new PlayerEnchantAdvanceEvent());

Ale... Nie mamy pustego konstruktora. więc trzeba te parametry podać.

Bukkit.getServer().getPluginManager().callEvent(new PlayerEnchantAdvanceEvent(e.getEnchanter(), s.getEnchantStatus()));

W tym momencie można nasłuchiwać naszego eventa PlayerEnchantAdvanceEvent. Done.

Zadanie domowe:

Pamiętasz jak w temacie 15 miałeś zrobić na enumie poziomy dla kopania? To teraz im stwórz nowego eventa.

PROJEKTY PODSUMOWUJĄCE

Projekt #1: Random teleport.

Random teleport, czyli teleportacja w losowe miejsce na mapie to częsty motyw na różnego rodzaju survivalach. Ale na bukkit dev trudno o zadawalający nas teleport. Napiszmy więc własny. Tworzymy nowy projekt tak jak w temacie 2 i dostosowujemy plugin.yml. Żeby nie bardzo uprościć zrobimy tak, że będzie nieco danych w configu. Teleport bedzie działał na tabliczce, ale w taki sposób, że przy tworzeniu tabliczki trzeba wpisać jakiś tam tekst (to bedzie w configu), wówczas ten tekst zmienia się na "aktywny" teleport (co też bedzie configu) i przy kliknięciu prawym bądź lewym na to, klikający jest teleportowany na losowy punkt z zakresu (który też będzie w configu). Więc zacznijmy od configa. Ja sobie wymyślam tak:

input:  line1: ""  line2: "[Random]"  line3: "[Teleport]"  line4: "" output:  line1: "[RT]"  line2: "Click for"  line3: "teleport to"  line4: "random place" range:  minX: -5000  maxX: 5000  minZ: -5000  maxZ: 5000

myślę, że jest oczywisty. Więc obok pliku plugin.yml tworzymy config.yml i tam wpisujemy to wszystko. Kiedy juz wsyztsko będzie, w onEnable() używamy metody

saveDefaultConfig();

która po prostu zapisuje ten plik do folderu pluginu jeśli nie istnieje. Bardzo wygodne. Teraz potrzebujemy klasę z listenerami, bo stworzenie i kliknięcie tabliczki to jednak listenery. Więc tworzymy jedną na nie, i nie zapominamy jej zarejestrować w onEnable():

Bukkit.getPluginManager().registerEvents(new RandomTeleportListeners(), this);

Teraz tworzymy listenera na modyfikację tabliczki

@EventHandlerpublic void signChange(SignChangeEvent e) {    }

I teraz. Co się ma zdarzyć? No jeśli wszytsko jest poprawnie (czyli tak jak w configu) to się ma zmienić. Wszystko fajnie... Tylko nie mamy configa. Znaczy plik config.yml mamy, ale nie mamy zmiennej dostępowej do tego pliku. Ona jest w klasie głównej. Więc... INSTANCJA!

private static MainClassName instance;

Pamiętamy, że MainClassName to nazwa klasy głównej i ta zmienna dokłądnie tam się znajduje. W onEnable()

instance = this;

a potem getter:

public static MainClassName getInstance() {    return instance;}

Pełna klasa główna na chwilę obecną:

public class RandomTeleport extends JavaPlugin {    private static RandomTeleport instance;        @Override    public void onEnable() {        instance = this;        saveDefaultConfig();        Bukkit.getPluginManager().registerEvents(new RandomTeleportListeners(), this);    }        public static RandomTeleport getInstance() {        return instance;    }}

Teraz... Ha, ha. Sprawdzanie czy linie na 100% są poprawne. Czyli drobny ifek...

FileConfiguration config = RandomTeleport.getInstance().getConfig();if (config.getString("input.line1").equals(e.getLine(0)) &&    config.getString("input.line2").equals(e.getLine(1)) &&    config.getString("input.line3").equals(e.getLine(2)) &&    config.getString("input.line4").equals(e.getLine(3))) { }

FileConfiguration config - to zmienna przechowujaca dane z pliku konfiguracyjnego. Ten if pozwala sprawdzić w evencie czy na nowo utworzonej tabliczce linie są takie jak w configu. Teraz jeśli są - trzeba ustawić inne. Czyli coś bardzo podobnego:

e.setLine(0, config.getString("output.line1"));e.setLine(1, config.getString("output.line2"));e.setLine(2, config.getString("output.line3"));e.setLine(3, config.getString("output.line4"));

I juz. To powinno działać do tego momentu. Teraz taki dodatek, permisje. Jak ktoś nie ma praw stworzenia to niech nie podmienia tekstów, tylko zostawi to co napisał. Czyli zanim sprawdzanie tebliczki to permisje. W efekcie:

@EventHandlerpublic void signChange(SignChangeEvent e) {    if (e.getPlayer().hasPermission("randomteleport.create")) {        FileConfiguration config = RandomTeleport.getInstance().getConfig();        if (config.getString("input.line1").equals(e.getLine(0)) &&                config.getString("input.line2").equals(e.getLine(1)) &&                config.getString("input.line3").equals(e.getLine(2)) &&                config.getString("input.line4").equals(e.getLine(3))) {            e.setLine(0, config.getString("output.line1"));            e.setLine(1, config.getString("output.line2"));            e.setLine(2, config.getString("output.line3"));            e.setLine(3, config.getString("output.line4"));            e.getPlayer().sendMessage("Utworzono random teleport!");        }    }}

Teraz drugi event - PlayerInteractEvent. Tutaj sprawdzamy czy to w co gracz uderzył to napewno tabliczka

if (e.getClickedBlock().getState() instanceof Sign) {    }

Czemu tak, a nie porównywanie typu? No bo nie wiadomo czy ta tabliczka stoi, wisi czy co robi, a stojąca a wisząca tabliczka to różne materiały, a mają wspólny BlockState. Kiedy wiemy, że to tabliczka, musimy sprawdzić czy to ta nasza tabliczka. Czyli znowu ifek.

FileConfiguration config = RandomTeleport.getInstance().getConfig();if (config.getString("output.line1").equals(e.getLine(0)) &&    config.getString("output.line2").equals(e.getLine(1)) &&    config.getString("output.line3").equals(e.getLine(2)) &&    config.getString("output.line4").equals(e.getLine(3))) { }

Analogicznie jak poprzednio. To teraz, jeszcze zanim go przeniesiemy, też sprawdźmy czy ma permisje!

if (e.getPlayer.hasPermission("randomteleport.use")) {    }

I teraz nasz zasadniczy algorytm teleportujący. Najpierw weźmiemy sobie te 4 zmienne z configa do zmiennych:

int minX = config.getInt("range.minX");int maxX = config.getInt("range.maxX");int minZ = config.getInt("range.minZ");int maxZ = config.getInt("range.maxZ");

I teraz tak. Wysolować możemy tylko od 0 do pewnej liczby, więc trzeba maszynce losującej nieco pomóc. Zaczniemy od tego, żeby maszynkę losującą stworzyć. Żeby nie było problemów z pamięcią, w klasiel listenerów tworzymy prywatne statyczne finalne pole typu Random i dajemy mu wartość konstruktorową

private static final Random random = new Random();

Wracamy do naszych czterech zmiennych i... Potrzebujemy zakres. No mamy zakres od -5000 do 5000, ale potrzebujemy od 0 do czegoś. Ale musimy trzymać się naszych danych. Musimy po prostu zakres przesunąć. Zacznijmy od tego, że weźmiemy różnicę wartości minimalnej i maksymalnej pod wartością bezwzględną (gdyby ktoś min podałwiększy od max) i mamy

int diffX = Math.abs(minX - maxX);int diffZ = Math.abs(minZ - maxZ);

Dla danych od -5000 do 5000 zmienna diffX ma wartość 10000 (bo 5000 - (-5000) = 5000+5000 = 10000, z drugiej strony jest (-5000) - 5000 = -10000, ale mamy to pod wartością bezwzględną, więc 10000), więc dokładnie to o co nam chodziło. Losujemy z tego zakresu

int x = random.nextInt(diffX);int z = random.nextInt(diffZ);

I teraz mamy dwie wartości, np. 2435 i 8702. A miało być z zakresu od -5000 do 5000. Więc co? Odejmujemy mniejszą!

x-=Math.min(minX, maxX);z-=Math.min(minZ, maxZ);

Ale strasznie dużo linijek, nieprawda? Może da się coś skrócić? Oczywiście. Rzućmy okiem na obecny kod

int diffX = Math.abs(minX - maxX);int diffZ = Math.abs(minZ - maxZ);int x = random.nextInt(diffX);int z = random.nextInt(diffZ);x-=Math.min(minX, maxX);z-=Math.min(minZ, maxZ);

A może pozbędziemy się zmiennych diffX i diffZ? Korzystamy z nich raz, więc wartość ciach do nawiasu i mamy

int x = random.nextInt(Math.abs(minX - maxX));int z = random.nextInt(Math.abs(minZ - maxZ));x-=Math.min(minX, maxX);z-=Math.min(minZ, maxZ);

Da się coś jeszcze? To odejmowanie można odrazu zrobić!

int x = random.nextInt(Math.abs(minX - maxX))-Math.min(minX, maxX);int z = random.nextInt(Math.abs(minZ - maxZ))-Math.min(minZ, maxZ);

I ciach, działa! Ej... A nie zapomnieliśmy o czymś? Może przeniesiemy gracza ta tą lokalizację? Chyba się przyda. Najpierw stwórzmy tą lokalizację

Location l = new Location(e.getPlayer().getWorld(), x, 100, z);

Wartość y ustawiam dowolną, bo teraz wyliczymy najwyższą (żeby nie zamurować go). Świat ma taką metodę jak getHighestBlockAt(Location), wiec z niej skorzystamy.

Block highest = e.getPlayer.getWorld().getHighestBlockAt(l);

Co daje pierwszy blok powietrza nad ostatnim innym blokiem. Więc przenosimy tam gracza:

e.getPlayer().teleport(highest.getLocation());

I na koniec powiemy mu o tym

e.getPlayer().sendMessage("Teleportowano na: x=" + highest.getX() + ", y=" + highest.getY() + ", z=" + highest.getZ() + "!");

Koniec! Przetestować! Jakby ktoś się zgubił, kod:

RandomTeleport.java

package eu.andret.randomteleport; import org.bukkit.Bukkit;import org.bukkit.plugin.java.JavaPlugin; public class RandomTeleport extends JavaPlugin {    private static RandomTeleport instance;        @Override    public void onEnable() {        instance = this;        saveDefaultConfig();        Bukkit.getPluginManager().registerEvents(new RandomTeleportListeners(), this);    }        public static RandomTeleport getInstance() {        return instance;    }}

RandomTeleportListeners.java

package eu.andret.randomteleport; import java.util.Random; import org.bukkit.Location;import org.bukkit.block.Block;import org.bukkit.block.Sign;import org.bukkit.configuration.file.FileConfiguration;import org.bukkit.event.EventHandler;import org.bukkit.event.Listener;import org.bukkit.event.block.SignChangeEvent;import org.bukkit.event.player.PlayerInteractEvent; public class RandomTeleportListeners implements Listener {    private static final Random random = new Random();        @EventHandler    public void interact(PlayerInteractEvent e) {        if (e.getClickedBlock().getState() instanceof Sign) {            Sign s = (Sign) e.getClickedBlock().getState();            FileConfiguration config = RandomTeleport.getInstance().getConfig();            if (config.getString("output.line1").equals(s.getLine(0)) &&             config.getString("output.line2").equals(s.getLine(1)) &&             config.getString("output.line3").equals(s.getLine(2)) &&             config.getString("output.line4").equals(s.getLine(3))) {                if (e.getPlayer().hasPermission("randomteleport.use")) {                    int minX = config.getInt("range.minX");                    int maxX = config.getInt("range.maxX");                    int minZ = config.getInt("range.minZ");                    int maxZ = config.getInt("range.maxZ");                    int x = random.nextInt(Math.abs(maxX - minX)) + Math.min(minX, maxX);                    int z = random.nextInt(Math.abs(maxZ - minZ)) + Math.min(minZ, maxZ);                    Location l = new Location(e.getPlayer().getWorld(), x, 100, z);                    Block highest = e.getPlayer().getWorld().getHighestBlockAt(l);                    e.getPlayer().teleport(highest.getLocation());                    e.getPlayer().sendMessage("Teleportowano na: x=" + highest.getX() + ", y=" + highest.getY() + ", z=" + highest.getZ() + "!");                }            }        }    }        @EventHandler    public void signChange(SignChangeEvent e) {        if (e.getPlayer().hasPermission("randomteleport.create")) {            FileConfiguration config = RandomTeleport.getInstance().getConfig();            if (config.getString("input.line1").equals(e.getLine(0)) &&             config.getString("input.line2").equals(e.getLine(1)) &&             config.getString("input.line3").equals(e.getLine(2)) &&             config.getString("input.line4").equals(e.getLine(3))) {                e.setLine(0, config.getString("output.line1"));                e.setLine(1, config.getString("output.line2"));                e.setLine(2, config.getString("output.line3"));                e.setLine(3, config.getString("output.line4"));                e.getPlayer().sendMessage("Utworzono random teleport!");            }        }    }}

Projekt #2: Wybuchająca miksturka.

Spoiler

Zawartość w trakcie tworzenia...

Projekt #3: Samogenerujący się kamień.

Spoiler

Zawartość w trakcie tworzenia...

Projekt #4: Ekonomia w bazie danych.

Spoiler

Zawartość w trakcie tworzenia...

Projekt #5: Piszemy minigrę!

Spoiler

Zawartość w trakcie tworzenia...

Dobry człowieku, na posanie tego poradnika poświęciłem masę czasu, czasu nie do policzenia, czyli w zasadzie dosyć sporo. Pozostaw proszę tutaj like'a. Ciebie to nic nie kosztuje, a mnie naprawdę zachęca i motywuje do dalszej pracy 🙂

PS. Tak, ja żyję, jakby ktoś pytał. Cheers!

PPS. Jestem w trakcie naprawiania poradnika, proszę o cierpliwość. Nowa wersja incoming!

Edytowane 14 Kwietnia 2022 przez Andret
WIelki powrót 1

Gewein · 9 Sierpnia 2013

Super poradnik plusik

TheBrzoskwinia · 9 Sierpnia 2013

Może nareszcie więcej tych "autorskich pluginów" postanie, czekam na rozwijanie poradnika oczywiście plus się należy,

Andret · 10 Sierpnia 2013

Przepraszam chwilowo za taki wygląd poradnika, ale... Edytor MPC odmówił mi posłuszeństwa, proszę o chwilę cierpliwości, dziekuję

Shirgerus · 10 Sierpnia 2013

Ladne like

TworcaSerwow · 11 Sierpnia 2013

Super biore sie za robienie pluginka

Andret · 11 Sierpnia 2013

Nie no... ja siępoddaję! Nie jestem w stanie czegokolwiek napisać nawet dlatego, ze zamiast polskich liter mam jakieś krzaczki, a spoilery mi nie działają. Nie mogę nawet otworzyć zwykłego pełnego edytora, tylko otwiera mi się taki ubogi... LUDZIE...! ja się poddaję, do kiedy nic nie wymyślę nie jestem w stanie rozwijać poradnika, przepraszam!

@Edit

Powiedzmy, że o tyle o ile działa, ale nie wiem jak to bedzie dalej wyglądało.... jakby co to za wszystkie usterki przepraszam ale powstajaz winy edytora tekstu forum MPC

Edytowane 11 Sierpnia 2013 przez andych1

michal343442 · 13 Sierpnia 2013

TuT staranie wykony, all wytłumaczone a nie kopiuj i wklej i się człowiek cieszy ze napisał plugin...
Zal ciśnie dupę jak wiedzę takie poradniki kopiuj i wklej a tu, jakiś normalny, bardzo mi się podoba zasługuje na LIKE.

Andret · 23 Stycznia 2014

@Refresh - pojawiły się nowe tematy

DJ-Mix-PL · 23 Stycznia 2014

Przydatne +

Rynichu · 23 Stycznia 2014

MEGA PORADNIK. Dziś biorę się do pisania Mam nadzieję, że wreszcie się porządnie nauczę. Jeśli grafika potrzebna jestem do usług Dx

//EDIT

Ej czuofjek weś pomusz

(klasa Komenda.java)

To jest ukryta treść, proszę

(klasa Poradnik.java - główna?)

To jest ukryta treść, proszę

Kilka pozamieniałem, bo mi eclipse wywalał błędy :c Mam wersję SDK :c

Edytowane 24 Stycznia 2014 przez Rynichu

Andret · 24 Stycznia 2014

@up

To jest ukryta treść, proszę

ta linijka to powinny być dwie tylko Ci się zlepiły, powinno być:

To jest ukryta treść, proszę

i drugi błąd to nie wiem czemu CI wyszło

To jest ukryta treść, proszę

skoro u mnie w poradniku jest, ze ma być

To jest ukryta treść, proszę

i trzeci błąd w linijce

To jest ukryta treść, proszę

gdzie

To jest ukryta treść, proszę

powinno być pod resztą juz za klamrą otwierającą

i czwarty błąd w linijce

To jest ukryta treść, proszę

co to za slowo "private"? jego nei powinno tu być!

btw e_komenda to Twoja nazwa i może byc jaka chcesz

Edytowane 24 Stycznia 2014 przez andych1

bubencja · 24 Stycznia 2014

Człowieku wielllki LIKE.

Widać ogrom pracy jaki w to włożyłeś.

Wszystko pokazane i wytłumaczone,

mimo iż nie twoże pluginu to miło się czyta

Andret · 24 Stycznia 2014

Dziękuję za miłe słowa naprawdę to wiele dla mnie znaczy i motywuje do dalszej pracy Nie ukrywam, że zależy mi, by trafiłdo jak najszerszej liczby odbiorców

Jeszcze raz wielkie dzieki

Rynichu · 24 Stycznia 2014

@up

To jest ukryta treść, proszę

Zaloguj się

lub

Zarejestruj się

ta linijka to powinny być dwie tylko Ci się zlepiły, powinno być:

To jest ukryta treść, proszę

Zaloguj się

lub

Zarejestruj się

i drugi błąd to nie wiem czemu CI wyszło

To jest ukryta treść, proszę

Zaloguj się

lub

Zarejestruj się

skoro u mnie w poradniku jest, ze ma być

To jest ukryta treść, proszę

Zaloguj się

lub

Zarejestruj się

i trzeci błąd w linijce

To jest ukryta treść, proszę

Zaloguj się

lub

Zarejestruj się

gdzie

To jest ukryta treść, proszę

Zaloguj się

lub

Zarejestruj się

powinno być pod resztą juz za klamrą otwierającą
i czwarty błąd w linijce

To jest ukryta treść, proszę

Zaloguj się

lub

Zarejestruj się

co to za slowo "private"? jego nei powinno tu być!
btw e_komenda to Twoja nazwa i może byc jaka chcesz

Tam troszku się pozmieniało, bo Eclipse wywalał błędy. Poza tym w poradniku było @Overridepublic :c

Może zawsze na koniec poradnika pokazuj jak powinien wyglądać kod? To by mi znacznie ułatwiło naukę

Andret · 25 Stycznia 2014

@UP

1. Zauważyłem w poradniku, faktycznie jest tam tam taki błąd, jednak go w najbliższym czasie naprawię, to na prawdę ma być w dwóch linijkach.

2. Jeżeli getCommand("poradniczek").setExecutor(e_komenda); wywala Ci jakikolwiek błąd (błąd jest na czerwono, na żółto są ostrzezenia, można je zignorować) to mi go tu napisz, jeżeli się na tym nie znasz nie próbuj go samodzielnie naprawiać.

3. O ile dobrze wiem to tak jak teraz napisałeś to wchodzisz w dziedziczenie z innych klas, sam tego JESZCZE nie ogarniam w JAVIE ale na pewno na tym etapie tak nie ma być. Zrób wg poradnika, ja to piszę na bieżąco u mnie i działa.

4. To samo, zaczynasz dziedziczyć, tylko tu są meody. prawidłowy zapis metody to TYP NAZWA(){...}, pomiędzy nawiasem a klamrami NIE MOŻE SIĘ NIC ZNLEŹĆ!

btw, jak coś napisałem w pordniku to wcześniej 2 tygodnie myślałem jak to napisać w eclipse, żeby w końcu zadzaiałało, potem 2 dni testowania, żeby było idealnie, czyli mój kod MUSI działać. Jeżeli nie działą jest informacja jak w temacie o nasłuchiwaniu serwera. Jeżeli kod skopiowany z poradnika nie działa wina jest po Twojej stronie.

Poza tym wersja Eclipse jak się okazuje nie ma zbytnio znaczenia, EE jest p prostu uboższa

shooly · 25 Stycznia 2014

Logika XXI wieku:

Stworzyłem linijkę wyżej zmienną którą mogę wykorzystać, ale po co?

To jest ukryta treść, proszę

;_;

Wypadałoby przeczytać poradnik jeszcze raz przed wysłaniem go.

Aha, i jeszcze jedno (cytat z postu powyżej):

To jest ukryta treść, proszę

Nie ogarniasz dziedziczenia, a piszesz poradniki w których z dziedziczenia korzystasz? Dobrze wiedzieć.

BTW. Nie jestem złośliwy, ale osoby które piszą poradniki, a nawet nie znają podstaw danego języka są według mnie idiotami.

Em, dalej:

To jest ukryta treść, proszę

Nie łatwiej wykorzystać metodę "entity.getEntityType()"? Jest o wiele czytelniejsza dla początkującego.

To jest ukryta treść, proszę

Kolejna rzecz która wkurza mnie u wszystkich młodych "programistów" to to, że nazywają zmienne, metody, klasy itp. po polsku - po jaką cholerę?

To że wy piszecie po polsku i wiecie co to oznacza, nie znaczy że ktoś kto pobralby ten plugin i chciałby go naprawić, albo zaktualizować - A NIE JEST POLAKIEM/NIE MÓWI PO POLSKU nie będzie wiedział co tam jest napisane.

Dlatego nazywajcie METODY, ZMIENNE, KLASY PO ANGIELSKU.

To tylko moja rada na przyszłość.

Oh i dopiero teraz zauważyłem:

To jest ukryta treść, proszę

Chyba pomyliłeś się ze static, a raczej na pewno pomyliłeś się ze "static".

...

To jest ukryta treść, proszę

Czemu nie

To jest ukryta treść, proszę

?

...

To jest ukryta treść, proszę

To tak jakby zadawać zadanie domowe z II wojny światowej, kiedy na lekcji było mówione o romantyźmie.

...

I co do @Rynichu:

Nie zauważyłeś że masz błąd jakim jest wpisanie "implements JavaPlugin" zamiast "extends JavaPlugin".

Edytowane 25 Stycznia 2014 przez shooly

Andret · 25 Stycznia 2014

1. To co napisałem nie ma uczyć pisać optymalnie, ma uczyć myśleć logicznie. na dobrą sprawę dały algorytm tp moge zamknąć w jednej linijce ale po co?

2. Dobra, nie bedę okłamywał, że dziedziczenie różni się pomiędzy ęzykami tak jak same języki, umiem dziedziczenie stosunkowo dobrze w C/C++, ale JAVA rządzi się własnymi prawami, a ja mówiąc "dziedziczenie" mam na myśli typ dziedziczenia, sekcję "protected", virtualność, klasy abstrakcyjne, coś czego na tym etapie nie znam w JAVIE, ale znam logikę.[hr[

3. Każdy popełnia błędy. Tym bardziej doceniam, że mi o nich powiedziałeś. Ja nie twierdzę, że znam JAVĘ BARDZO dobrze, ale umiem sporo napisać pod kątem języka a nie API bukkita.

4. Nie, nie łatwiej entity.getEntityType(); bo w 1.7 TEGO JUŻ NIE MA!

5. Tu masz rację, ja w 100% podzielam Twoje zdanie co do nomenklatury klas, metod, zmiennych, sam nie lubiepolskich ale piszę polskie, żeby ludzim było się łatwiej odnaleźć, jeżeli ktoś nie lubi polskich to sobie je zmieni. Rada jak najbardziej trafna, jak bedę miał wenę przepiszę poradnik, bo masz w sumie dużo racji.

6. codo @public - pisałęm to dawno nie do końca wiedząc co to jest i teraz sam stwierdzam, że to najdebilniejsza deficinia public jaką widziałem, jak będę edytował to i to napiszę na nowo. Bo tutaj dziedziczenie, prawo do użycia i wgl...

7. Czemu cmd.getName() zamiast label? bo w nawiasie było pierwsze i po prostu sprawdziłęm czy jest i było. nigdy na dobrą sprawę nie zastanawiałęm się nad label, i przyznaję siębez bicia, nie wiem za co odpowiada.

8. Trochę w tym racji jest, nawet dużo... do zmiany...

Dzięki za krytykę

shooly · 25 Stycznia 2014

@UP

Ad.1. Jeśli będziesz uczył ludzi jak pisać tak żeby działało, a nie tak żeby było dobrze zoptymalizowane I DZIAŁAŁO to na MPC, BukkitDev itp. pojawi się milion pluginów które nie będą używane z prostej przyczyny - będą zbytnio obciążały serwer.

To jest ukryta treść, proszę

"Po co korzystasz z 2 - bardziej czytelniejszego, oraz szybszego sposobu - skoro pierwszy również działa?" - tak ludzie będą myśleć, jeśli tak nauczymy ich myśleć.

Ad.4. Jest - entity.getType() (nie możliwe żeby nie było bo użyłem tego w swoim pluginie który napisałem dzisiaj rano pod Bukkita 1.7 )

BTW. Gdy tak popatrzyłem na ten skrypt:

To jest ukryta treść, proszę

Czemu nie:

To jest ukryta treść, proszę

?

Wszystko jest przecież zrozumiałe nawet dla początkującego, a pobieranie lokalizacji gracza którą potem całkowicie się zmienia jest.. bez sensu.

Edytowane 25 Stycznia 2014 przez shooly

Andret · 25 Stycznia 2014

@Up

ok, spoko, rozumiem co masz na myśli, to ja mam prośbę, wypisz mi wszystkie (Twoim zdaniem) Błędy które popełniłem a jutro z samego rana powalczę z MPC i to wszytsko pozmieniam, bo zależy mi, żeby poranik był przyjazny dla zwykłego usera, który dopiero się uczy

26 Stycznia 2014

Like

matixd3 · 27 Stycznia 2014

Great z tym poradnikiem moze skoncze moje mini gry thx

Karolina_666 · 27 Stycznia 2014

Ooooo.... nie widziałam tego poradnika, a już taki stary! Czaj na moje zdanie!

Wyjątkowo zaczne od końca...

Gratuluje że ci się chciało to wszystko pisać i wyjaśniać.

No doba, straczy tego miłego :P

(kolejność według tego co czytam, więc raz jest coś ważnego raz nie)

1. Jak już robiłeś instalacje środowiska, mogłeś też pokazać jak zrobić debuger który znacznie ułatwia testowanie pluginów

2. Paczki nazywamy naszą domeną lub jak nie mamy domeny to np adresem e-mail, com.ja.mojplugin.jakasTamPaczka com.gmail.ja.mojplugin.jakasTamPaczka

3. Nie napisałeś nic o javadocs dla bukkita.

4. Nie napisałeś że powinno pisać się pod Bukkita a nie CraftBukkita (można pod oba, ale jak się jest początkującym to tylko narobisz sobie problemów)

5. kilka opisów z działu 3... jak wyjaśniasz podstawy nie zapominaj o najważniejszym, "static" bo co z tego że ktoś da public jak i tak nie może tego użyć tak jak ty to opisałeś, i nie wie dlaczego No i ogólnie prawie nic nie wyjaśniłes.

6. w plugin.yml powinieneś napisać że należy podac paczkę i nazwę klasy głównej a nie "NAZWAAUTORA.NAZWAPLUGINU.NAZWAKLASYGŁóWNEJ" Dla jasności.

7.

To jest ukryta treść, proszę

Zamiast tego lepiej w nawiasie podać new <pełna ścieżka dostępu>()

Jest to wygodniejsze (nie ma importu, a jak się rejestruje np 200 komend to miałbyś 200 importów (no chyba że polecisz grupowo)

i nie trzeba robić zmiennej komendy skoro nie jest nam potrzebna...

8. Nie wyjaśniłeś różnicy pomiędzy float a Float, int a Integer itp

I ogólnie dlaczego zwykle jest duża litera a w przypadku kilku typów jakimś cudem jest mała :P

9. const? WTF? to nie C, tutaj z jakiegoś powodu mamy tylko "final"

Słowo tylko istnieje w jave, ale nie ma żadnego zastosowania... Więc nie pierdziel bezsensowych rzeczy!

10. Zapomniałeś dodać że w tablicach/lisach jak kto tam zwał nie trzeba ustalać liczby miejsc

int[] ciastko = new int[];

int[] ciastko = new int[]{5,6,3,6,2,5,7,78,4,3};

int[][] ciastki = new int[][]{{46,3,5,3,2}, {33,5,6,2,5,}, {43,6,7,3,2,5}};

11.

To jest ukryta treść, proszę

nie prościej Location loc = new Location(x,y,z,inne pierdoly...);

12. Temat 6 to jakaś jebana bajka... po uj używać pexa, zawsze używamy vault, bo inaczej nasz plugin jest zacnie chujowy i działa tylko z pexem... a nie wszyscy go mają

I od kiedy kurwa player.hasPermission("permisja") to wymaga pexa? od kiedy ja się pytam? permissions jest wspierane przez czystego bukkita..., jak by nie bylo... to... pex by był magikiem, dodał nowa metode do istniejącego już kodu! magia (no tak właściwe to się da... ale to inna sprawa)!
Ten temat mnie rozwalił...

13. Temat 7... hp działa świetnie, tylko że jest w double....

14. LivingEntity killer = entity.getKiller(); killer na 100% musi być graczem, albo gracz, albo null innej opcji nie ma.

Player killer = entity.getKiller();

Czyli to jest bez sensu...

To jest ukryta treść, proszę

15. Czas na kolejny debilizm...

Czyli możemy napisać najpierw

To jest ukryta treść, proszę

Zaloguj się

lub

Zarejestruj się

To służy temu, byśmy mieli w zmiennej nazwa nazwę (masło maślane) zabitego entity. Ich nazwa to "CraftANGIELSKANAZWA" czyli np. CraftCreeper, CraftSpider. normalnie napisalibyśmy

To jest ukryta treść, proszę

Zaloguj się

lub

Zarejestruj się

a nie prościej entity.getType(); ?

To jest ukryta treść, proszę

Szybsze, bezpieczniejsze, wygodniejsze.... a nie bezsensowne pobieranie nazwy klassy...

16. Ufff koniec

Brawo że ci się chciało to robić ale jednak niezbyt ci to wyszlo

EDIT: oo widze że ktoś już kilka błędów tez napisał, ale wcześniej

Edytowane 27 Stycznia 2014 przez Karolina_666

Andret · 27 Stycznia 2014

powiem tak... wszytko co mi zarzucono poprawię bo jak pisałem ten temat ma być przyjazny dla najbardziej poczatkujących... ale dopiero kiedy edytor MPC zacznie z łaski swojej działać... bo na serio nie chce mi się poprawiać czegoś takiego:

Jednak ja osobiście proszę o wyjasnienie nomenklatury paczek, gdyż można nazwać w sposób przeze mnie opisany i nie ma to wpływu na plugin a nie ukrywam, nie siedzę w tym jakos bardzo długo, więc nie do końca wiem czym to się je. Więc proszę o rozwianie moich wątpliwosci na ten temat, dziękuję .

Karolina_666 · 27 Stycznia 2014

powiem tak... wszytko co mi zarzucono poprawię bo jak pisałem ten temat ma być przyjazny dla najbardziej poczatkujących... ale dopiero kiedy edytor MPC zacznie z łaski swojej działać... bo na serio nie chce mi się poprawiać czegoś takiego:

Jednak ja osobiście proszę o wyjasnienie nomenklatury paczek, gdyż można nazwać w sposób przeze mnie opisany i nie ma to wpływu na plugin a nie ukrywam, nie siedzę w tym jakos bardzo długo, więc nie do końca wiem czym to się je. Więc proszę o rozwianie moich wątpliwosci na ten temat, dziękuję .

Czyste konwencje javy, nie jest to wymagane do życia, ale jednak każdy powinien przynajmniej starać się ich używać

Sama często zrobie coś nie koniecznie jak się powinno, ale co tam, dalej się uczę, bo nikim wielkim nie jestem :P

PS: jak szukacie wielkich to polecam zobaczyć jak wygląda plugin ProtocolLib tam to dopiero jest bajka I edycja kodu bukkita w runtime...

PS2: jak piszezsz na gg... to napisz a nie zapraszasz ja w zaproszenia nie wchodzę, za dużo tego.

i taki link:

To jest ukryta treść, proszę

Edytowane 27 Stycznia 2014 przez Karolina_666

Zaloguj się

👋 Witaj na MPCForum!

Od zera do Bukkit's plugin developera

Ocena poradnika 92 użytkowników zagłosowało

1. Co uważasz o tym poradniku?

2. Jaki teram obtać w kolejnym poradniku?

Rekomendowane odpowiedzi

Top użytkownicy w tym temacie

Top użytkownicy w tym temacie

Gość

Gość

Jeśli chcesz dodać odpowiedź, zaloguj się lub zarejestruj nowe konto

Zarejestruj nowe konto

Zaloguj się

Ocena poradnika
92 użytkowników zagłosowało