Plugin na /r (Reply)

Daj twoj skrypt moze cos sie uda zrobic

32 minuty temu, magmacode_2 napisał:

Daj twoj skrypt moze cos sie uda zrobic

 

Pytanie dotyczy tworzenia pluginu, nie skryptu interpretowanego przez plugin Skript.

54 minuty temu, DeepesT napisał:

Witam, mam plugin na /msg który napisałem ale za uja nie mogę zrobić na /r ktoś pomoże jak to ugryźć  Dziękuję  

Co prawda twórca pluginów ze mnie żaden, ale powiem Panu jak ja to widzę.

Moim zdaniem, najprostszym rozwiązaniem będzie stworzenie mapy (HashMap) przechowującej pary graczy, gdzie klucz to gracz odbierający, a wartość to gracz wysyłający. Mapa ta będzie używana jednocześnie przez komendy /msg i /r.

HashMap<Player, Player> replyMap = new HashMap<>();

Komenda /msg przy wysyłaniu wiadomości będzie uzupełniała mapę o parę <gracz odbierający, gracz wysyłający>. W ten sposób można łatwo w kodzie komendy /r wykorzystać poniższą linijkę, która zwróci gracza, do którego ma zostać wysłana odpowiedź.

Player receiver = replyMap.get(player);

Naturalnie, po wysłaniu odpowiedzi za pomocą komendy /r należy ponownie uzupełnić mapę tak samo jak w przypadku komendy /msg. Proszę tylko pamiętać, że tutaj role się zamieniają - gracz wysyłający wiadomość przy pomocy komendy /msg staje się odbierającym, a gracz wysyłający odpowiedź staje się wysyłającym.

Pominąłem czysto techniczne kwestie takie jak chociażby sprawdzanie czy gracz, do którego wysyła się wiadomość/odpowiedź, jest obecny na serwerze, czy też sprawdzanie czy gracz może komukolwiek odpowiedzieć za pomocą komendy /r (posiada gracza mu przypisanego w mapie). Moim celem nie było dokładne pokazanie jak należy zaimplementować ten mechanizm. Chciałem jedynie pokazać samą ideę.

Pozdrawiam.

4 godziny temu, Kormic napisał:

Pytanie dotyczy tworzenia pluginu, nie skryptu interpretowanego przez plugin Skript.

Co prawda twórca pluginów ze mnie żaden, ale powiem Panu jak ja to widzę.

Moim zdaniem, najprostszym rozwiązaniem będzie stworzenie mapy (HashMap) przechowującej pary graczy, gdzie klucz to gracz odbierający, a wartość to gracz wysyłający. Mapa ta będzie używana jednocześnie przez komendy /msg i /r.

HashMap<Player, Player> replyMap = new HashMap<>();

Komenda /msg przy wysyłaniu wiadomości będzie uzupełniała mapę o parę <gracz odbierający, gracz wysyłający>. W ten sposób można łatwo w kodzie komendy /r wykorzystać poniższą linijkę, która zwróci gracza, do którego ma zostać wysłana odpowiedź.

Player receiver = replyMap.get(player);

Naturalnie, po wysłaniu odpowiedzi za pomocą komendy /r należy ponownie uzupełnić mapę tak samo jak w przypadku komendy /msg. Proszę tylko pamiętać, że tutaj role się zamieniają - gracz wysyłający wiadomość przy pomocy komendy /msg staje się odbierającym, a gracz wysyłający odpowiedź staje się wysyłającym.

Pominąłem czysto techniczne kwestie takie jak chociażby sprawdzanie czy gracz, do którego wysyła się wiadomość/odpowiedź, jest obecny na serwerze, czy też sprawdzanie czy gracz może komukolwiek odpowiedzieć za pomocą komendy /r (posiada gracza mu przypisanego w mapie). Moim celem nie było dokładne pokazanie jak należy zaimplementować ten mechanizm. Chciałem jedynie pokazać samą ideę.

Pozdrawiam.

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

Bo zatrzymałem się na usage /.... a dalej nie mam pojęcia co i jak /msg poszło w miarę a /r nie idzie mi wg  

10 minut temu, opkarol napisał:

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

Nie powiedziałbym "można, ale "nawet trzeba", tak więc dziękuję za uwagę. Skupiłem się na tłumaczeniu mechanizmu i samej idei (o czym zresztą wspomniałem), przez co zapomniałem o takiej prostocie, która może być groźna na dłuższą metę. Dla mniej świadomych, już tłumaczę dlaczego.

1. W przypadku chęci zapisu zawartości mapy na dysku wymagałoby to serializacji danych, a przy odczycie deserializacji. Jeżeli zapiszemy samo UUID, problem ten się rozwiązuje, a pobranie obiektu gracza na jego podstawie jest trywialne.
2. Używanie UUID nie jest jakkolwiek gorsze względem używanie obiektu gracza. Poza tym, łatwiej jest zarządzać mapą de facto ciągów znaków (nie w dosłownym sensie) niż mapą złożonych obiektów, które w następnym ticku już nie muszą być idealnym odzwierciedleniem (np. lokalizacja może być inna).
3. Obiekt Player ulega ciągłym modyfikacjom, szczególnie między ponownymi dołączeniami do serwera. Przy wychodzeniu, ponownym wchodzeniu i pisaniu wiadomości najprawdopodobniej tworzyłoby się wiele obiektów gracza wskazujących na tego samego gracza, z czego poprzednie byłyby już nieaktualne, a więc zostawałyby w tej mapie do restartu serwera, co w konsekwencji doprowadziłoby do wycieku pamięci. Co prawda nie byłby on drastyczny, ale każdy wyciek pamięci należy traktować z powagą. Mogę się jednak mylić i nawet po ponownym dołączeniu stary obiekt Player będzie w pełni poprawny - wtedy proszę o poprawienie mnie.

Programistyczni puryści z pewnością jeszcze pokusiliby się o dalsze zabezpieczenia, aby zapobiec wyciekowi w przypadku zmiany nazwy gracza na serwerze w trybie offline, bo trzeba pamiętać, że na serwerach offline UUID jest generowane na podstawie nazwy gracza. 

Pozdrawiam.

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.

20 minut temu, kerpson napisał:

 

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

11 godzin temu, opkarol napisał:

jakaś bazę danych do zapisu plików na serwerze

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.

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

11 godzin temu, opkarol napisał:

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.

Nie rozumiem ostatniej części z tą bazą danych. Można jaśniej?

11 godzin temu, opkarol napisał:

Zamiast tego wszystkiego można postawić zwykłą mapę która wystarczy autorowi postu

Też tak uważam.

Pozdrawiam.

Godzinę temu, Kormic napisał:

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.

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.