[HELP] Ban GUI - player name to event handler

Discussion in 'Spigot Plugin Development' started by TheCyberCode, Jun 17, 2018.

  1. Basically i'm making a Ban GUI it all works except for i can't seem to figure out how to let the event handler get the targeted player name from the command executor...

    Can someone shed some light on how i would do that, it would be much appreciated.

    Cyber (Mainstrike)
  2. Chances are if your Inventory Click Listener is a Singleton, in which case give it a public Map<Player, String> (should be a WeakHashMap when storing Player objects to avoid memory leaks afaik)
    When the player types the command, put the argument into the Map. When they click on an Inventory, check to see if the map contains the player then handle as necessary.

    Alternatively have one Inventory Handler per player, instantiate it with the Player object and the argument, then only handle if e.getWhoClicked().equals(player)

    Hope this helps

    Sent from my SM-G903F using Tapatalk
  3. I want it to get the target player (user to be banned not the person clicking)
  4. The easiest way would be storing the sender and the target in an HashMap<UUID, UUID> and just get the player like that and after youre done just remove the player from the hashmap
  5. Here: https://hastebin.com/oxesubesov.cs
    This should help I actually found it how we did it in our freeze gui plugin

    So on command you would just do hashmap.put(player.getUniqueId(), target.getUniqueId()); and open the GUI
  6. I know, that's what the String is (the target's username). The player is just for checking if the person who clicked the inventory actually chose to ban someone

    Sent from my SM-G903F using Tapatalk
  7. Well how would I do the code for that.?
  8. Just use the same class for the command handling and the listener (assuming the class / inventory logic isn't massive), then you can just use fields to store relevant data without having to pass it around.
    Why would it be a singleton though.
    private, not public. For encapsulation, only immutable, final fields should be public
    You only have memory leaks if you don't remove the object on player quit.
    That's up to you, no? Spoonfeeding takes out all the learning opportunities :p
  9. It ain't really spoon feeding if I make all the rest of my plugins myself so...
  10. Its just hash map stuff I don't know how to do.
  11. Is there no way to do it without a hash map.
  12. Why wouldn't it be? If I have a class that filters every user's chat, I'd only need one instance of it, or you'd likely get duplicate event handling. Granted not a true singleton (only instance is created onEnable) but practically only one instance is used.

    Private with a getter then, or delegate a put method. That was pseudo code so was trying to keep it simple.

    Aware of that, but Weak References save having a quit listener that removes loads of collections with Player objects in.

    @Op, I'll give you a clue
    1) get instance of inventory listener. If you're doing it all in one class, make a Map field to store all the data
    2) on command, store their argument into the map
    3) when they click the inventory, get the data from the map, and do whatever you need to with

    Sent from my SM-G903F using Tapatalk
  13. http://bfy.tw/IeNO

    It's simple stuff, we're not here to spoonfeed you with the absolute basics.

    Sent from my SM-G903F using Tapatalk
  14. Hmmm... Maybe if your gonna put this maybe just don't. Also I did Google alot before I made a post here so don't even say this.
    "For all those people who find it more convenient to bother you with their question rather than search it for themselves."
  15. "New Basically i'm making a Ban GUI it all works except for i can't seem to figure out how to let the event handler get the targeted player name from the command executor..." So Idk what you want,but this would be getting a player from a command
    Code (Text):
                Player target = Bukkit.getServer().getPlayer(args[0]);
                if (target == null) {
                    sender.sendMessage(ChatColor.RED + "INVALID TARGET");
                    return true;

    to get the player from a clicked gui icon
    [code]Player p = (Player) ChatColor.stripColor(e.getClickedItem().getItemMeta().getDisplayName());
    Code (Text):
        public ArrayList<Player> players = new ArrayList();

    Code (Text):
    Code (Text):
    public HashMap<Key, Value> map = new HashMap<>();
    map.put(e.getPlayer(), 0);
    int bans = map.get(e.getPlayer());
    • Informative Informative x 1
  16. Hence not a singleton programming wise :p
    Not sure whether to call it lazy, bad practice, or both.
    Fields should never be public, unless final and immutable (or primitives where you want to allow get/set).

    Also, Liskov Substitution Principle, program against abstractions rather than implementations. You should use the interface types as field/parameter types instead.

    @Mainstrike create a private Map field, with as key type Player, and as value type UUID. On command, figure out the UUID of the name the Player gives you as argument, and store this in the Map.

    Then open the inventory, and handle the click event in the same class (so the class both implements CommanderExecutor and Listener), and if they click the right item in the opened Inventory, you ban the player.
    • Creative Creative x 1
  17. So from what I understood you want to get the player from the event and use it in a command, if that's what you need, I would recommend you setting setters and getters. For example:

    Code (Text):

        private Player player;

        public void setPlayer(Player player) {
            this.player = player;
        public Player getPlayer() {
            return this.player;
    So have this in your main class and in the event class use main.setPlayer(yourplayer); and in the command class just have main.getPlayer(); Hopefully that helps a bit!
  18. I want to get the target from the command to the event. (the targets username)
  19. I literally gave u the code u need to do so.