• Es freut uns dass du in unser Minecraft Forum gefunden hast. Hier kannst du mit über 130.000 Minecraft Fans über Minecraft diskutieren, Fragen stellen und anderen helfen. In diesem Minecraft Forum kannst du auch nach Teammitgliedern, Administratoren, Moderatoren , Supporter oder Sponsoren suchen. Gerne kannst du im Offtopic Bereich unseres Minecraft Forums auch über nicht Minecraft spezifische Themen reden. Wir hoffen dir gefällt es in unserem Minecraft Forum!

Hilfe! Events funktionieren bei mir ned

AtomicDev

Minecrafter
Registriert
7 März 2016
Beiträge
5
Alter
46
Diamanten
300
Hallo Leute,
Könnt ihr mir helfen!!
Wieso funktionieren die Event bei mir nicht????
Mein Code:
Code:
package me.plugin.Dev;

import org.bukkit.ChatColor;
import org.bukkit.Sound;
import org.bukkit.command.Command;
import org.bukkit.command.CommandSender;
import org.bukkit.entity.Player;
import org.bukkit.event.EventHandler;
import org.bukkit.event.Listener;
import org.bukkit.event.player.PlayerJoinEvent;
import org.bukkit.plugin.java.JavaPlugin;

import me.plugin.Dev.Listeners.JoinQuit;

public class Core extends JavaPlugin implements Listener {
    public static String prefix = ChatColor.RED + "["+ ChatColor.AQUA + "Gun" + ChatColor.DARK_AQUA + "Game" + ChatColor.RED + "]";
    public void onEnabled(){
    registerEvents();
    System.out.println(prefix + "Enabled");
        getServer().getPluginManager().registerEvents(this, this);
       
    }
     @EventHandler
    public void onJoin(PlayerJoinEvent e){
    
        Player p = e.getPlayer();
        if(p.hasPermission("GunGame.Join")){
        e.setJoinMessage(prefix + p.getName() + " -->");
        p.playSound(p.getLocation(), Sound.BLOCK_NOTE_BASS, 10, 10);
     }
     }
    
    public boolean onCommand(CommandSender sender, Command cmd, String label,String[] args){
    if(cmd.getName().equalsIgnoreCase("GunGame")){
        Player p = (Player) sender;
       
        //Help
        if(p.hasPermission("gungame.help")){
        p.playSound(p.getLocation(), Sound.BLOCK_NOTE_BASS, 5, 5);
        p.sendMessage (ChatColor.GOLD + "---------------- " +  prefix + ChatColor.GOLD +" ----------------");
       
        p.sendMessage (ChatColor.GOLD + "---------------- " +  prefix + ChatColor.GOLD +" ----------------");
       
    }
   
   
      
    }  
       
    return false;
   
   
   
   
   

}
    public void registerEvents(){
    new JoinQuit(this);
    }
   
      
       
   
       
    }
 

UnityGaming

Workaholic
Registriert
25 Oktober 2015
Beiträge
527
Alter
26
Diamanten
312
Minecraft
FastFelix771
Nimm das bitte nicht persönlich, aber das ist 100% Schrott!
Ein 5 Minuten YouTube Tutorial ist von höherer Qualität als dieses Code-Geschwür.

Das ganze zu korrigieren wäre eigentlich sinnlos, da es nun mal von vorne bis hinten unbrauchbar ist, ein kleiner Tipp kommt dennoch.
Eigentlich macht man Listener in Extra Klassen, aber für Beispielzwecke muss das jetzt nicht sein.

Hier ist mal eine Grundklasse, mit der dürften dann deine EventHandler wenigstens funktionieren:
Code:
package de.beispiel.plugin;

import org.bukkit.event.EventHandler;
import org.bukkit.event.Listener;
import org.bukkit.event.player.PlayerJoinEvent;
import org.bukkit.event.player.PlayerQuitEvent;
import org.bukkit.plugin.java.JavaPlugin;

public class DeinPlugin extends JavaPlugin implements Listener {

    private static DeinPlugin instance;


    @Override
    public void onEnable() {
        instance = this;
        getServer().getPluginManager().registerEvents(this, this);
    }

    @Override
    public void onDisable() {
        instance = null;
    }

    public static DeinPlugin getInstance() { 
        return instance;
    }

    // EVENTS //

    @EventHandler
    public void onJoin(PlayerJoinEvent e) {

    }

    @EventHandler
    public void onQuit(PlayerQuitEvent e) {

    }

}

Aber bitte, schau dir nochmal die Java und Bukkit Basics wenigstens an, bevor du mit sowas rumbastelst.
Ich weiß, learning by doing ist ne tolle Sache, aber ein wenig zu lesen um es zumindest zum laufen zu kriegen ist wirkliche ne große Hilfe am Anfang!
 

AtomicDev

Minecrafter
Registriert
7 März 2016
Beiträge
5
Alter
46
Diamanten
300
Nimm das bitte nicht persönlich, aber das ist 100% Schrott!
Ein 5 Minuten YouTube Tutorial ist von höherer Qualität als dieses Code-Geschwür.

Das ganze zu korrigieren wäre eigentlich sinnlos, da es nun mal von vorne bis hinten unbrauchbar ist, ein kleiner Tipp kommt dennoch.
Eigentlich macht man Listener in Extra Klassen, aber für Beispielzwecke muss das jetzt nicht sein.

Hier ist mal eine Grundklasse, mit der dürften dann deine EventHandler wenigstens funktionieren:
Code:
package de.beispiel.plugin;

import org.bukkit.event.EventHandler;
import org.bukkit.event.Listener;
import org.bukkit.event.player.PlayerJoinEvent;
import org.bukkit.event.player.PlayerQuitEvent;
import org.bukkit.plugin.java.JavaPlugin;

public class DeinPlugin extends JavaPlugin implements Listener {

    private static DeinPlugin instance;


    @Override
    public void onEnable() {
        instance = this;
        getServer().getPluginManager().registerEvents(this, this);
    }

    @Override
    public void onDisable() {
        instance = null;
    }

    public static DeinPlugin getInstance() {
        return instance;
    }

    // EVENTS //

    @EventHandler
    public void onJoin(PlayerJoinEvent e) {

    }

    @EventHandler
    public void onQuit(PlayerQuitEvent e) {

    }

}

Aber bitte, schau dir nochmal die Java und Bukkit Basics wenigstens an, bevor du mit sowas rumbastelst.
Ich weiß, learning by doing ist ne tolle Sache, aber ein wenig zu lesen um es zumindest zum laufen zu kriegen ist wirkliche ne große Hilfe am Anfang!
Trotzdem geht es nich
 

TheSimufreak

Kuhfänger
Registriert
28 Juni 2012
Beiträge
78
Diamanten
0
Nimm das bitte nicht persönlich, aber das ist 100% Schrott!
Ein 5 Minuten YouTube Tutorial ist von höherer Qualität als dieses Code-Geschwür.
Prinzipiell hast du zwar recht, der Quelltext ist nicht besonders schön und das Auslagern des Listeners in eine separate Kontrollklasse gehört zu einer guten Systemarchitektur dazu, aber deshalb gleich mit solchen Vokabular um dich zu schmeißen macht die Sache auch nicht besser.
Wir alle haben mal klein Angefangen und herum experimentiert...

Zum Problem:
Code:
    public void onEnabled(){
    registerEvents();
    System.out.println(prefix + "Enabled");
        getServer().getPluginManager().registerEvents(this, this);
}
Das Problem liegt nicht bei den Events sondern schlichtweg daran, dass du die onEnable Methode der Superklasse nicht überschreibst, wodurch dann eben nicht die von dir deklarierte Methode ausgeführt wird sondern die der Klasse JavaPlugin.
Wenn dir das gerade spanisch vorkommt rate ich dir dich über Vererbung schlau zu machen.
Ich empfehle dir beim überschreiben von Methoden immer die @Override Annotation zu verwenden, dann schleichen sich solche Fehler nicht so schnell ein.
 
X

|| xX [DEV][LP] Ms. DivaCraft Xx ||

Guest
Im Kern eine derartig falsche Aussage, ich gehe diese einfach mal Punkt für Punkt durch.

Zum einen ruft der AtomicDev eine Methode namens onEnabled() auf, anstatt onEnable(). Folglich wird der Körper dieser Methode auch nie aufgerufen.
Naja, nicht ganz. Ein normales Plugin erweitert idR. die Klasse JavaPlugin, dadurch werden einige Methoden automatisch implementiert und es wird immer ein neues Objekt dieser Klasse erzeugt. Ein Thema, dass zu komplex ist um es hier genauer darzustellen. Danach ruft der PluginLoader die notwendigen Methoden auf (Sprich "Contracts").

Ein Ausschnitt aus der besagten Klasse:
Code:
@Override
public void onLoad() {}
@Override
public void onDisable() {}
@Override
public void onEnable() {}
(SRC: https://github.com/Bukkit/Bukkit/blob/master/src/main/java/org/bukkit/plugin/java/JavaPlugin.java)

Ein Kind muss diese nun nicht mehr überschreiben, kann es aber um Funktionen hinzuzufügen (Nennt sich Vererbung!).

Zum anderen ist die @Override Annotation hier "nur" eine Java Coding-Konvention.
Ach wirklich? @Override ist eine Annotation für den Compiler, also eine Anweisung / Anforderung an die Oberklasse. Diese als lediglich optional zu bezeichnen kann nur von einem schlechten Programmierer kommen. Keine Konvention, sondern nur ein Anfängerfehler.


Beim Laden des Plugins wird nämlich gezielt die onEnable Funktion deiner Main-Klasse, die man ja auch in einer plugin.yml angibt, aufgerufen.

Möchte man jedoch z.B. die toString() Funktion eines Objektes und damit eine native Java-Funktion überschreiben[, zeigt die @Override Annotation erst ihre Funktion :)
Oh zwei Dinge:
Das ist Bullshit und das ist Bullshit: Weder ist die toString() methode in Java eine native Funktion, noch zeigt diese Annotation erst dort ihre Wirkung.

Im übrigen Implementiert das open-jdk die Funktion so:

Code:
public String toString() {
           return getClass().getName() + "@" + Integer.toHexString(hashCode());
}
 
X

|| xX [DEV][LP] Ms. DivaCraft Xx ||

Guest
Wie du einfach meinst einen richtigen und gut formulierten Beitrag ad absurdum zu führen.
Wäre dein Beitrag wirklich richtig und gut formuliert, dann gäbe es absolut keine Grundlage ihn ad absurdum zu führen, weil mein Beitrag die offensichtlichen Fehler auflistet.

Aus diesem Interface erfolgt die ursprüngliche Implementierung der besagten Methoden. Bei dieser Vererbung ist so die Überschreibung nicht notwendig.
Diese "Vererbung" existiert nicht, weil es keine Elternklasse mit dieser Methode gibt. Zudem funktioniert das einfache implementieren des Plugin interfaces nicht so einfach, wie man erwarten würde, weil es eine
direkte Bindung zwischen dem JavaPlugin und dem PluginClassLoader gibt.

Näheres findet man hier: https://github.com/Bukkit/Bukkit/bl...org/bukkit/plugin/java/PluginClassLoader.java

Und klar ist toString eine native Funktion.
Nein, es ist eine ganz normale Methode in Java. Die Klasse Objekt mag zwar implizit und überall in jedem JRE vorhanden sein, aber dies macht diese Methode noch lange nicht "native". Eine native Methode wird mit nativem Code (z.B. C) ausgeführt. Java ist eine plattformunabhängige Sprache. Mehr zu nativen Methoden findet man hier.

Sie findet sich unter anderem in allen primitiven Datentypen.
Also, das ist auch nicht richtig. Ein primitiver Datentyp hat per Definition (in Java) keine Methoden. Dieser ist kein Objekt. Nur die entsprechenden Wrapperklassen haben Methoden und können folglich Methoden aufrufen.

Folglich lässt sich diese mitteils Override überschreiben.
Also man kann jede Methode ohne @Override überschreiben, jedoch gibt es dann keine Überprüfung des Compilers, ob eine entsprechende Methode überschrieben wird. Folglich muss diese Methode nicht überschrieben werden können und könnte eine neue Methode darstellen.
 
Oben