The Bug I Really Cant Squash!!!!

Hello im learning java and i am making this plugin that when a player tries to throw an egg they get kicked (Just Trying Random Stuff) This here is my code...

This is The main class

Code:

package me.SkyGlue;

import org.bukkit.plugin.java.JavaPlugin;

public class EventHandle extends JavaPlugin {

@Override
public void onEnable() {
    new PlayerListener(this);
}

@Override
public void onDisable() {

}

}

This Is the PlayerListener class

Code:

package me.SkyGlue;

import org.bukkit.ChatColor;
import org.bukkit.entity.Player;
import org.bukkit.event.EventHandler;
import org.bukkit.event.Listener;
import org.bukkit.event.player.PlayerEggThrowEvent;

public class PlayerListener implements Listener {
   
    public PlayerListener(EventHandle plugin) {
     plugin.getPluginLoader().registerEvents(this, plugin);
       
    }
   
    @EventHandler
    public void onThrow(PlayerEggThrowEvent event) {
       
        Player player = event.getPlayer();
               
            player.sendMessage(ChatColor.RED + "Uh-Oh. You Threw A Egg. That Is Prohibited On This Server!");
            player.kickPlayer("Woopsy's. You Threw An Egg. You May Rejoin. You Have Been Warned! ");
                               
    }
   
}

This is the error i get

The method registerEvents(PlayerListener, EventHandle) is undefined for the type PluginLoader

 

@SkyGlue I would suggest registering your events in your onEnable with:

Code:

PluginManager pm = getServer().getPluginManager();
pm.registerEvents(new PlayerListener(), this); // I suggest removing parameters and code from your constructor.

Also, someone tell me if I'm wrong, but doesn't it do nothing if you just create a random instance of EventHandle in your constructor without it relating to your main class?

 

@pookeythekid

Yes, you're wrong on both accounts, there's no reason to use your code over his.


@SkyGlue

You need the PluginManager, not the PluginLoader.

 

Code:java

package me.SkyGlue;
 
import org.bukkit.ChatColor;
import org.bukkit.entity.Player;
import org.bukkit.event.EventHandler;
import org.bukkit.event.Listener;
import org.bukkit.event.player.PlayerEggThrowEvent;
 
public class PlayerListener implements Listener {
 
    public PlayerListener(EventHandle plugin) {
     plugin.getServer().getPluginManager().registerEvents(this, plugin);
 
    }
 
    @EventHandler
    public void onThrow(PlayerEggThrowEvent event) {
 
        Player player = event.getPlayer();
 
            player.sendMessage(ChatColor.RED + "Uh-Oh. You Threw A Egg. That Is Prohibited On This Server!");
            player.kickPlayer("Woopsy's. You Threw An Egg. You May Rejoin. You Have Been Warned! ");
 
    }
 
}
 

 

Ok i have done that but now it gives me this error...
The method getPluginManager() is undefined for the type EventHandle

@mythbusterma

 

@SkyGlue
look at my post, I edited it. Should work now.

 

@mythbusterma I can think of several reasons as to why it would be better to register events in onEnable rather than scattering them all over the place.

 

@Rocoty

That all comes down to coding preference and standards.

 

@Dragonphase The way I see it it comes down to structure and maintainability. Keeping the registering in a centralised place makes for a tidier structure and it would be easier to maintain in the future.

 

*facepalm* Right...

 

@DeadlyScone spoonfeed is real lol

 

@Rocoty

I would have them each register in their constructor, just for the cleanliness of the JavaPlugin class, but as long as you're consistent, it isn't really an issue either way.

 

@mythbusterma That's what I would call giving the object too much work. It would be doing more than it's supposed to. A listener object is only supposed to listen for events and handle them. Giving it the power to register itself defies the Single Responsibility Principle (the 'S' in SOLID). Also, if allowing the object to register itself when it is created is a must, then this should be clearly documented in comments or JavaDocs, as it would by no means denote obvious behavior.

If you give the main class the responsibility to register all of its own listeners, not only do you abide by the SRP and make your code more maintaniable, you also make your intent a whole lot clearer, which is always a good thing.

 

@Rocoty

Fair enough, that's how I've always done it anyway. You make a good argument.

 

@mythbusterma @Rocoty
intrestingly enough , there are two ways bukkit shows. Check this out.

http://wiki.bukkit.org/Event_API_Reference

I regester them in my classes versus my main. I don't know why I do, it's just how I've always done it .

 

@DeadlyScone

The point being, Bukkit isn't infallible, and, programmatically, it makes no difference.

Rocoty brought the idea of limited scope of responsibility of each class, that is it should serve one or a few clearly defined purposes, with a Listener being a class that should listen for events and (optionally) act upon said events within a limited scope. Having it register itself as a listener falls outside that scope, and is much more in line with the goal of your Main class, which, among other things, is to manage dependant classes.

 

@mythbusterma
I indeed follow the argument at foot and understand what you are justifying. I just thought it would be a valid point, or at least an interesting fact to ponder.