GotoFinal

też średnio lubie API sponga, ale jednak entity czy bloki mają dobrze zrobione, trochę tylko zmienić by jednak pozbyć się nadmiaru pierniczenia z tym. Typy tylko na strigach to też jak napisałem beznadziejny pomysł w API bo ani to wygodne ani bezpieczne. Bukkit nie jest takim typem abstrakcji, tylko większość obiektów cały czas gdzieś żyje i bukkit to ogarnia by nie tworzyć ich za dużo i za często. I własny plugin jak najbardziej może być wieloplatformowy, a robiąc API pod wiele platform powinniście od razu pisać nad przynajmniej dwa, nie po to by było, ale po to by zobaczyć jak wiele jest różnić i że z waszymi rozwiązaniami nie będziecie w stanie tego dobrze wspierać. + możliwości, na każdym silniku są inne, nie każdy wspiera wszystkie featury, gdzie bukkit jest chyba najniżej i wspiera najmniej. A closed source często ubija takie projekty, bo mała szansa że ktoś będzie chciał to dalej rozwijać i pomagać, a to tylko mały kawałek dupnego kodu, nie ma co go chować. A skrypowych libek pod bukkita też jest sporo i to na różne języki, jak też np groovy - zdecydowanie ciekawszy pod szybkie skrypty, co prawda niby nie są pisane pod wieloplatformowość, ale wasza wieloplatformowość i tak nie istnieje i jest tylko pustym sloganem Pisze to jako osoba co robiła podobne API chcąc stworzyć diorite i poległa bo 2 wersje minecrafta potem 90% była już nieaktualna i tak właściwe legacy. A wy napisaliście legacy już od razu. Bukkit kompletnie nie odwzorowuje aktualnego wyglądu minecrafta, to jedna wielka paczka legacy dająca ci możliwości minecrafta beta ale pod najnowszą wersją MC

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

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

tylko po co robić to samemu? użyj fast login + ma też kod open source to jak coś nie dziala jak ty chcesz to możesz sobie edytować, ale w 90% przypadków wystarczy zmienić samą konfiguracje, a pozostałe 10% to głównie podczepienie wlasnego pluginu logowania, ale wtedy też chyba nie trzeba edytować pluginu tylko dopisać wsparcie w pluginie na logowanie lub dodatkowym osobnym pluginie. A w dużym skrócie sprawdzanie polega na: 1. Już w momencie handshake i pierwszego pakietu logowania sprawdzeniu czy nick gracza który chce wejść należy do konta premium (w bungee jest event w tym momencie) 2. Jeśli należy to jest szansa że gracz też jest premium, dlatego przeprowadza się autoryzację - taką samą jak normlanie wykonuje serwer z online-mode true (bungee ma prostą metodę connection.setOnlineMode i samo osobie ogarnie autoryzacje) 3. Jeśli nie należy to na pewno jest to gracz z pirackim klientem dlatego nie można przeprowadzić autoryzacji bo klient się rozłączy Oczywiście dochodzi masa problemów do przemyślenia: Co robić z UUID, co jak gracz premium zmieni nick na nick kogoś to już gra jako pirat itd itp.

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

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

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

Pewnie event wywołuje się więcej niż raz, np ze względu na to jak minecraft obsługuje obie ręce https://hub.spigotmc.org/javadocs/bukkit/org/bukkit/event/player/PlayerInteractEntityEvent.html#getHand-- Musisz sprawdzić czy użył głównej ręki. A tak to nie ładuj plików w takich eventach przy każdym kliknięciu... wszystkie takie dane powinieneś załadować na starcie pluginów do odpowiedniej struktury obiektów - inaczej każde kliknięcie będzie zatrzymywać serwer na czas odczytu pliku.

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

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

trudno powiedzieć... skrypty to bardzo ch... język który jest pełen dziwnych rozwiązań których się nigdy nie stosuje w normlanym kodzie i pewnie nawet funkcji nie tworzyłeś. No ale coś tam łatwiej na pewno będzie

Ah, co do pkt piątego to chyba dodał to podczas edytowania postu, bo wcześniej zwyczajnie nie widziałem tam żadnego punktu piątego było 4 a potem 6 ;/ a kolizje powinien spectator jako tako ogarnąć. A EntityTargetEvent to no, średnio to działa, moby i tak będą go widzieć i np losowo zerkać i śledzić go wzrokiem - bo mają to w AI.

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

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