How Do I get a Menu From Another Class

Discussion in 'Spigot Plugin Development' started by DeadlyDeath001, May 7, 2015.

  1. This is my Compass Class:
    Code (Text):
      public static void openClassCompass(Player player){
            Inventory inv = Bukkit.createInventory(null, 9, "§8Pick your class!");
    //Items and Stuff
    This would be my Event Class:
    Code (Text):
        @EventHandler
        public void onPlayerInteract(PlayerInteractEvent event){
            Player player = event.getPlayer();
            Action action = event.getAction();
            ItemStack item = event.getItem();
            Inventory inv = ?
            if(event.getAction() == Action.RIGHT_CLICK_BLOCK | event.getAction() == Action.RIGHT_CLICK_AIR){
                return;
            }
            if(item.getType() == Material.COMPASS){
                return;          
            }    
            if(ChatColor.stripColor(item.getItemMeta().getDisplayName()).equalsIgnoreCase("Class Selector")){
                event.setCancelled(true);
                ClassCompass.openClassInventory(inv);
    How would I get the name of the other class so Inventory inv = ? can work for This error
    Code (Text):
    ClassCompass.openClassInventory(inv);
    [​IMG]
     
    • Funny Funny x 2
  2. Inkzzz

    Resource Staff

    To open a inventory use player#OpenInventory();
    To open a inventory, call the method were you make, and open the inventory.
    For inventory interact event check the inventory title
     
  3. You don't have a method called openClassInventory, you called it openClassCompass.
     
  4. Can I Just Get The Code? I tried Looking
     
  5. Code (Text):
      public static void openClassCompass(Player player){
            Inventory inv = Bukkit.createInventory(null, 9, "§8Pick your class!");


    player.closeInventory();
    player.openInventory(inv);
    }
     
  6. Your openClassCompass takes a Player type arg and you are inkoking the method with a Inventory type so you will get compiler errors
     
  7. Inkzzz

    Resource Staff

    Then you call this method when you want to open a inventory (if you didn't know)
     
  8. The static.... IT BURNS!!!

    Might need this while ur at it
    [​IMG]
     
    • Funny Funny x 2
    • Agree Agree x 1
  9. Turns out I Had == return true. I meant to say != return true.
    For player internet, that is why right clicking never worked LoL
    SOLVED! :D
     

  10. I just want to pass some advice onto you .. whenever you're performing conditional checking .. use the syntax:

    known.equals(unknown);

    In your case, you have:
    event.getAction() == Action.RIGHT_CLICK_BLOCK

    Instead, do:
    Action.RIGHT_CLICK_BLOCK.equals(event.getAction())

    While you'll be hard pressed to throw a NPE doing event.getAction() .. other scenarios can throw NPE's.

    Using known.equals(unknown) is a simple way of preventing those NPE's .. however there are many options for preventing NPE's
     
  11. The action will never be null (what triggers the event?) so using == to compare the two objects has no difference
     
  12.  
  13. I'd rather it through an NPE (so I can find out what is null) then nothing
     
  14. I disagree. Nulls should be handled because plugins revolve entirely upon user input.

    For example, say you want to create HashMap that associates Players with Inventories. An example of this would be a Backpack plugin. Player 1 wants to open Player 2's backpack. However, Player 2 is offline (ie: null). Are you just going to let that throw a null pointer error, or hope that Player 2 is online? What about if you use this code later in an extension of the plugin, and go playerMap.keySet() and try to get the Player's Health? That will certainly throw a null. Handling nulls is an inevitability.

    Letting nulls just kind of happen is sloppy. Plugins should be flexible and able to handle whatever scenario is thrown at them.
     
  15. 1. Enums *should* be compared using == rather than #equals
    2. == can handle null objects, it will return false then (except both are null), so no NPE is thrown
    3. Event#getAction will never return null, and if it does you've got other problems


    That's totally right.
    Ever user input has to be verified. That isn't limited to nulls. So e.g. don't expect a user to input a number if you need one, expect they do everything they can.

    However your suggestion to avoid NPE is only partly right. See this code:
    Code (Text):

    if (!known.equals(unknown))
       unknown.foo();
     
    We've just moved the NPE a line further. Additionally, a code looks in most cases better, if you just put a null check before trying to do sth with that object.
    See, how many cases exist you get a possible null object, you have to check whether it is equal to another object and if it isn't you do ... nothing with this object? Because if you need to do sth with it, you have to null check, making the suggestion useless.