Skocz do zawartości

  • 👋 Witaj na MPCForum!

    Przeglądasz forum jako gość, co oznacza, że wiele świetnych funkcji jest jeszcze przed Tobą! 😎

    • ✅ Pełny dostęp do działów i ukrytych treści
    • ✅ Możliwość pisania i odpowiadania w tematach
    • ✅ System prywatnych wiadomości
    • ✅ Zbieranie reputacji i rozwijanie swojego profilu
    • ✅ Członkostwo w jednej z największych społeczności graczy

    👉 Dołączenie zajmie Ci mniej niż minutę – a zyskasz znacznie więcej!

    Zarejestruj się teraz

[Plugin] BetonQuest - Zaawansowany plugin na questy w stylu RPG

Gość

Przez Gość
w Minecraft - Projekty i download

Rekomendowane odpowiedzi

  • Odpowiedzi 280
  • Dodano
  • Ostatniej odpowiedzi
Gość

Gość

Opublikowano

Gość

Opublikowano

EDIT: już nieważne xD

 

Naprawiłeś czy olałeś sprawę? W obu przypadkach odpisz mi na PW, bo chciałbym to naprawić. btw REFRESH

Gość

Gość

Opublikowano

Gość

Opublikowano

@Co0sh

 

Marnujesz sie Typie przy tym projekcie :P

 

A masz jakiś lepszy? :P

SlimaKCode Pomocnik

SlimaKCode

Opublikowano
Pomocnik

SlimaKCode

Opublikowano

@Co0sh 

Co byś powiedział na jakąś listę questów i miejsc gdzie są na stronie WWW? Lub nawet możliwość pisania, wybierania, wykonywania i nadzorowania questów przez stronę WWW. Dodatkowo myślę, że osobną kwestią byłaby możliwa kompatybilność z Dynmap. Można by wtedy oznaczać na mapie różne lokację z listą questów.

Gość

Gość

Opublikowano

Gość

Opublikowano
 

@Co0sh 

Co byś powiedział na jakąś listę questów i miejsc gdzie są na stronie WWW? Lub nawet możliwość pisania, wybierania, wykonywania i nadzorowania questów przez stronę WWW. Dodatkowo myślę, że osobną kwestią byłaby możliwa kompatybilność z Dynmap. Można by wtedy oznaczać na mapie różne lokację z listą questów.

 

https://github.com/Co0sh/BetonQuest/milestones/Editor

 

Takie coś już jest zaplanowane, nawet jest pierwsza implementacja serwera HTTP (która nic jeszcze nie robi poza wyświetlaniem napisu "Hello World"). Niestety jest to temat na tyle rozbudowany, że nie pojawi się w kolejnej wersji 1.6, tylko później, w 1.7.

 

Kompatybilność z DynMap jest zbędna, bo znaczniki możesz dodawać z poziomu dynmapowej komendy. A znaczniki widoczne tylko dla konkretnych graczy nie są możliwe do zrobienia przez API Dynmapy.

 

­Bardzo ciekawy plugin, muszę przyznać. Bardzo rozbudowany jak na normalny plugin na Questy. :)

 

Bo to nie jest normalny plugin na questy. To jest Zaawansowany plugin na questy :D

SlimaKCode Pomocnik

SlimaKCode

Opublikowano
Pomocnik

SlimaKCode

Opublikowano

@Co0sh

 

 

 

 

https://github.com/Co0sh/BetonQuest/milestones/Editor

 

Takie coś już jest zaplanowane, nawet jest pierwsza implementacja serwera HTTP (która nic jeszcze nie robi poza wyświetlaniem napisu "Hello World"). Niestety jest to temat na tyle rozbudowany, że nie pojawi się w kolejnej wersji 1.6, tylko później, w 1.7.

 

Kompatybilność z DynMap jest zbędna, bo znaczniki możesz dodawać z poziomu dynmapowej komendy. A znaczniki widoczne tylko dla konkretnych graczy nie są możliwe do zrobienia przez API Dynmapy.

 

 

Bo to nie jest normalny plugin na questy. To jest Zaawansowany plugin na questy :D

 

 

Dla Dynmap nie do końca o same znaczniki chodziło, ale w sumie to bez znaczenia. Tak po zastanowieniu, więcej było by z tym pracy niż to warte.

 

A co do interfejsu web nie jest on jeszcze tworzony, jedynie planowany, tak? Jeżeli tak to nic nie szkodzi na przeszkodzie bym coś takiego napisał? ;) Podoba mi się ten projekt i chętnie bym go wspomógł, ale niestety nie znam się za dobrze na Javie, ale za to z PHP5 dałbym sobie radę (chyba... I'm still new...)  ;) (Mam nawet już jeden publiczny projekt jak Cię to interesuje: https://github.com/projectQOrganization/projectQ/tree/Development, jest tam link do strony z demo).

Gość

Gość

Opublikowano

Gość

Opublikowano

Dla Dynmap nie do końca o same znaczniki chodziło, ale w sumie to bez znaczenia. Tak po zastanowieniu, więcej było by z tym pracy niż to warte.

 

A co do interfejsu web nie jest on jeszcze tworzony, jedynie planowany, tak? Jeżeli tak to nic nie szkodzi na przeszkodzie bym coś takiego napisał? ;) Podoba mi się ten projekt i chętnie bym go wspomógł, ale niestety nie znam się za dobrze na Javie, ale za to z PHP5 dałbym sobie radę (chyba... I'm still new...)  ;) (Mam nawet już jeden publiczny projekt jak Cię to interesuje: https://github.com/projectQOrganization/projectQ, jest tam link do strony z demo).

 

Pisanie tego w PHP wymagałoby dołączenia do pluginu interpretera tego języka. To za bardzo nie ma sensu. Strona zostanie napisana w Javie, bo tak jest w tym wypadku najłatwiej. Za pomocą Javy będzie generowany kod HTML, CSS i JavaScript. JavaScript będzie wykonywał operacje na plikach i odpowiednimi metodami dostarczał je do serwera, który będzie to weryfikował i zapisywał do konfiguracji / bazy danych.

 

EDIT:

Ah, masz na myśli edytor całkowicie zewnętrzny, niezależny od pluginu... Ja miałem pomysł dołączenia go bezpośrednio do pluginu, tak jak stronka, którą generuje Dynmapa. Wydaje mi się, że moje rozwiązanie będzie jednak odrobinę lepsze: nie musisz posiadać osobnego serwera WWW ani bazy MySQL, nie musisz instalować dodatkowych pluginów łączących web-end z BetonQuestem, wszystko to jest dołączone do pluginu. A wydajność Twojego rozwiązania jest tylko odrobinę większa (generowanie strony internetowej nie jest obsługiwane przez serwer, ale cała logika połączenia tego z BetonQuestem już tak), i raczej nie rekompensuje potrzeby utrzymania dodatkowego serwera WWW. A jak ten serwer jest na tej samej maszynie to łączna wydajność będzie jeszcze niższa.

SlimaKCode Pomocnik

SlimaKCode

Opublikowano
Pomocnik

SlimaKCode

Opublikowano

Pisanie tego w PHP wymagałoby dołączenia do pluginu interpretera tego języka. To za bardzo nie ma sensu. Strona zostanie napisana w Javie, bo tak jest w tym wypadku najłatwiej. Za pomocą Javy będzie generowany kod HTML, CSS i JavaScript. JavaScript będzie wykonywał operacje na plikach i odpowiednimi metodami dostarczał je do serwera, który będzie to weryfikował i zapisywał do konfiguracji / bazy danych.

 

Nie musisz dołączać interpretera języka do pluginu. PHP5 pracowało by jako webend na bazie danych, a plugin musiałby ją tylko aktualizować. Pakowanie całej strony do pluginu i pisanie jej w Javie to przesada. Jedyny pluginem przy jakim miało to sens jest Dynmap, który był stworzony tylko po to. Do tego Dynmap musiał być stworzony w ten sposób ze względu na wysoką dynamiczność jego interfejsu. Po za tym zarządzanie stroną z pozycji pluginu mija się z celem, w tym wypadku nie dość, że strona WWW obciąża sam serwer Minecraft i Javę to do tego musi być na tej samej maszynie co serwer. Wiele ogarniętych serwerów trzyma osobno serwery Minecraft, osobno bazy danych i osobno serwer WWW.  Stronę napisaną w PHP5 łatwiej jest dostosować do już istniejących stron internetowych, które również są napisane w PHP5. Wspomniałeś coś o JavaScript, oczywiście jest nieodzownym fragmentem PHP5, ale opieranie się tylko o niego jest głupstwem. Jak już dla wysoko-dynamicznych stron stosuje się AJAX, który nie ogranicza się tylko do JavaScript. Jednakże pisanie strony w AJAX ma sens na przykład w przypadku GG, czy gdzieś gdzie strona musi obsługiwać zapytania bez przeładowywania jej. Oczywiście są liczne wady takiego rozwiązania i wymaga ono webmasterów na dość wysokim poziomie oraz sporo czasu. Reasumując mam nadzieję, że już rozumiesz czemu stawiam na PHP5 (Mysqli) + JavaScript (JQuery) + CSS3 (ew. Less lub Sass).

 

@Edit

 

Pisanie tego w PHP wymagałoby dołączenia do pluginu interpretera tego języka. To za bardzo nie ma sensu. Strona zostanie napisana w Javie, bo tak jest w tym wypadku najłatwiej. Za pomocą Javy będzie generowany kod HTML, CSS i JavaScript. JavaScript będzie wykonywał operacje na plikach i odpowiednimi metodami dostarczał je do serwera, który będzie to weryfikował i zapisywał do konfiguracji / bazy danych.

 

EDIT:

Ah, masz na myśli edytor całkowicie zewnętrzny, niezależny od pluginu... Ja miałem pomysł dołączenia go bezpośrednio do pluginu, tak jak stronka, którą generuje Dynmapa. Wydaje mi się, że moje rozwiązanie będzie jednak odrobinę lepsze: nie musisz posiadać osobnego serwera WWW ani bazy MySQL, nie musisz instalować dodatkowych pluginów łączących web-end z BetonQuestem, wszystko to jest dołączone do pluginu. A wydajność Twojego rozwiązania jest tylko odrobinę większa (generowanie strony internetowej nie jest obsługiwane przez serwer, ale cała logika połączenia tego z BetonQuestem już tak), i raczej nie rekompensuje potrzeby utrzymania dodatkowego serwera WWW. A jak ten serwer jest na tej samej maszynie to łączna wydajność będzie jeszcze niższa.

 
Zdecydowana większość serwerów ma swoje strony internetowe, więc również serwery WWW. A nawet jeżeli nie ma to koszt takiego serwera to grosze, jest także sporo darmowych hostingów, ale z reklamami. Jeżeli ktoś postawił serwer WWW na tej samej maszynie co serwer Minecraft to w gruncie rzeczy dodanie dodatkowej podstrony nie robi mu różnicy ;)
Gość

Gość

Opublikowano

Gość

Opublikowano

 

Nie musisz dołączać interpretera języka do pluginu. PHP5 pracowało by jako webend na bazie danych, a plugin musiałby ją tylko aktualizować. Pakowanie całej strony do pluginu i pisanie jej w Javie to przesada. Jedyny pluginem przy jakim miało to sens jest Dynmap, który był stworzony tylko po to. Do tego Dynmap musiał być stworzony w ten sposób ze względu na wysoką dynamiczność jego interfejsu. Po za tym zarządzanie stroną z pozycji pluginu mija się z celem, w tym wypadku nie dość, że strona WWW obciąża sam serwer Minecraft i Javę to do tego musi być na tej samej maszynie co serwer. Wiele ogarniętych serwerów trzyma osobno serwery Minecraft, osobno bazy danych i osobno serwer WWW.  Stronę napisaną w PHP5 łatwiej jest dostosować do już istniejących stron internetowych, które również są napisane w PHP5. Wspomniałeś coś o JavaScript, oczywiście jest nieodzownym fragmentem PHP5, ale opieranie się tylko o niego jest głupstwem. Jak już dla wysoko-dynamicznych stron stosuje się AJAX, który nie ogranicza się tylko do JavaScript. Jednakże pisanie strony w AJAX ma sens na przykład w przypadku GG, czy gdzieś gdzie strona musi obsługiwać zapytania bez przeładowywania jej. Oczywiście są liczne wady takiego rozwiązania i wymaga ono webmasterów na dość wysokim poziomie oraz sporo czasu. Reasumując mam nadzieję, że już rozumiesz czemu stawiam na PHP5 (Mysqli) + JavaScript (JQuery) + CSS3 (ew. Less lub Sass).

 

@Edit

 

 
Zdecydowana większość serwerów ma swoje strony internetowe, więc również serwery WWW. A nawet jeżeli nie ma to koszt takiego serwera to grosze, jest także sporo darmowych hostingów, ale z reklamami. Jeżeli ktoś postawił serwer WWW na tej samej maszynie co serwer Minecraft to w gruncie rzeczy dodanie dodatkowej podstrony nie robi mu różnicy ;)

 

 

To co mówisz o obciążeniu wywoływanym przez stronę byłoby prawdą, jeśli edytor byłby używany przez każdego gracza. Tak jednak nie będzie, więc jedyne obciążenie dla serwera to jeden asynchroniczny wątek pasywnie nasłuchujący requestów HTTP i ewentualnie odpowiadający na nie. Kod odpowiedzialny za odpowiadanie na te żądania będzie niewielki (weryfikacja użytkownika + ładowanie otrzymanych danych do pluginu), więc biorąc pod uwagę to, że będzie wykonywany średnio raz na minutę obciążenie jest prawie żadne.

 

Zauważ, że nie ma potrzeby dodawania miliona różnych zabezpieczeń. Wystarczy olewać wszystkie requesty od niezalogowanych użytkowników, a jeśli użytkownik jest zalogowany (admin), to nie będzie chciał przecież niszczyć ani hackować swojego własnego serwera.

 

Dodatkowo Twój web-end będzie musiał korzystać z  osobnego pluginu do interakcji z BetonQuestem, bo konfiguracja questów nie jest przechowywana w bazie danych, tylko w plikach na serwerze. Baza danych przechowuje jedynie dane graczy (tak jak być powinno).

 

Można takie coś napisać, ale uważam to za odrobinę bezsensowne, bo uparłem się na wbudowanie w mój plugin edytora questów już dawno i zamierzam to zrobić.

SlimaKCode Pomocnik

SlimaKCode

Opublikowano
Pomocnik

SlimaKCode

Opublikowano

To co mówisz o obciążeniu wywoływanym przez stronę byłoby prawdą, jeśli edytor byłby używany przez każdego gracza. Tak jednak nie będzie, więc jedyne obciążenie dla serwera to jeden asynchroniczny wątek pasywnie nasłuchujący requestów HTTP i ewentualnie odpowiadający na nie. Kod odpowiedzialny za odpowiadanie na te żądania będzie niewielki (weryfikacja użytkownika + ładowanie otrzymanych danych do pluginu), więc biorąc pod uwagę to, że będzie wykonywany średnio raz na minutę obciążenie jest prawie żadne.

 

Zauważ, że nie ma potrzeby dodawania miliona różnych zabezpieczeń. Wystarczy olewać wszystkie requesty od niezalogowanych użytkowników, a jeśli użytkownik jest zalogowany (admin), to nie będzie chciał przecież niszczyć ani hackować swojego własnego serwera.

 

Dodatkowo Twój web-end będzie musiał korzystać z  osobnego pluginu do interakcji z BetonQuestem, bo konfiguracja questów nie jest przechowywana w bazie danych, tylko w plikach na serwerze. Baza danych przechowuje jedynie dane graczy (tak jak być powinno).

 

Można takie coś napisać, ale uważam to za odrobinę bezsensowne, bo uparłem się na wbudowanie w mój plugin edytora questów już dawno i zamierzam to zrobić.

 

Jak wolisz pisać w Javie to pisz ;) Aczkolwiek co do zabezpieczeń to powodzenia życzę. O ile serwery WWW mają dość złożone filtry i ochronę DDOS to w przypadku czystej Javy nie wiem jak się to sprawdzi. Co z tego, że użytkownik nie jest zalogowany skoro może zamęczyć serwer zapytaniami o logowanie (np. wykonując atak typu brutal force lub DOS). Nie wiem jak Java sobie z tym radzi, więc za wiele na ten temat nie jestem Ci w stanie napisać ;/

 

Po za tym jak już wspomniałeś to takie rozwiązanie sprawdzi się tylko dla adminów. A wprowadzenie możliwość zarządzania, podglądu, szukania, wybierania i oddawania questów przez graczy na stronie WWW było by fajną opcją. Na pewno interfejs WWW jest o wiele czytelniejszy od tego w grze. I tutaj pewnie przypomnisz mi, że dla graczy trzeba by utworzyć osobny system logowania, zintegrować z AuthMe czy Mojang albo coś w ten deseń. Niekoniecznie... Wystarczy, że każdy gracz mógłby sobie wygenerować prosty kod Token w grze i wpisać go razem z nickiem na stronie WWW by się zalogować. W wypadku tego typu pluginu to powinno wystarczyć ;)

Gość

Gość

Opublikowano

Gość

Opublikowano

Jak wolisz pisać w Javie to pisz ;) Aczkolwiek co do zabezpieczeń to powodzenia życzę. O ile serwery WWW mają dość złożone filtry i ochronę DDOS to w przypadku czystej Javy nie wiem jak się to sprawdzi. Co z tego, że użytkownik nie jest zalogowany skoro może zamęczyć serwer zapytaniami o logowanie (np. wykonując atak typu brutal force lub DOS). Nie wiem jak Java sobie z tym radzi, więc za wiele na ten temat nie jestem Ci w stanie napisać ;/

 

Po za tym jak już wspomniałeś to takie rozwiązanie sprawdzi się tylko dla adminów. A wprowadzenie możliwość zarządzania, podglądu, szukania, wybierania i oddawania questów przez graczy na stronie WWW było by fajną opcją. Na pewno interfejs WWW jest o wiele czytelniejszy od tego w grze. I tutaj pewnie przypomnisz mi, że dla graczy trzeba by utworzyć osobny system logowania, zintegrować z AuthMe czy Mojang albo coś w ten deseń. Niekoniecznie... Wystarczy, że każdy gracz mógłby sobie wygenerować prosty kod Token w grze i wpisać go razem z nickiem na stronie WWW by się zalogować. W wypadku tego typu pluginu to powinno wystarczyć ;)

 

Musisz znać port żeby go pingować, a uwierz mi, pingowanie samego Minecrafta jest bardziej zasobożerne niż strony, która olewa wszystkie zapytania po przekroczeniu limitu. Poza tym nie zamierzam sam pisać serwera, tylko użyć sprawdzonego NanoHttpd.

 

Muszę Ci jednak przyznać, że web-end dla graczy do sprawdzania statystyk itp. jest fajnym pomysłem. Takie coś z chęcią bym pomógł pisać ^^ Musiałbym tylko trochę zmodyfikować strukturę pluginu, żeby baza danych była aktualizowana na bieżąco, a nie po wyjściu gracza z serwera.

SlimaKCode Pomocnik

SlimaKCode

Opublikowano
Pomocnik

SlimaKCode

Opublikowano

Musisz znać port żeby go pingować, a uwierz mi, pingowanie samego Minecrafta jest bardziej zasobożerne niż strony, która olewa wszystkie zapytania po przekroczeniu limitu. Poza tym nie zamierzam sam pisać serwera, tylko użyć sprawdzonego NanoHttpd.

 

Muszę Ci jednak przyznać, że web-end dla graczy do sprawdzania statystyk itp. jest fajnym pomysłem. Takie coś z chęcią bym pomógł pisać ^^ Musiałbym tylko trochę zmodyfikować strukturę pluginu, żeby baza danych była aktualizowana na bieżąco, a nie po wyjściu gracza z serwera.

 

NanoHttpd, z opisów i opinii wydaje się być spoko. Co do pingowania to sam zapuszczałem niegdyś skany na różne serwery ;) I później okazywało się, że ktoś na 25565 miał Bungeecord, a na 35500+ niezablokowane serwery xD No, ale wracając odkrycie portu de fakto nie jest trudne. Zwłaszcza, że 90% osób będzie korzystać z domyślnego jaki ustawisz. Do tego pingowanie strony WWW czy Minecrafta nie robi różnicy, zapuszczasz skan portów na całą maszynę i leci. Nawet są do tego specjalne strony WWW, które zrobią to za Ciebie ;)

 

W temacie tego web-endu to wydaje mi się, że oba Nasze pomysły są dobre. Aczkolwiek mój skupia się bardziej na funkcjach i dla graczy, i dla adminów oraz na ewentualnej nieograniczonej rozbudowie tegoż pomysłu. Natomiast Twój pomysł skupia się tylko i wyłącznie na funkcjach dla adminów do zarządzania questami i nic po za tym.

Gość

Gość

Opublikowano

Gość

Opublikowano

NanoHttpd, z opisów i opinii wydaje się być spoko. Co do pingowania to sam zapuszczałem niegdyś skany na różne serwery ;) I później okazywało się, że ktoś na 25565 miał Bungeecord, a na 35500+ niezablokowane serwery xD No, ale wracając odkrycie portu de fakto nie jest trudne. Zwłaszcza, że 90% osób będzie korzystać z domyślnego jaki ustawisz. Do tego pingowanie strony WWW czy Minecrafta nie robi różnicy, zapuszczasz skan portów na całą maszynę i leci. Nawet są do tego specjalne strony WWW, które zrobią to za Ciebie ;)

 

W temacie tego web-endu to wydaje mi się, że oba Nasze pomysły są dobre. Aczkolwiek mój skupia się bardziej na funkcjach i dla graczy, i dla adminów oraz na ewentualnej nieograniczonej rozbudowie tegoż pomysłu. Natomiast Twój pomysł skupia się tylko i wyłącznie na funkcjach dla adminów do zarządzania questami i nic po za tym.

 

Wewnętrzny edytor jest potrzebny w tym pluginie, bo tak jak już mówiłem - nikt nie będzie chciał ustawiać nowej strony internetowej tylko po to, żeby móc wygodnie edytować questy. Takie coś powinno być dostarczone razem z pluginem, żeby nie było problemów. A jeśli ktoś chce dodatkowo mieć stronę dla graczy to ustawi sobie taki serwer.

SlimaKCode Pomocnik

SlimaKCode

Opublikowano
Pomocnik

SlimaKCode

Opublikowano

Wewnętrzny edytor jest potrzebny w tym pluginie, bo tak jak już mówiłem - nikt nie będzie chciał ustawiać nowej strony internetowej tylko po to, żeby móc wygodnie edytować questy. Takie coś powinno być dostarczone razem z pluginem, żeby nie było problemów. A jeśli ktoś chce dodatkowo mieć stronę dla graczy to ustawi sobie taki serwer.

 

Oczywiście, dlatego napisałem, że oba projekty są dobre i mają sens. Można by ustawić minimalistyczny wewnętrzny edytor via WWW wewnątrz pluginu oraz dać możliwość wyłączenia go i przejścia na bardziej rozbudowany zewnętrzny interfejs PHP5 skierowany również dla graczy. Wtedy oba pomysły miały by sens, a od potrzeb i preferencji końcowych użytkowników zależałby wybór.

Zarchiwizowany

Ten temat przebywa obecnie w archiwum. Dodawanie nowych odpowiedzi zostało zablokowane.

Tematy
×
×
  • Dodaj nową pozycję...