Ranking

Witajcie! Nowa Aktualizacja o opcje o którą pytał @maloy78 została wdrożona zapraszam wszystkich do testów! Skrypt testowany na wersji serwer 1.20.4 oraz skripcie 2.8.3! Kod zamieszczony w pierwszym poście!

Już ogarnięte. Dzięki za pomoc osobom z discorda!

Zgadzam się z Tobą, samo przetrzymywanie takich danych w mapie nie jest pamięcio-żerne, nie wpłynie w większej ilości na wydajność. Ale na wydajność składa się całokształt, pisząc bardziej rozbudowane pluginy, należy mieć na uwadze wszystkie zmienne, nie możemy przypuszczać czy zapiszemy 200 obiektów, czy jednak 2000. Trzeba umieć rozróżnić, czy dane muszą być przetrzymywane stale, czy jednak mogą być uwalniane co jakiś czas. Dodatkowo sposób ułożenia takiej mapy jest dosyć istotny (konkretnie chodzi o to, co ma być kluczem a co wartością, gdyż w przypadku reply wpływać to będzie na ilość wpisów). Autor jest osobą początkującą w pluginach, uważam, że warto poruszać takie tematy gdyż to siłą rzeczy nie są proste rozwiązania, a raczej wymagają zastanowienia się. Dla autora: możesz śmiało użyć zwykłej mapy, nie wpłynie to na wydajność i nie będzie złe. Natomiast dla dobrej praktyki dane powinny być uwalniane gdy nie muszą być stałe.

Chodzi mu o to, żeby nie móc stawiać kryształów w overworldzie. Skoro Pan się pyta to rozumiem, że nie jest Pan za bardzo w temacie PvP. Crystali się używa do walki bo po prostu zadają chory damage jak się postawi w odpowiednim miejscu, tak zwany Crystal PvP, ale wracając - Chodzi mu o to, żeby tych Crystali się dało używać tylko w endzie, a w zwykłym świecie nie. Czyli inaczej żeby Crystal PvP był dostępny tylko w Endzie.

Będąc szczerym, nie sądziłem, że tutaj dojdzie do tak merytorycznej dyskusji. Taka wymiana zdań zawsze cieszy oko. Chapeau bas dla obu Panów. A teraz wrócę do meritum sprawy. @kerpson Cache'owanie to z pewnością dobra praktyka i po przejrzeniu biblioteki Caffeine mogę stwierdzić, że jest naprawdę sensownie napisana. Pytanie jednak brzmi - czy warto? A raczej - czy opłaca się? Wystarczy spojrzeć na ilość danych, na jakiej plugin będzie operował. Jeżeli założymy, że ta mapa (HashMap) będzie jedynym pojemnikiem na dane w pluginie, łatwo pokazać, że w normalnych warunkach pracy (patrz: programistyczni puryści, o których wspomniałem wyżej) nie będzie ona przechowywała więcej niż N wpisów, gdzie N to ilość graczy, która weszła na serwer od początku startu serwera. Zakładając, że mówimy o małym serwerze, który jest restartowany co 24 godziny w środku nocy, liczba graczy nie przekroczy 200-300 (mówimy ciągle o wszystkich unikalnych graczach liczonych od początku działania pluginu). Gdyby to był popularny serwer, z pewnością użycie tej czy innej biblioteki do cache'owania jest dobre. W tym przypadku jednak wydaje mi się, że to jest delikatny tzw. overkill, ponieważ przechowywanie kilkuset par UUID zajmie nie więcej niż kilkadziesiąt kilobajtów pamięci RAM. Swoją drogą, to co jest sensowne, jest w tym przypadku rzeczą względnie subiektywną. Jeden właściciel serwera faktycznie może uważać, że usuwanie danych od komendy /r powinno następować po 15 minutach. Drugi uzna, że nie musi czyścić tych danych, bo chce, aby gracze nawet po pójściu AFK na 30 minut mogli nadal odpisać swojemu koledze, a poza tym to na serwerze będzie w jednym momencie nie więcej niż 20 graczy. @opkarol Nie rozumiem ostatniej części z tą bazą danych. Można jaśniej? Też tak uważam. Pozdrawiam.

wut Co do wypowiedzi, nie, funkcja reply to nie jest istotna funkcja, która powinna być przechowywana w mapie przez cały czas działania pluginu. Reply powinno być zachowane w pamięci tylko przez pewien czas, trzymanie tej funkcji w nieskończoność jest marnowaniem pamięci i przy okazji niepoprawną praktyką. // Edit jeszcze odniosę się do jednego Tak, autorowi postu to wystarczy jak najbardziej, lecz to jest zła praktyka. Nie trzymamy bez sensu obiektów, które tego nie wymagają. Obiekty powinny być tak długo przechowywane, tak długo jak będą nam potrzebne.

A mi się akurat wydaje, że bardzo ważnym będzie zachować persistence podczas restartów serwera, żeby podczas możliwego crasha serwera (np. Spowodowanego zbyt duża ilością bibliotek cacheujacych w pluginach) gracz X mógł nadal szybko odpisać graczowi Y. Aby to osiągnąć wypadałoby zastosować bazę danych i dobrym wyborem będzie użycie HikariCP, żeby dobrze zarządzać poolem połączeń oraz jakaś bazę danych do zapisu plików na serwerze, żeby nie płacić za dodatkowe bazy danych. Albo nawet nie! Zamiast tego wszystkiego można postawić zwykłą mapę która wystarczy autorowi postu

No a ja bym Panowie powiedział inaczej, po co trzymać te obiekty? Reply nie posiada wartości, które muszą być przechowywane przez cały czas działania pluginu. Zaleciłbym użycie cache od Caffeine, który automatycznie usuwa wartości po ustalonym przez nas czasie np. 15 minut. Przy wymianach wiadomości, można ten czas odnawiać. Będzie to najlepsze rozwiązanie, gdyż po pewnym czasie obiekty zostaną usunięte z cache.

Niestety dalej to samo, dziwnym jest to że tylko z butami jest taki problem, ponieważ np. ze zwykłym diamentem wszystko działa.

Generalnie tak, ale są pewne wyjątki od tej reguły. Czasem pojawia się chęć spolszczenia jakiegoś pluginu, a nieraz bywa tak, że wszystko w pluginie jest zaimplementowane w jednej komendzie, która posiada wiele możliwych do podania argumentów. Wtedy plik commands.yml staje się niewystarczający i trzeba się posiłkować pluginami lub Skriptem, ponieważ pozwala on jedynie na pobranie wpisanego argumentu, a nie przypisanie de facto aliasów do argumentów komend. Dobrym przykładem takiej "uber" komendy jest /lp od pluginu LuckPerms. Pozdrawiam.

Wszystko ok tylko zamiast mapy Player, Player można dać UUID, UUID i później pobierać gracza z Bukkit.getPlayer(#uuid)