[Plugin] ＴＲＡＤＥＩＱ - Bezpieczny i szybki handel z graczami.

Qwant1 · 15 Listopada 2017

23574472_926878270846913_1460024662_n.pn

TradeIQ to wtyczka, która wprowadza do naszej gry bezpieczną wymianę.
Od teraz już nikt nie oszuka Cię w trakcie wymiany za Twoje drogocenne przedmioty.

Wtyczka dodaje nam nowe okno poprzez trzymanie klawisza "Shift" i interakcję prawego klawiszu myszy.
Okno pojawia się natomiast po tym jak gracz na którego została wykonana interakcja również kliknie na tego gracza, który wykonał wcześniej interakcje.
Po kliknięciu w dowolny przedmiot w naszym ekwipunku w trakcie włączonego okna, zostanie on natychmiastowo przeniesiony do tego okna.
Wygląd okna oraz wielkość, jak i czas na akceptacje i inne tego typu właściwości zależą tylko i wyłącznie od konfiguracji, która tworzy się w folderze "plugins", po uruchomieniu serwera.

Konfiguracja:

# 
# +---------------------------------------------------------------------+ #
# |                       Trade IQ by MaRsOnIx                          | #
# +---------------------------------------------------------------------+ #
prefix: '&b[&7TradeIQ&b] ' # Wiadomość, która będzie się pojawiać zawsze przed każdą wiadomością wtyczki, jeżeli chcesz usunąć to zostaw puste. 
size: 4 # Rozmiar okna [ 1 - 6 ], każda liczba o jeden większa od poprzedniej to 9 dodatkowych slotów.
frameId: 65 # Identyfikator przedmiotu, który ma oddzielać lewą stronę od prawej.
frameLore: '&2Ty||&a<==========||&2<target>||&a==========>' # Opis przedmiotu wyżej.
timeExpiryRequest: 10 # Czas po jakim ma mijać zaproszenie do handlu.
timeEndTrade: 5 # Czas po jakim handel ma zakończyć się powodzeniem, chodzi o licznik, który jest w celach bezpieczeństwa po tym jak dwie strony dokonają akceptacji.
acceptItem: '&aAkceptuj' # Nazwa przedmiotu do akceptacji.
acceptedItem: '&aZaakceptowano' # Nazwa przedmiotu po kliknięciu w akceptacje.
guiName: '&lOkno Handlowania' # Nazwa okna.
playerNotOffline: '&cGracz <target> nie jest na serwerze.' # Wiadomość, która się pojawia, jeśli gracz nie jest na serwerze.
alreadyTrading: '&cGracz aktualnie handluje z inna osoba.' # Wiadomość, która się pojawia w trakcie, gdy gracz już handluje z innym graczen.
dontWantTrade: '&cGracz nie chce z Toba handlowac.' # Wiadomość, która się pojawia jeśli gracz na którego została dokonana interacja, kliknął już na innego gracza i tym samym chce z innym graczem handlować.
requestAlreadySent: '&cProsba o handel zostala juz wyslana do jakiegos gracza, sprobuj za chwile.' # Wiadomość, która się pojawia, gdy gracz już wysłał do kogoś zaproszenie o handel i musi czekać na ackeptacje.
requestSent: '&aProsba o handel z graczem <target> zostala wyslana.' # Wiadomość, która się pojawia, jeśli gracz wyśle zaproszenie poprzez kliknięcie.
requestReceived: '&aGracz <player> chce z Toba handlowac.' # Wiadmoność, kóra się pojawia, gdy ktoś klinął na gracza i chce handel z nim.
checkUpdate: true # Sprawdza nowe aktualizacje i tym samym informuje o potrzebie pobrania nowej wersji.

Tymczasowo wtyczka nie posiada komend.

Tymczasowo wtyczka nie posiada uprawnień.

Pobierz
Skan

Wersja 1.0:
- Wydanie podstawowego systemu handlu
Wersja 1.5:
- Dodanie informatora o nowej wersji wtyczki
- Dodanie konfiguracji wtyczki

Drejkus · 15 Listopada 2017

Witam, przetestuje jeżeli będzie dobry to wkleję go w paczkę mediumhc na mpc mam pytanie, czy mogę użyć tego pluginu w paczce?

Qwant1 · 15 Listopada 2017

4 minuty temu, Drejkus napisał:

Witam, przetestuje będzie robię paczkę mediumhc na mpc mam pytanie, czy mogę użyć tego pluginu w paczce?

Nie ma żadnego problemu

Envqu · 16 Listopada 2017

Popraw zdjęcia, bo nie za bardzo je widać .

de76 · 21 Listopada 2017

Nie przetrzymujemy obietku gracza, za latwo o leak.

private Player player;
private static HashMap<Player, Player> requests;

Nie tworzymy dodatkowych loggerow w bukkicie, a w dodatku w tej samej klasie.. masz getLoggera..

private Logger log;

Przy wyjsciu z serwera, trade sie prawdopodobnie zbuguje

Qwant1 · 22 Listopada 2017

8 godzin temu, de76 napisał:

Nie przetrzymujemy obietku gracza, za latwo o leak.

private Player player;
private static HashMap<Player, Player> requests;

Nie tworzymy dodatkowych loggerow w bukkicie, a w dodatku w tej samej klasie.. masz getLoggera..

private Logger log;

Przy wyjsciu z serwera, trade sie prawdopodobnie zbuguje

Co Ty gadasz w ogóle gadasz?

Zdaje sobie sprawę, że zamiast obiektu gracza, mogłem zrobić obiekt UUID, lecz ten plugin pisałem typowo pod mój serwer non-premium, przyszłościowo zamienię to, ale mimo wszystko to i tak jest zmienna tymczasowa, która nigdzie się nie zapisuje i nie ma to prawa do błędu.
Odnośnie logger'a, to nie tworzę dodatkowych, przypisałem do dodatkowej zmiennej, zamienię to, bo faktycznie w tej głównej klasie znajduje się niepotrzebna zmienna.
Co do ostatniego spostrzeżenia, to nie oceniaj czegoś, skoro nawet tego nie testowałeś, nie buguje się, bo wtyczka ma odpowiednie zabezpieczenia.

de76 · 23 Listopada 2017

Chlopie, ja oceniam kod, jest chujowy, wrecz tragiczny, moznaby to zrobic o wiele lepiej.

"zmienna tymczasowa, która nigdzie się nie zapisuje i nie ma to prawa do błędu."

W tym czasie dwoch graczy wychodzi z serwera, trade zostaje, nie uzywasz soft/weak referencji, wiec czego Ty oczekujesz? ze znikna z nieba? GC bedzie myslal ze wciaz uzywasz tego obiektu.

- Gracz po wyjsciu na serwer a potem wejsciu TO NIE TEN SAM OBIEKT.

Polecam sie douczyc, i sluchac rad od kogos kto ma doswiadczenie, a jak sie nie potrafi sluchac krytyki, to nie wrzucac na forum.

Qwant1 · 24 Listopada 2017

Dnia 23.11.2017 o 07:17, de76 napisał:

Chlopie, ja oceniam kod, jest chujowy, wrecz tragiczny, moznaby to zrobic o wiele lepiej.

"zmienna tymczasowa, która nigdzie się nie zapisuje i nie ma to prawa do błędu."

W tym czasie dwoch graczy wychodzi z serwera, trade zostaje, nie uzywasz soft/weak referencji, wiec czego Ty oczekujesz? ze znikna z nieba? GC bedzie myslal ze wciaz uzywasz tego obiektu.

- Gracz po wyjsciu na serwer a potem wejsciu TO NIE TEN SAM OBIEKT.

Polecam sie douczyc, i sluchac rad od kogos kto ma doswiadczenie, a jak sie nie potrafi sluchac krytyki, to nie wrzucac na forum.

Nie mam zamiaru tłumaczyć czegokolwiek osobie, która nic w zakresie programowania nie osiągnęła i która kompletnie nie rozumie działania mojego projektu, referencja do obiektu usuwa się, co wiążę się z tym, że, obiekt usuwa się również automatycznie przez język Javy, ale pozostawię to Tobie znalezienie tego, bo może się czegoś przynajmniej nauczysz.
Gdzie ja napisałem, że gracz po wyjściu, a potem po wejściu na serwer, że jest to ten sam obiekt?
Obiekt "Trade" tworzy się tylko i wyłącznie w trakcie wykonania dwóch pomyślnych interakcji, pomiędzy dwoma graczami.

Potrafię słuchać krytyki, ale nie potrafię słuchać wypowiadania się osób, które myślą, że coś umieją, a tak naprawdę mają pustkę w mózgu odnośnie dziedziny jaką jest programowanie.

DragereKK · 24 Listopada 2017

Ch*jowy plugin.
Sam zrobilbym to lepiej

__AHA__ · 25 Listopada 2017

15 godzin temu, Qwant1 napisał:

Nie mam zamiaru tłumaczyć czegokolwiek osobie, która nic w zakresie programowania nie osiągnęła i która kompletnie nie rozumie działania mojego projektu, referencja do obiektu usuwa się, co wiążę się z tym, że, obiekt usuwa się również automatycznie przez język Javy, ale pozostawię to Tobie znalezienie tego, bo może się czegoś przynajmniej nauczysz.
Gdzie ja napisałem, że gracz po wyjściu, a potem po wejściu na serwer, że jest to ten sam obiekt?
Obiekt "Trade" tworzy się tylko i wyłącznie w trakcie wykonania dwóch pomyślnych interakcji, pomiędzy dwoma graczami.

Potrafię słuchać krytyki, ale nie potrafię słuchać wypowiadania się osób, które myślą, że coś umieją, a tak naprawdę mają pustkę w mózgu odnośnie dziedziny jaką jest programowanie.

przeciez de76 ma racje. To jest tylko kwestia czasu jest jak po trzymaniu obiektow gracza w mapie nagle bedziesz mial leaki.

'referencja do obiektu usuwa się, co wiążę się z tym, że, obiekt usuwa się również automatycznie przez język Javy' *facepalm*

serio?

            Request.requests.put(player, playerTwo);
            Bukkit.getScheduler().scheduleSyncDelayedTask((Plugin)TradeIQ.getInstance(), (Runnable)new Runnable() {
                @Override
                public void run() {
                    if (Request.requests.get(player) == null) {
                        return;
                    }
                    if (Request.requests.get(player).equals(playerTwo)) {
                        Request.requests.remove(player);
                    }
                }
            }, (long)(Config.timeExpiryRequest * 20));
            return;

Qwant1 · 25 Listopada 2017

57 minut temu, __AHA__ napisał:

przeciez de76 ma racje. To jest tylko kwestia czasu jest jak po trzymaniu obiektow gracza w mapie nagle bedziesz mial leaki.

'referencja do obiektu usuwa się, co wiążę się z tym, że, obiekt usuwa się również automatycznie przez język Javy' *facepalm*

serio?


            Request.requests.put(player, playerTwo);
            Bukkit.getScheduler().scheduleSyncDelayedTask((Plugin)TradeIQ.getInstance(), (Runnable)new Runnable() {
                @Override
                public void run() {
                    if (Request.requests.get(player) == null) {
                        return;
                    }
                    if (Request.requests.get(player).equals(playerTwo)) {
                        Request.requests.remove(player);
                    }
                }
            }, (long)(Config.timeExpiryRequest * 20));
            return;

W kwestii żądań usprawnię ten system, bo faktycznie mógłbym to zrobić lepiej, nie zwróciłem na to uwagi, tyle, że my rozmawiamy w tym momencie o obiekcie "Trade" i nie ma on racji, bo jeżeli nie ma referencji do obiektu i jeżeli nie jest on już potrzebny to w takiej sytuacji mechanizm Garbage Collector odzyska zajętą przez obiekt pamięć, pozwalając na jej ponowne wykorzystanie.
W Javie odbywa się to automatycznie, więc nie rozumiem skąd Twoje zaskoczenie.
Natomiast w kwestii soft/weak referencji to w przypadku obiektu "Trade", nie jest to zbytnio bezpieczne, w sytuacji, kiedy gracze handlują swoimi przedmiotami.

Powracając jeszcze do żądań, to mam w planach stworzyć obiekt dla jednego i drugiego gracza i usunąć tą HashMapę.

__AHA__ · 25 Listopada 2017

13 minut temu, Qwant1 napisał:

W kwestii żądań usprawnię ten system, bo faktycznie mógłbym to zrobić lepiej, nie zwróciłem na to uwagi, tyle, że my rozmawiamy w tym momencie o obiekcie "Trade" i nie ma on racji, bo jeżeli nie ma referencji do obiektu i jeżeli nie jest on już potrzebny to w takiej sytuacji mechanizm Garbage Collector odzyska zajętą przez obiekt pamięć, pozwalając na jej ponowne wykorzystanie.
W Javie odbywa się to automatycznie, więc nie rozumiem skąd Twoje zaskoczenie.

Nie chce mi sie sprawdzac dokladnie twojego kodu ale widze ze obiekty trade trzymasz w liscie i nie widze zebys je usuwal gdy gracz wyjdzie z serwera podczas wymiany wiec obiek trade sie nie usuwa

Qwant1 · 25 Listopada 2017

23 minuty temu, __AHA__ napisał:

Nie chce mi sie sprawdzac dokladnie twojego kodu ale widze ze obiekty trade trzymasz w liscie i nie widze zebys je usuwal gdy gracz wyjdzie z serwera podczas wymiany wiec obiek trade sie nie usuwa

Jak możesz cokolwiek widzieć, skoro nie chce Ci się sprawdzać, to teraz zaskoczę Cię:

24019831_924284027729258_1743418991_n.pn

24019768_924284141062580_1229664121_n.pn

Image%202017-11-25%20at%202.45.47%20PM.p

Przypominam, że metoda InventoryCloseEvent wykonuje się, wtedy kiedy gracz zamyka inventory, w sytuacji, kiedy gracz ma otwarte inventory i wychodzi z gry, to wydarzenie wykona się, więc PlayerQuitEvent w tym przypadku nie jest potrzebny.

`Kuba · 25 Listopada 2017

Popraw wszystkie img.

__AHA__ · 25 Listopada 2017

11 minut temu, Qwant1 napisał:

Jak możesz cokolwiek widzieć, skoro nie chce Ci się sprawdzać, to teraz zaskoczę Cię:

Przypominam, że metoda InventoryCloseEvent wykonuje się, wtedy kiedy gracz zamyka inventory, w sytuacji, kiedy gracz ma otwarte inventory i wychodzi z gry, to wydarzenie event się, więc PlayerQuitEvent w tym przypadku nie jest potrzebny.

Nie wiem czy InventoryCloseEvent odpala sie przy wyjsciu z gry ale jezeli tak to w tej kwestii wszystko jest dobrze. Ale tak czy siak pare innych rzeczy mozna poprawic

Qwant1 · 25 Listopada 2017

1 minutę temu, __AHA__ napisał:

Nie wiem czy InventoryCloseEvent odpala sie przy wyjsciu z gry ale jezeli tak to w tej kwestii wszystko jest dobrze

Proszę tutaj masz nawet dowód w postaci sprawdzania długości listy co jedną sekundę:

Image%202017-11-25%20at%202.56.29%20PM.p

Jak widać po wyrzuceniu gracza z serwera InventoryCloseEvent wykonał się, a referencja została usunięta.

de76 · 27 Listopada 2017

Nie we wszystkich przypadkach geniszu, przy exceptionie, przy bungee nie leci czasami clsoeEvent, dlatego sie czepilem.

Gdybys ty glabie wiedzial kim jestem, to bys odszczekal swoje slowa, bylem w minecrafcie zanim ty slyszales slowo java.

Ale skoro juz chcesz byc cwany, to zacznijmy oceniac kod tak jak powinenem to zrobic

1.Projekt
- Nazewnictwo klas to porazka, tak samo paczek.
- Klasa Events to nie Events a Listeners, to po pierwsze, Ty nie "wykonujesz", tylko "sluchasz"
Klasa Request:
- private static HashMap<Player, Player> requests; <-- Tutaj tez kochany usuwasz tak? jak wyjdzie z serwera, bez cache, free memory leaki!
if (Request.requests.get(player) == null) {
return;
}
if (Request.requests.get(player).equals(playerTwo)) {
Request.requests.remove(player);
}

To nie ma racji bytu, przypominam Ci ze w momencie gdy wychodzi gracz on sie staje nullem dopiero gdy nie ma referencji ktora Ty przetrzymujesz, dalej chcesz sie klocic?
Klasa ItemStackAPI:
- Metoda isFull nie jest adekwatna do nazwy, on zwraca Ci czy jest miejsce na slot a nie czy wszystkie itemstacki sa full.
Klasa TradeIQ:
- Naucz sie nazywac klasy, poprawnie, PascalCase
- Nie ustawiasz instancji pluginu onDisable na nulla, przez co referencja dalej istnieje, poleci exception przy loadzie/enable, i juz leak!
- new Config(this.config); <-- Tak btw, nie chce tego komentowac, to w koncu to jest statyczny config czy obiektowy v;?
- private NewUpdate newUpadate; <-- XD, Tak jak mowilem, polecam statyczne metody od takich rzeczy zamiast pakowac obiekt od ujwego update.
Klasa Events:
- Tak jak juz mowilem to sa Listenery! Nie Eventy
- public void join(final PlayerJoinEvent e) <-- x KURWA D , join, co join? matka Ci joinuje?
- final NewUpdate newUpd = TradeIQ.getInstance().getNewUpadate(); <-- Zdajesz sobie sprawe ze co kazdy op wchodzi na serwer STOPUJESZ GLOWNY WATEK BUKKITA SWOIM ujowym requestem apropo update? a co gdy Ci strona padnie?
Klasa PlayerTrade:
- Brak finalnych, nie zmienaisz ich, wiec pilnuj tego, nauczcie sie ze finalne sa po to aby je stosowac.
Klasa Status:
- Nie jestem pewny czy to blad dekompilatora, ale ty zmiennych ktore masz w konstruktorach nigdzie nie przypisujesz wiec na chuj one sa tam?
Klasa NewUpdate:
- XD, blagam nie chce tego komentowac, nie wystarzcylo Ci zrobic statycznej metody, albo stalego obiektu.
PRZECHODZIMY DO FINALU:
KLASA TRADE:
- Wiec jednak wiesz co to obiekt? WoW, dobry poczatek, ale czekaj czekaj... co to tutaj robi? {
private static ArrayList<Trade> trades; <-- Rak CONTENT.
- Dobre nazewnictwo obiektow, player ,playerTwo, bo po co nazwac ich po "imieniu" inviter, accepter, czy jaki inny chuj, jeden dwa, Ciebie mama tez najwyrazniej nazywala trzy.
- Metoda openInventory, czekaj co? A po co tam jest task XD?
- No i te super nazewnictwo zmiennych w metodzie end ;v...
- Czekaj czekaj, to nie koniec!
p1.closeInventory(); p1.updateInventory(); <-- XD? XD? Nie uzywamy updateInventory od X wieku.
- final Inventory inv = Bukkit.createInventory((InventoryHolder)null, Config.size * 9, ChatColor.translateAlternateColorCodes('&', Config.guiName)); <-- Mozna by sobie uproscic zycie tym trade holderem, ale lepiej jebnac nulla, prawda? W koncu Ciebie ktos kiedys tez znullowal.
FINAL:
-
public void inventoryEvent(final InventoryClickEvent e) { <-- Cos zgubiles? Czekaj? To jest listener? obiekt? czy manager? moze factory jednak? No bo nie ma event handlera.. a wiec postanowiles ze przekazujesz caly inventoryClickEvent.. uhm.
   - if (e.getSlot() == 3) { To dobra konfirugacja... po co ten Config
   - Task przetrzymujesz obiekt geniuszu = Przetrzymanie graczy.

   - A wystarczyloby przyjac krytyke, bym sie tak nie czepial!

   btw:
   plugin.yml:
   Nad nazewnictwem wersji tez sie nie znamy?
   version: 1.5
   a ten header w conifgu bym se darowal, ja bym sie nie chwalil ze napisalem "cos" takiego... pluginem tego nie nazwe, obrazilbym swoj kod.
- Kompilowanie pluginu tez ssie, co tutaj robi .classPath oraz .project

Osobiscie mi by musieli doplacic za uzywanie czegos takiego.

Nastepnym razem nie probuj zablysnac, nie cwaniakuj, tym bardziej ze nie masz pojecia zielonego jak dziala GC.

TheMajster · 27 Listopada 2017

1 godzinę temu, de76 napisał:

Nie we wszystkich przypadkach geniszu, przy exceptionie, przy bungee nie leci czasami clsoeEvent, dlatego sie czepilem.

Gdybys ty glabie wiedzial kim jestem, to bys odszczekal swoje slowa, bylem w minecrafcie zanim ty slyszales slowo java.

Ale skoro juz chcesz byc cwany, to zacznijmy oceniac kod tak jak powinenem to zrobic

1.Projekt
- Nazewnictwo klas to porazka, tak samo paczek.
- Klasa Events to nie Events a Listeners, to po pierwsze, Ty nie "wykonujesz", tylko "sluchasz"
Klasa Request:
- private static HashMap<Player, Player> requests; <-- Tutaj tez kochany usuwasz tak? jak wyjdzie z serwera, bez cache, free memory leaki!
if (Request.requests.get(player) == null) {
return;
}
if (Request.requests.get(player).equals(playerTwo)) {
Request.requests.remove(player);
}

To nie ma racji bytu, przypominam Ci ze w momencie gdy wychodzi gracz on sie staje nullem dopiero gdy nie ma referencji ktora Ty przetrzymujesz, dalej chcesz sie klocic?
Klasa ItemStackAPI:
- Metoda isFull nie jest adekwatna do nazwy, on zwraca Ci czy jest miejsce na slot a nie czy wszystkie itemstacki sa full.
Klasa TradeIQ:
- Naucz sie nazywac klasy, poprawnie, PascalCase
- Nie ustawiasz instancji pluginu onDisable na nulla, przez co referencja dalej istnieje, poleci exception przy loadzie/enable, i juz leak!
- new Config(this.config); <-- Tak btw, nie chce tego komentowac, to w koncu to jest statyczny config czy obiektowy v;?
- private NewUpdate newUpadate; <-- XD, Tak jak mowilem, polecam statyczne metody od takich rzeczy zamiast pakowac obiekt od ujwego update.
Klasa Events:
- Tak jak juz mowilem to sa Listenery! Nie Eventy
- public void join(final PlayerJoinEvent e) <-- x KURWA D , join, co join? matka Ci joinuje?
- final NewUpdate newUpd = TradeIQ.getInstance().getNewUpadate(); <-- Zdajesz sobie sprawe ze co kazdy op wchodzi na serwer STOPUJESZ GLOWNY WATEK BUKKITA SWOIM ujowym requestem apropo update? a co gdy Ci strona padnie?
Klasa PlayerTrade:
- Brak finalnych, nie zmienaisz ich, wiec pilnuj tego, nauczcie sie ze finalne sa po to aby je stosowac.
Klasa Status:
- Nie jestem pewny czy to blad dekompilatora, ale ty zmiennych ktore masz w konstruktorach nigdzie nie przypisujesz wiec na chuj one sa tam?
Klasa NewUpdate:
- XD, blagam nie chce tego komentowac, nie wystarzcylo Ci zrobic statycznej metody, albo stalego obiektu.
PRZECHODZIMY DO FINALU:
KLASA TRADE:
- Wiec jednak wiesz co to obiekt? WoW, dobry poczatek, ale czekaj czekaj... co to tutaj robi? {
private static ArrayList<Trade> trades; <-- Rak CONTENT.
- Dobre nazewnictwo obiektow, player ,playerTwo, bo po co nazwac ich po "imieniu" inviter, accepter, czy jaki inny chuj, jeden dwa, Ciebie mama tez najwyrazniej nazywala trzy.
- Metoda openInventory, czekaj co? A po co tam jest task XD?
- No i te super nazewnictwo zmiennych w metodzie end ;v...
- Czekaj czekaj, to nie koniec!
p1.closeInventory(); p1.updateInventory(); <-- XD? XD? Nie uzywamy updateInventory od X wieku.
- final Inventory inv = Bukkit.createInventory((InventoryHolder)null, Config.size * 9, ChatColor.translateAlternateColorCodes('&', Config.guiName)); <-- Mozna by sobie uproscic zycie tym trade holderem, ale lepiej jebnac nulla, prawda? W koncu Ciebie ktos kiedys tez znullowal.
FINAL:
-
public void inventoryEvent(final InventoryClickEvent e) { <-- Cos zgubiles? Czekaj? To jest listener? obiekt? czy manager? moze factory jednak? No bo nie ma event handlera.. a wiec postanowiles ze przekazujesz caly inventoryClickEvent.. uhm.
   - if (e.getSlot() == 3) { To dobra konfirugacja... po co ten Config
   - Task przetrzymujesz obiekt geniuszu = Przetrzymanie graczy.

   - A wystarczyloby przyjac krytyke, bym sie tak nie czepial!

   btw:
   plugin.yml:
   Nad nazewnictwem wersji tez sie nie znamy?
   version: 1.5
   a ten header w conifgu bym se darowal, ja bym sie nie chwalil ze napisalem "cos" takiego... pluginem tego nie nazwe, obrazilbym swoj kod.
- Kompilowanie pluginu tez ssie, co tutaj robi .classPath oraz .project


Osobiscie mi by musieli doplacic za uzywanie czegos takiego.

Nastepnym razem nie probuj zablysnac, nie cwaniakuj, tym bardziej ze nie masz pojecia zielonego jak dziala GC.

Programistik, Ty dalej na tym forum ??

@Topic

Co do pluginu, zgodzę się z Otkiem.

Autorze tematu, teraz powinienneś zastosować te wszystkie "upominki" które dostałeś i update wpierdzielic

Zaloguj się

👋 Witaj na MPCForum!

[Plugin] ＴＲＡＤＥＩＱ - Bezpieczny i szybki handel z graczami.

Rekomendowane odpowiedzi

Zarchiwizowany