Hallo ToDiYT,
auch wenn dieser Thread mittlerweile 2 Monate alt ist, wollte ich noch einmal auf ein paar Dinge aufmerksam machen, ungeachtet davon ob das Problem gelöst ist. Nachdem ich einige Zeit deinen Code gelesen habe, sind mir ein paar Dinge aufgefallen, die Problempotential bieten und das Problem unter anderem ausgelöst haben könnten.
if(e.getItem() != null && e.getItem().getItemMeta() != null && e.getItem().getType() == Material.BARRIER) { if(!JoinListener.ingame.contains(e.getPlayer())) { e.getPlayer().kickPlayer(""); }else { e.getPlayer().sendMessage("§cDas Kannst du nur als Spectator ausführen!"); e.setCancelled(true); }
Obwohl das ClickEvent gecanncelt ist kann er diese Items bewegen
Wenn du nicht willst, dass die Items bewegt werden können, wenn man tot ist, musst du die setCancelled Methode ebenfalls aufrufen, wenn sich ein Spieler nicht in der Liste befindet. Beispielsweise:
public void onInteractEvent(PlayerInteractEvent event)
{
if(!JoinListener.ingame.contains(event.getPlayer()))
{
event.setCancelled(true);
}
}
Des weiteren würde ich für den InteractListener anmerken, dass es in meinen Augen mehr Sinn machen würde, wenn man erst die Abfrage der Liste macht und danach lediglich abfragt, ob das Item ungleich null ist und dem Material einer Barriere entspricht. Die ItemMeta-Abfrage würde entfallen, da ich stark bezweifle, dass ein Spieler zu einem anderen Zeitpunkt eine Barriere bei sich tragen wird. Falls doch ist es klüger, direkt den spezifisch gesetzten Parameter abzufragen, in deinem Fall den Namen. Zusätzlich ist es besser, diese Abfragen geschachtelt zu tätigen, da der Code so weniger an Struktur verliert und potentiell variierbarer ist.
In etwa so:
public static final String LEAVE_NAME = "§8» §cVerlassen";
public void onRespawn(PlayerRespawnEvent event) { /*...*/ }
public void onInteractEvent(PlayerInteractEvent event)
{
if(!JoinListener.ingame.contains(event.getPlayer()))
{
event.setCancelled(true);
if(event.getItem() != null)
if(event.getItem().getType() == Material.BARRIER)
if(event.getItem().getItemMeta().getDisplayName().equals(RespawnListener.LEAVE_NAME))
event.getPlayer().kickPlayer("");
//potentielle else Abfragen
}
}
Wie du siehst, habe ich den Namen der Barriere direkt als statische Variable gespeichert, so kannst du diesen zentral verändern und musst ihn nicht immer neu schreiben und es gibt weniger Hardcodings.
Nun noch ein paar theoretische Ansätze. Ich würde dir wirklich ans Herz legen noch einmal zu Themen Struktur und Formatierung des Codes, sowie Benennung von Variablen und das Kommentieren des Codes zu recherchieren. Ich selbst habe vor ein paar Jahren manchmal unkommentierten Code mit einer schrecklichen Variablenbenennung geschrieben und wie zu erwarten, musste ich mich später immer und immer wieder in meinen eigenen Code einarbeiten, um ihn zu verstehen und anzupassen. Wenn dies schon bei dem eigenen Code passiert, kannst du dir sicher vorstellen, dass sich nicht viele Leute so einen Code von Fremden anschauen werden und versuchen ihn zu verstehen. Deshalb kann ich dir auch unter anderem zu deinem eigentlichen Problem keine direkte Lösung oder einen direkten Fehler nennen, da er vermutlich inmitten der Klassen irgendwo klein und leicht zu übersehen schlummert! Gerade wenn du mit vielen statischen Verlinkungen arbeitest, können sich schnell Fehler ergeben. Statische Werte beziehen sich auf die Klasse und können so an vielen Stellen verändert werden, ich würde bei Listen eher davon abraten, static einzusetzen. (In deinem Fall geht es natürlich, allerdings sollte man mit static-Deklarierungen trotzdem vorsichtig sein).
Als einen letzten Schritt würde ich dir ebenfalls noch empfehlen, gerade für deinen DeathListener, einzelne Abläufe auf jeden Fall in Methoden abzuspeichern und diese lediglich bei gewissen Zuständen auszuführen oder (wenn es sich anbietet) auf andere Klassen zu verteilen. Denn dein DeathListener zieht sich sehr in die Länge und ist gerade im Forum schwer zu lesen (wann welcher Zustand eintrifft, wann etwas gemacht wird etc). Und gerade bei Runnables, von denen ich beim Überfliegen einige gesehen habe, sollten lieber strukturiert geführt werden, da hier bei Fehlern vor allem auch die Rechenleistung des Servers in Mitleidenschaft gezogen wird.
Ich hoffe, ich konnte hiermit ein paar Denkansätze geben und für spätere Zeit weiterhelfen!
Freundliche Grüße,
Qubbe
