GotoFinal

testuj to na czystym mc, bo z tego błędu trudno coś zrozumieć bo pozmieniali nazwy klas.
Ale wygląda na to że prefix ma więcej niż 16 znaków - a taki jest limit w mc.

no nie podałeś typu generycznego callbacku, new TimerCallback<Player>() {....

No jak tak nie działa, to niestety z tego co wiem są tylko trzy sposoby: (i nie jestem pewien czy pierwszy działa poprawnie, dawno tego nie robiłem  tam gdzie pracowałem to najczęściej używało się metody trzeciej, ale to dość sporo kodu więc nie znajdę i nie napiszę tego tutaj z palca, na pewno są jakiegoś gotowe biblioteki na spigotmc  czy coś.)
1. Stworzyć prawdziwe kowadło i ustawić je jako holdera inventory: 
someBlock.setType(Material.ANVIL); Inventory inventory = Bukkit.createInventory((InventoryHolder) someBlock.getState(), InventoryType.ANVIL); someBlock to jakiś Block który sobie pobierasz, wydaje mi się że to też musi być block blisko gracza, ale możliwe że wystarczy że to jakiś block na załadowanym chunku - czyli np na spawnie. Ale nie zdziwię się wtedy jeśli przy zamykaniu EQ z itemami w środku wypadaną one obok kowadła zamiast gracza
2. Pakiety i tworzenie fałszywego bloku kowadła i fałszywego inventory kowadła i symulowanie każdej akcji ręcznie.
3. Kod z NMS by wymusić stworzenie fałszywego obiektu kowadła.

No to dalej średniawy antybot, ale tak to zostaje to co napisałem w pierwszym poście, filtr do logów, lub poprawnie anty bota by wykonywał swoje sprawdzenia przed tą wiadomością.

jak zostawało w tekście to wina pluginu ;/ pewnie robi idiotyczne replace każdego możliwego &X ale uwzględnił tylko kolory... wina że autor pluginu nie potrafi ich poprawnie pisać, zgłoś buga do autora, a tak to możesz to obejść używają tego znaku paragrafu §l

a pokaż plugin.yml

@JanekMaSkrypta_ ConcurrentHashMap drobnym kosztem wydajności i pamięciowym wspiera operacje z wielu wątków bez blokowania ich za pomocą atomowych operacji CAS.
Jednak warto zaznaczyć że nie mamy wtedy gwarancji co tak na prawdę zobaczymy w takiej mapie, jeśli w trakcie iteracji po mapie w wątku A zostaje dodana nowa wartość w wątku B to nie ma żadnej pewności czy dodany obiekt też będzie elementem tej iteracji czy nie - zależy czy nowy obiekt wyląduje w przed czy za wskaźnikiem iteratora.
Zazwyczaj nie mamy takiej konieczności by ta wartość tam od razu była, ale czasem jednak jedyne dobre wyjście to synchronizacja HashMapy zamiast użycia concurrent.
Tak samo można taką mapę edytować w trakcie iteracji z tego samego wątku - co w przypadku zwykłej hash mapy wywali błąd CME.
Dodatkowo mapa Concurrent nie wspiera ani kluczy ani wartości nullowych - gdzie w HashMapie można do klucza przypisać wartość null, czy też wartość do klucza o watości null.

Nooo, to masz spory problem  Masz 3 opcje, wszystkie niezbyt dobre, ale zacznijmy od tego czy na pewno tego potrzebujesz? teoretycznie spigot powinien stackować itemu.
1. Symulujesz drop samemu, anulujesz BlockBreakEvent i sam symulujesz drop, z tym że nie dość ze to masa kodu by symulować wszystke możliwe dropy z enchantami, to jeszcze psujesz kompatybilność z innymi pluginami które mogą nasłuchiwać tego eventu, bo nie będą się spodziewały zniszczenia bloku pomimo anulowania eventu.
2. Musisz pogrzebać w NMS i znaleźć tam funkcje odpowiedzialną za generowanie dropu i wywołać ją ręcznie - tutaj niestety nie jestem pewien jak, dokładnie czegoś takiego nie robiłem, ja się zadowalałem symolwaniem zniszczenia bloku, ale to co innego.
3. I chyba najprościej, możesz spróbować stackować itemy blisko siebie w ItemSpawnEvent z dodatkowym wsparciem na stackowanie itemów powyżej 64, ale wydaje mi się że spigot już to powinien robić za ciebie, ogarnij config spigota, moze coś znajdziesz by to lepiej skonfigurować.

użyj BukkitRunnable, znacznie wygodniejsze do takiej zabaw
new BukkitRunnable(){ @Override public void run() { System.out.println("Z tasku"); this.cancel(); // i anulowany } }.runTaskTimer(plugin, 0, 20); możesz też przypisać do zmiennej i anulować kiedy chcesz z innego miejsca:
BukkitTask printTask = new BukkitRunnable() { @Override public void run() { System.out.println("Z tasku"); this.cancel(); // i anulowany } }.runTaskTimer(plugin, 0, 20); // w innym miejscu: printTask.cancel();  

każdy dobrze napisany kod obiektowy jest łatwy do pracy w zespole, trudno tu o jakieś konkretne wzorce jeśli chodzi ci o bukkita itd, bo większość wzorców jest z myślą o webdevie czy innych aplikacjach z typowym frontem, do gamedevu popularny jest entity component system, ale minecraft go nie ma, więc średnio idzie go sensownie użyć. Zostaje tylko pisanie dobrego obiektowego kodu, czystego i z dobrym podziałem.

ale w tym pomie jest tylko spigot api, więc jak ci dodało dobrze samego spigota?
A tak to zobacz czy to pomaga: 
 
I zobacz czy są jakieś błędy przy buildzie mavena:   

no jak gracz wyjdzie to możesz go z tej mapy usunąć - i jak chcesz liczyć kompletny czas online to musisz też to zapisywać do jakiegoś pliku lub bazy bo przecież bungee może być gdzieś resetowane, paść itd. np czasy wejścia i wyjścia każdego gracza w bazie i wtedy pobierasz i podliczasz cały czas - lub tylko zapisywać kompletny czas do bazy/pliku, no ale daty mogą być pomocniejsze, możesz potem więcej stworzyć, np czas online w ostatnim tygodniu itd.

najlepszy i najprostszy wybierz jedno
 
Najprostszy to właśnie w yaml z domyślną wbudowaną serializacją, można też wtedy to próbować przerobić na jsona jak ktoś chce/potrzebuje.
A tak to wszystko zależy co się robi, do zapisu w bazie lub przesyłania np redisem znacznie wygodniej zapisać jaki czyste bajty z NBT, bo mniej danych, ale niestety bukkit nie udostępnia żadnego api od tego.
No ale plugin na magazyny to raczej zapisujesz array itemów do pliku yml i tyle, i niech sobie bukkit sam serializuje do yamla.

nie sprawdzasz.
Tutaj sprawdzasz czy otworzone EQ to te prawidłowe, ale nie sprawdzasz czy to te kliknięte...
Jest osobna metoda .getClickedInventory 

Nie ma jeszcze czegoś niżej? bo jak nie to to jedyne o czym myślę to próba zaktualizowania essentials, zobacz może EssentialsX, bo z jakiegoś powodu brakuje mu klasy, może jakiś uszkodzony .jar, trudno powiedzieć
idz być nobem gdzieś indziej

zauważ że to się parsuje jako obiekt jak nie dasz cytatów

To jest niepoprawna odpowiedz, zadziała poprawnie tylko jeśli dajesz 1 item z ilością 1, w innych przypadkach masz bugi i to poważne, wiec lepiej nigdy nie pisać takiego kodu.
Poprawnie powinno być
 
Location loc = p.getLocation(); HashMap<Integer, ItemStack> rest = p.getInventory().addItem(items); for (ItemStack item : rest.values()) { loc.getWorld().dropItemNaturally(loc, item); } bo metoda .addItem zwraca mapę gdzie klucz to index z array itemów do dodania, a wartość to itemy których nie udało się dodać

AutoIn nie jest juz wspierane, zerknij na plugin FastLogin oferuje to samo co autoin
 
EDIT: i nauczcie się czytać xD
# If you have one of that plugin, you can force AutoIn to don't use them even if they can be used. (change to true) ForceDisable: ProtocolLib: true Skript: false AuthMe: true LogIt: false XAuth: false LoginSecurity: false pisze że zmiana na true oznacza zignorowanie pluginu a i tak ludzie ustawiają xD

Twoje jest jeszcze bardziej bez sensu, bo nie masz pewności że dany string da się sparsować do inta.

Najwygodniej mieć coś takiego:
public static Integer parseOrNull(String str) { try { return Integer.parseInt(str); } catch (NumberFormatException e) { return null; } } parsujesz tym i jak jest null to znaczy że to nie był poprawny int, proste, szybkie, wygodne.
A wydajność pewnie i tak nie jest problemem bo pewnie robisz to w komendzie, to fakt czy komenda wykona się 300ns wolniej nic nie zmieni
Integer value = parseOrNull(arg); if (value == null) { return; } // i dalej możesz używać jak inta  

Nie twórz nowego random za każdym razem...
daj:
public int getRandom(int lower, int upper) { Random random = ThreadLocalRandom.current(); return random.nextInt((upper - lower) + 1) + lower;  

no ale nie potrzebujesz żadnego loopa wtedy
@EventHandler public void onCommand(PlayerCommandPreprocessEvent event) { if (!event.getMessage().startsWith("/")) return; String msg = getConfig().getString(event.getMessage().substring(1)); if (msg == null) return; event.setCancelled(true); sender.sendMessage(s); }  
 
Ale ogólnie... to powinieneś normalnie rejestrować komendy w plugin.yml ;/ można też od biedy dynamicznie refleksjami dodawać, używanie do tego eventu nie jest zalecane, no ale niestety... bukkit jest jaki jest.

ale jaki dokladnie masz problem? dlaczego miałoby pisać coś innego? jeśli spodziewales się event będzie anulowany, to możesz spr pobawić się z priorytetami np
@EventHandler(priority = EventPriority.NORMAL) i tak posprawdzać różne wartości EventPriority, raczej te powyżej NORMAL, jak HIGH itd, IDE ci podpowie jakie masz możliwości lub zerknij do dokumentacji, bo tak to nie wiem który masz ustawić... musisz wybadać, bo plugin który chroni spawn anuluje ten event w swoim listenerze, i jeśli twój listenerze wykonuje się przed nim... no to jeszcze nie widzisz tej zmiany.
ALE, jeśli chcesz TYLKO nasłuchiwać eventu (nie chcesz go potem anulować czy zmiemić jakieś jego dane) to możesz użyć
@EventHandler(priority = EventPriority.MONITOR) zawsze wykonuje się jako ostatni, ale pamiętaj BY NIGDY NIE ANULOWAC LUB EDYTOWAC TAM EVENTU, bo inaczej to wszystko straci sens a ty wylądujesz z setkami bugów, bo już nie będziesz miał żadnej gwarancji że ten listener wykona się ostatni.