How to set a tag for a block that can be read by other classes?

Discussion in 'Plugin Development' started by nbrandwine, Jul 7, 2014.

Thread Status:
Not open for further replies.
  1. Offline

    nbrandwine

    Hello!
    I have a question regarding a plugin I'm working on.

    I'm trying to spawn a chest, which I have no problems with, but the problem lies within. An event triggers a block 'spawn' which makes a chest. In another class, which carries an interact event, needs to compare ALL the chests in the default world, and see if there's a tag from those chests placed by the first event.

    If the tag is present, it will check the player who interacted with the chests perms for a specific node that allows them to open/use the chest. I need to find a way that makes it so:

    This BLOCK spawns with a certain TAG of "VALID_" or some type of String/Value.
    Another event CHECKS if that BLOCK is being interacted with HAS that TAG.
    If it does, check the interacting player's permissions for the node 'ps.use'.

    I looked into metadata, but it seems to be VERY difficult for myself, which I am working on!
     
  2. Offline

    Wizehh

    Obviously you'd need to tweak this a bit, but here's the gist of it:
    Create a new HashMap<Block, String> object. To store information about a block, use the Map's put(key, value) method; e.g., blockInfo.put(block, "VALID"), where blockInfo is your HashMap variable and block your, well, Block object.
    To get the information associated with a block, use the get(key) method, which (if the HashMap contains the key) returns the value associated with the key; in this case, calling get(key) will return a String.
    boolean blockHasTag = blockInfo.get(block).equalsIgnoreCase("valid")

    I hope this wasn't too convoluted of an explanation; please tell me if you need something clarified or further explained.
     
  3. Offline

    coasterman10

    Since you can attach metadata to blocks, you can use the metadata system that Bukkit provides. To do this, you need an instance of Plugin, which is going to be the instance of your plugin's main class.

    An alternate method would be to create a Map to link Location to some value that you would like to use for your tags.
     
  4. Offline

    nbrandwine

    Thank you for the reply! I just have some confirmation one one.

    Now how would I read this from the block (in another class) to confirm if it's valid or not? I'm still a little confused on it. Would it be possible to show me in a code-perspective of how this works?


    I've tried this on my own, and this is what I've gotten:

    Create:
    Code:java
    1.  
    2. import java.util.HashMap;
    3.  
    4. import org.bukkit.block.Block;
    5.  
    6. public class Map_Create
    7. {
    8. static HashMap<Block, String> h = new HashMap<Block, String>();
    9.  
    10. public void putBlockInfo(Block b, String s)
    11. {
    12. h.put(b, s);
    13. }
    14. }
    15.  


    Read:
    Code:java
    1. package com.nbrandwine.lightningChest;
    2.  
    3. import java.util.HashMap;
    4.  
    5. import org.bukkit.block.Block;
    6.  
    7. public class Map_Read {
    8.  
    9. public boolean readBlockInfo(Block b, String s)
    10. {
    11. @SuppressWarnings("rawtypes")
    12. HashMap hm = Map_Create.h;
    13.  
    14. boolean blockHasTag = hm.get(b).equals(s);
    15.  
    16. if(blockHasTag == true)
    17. {
    18. return true;
    19. }
    20.  
    21. if(blockHasTag == false)
    22. {
    23. return false;
    24. }
    25.  
    26. // It should never get to this, right?
    27. return false;
    28. }
    29.  
    30. }
    31.  


    Thank you for the help!
     
  5. Offline

    Flamedek

    nbrandwine Off-topic on the thread problem, but in the read class you could just use "return blockHasTag;"
    Since blockHasTag is a boolean it will just return that value, saves a lot of lines. You could even use "return hm.get(b).equals(s);"
     
  6. Offline

    nbrandwine


    Alright, I used that! Thank you!
     
  7. Offline

    Wizehh

    Besides the redundant return statements and usage of static fields, your code looks fine to me.
     
Thread Status:
Not open for further replies.

Share This Page