TheMolkaPL

ItemStack ma wbudowaną serializację do klucz-wartość. Z Inventory możesz pobrać zawartość jako tablicę ItemStacków. Taką tablicę możesz sobie serializować Gsonem do JSONa i zapisywać w Redis.

Blazingpack posiadał plugin Bukkit dostępny publicznie po ustaleniu jakiejś tam umowy. Natomiast umowa ta była nagminnie łamana (ba, przecież żyjecie w Polsce, nic nowego), więc Blazingpack jest jedynie zamkniętym pluginem.

Musicie zapytanie zapisywać w pamięci. Najlepiej użyjcie klasy Cache z Guavy. Do jej tworzenia używacie CacheBuilder. Cache ma taką fajną rzecz, że po określonym przez nasz czasie usuwa z pamięci dane, czyli w tym przypadku ma je usunąć po upływie czasu zapytania o teleportację. https://github.com/google/guava/wiki/CachesExplained

Jedynie cuboid? Masz - https://github.com/ShootGame/Arcade2/blob/master/src/main/java/pl/themolka/arcade/region/CuboidRegion.java Kula - https://github.com/ShootGame/Arcade2/blob/master/src/main/java/pl/themolka/arcade/region/SphereRegion.java Cylinder - https://github.com/ShootGame/Arcade2/blob/master/src/main/java/pl/themolka/arcade/region/CylinderRegion.java

Ja też nie, a się nauczyłem Trzeba po prostu chcieć @GotoFinal też pisze łamanym angielskim ;d

Serwer stoi na 1.11.2, z tym że jest obsługa pakietów ze starszych wersji. Dużo z tym zabawy i masa przy tym błędów. Ogólnie wynik dość niezadowalający, budowle inaczej wyglądają na różnych wersjach z zużyciem nowszych bloków (na starszych zawsze będzie stone).

on join (PlayerJoinEvent) a on connect (PlayerLoginEvent) to dwa różne eventy. PlayerJoinEvent nigdy nie powinien służyć jako jakakolwiek walidacja gracza. PlayerJoinEvent nie jest anulowalny. Służy on między innymi do przydzielania graczowi itemów, efektów i innych takich. Jest to już pełnoprawny gracz na serwerze, który jest online i ma przydzielone nawet uprawnienia. Walidację graczy powinniście przeprowadzić w PlayerLoginEvent oraz nałożyć na gracza metadane, np uprawnienia. Dodatkowo w miarę możliwości powinniście każdą walidację przeprowadzać w asynchronicznym evencie AsyncPlayerPreLoginEvent, który nie ma wpływu na działanie serwera. Myślę że nie ma na serwerze ani jednego ani drugiego pluginu. Wszystko przez to, że chce postawić serwer wyłącznie na 1.7 - po co potrzebowaliby do niego ViaVersion/ProtocolSupport? No tak... zawsze może pobrać. Czyli do jednej rzeczy w skrypcie potrzebuje dwa pluginy (TuSKe i ViaVersion/ProtocolSupport)? I powtórzę, że w Skript nie jest to możliwe. Skript nie wychodzi poza API Bukkita jeżeli chodzi o Minecrafta. Oczywiście można zrobić jakiś tam dodatek, ale to już jest dodatkowy plugin, a nie Skript. Można nawet napisać plugin na gildie który będziemy uruchamiać skryptem //Już pomijam to komunistyczne pozdrowienie; pisząc "na to samo wyjdzie", nie miałem na myśli, że to te same eventy. Pierwszy wykonywany jest już po wejściu na serwer, drugi dopiero przy łączeniu; miałem na myśli fakt, że przeciętny admin nie zauważy różnicy na pierwszy rzut oka; pozdrawiam zielono @TheMolkaPL A teraz skończmy ten uświadamiająco-dyskusyjny OT albo zapraszam na discorda/PW~PoweredDragon

Meeeh, znam się... Bo widzisz, tutaj popełniacie błąd. Chcecie wyrzucić gracza w on join (PlayerJoinEvent) - czyli wtedy kiedy jest on już tak na prawdę na serwerze. Został dodany do listy graczy online, a sam serwer zaczął mu już wysyłać mapę. To po pierwsze, po drugie jeżeli serwer nie wspiera 1.8 to do wykonania tego eventu nigdy nawet nie dojdzie. Zostanie już wcześniej wyrzucony przez serwer z informacją "Outdated server", jeszcze przed wywołaniem AsyncPlayerPreLoginEvent. Po trzecie to wyrażenie w Skrypt wymaga na serwerze pluginu ViaVersion lub ProtocolSupport. Tutaj macie jego kod źródłowy: https://github.com/Tuke-Nuke/TuSKe/blob/706207cf77bbde13cfb6bdc6d262eb4233d0c1a0/src/me/tuke/sktuke/expressions/ExprPlayerVersion.java

Z tym, że to jest reload pluginów, a nie restart serwera... Spigot ma /restart.

Nie ma takiej możliwości. Całą dokumentację API Mojangu macie tutaj - http://wiki.vg/Mojang_API

Wątpię żeby któryś tutaj z Towarzyszy napisze wam gotowca. Nie rozumiecie celu istnienia w internecie for. Mają one pomóc - dać możliwość każdemu się wypowiedzieć. Dzięki wspólnej rozmowie, dzięki współpracy (przeciwnie do konkurencji) można stworzyć lepsze jutro. Można dzięki temu tworzyć nowe, lepsze oprogramowanie i wszystko inne. Wy natomiast czekacie jedynie na gotowca, który wam w niczym nie pomoże.

W takim razie jest to po prostu źle napisany plugin...

<!DOCTYPE html> <html> <head> <script async src="https://widgets.nitropanel.com/widgets.js" type="text/javascript"></script> </head> <body> <div class="nitrous-widget" data-server-id="NN99025299" data-theme="green" data-refresh="10"></div> </body> </html>

1. Plik w którym znajduje się treść wiadomości, czyli te strzałki musicie zapisać w kodowaniu UTF-8. 2. Proszę o logi serwera. Macie plugin na formatowanie chatu?

Najlepszy jest ewidentnie NoCheatPlus, który jest ciągle aktualizowany. Nie rozumiem dlaczego go nie chcecie. Pozdrawiam antykapitalistycznie.

Ten tekst? To jest modyfikacja klienta.

Hmmm... a jak inaczej taki chat administracyjny wykonać? Założenie jest to samo, więc i kod jest ten sam. Chociaż te mają jednak spore różnice. command /a [<text>]: trigger: if player has permission "chat.Admin": if arg is not set: send "&lMoze napisz /v wiadomosc ? :D" else: loop all players: loop-player has permission "chat.Admin": send "&6&l%player%: &f%arg%" to loop-player else: send "&lTo jest admin chat ;)" command /achat [<text>]: trigger: if argument 1 is not empty: if player has permission "mrachat.diaxhc": loop all players: loop-player has permission "mrachat.diaxhc": send "&8[&6ACHAT&8] &7%name of player%&8 » &b%arg 1%" to loop-player else: send "&8» &7Prawidlowe uzycie: &a/achat &c(wiadomosc)"

Wystarczy to zrobić na priority = EventPriority.HIGHEST po prostu. No ale właśnie, chyba brakuje programistów A nie, czekaj, tu komenda XD No to wystarczy BlockPlaceEvent wywołać i sprawdzić czy nie jest canceled.

Macie Towarzyszu https://gist.github.com/TheMolkaPL/ae95e7ea8bd8674e69615e40892525c7 Pozdrawiam Czerwono!

W twoim listenerze do ServerListPingEveny.

To ci się nawet nie skompiluje. Tworzysz zmienną maxplayers w środku metody onEnable. Oznacza to, że będzie ona widoczna i dostępna jedynie w środku tej metody. Po jej wykonaniu maxplayers zostanie wykazane z pamięci podręcznej na zawsze. Musisz to sobie zapisać na cały okres działania pluginu na serwerze. Twoja klasa Main zostanie stworzona przy wlaczeniu pluginu i usunieta przy wyladowaniu. Musisz więc zapisać int maxSlots = 0; na górze klasy. W onEnable wykonujesz maxPlayers = this.getConfig().... W listenerze robisz setMaxPlayers(this.maxPlayers);

Zrobiłeś to samo w config.yml na twoim serwerze testowym?

Masz nieprawidłowy plik YAML. W cudzysłowach - ", lub apostrofach - ' podaje się string - ciąg znaków. Ty podałeś liczbę - usuń proszę apostrofy z maxplayer (w configu powinno byc max-players).

Nie laduj danych z configu prosto w deklaracji zmiennej. Przez to dane będą się próbować załadować przy stworzeniu instancji głównej klasy, a tak nie koniecznie powinno być (używanie API Bukkita przed zaladowaniem samego pluginu). Zrób to w onEnable

To zmienna którą sobie tak nazwałeś - mówię, że lepiej byłoby to nazwać maxPlayers, bo bo maksymalnieGraczy, a nie maksymalnieGracz.