Od zera do Bukkit's plugin developera

[HugoZvPlayZ]

I to jest poradnik

[Andret]

@Refresh - naprawa wielu błędów

 

@shooly

1. NAPRAWIONO!

2. NAPRAWIONO!

3. NAPRAWIONO!

4. NAPRAWIONO!

5. NAPRAWIONO!

6. NAPRAWIONO!

7. NAPRAWIONO!

8. NAPRAWIONO!

 

@Karolina_666

1. Jak sam ogarnę debugger to spoko

2. NAPRAWIONO!

3. NAPRAWIONO!

4. NAPRAWIONO!

5. NAPRAWIONO!

6. NAPRAWIONO!

7. NAPRAWIONO!

8. NAPRAWIONO!

9. NAPRAWIONO!

10. NAPRAWIONO!

11. NAPRAWIONO!

12. NAPRAWIONO!

13. NAPRAWIONO!

14. NAPRAWIONO!

15. NAPRAWIONO!

16. Ufff koniec

Edytowane 28 Stycznia 2014 przez andych1

[shooly]

Czy to tylko u mnie tak jest?

To jest ukryta treść, proszę

• Zaloguj się
• lub
• Zarejestruj się

To jest ukryta treść, proszę

• Zaloguj się
• lub
• Zarejestruj się

@UP

Świetnie, szkoda że my musiliśmy Ci zwrócić uwagę na tyle błędów. :P

Edytowane 28 Stycznia 2014 przez shooly

[Andret]

Lepiej, że zwróciliście uwagę niż ten tutorial byłby bez tych poprawek, to mój - nie ukrywam - pierwszy tutorial na tak sporą skalę

 

a co do kodu, to ja nie wiem jak mam, żadny sposobem nie mogę wejść w pełny edytor, zawsze mam okrojona wersję i do tego spoilery mi nie działają...

[Karolina_666]

@Refresh - naprawa wielu błędów

 

@shooly

1. NAPRAWIONO!

2. NAPRAWIONO!

3. NAPRAWIONO!

4. NAPRAWIONO!

5. NAPRAWIONO!

6. NAPRAWIONO!

7. NAPRAWIONO!

8. NAPRAWIONO!

 

@Karolina_666

1. Jak sam ogarnę debugger to spoko

2. NAPRAWIONO!

3. NAPRAWIONO!

4. Osobiście sam piszę jedynie pod craftbukkita i jakoś nic się nie dzieje, jak męczyłęm się z szukaniem bukkita... żadnej różnicy...

5. NAPRAWIONO!

6. NAPRAWIONO!

7. NAPRAWIONO!

8. NAPRAWIONO!

9. NAPRAWIONO!

10. NAPRAWIONO!

11. NAPRAWIONO!

12. NAPRAWIONO!

13. No nie działa, jakkolwiek tego nie zrzutuję dalej jest źle...

14. NAPRAWIONO!

15. NAPRAWIONO!

16. Ufff koniec

Na a zgadnij dlaczego pkt 13 nie działa?

Bo piszesz na Craftbukkicie zamiast bukkcie, zmień i poczuj magie świąt! :>

 

Ale brawo że poprawiłeś, ide poczyać, może znajde coś nowego

[Andret]

@Refresh - kolejne poprawki

 

Jeszcze jakieś uwagi?

[matixd3]

a ne moze byc tak?

extends JavaPlugin zamiast implements JavaPlugin ?

bo przy 1 jest git a przy 2 error

 

 

I piszesz w 2 dziale o tym ze trzeba miec bukkita a potem o kopiowaniu craftbukkita Popraw to

[TmKWork]

czegoś się nauczylem , dzieki za tut + dla ciebie za checi same!

[MastersOfPlays]

Nie na moją głowe :P Ale poradnik przydatny !

[Andret]

Wydaje mi sie, że każdy jest w stanie się tego nauczyć jeśli mu zależy, wiec jest to również i na Twoją głowę wystarczy spróbować

Edytowane 30 Stycznia 2014 przez andych1

[maciekmm]

@andych1 Niestety poradnik leży pod względem przyjętych reguł. Fajnie, że chcesz pomóc innym tworzyć pluginy, ale jeszcze dużo musisz się nauczyć.

 

1. System.out... - Stosuje się tylko do ewentualnych breakpointów, nie do logów, które powinny być zarządzane klasą loggera <? extends JavaPlugin>.getServer().getLogger() bądź Bukkit.getLogger()
2. PluginLoader bądź PluginManager automatycznie wyświetli odpowiednie powiadomienia dotyczące ładowania pluginu
3. Każda metoda przesłaniana - dziedziczona - od javy 1.5 powinna być opatrzona adnotacją @Override,\
5. To jest ukryta treść, proszę

   • Zaloguj się
   • lub
   • Zarejestruj się
   IMO kod zapisany w taki sposób jest nieczytelny
6. To jest ukryta treść, proszę

   • Zaloguj się
   • lub
   • Zarejestruj się
   - false wydrukuje usage, warto z tego korzystać
7. Permissions w komendach? Tylko w przypadku komend z argumentami, które wymagają osobnych praw, normalnie można pokusić się o permission: w plugin.yml a także cmd.setPermissionMassage(String failure)
8. Warto wspomnieć o taskach i kolejkach podczas zmiany bloków, gdyż ze względu na czasochłonność obliczania światła wykonanie wielu operacji na raz spowoduje wstrzymanie głównego wątku.
9. Gdy będziesz opisywać wielowątkowość zajrzyj w kod craftbukkita i zobacz, które metody są thread-safe, a które nie

[Karolina_666]

 

@andych1 Niestety poradnik leży pod względem przyjętych reguł. Fajnie, że chcesz pomóc innym tworzyć pluginy, ale jeszcze dużo musisz się nauczyć.

 

1. System.out... - Stosuje się tylko do ewentualnych breakpointów, nie do logów, które powinny być zarządzane klasą loggera <? extends JavaPlugin>.getServer().getLogger() bądź Bukkit.getLogger()
2. PluginLoader bądź PluginManager automatycznie wyświetli odpowiednie powiadomienia dotyczące ładowania pluginu
3. Każda metoda przesłaniana - dziedziczona - od javy 1.5 powinna być opatrzona adnotacją @Override,\
5. To jest ukryta treść, proszę

   • Zaloguj się
   • lub
   • Zarejestruj się
   IMO kod zapisany w taki sposób jest nieczytelny
6. To jest ukryta treść, proszę

   • Zaloguj się
   • lub
   • Zarejestruj się
   - false wydrukuje usage, warto z tego korzystać
7. Permissions w komendach? Tylko w przypadku komend z argumentami, które wymagają osobnych praw, normalnie można pokusić się o permission: w plugin.yml a także cmd.setPermissionMassage(String failure)
8. Warto wspomnieć o taskach i kolejkach podczas zmiany bloków, gdyż ze względu na czasochłonność obliczania światła wykonanie wielu operacji na raz spowoduje wstrzymanie głównego wątku.
9. Gdy będziesz opisywać wielowątkowość zajrzyj w kod craftbukkita i zobacz, które metody są thread-safe, a które nie

 

co do 4 to się nie zgodze ustawienia co do komend te domyślna zawsze mnie wkur...

wole napisać własną wiadomość, z tym że dla ulatwienia mam metode ktora automatycznie wysyla wiadomość do celu i zwraca prawde bo ładniej wyglada:

To jest ukryta treść, proszę

• Zaloguj się
• lub
• Zarejestruj się

niż robienie jeszcze dodatkowego returna.

 

Nie wnikam gdzie zjedłes 5 i 6 pkt

 

Ale z 7 to samo co z 4

 

 

A 2 pkt nie istotny wiadomość na wyłączeniu może i kompletne głupia, ale przy większym pluginu warto dodać coś podczas uruchamiania, by użytkownik wiedział że to się laduje, a nie zacieło :F

 

 

Logger jest średnio istotny możesz nawet wysyłać wiadomości po prostu do konosli i wyjdzie na to samo a nawet masz kolorki

co najwyżej zgodze się że systemowy najlepiej nadają się do debugu, wygodniej i szybciej.

 

 

Ciesz się że nie widziałeś tego przed jego edycją !

[maciekmm]

 

 

A 2 pkt nie istotny wiadomość na wyłączeniu może i kompletne głupia, ale przy większym pluginu warto dodać coś podczas uruchamiania, by użytkownik wiedział że to się laduje, a nie zacieło :F

Plugin domyślnie łądując się wyświetla odpowiednią wiadomość w konsoli.

 

 

 

 

co do 4 to się nie zgodze ustawienia co do komend te domyślna zawsze mnie wkur...

wole napisać własną wiadomość, z tym że dla ulatwienia mam metode ktora automatycznie wysyla wiadomość do celu i zwraca prawde bo ładniej wyglada:

if (args.lenght < 1)
return Utils.fixAndSend("Coś tam &5 coś tam ", sender)

Ależ wiem, tylko mówię, że przy tego typu komendach jest to idealne, przy większych komendach można pokusić się o własną wiadomość.

 

 

 

Logger jest średnio istotny możesz nawet wysyłać wiadomości po prostu do konosli i wyjdzie na to samo a nawet masz kolorki

co najwyżej zgodze się że systemowy najlepiej nadają się do debugu, wygodniej i szybciej.

Logger jest istotny, szczególnie, że jeżeli wystąpi gdzieś problem to później można zlokalizować kiedy i jak. Po coś te wiadomości tam się pokazują nie?

[Karolina_666]

Plugin domyślnie łądując się wyświetla odpowiednią wiadomość w konsoli.

 

 

 

 

Ależ wiem, tylko mówię, że przy tego typu komendach jest to idealne, przy większych komendach można pokusić się o własną wiadomość.

 

 

Logger jest istotny, szczególnie, że jeżeli wystąpi gdzieś problem to później można zlokalizować kiedy i jak. Po coś te wiadomości tam się pokazują nie?

 

Z loggerem chodzi o to że średnio ma znaczenie którego sposobu użyjesz :>

 

 

plugin wywala jedną wiadomość gdy zaczyna sie ładować, a jak ładujesz 200KB configu, do tego inicjujesz 30 eventów, 50 komend, to warto na końcu powiedzieć

"Kurwa... w końcu się załadowało"

PS: większość dev dodaje takie wiadomości :P czasami nawet stopniowe przy naprawdę dużych projektach :>

I czasami chcesz też coś dodać

np:

Plugin załadowany, wykryto 40 czegoś-tam

Edytowane 30 Stycznia 2014 przez Karolina_666

[maciekmm]

Wtedy tak, ale to też w Loggerze, Poza tym

 

[11:37:16] [server thread/INFO]: [mAuth-bukkit] Loading mAuth-bukkit v1.0-SNAPSHOT

[11:37:19] [server thread/INFO]: [mAuth-bukkit] Enabling mAuth-bukkit v1.0-SNAPSHOT

[11:37:20] [server thread/INFO]: Done (3,718s)! For help, type "help" or "?"

 

Nie powiesz mi, że nie jest to wystarczająca ilość wiadomości. Jeśli chcemy poinformować użytkownika o czymś to możemy, ale w Loggerze, aby możliwy był debug.

 

 

[11:37:19] [server thread/INFO]: [mAuth-bukkit] Established connection to bungee cord

 

lub

 

[11:37:19] [server thread/INFO]: [mAuth-bukkit] Couldn't find bungee cord proxy, returning to standard authorization

a nie

 

Couldn't find bungee cord proxy, returning to standard authorization

 

Logger sam zadba o dodanie TimeStampa i prefixu

 

Poza tym System.out nie zapisze się w server.log

Edytowane 30 Stycznia 2014 przez maciekmm

[kuba1498]

Super poradnik . Dzięki tobie już to rozumiem

[Karolina_666]

Wtedy tak, ale to też w Loggerze, Poza tym

 

 

Nie powiesz mi, że nie jest to wystarczająca ilość wiadomości. Jeśli chcemy poinformować użytkownika o czymś to możemy, ale w Loggerze, aby możliwy był debug.

 

 

 

lub

 

a nie

 

 

Logger sam zadba o dodanie TimeStampa i prefixu

 

Poza tym System.out nie zapisze się w server.log

Hyyym, polecam ci przetestować to co piszesz

System.out.print("dupa dupa dupa :*")

[14:26:32 INFO]: dupa dupa dupa :*

 

Bukkit.getLogger().log(Level.INFO, "fgdfgdfgdrgh");

[14:26:32 INFO]: fgdfgdfgdrgh2

 

 

W logach tez wszystko śmiga :<

[14:26:32] [server thread/INFO]: fgdfgdfgdrgh

[14:26:32] [server thread/INFO]: dupa dupa dupa :*

Edytowane 30 Stycznia 2014 przez Karolina_666

[maciekmm]

Hyyym, polecam ci przetestować to co piszesz

System.out.print("dupa dupa dupa :*")

[14:26:32 INFO]: dupa dupa dupa :*

 

Bukkit.getLogger().log(Level.INFO, "fgdfgdfgdrgh");

[14:26:32 INFO]: fgdfgdfgdrgh2

 

 

W logach tez wszystko śmiga :<

[14:26:32] [server thread/INFO]: fgdfgdfgdrgh

[14:26:32] [server thread/INFO]: dupa dupa dupa :*

To jest ciekawe, bo u mnie wiadomości z System.out nie zapisują się w logu i nie posiadają timestampa.

[Andret]

@Refresh - Pojawił się nowy temat: Stary "nowy" item

[Andret]

@Refresh - Pojawił się nowy temat Może jakiś config?

Edytowane 14 Marca 2014 przez andych1

[Andret]

@Refresh - pojawił się nowy temat Co się dzieje gdy nas nie ma czyli plik logów

[Andret]

@Refresh - pojawił się nowy obszerny temat Dane towarzyszące gracozm

Edytowane 3 Kwietnia 2014 przez andych1

[Andret]

Nie wiem czy kogoś to jeszcze ciekawi, ale jeśli tak, to

@Refresh - pojawił się temat By nie pamiętać co oznacza jaka wartość zmiennej

[Karolina_666]

To jest kompletnie bez sensu

To jest ukryta treść, proszę

• Zaloguj się
• lub
• Zarejestruj się

Po co ta klasa public class EnumEnchanter { .... kompletnie jest tutaj nie potrzebna

To jest ukryta treść, proszę

• Zaloguj się
• lub
• Zarejestruj się

Jak bd miał 200 wartości też będziesz tak jechał?

Masz kilka możliwości:

- Zapisać level w każdym z elementów enum i wtedy szukać w pętli.

- Stworzyć mapkę która podczas 1 użycia sama ustali te levele i wtedy pobrać z mapki.

 

 

 

Czemu konstuktor bez oznacznika widoczności? bo jest obłędem, bo wyobrażacie sobie prywatny konstruktor?

Enum ma konstuktor zablokowany, ale sam brak oznacznika widoczności... oznacza widoczność domyślną - klasa/zmienna/metoda widoczna w całej paczce.

 

Prywatny konstruktor? w wielu miejscach:

- Jak nie chcesz by ktoś inny lub ty jak zapomnisz, tworzył nowej instancji tej klasy z poza niej. (szczególnie jak jest to "klasa w klasie", wtedy czasami nie potrzebujemy jej w innych miejscach)

- Jak klasa jest statycza - nie zawiera żadnych danych nie-statycznych i ogólnie nie ma sensu używać jej jako obiektu np klasa "Utils"

[Andret]

Dobra, pytanie, CO konkretnie jest bez sensu? Bo z tego co napisałąś wychodzi, ze calą klasa zawierająca enuma, kiedy o enumie jest poradnik