My Hashmap isn't saving to the config

Discussion in 'Plugin Development' started by MasterDoctor, Oct 27, 2014.

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

    MasterDoctor

    Here is my saving and loading of the hashmap, if you need more, just let me know.

    My Code:
    Code:java
    1. public void onEnable(){
    2.  
    3. //Config Stuff...
    4.  
    5. this.saveDefaultConfig();
    6. this.reloadConfig();
    7.  
    8.  
    9. // Load Hashmap
    10. if(this.getConfig().contains("hashmap.data-storage")){
    11. this.getConfig().getConfigurationSection("hashmap.data-storage").getValues(false);
    12. }else{
    13. this.getConfig().createSection("hashmap.data-storage");
    14. }
    15.  
    16.  
    17. }
    18.  
    19. public void onDisable(){
    20. // Save Hashmap
    21. this.getConfig().createSection("hashmap.data-storage", hashmap);
    22. this.saveConfig();
    23.  
    24. //Logging Stuff
    25. Bukkit.getConsoleSender().sendMessage(ChatColor.RED + "[eTokens]" + " " + "Configs all Saved :)");
    26. }
    27.  
    28. //TODO: Redeem Enderpearl
    29.  
    30.  
    31.  
    32.  
    33.  
    34. @EventHandler
    35. public void onJoin(PlayerJoinEvent event){
    36. Player MCplayer = event.getPlayer();
    37. String player = MCplayer.getName();
    38. boolean playerLoggedBefore = hashmap.containsKey(player);
    39. if(playerLoggedBefore == true){
    40. //Player has logged in before
    41. }else if(playerLoggedBefore == false){
    42. //Player has logged in for first time!
    43. hashmap.put(player,0);
    44. }
    45. }
    46.  
    47. //TODO: New enchant command
    48.  
    49.  
    50.  


    My config, after reloading, stopping, starting etc.
    Code:
    #
    # eTokens Config  #
    hashmap:
      data-storage: {}
    
    Bear in mind, I had invoked the save.

    Quick Bump

    EDIT by Moderator: merged posts, please use the edit button instead of double posting.
     
    Last edited by a moderator: Jun 14, 2016
  2. Offline

    Funergy

  3. Offline

    Shmobi

    MasterDoctor I cant tell you your error, but you could clean up your code :eek:
    First of all, save getConfig() in a private variable and access it through it, because it is quiet ugly to call a listener again and again... second, you should store the players uuid in the hashmap instead of his name, because since version dont.Ask.Me players can change their name. not throught the client but bukkit can do i think. the uuid is the id which is used to save the data of the player into his file etc...
    can you show me the code you are initializing the hashmap?
     
  4. Offline

    MasterDoctor

    Code:java
    1. hashmap.put(player, 1)
     
  5. Offline

    Shmobi

    MasterDoctor this is how you put content in your map, but somewhere you must initialize it like HashMap<String, Integer> hashmap = new HashMap<String, Integer>(); or something like this. I want to see this because it could be that you're saveing an empty hashmap in your config because your pointer "hashmap" is not pointing on the object you want to
    ps thag me or i may wont respond to this thread, this time was pure luck because i was afk for a few minutes and come back right now
     
  6. Offline

    MasterDoctor

    Shmobi
    Code:java
    1. HashMap<Player, Integer> hashmap = new HashMap<Player, Integer>();
     
  7. Offline

    Monkey_Swag

    MasterDoctor The way I made a plugin similar to this didn't require hashmaps. Also, someone correct me if I'm wrong but your 'playerloggedbefore' variable wouldn't work, because after each reload/restart, the hashmap would clear. Anyways, just check if the config contains the player's uuid, if not, create a section in the config with this player's data. After that, just get the int from the config whenever you want to add/remove tokens. No hashmaps needed :) (You could do it with hashmaps but I find my way easier :p )
     
  8. Offline

    AdamQpzm

    MasterDoctor Based on your code, I'm assuming you're pretty new to Java. I'd recommend learning more Java before trying to make plugins, otherwise you just run into problems. I recommend the Oracle tutorials or a Java book :)

    Shmobi Just because you'd rather see fields that method calls, doesn't mean they're ugly. Stop trying to assert your personal preference as fact. :)
     
    fireblast709 likes this.
  9. Offline

    CraftCreeper6

    MasterDoctor
    You realise you can just do:
    if(player.hasPlayedBefore()){}

    right?
     
  10. Offline

    Abs0rbed

  11. Offline

    fireblast709

    Abs0rbed how exactly is it bad practice? Please elaborate.
     
  12. Offline

    CraftCreeper6

    Abs0rbed I wouldn't call it bad practice. It's more of it can cause memory leaks if you don't remove them.
     
  13. Offline

    Abs0rbed

    CraftCreeper6 Yeah, I guess you're right about that, though it's not great if you don't remove them and leaks are caused xD
    In this case it completely ruins the purpose, because you'd be removing the player object from that hashmap when they quit (or some other time), and then you can't use it for checking to see if they've played before because they're not in the list.
     
  14. Offline

    CraftCreeper6

    Abs0rbed
    player.getName(); || player.getUniqueId();

    The HashMap would be:
    private HashMap<String, Other thingy> = new...
    Or:
    private HashMap<UUID, Other thingy> = new...
     
  15. Offline

    Abs0rbed

    That's what I'm trying to say. It's better to do one of those than storing the Player object, because you'll have to remove it to prevent the leak, rendering saving the player object to see if they've played before useless
     
  16. Offline

    fireblast709

    Abs0rbed if you forget to remove them and cause memory leaks... Well that's 100% your issue :p. And my point was completely against the bad practice part. Of course it wouldn't be practical at all if you only want to track if an UUID has been online before, it's more a small performance boost when you need the Player object when iterating over the said collection.
     
  17. Offline

    CraftCreeper6

  18. Offline

    Abs0rbed

    fireblast709 Point taken, I suppose :p, though I would still end up using hasPlayedBefore() in this case xD
     
  19. Offline

    fireblast709

    CraftCreeper6 yes but that's still extra code to execute, and extra code to execute means it consumes more time of a tick :p.
     
  20. Offline

    CraftCreeper6

  21. Offline

    Shmobi

    Yea you're right. But at least you can't say it wouldn't be nicer. Sure it works both ways and it is readable. But at the timepoint he want to access the array (not in this case), he need to do this. i just wanted to say, safeing objects in variables even if it is not needed can prevent from possible errors in the future and can make less work

    Never store objects like a full Player in a hashmap. Because if the player leaves the server the object is not deleted, because you're keep pointing at it in your hashmap. you should store the UUID of the player. This id is used to load and safe data of a player and is generated only 1 time per player. use HashMap<UUID, Integer> and get a Player by using Bukkit.getPlayer(uuidOfPlayer)
     
  22. Offline

    AdamQpzm

    I can indeed say that and will say it now: config.whatever() does not look any nicer than getConfig().whatever()... Again, you may thing the former looks better, but it's personal opinion. I believe the latter looks nicer, and I can be sure (bar overriding) it's the default config. Your opinion is not a fact.
     
  23. Offline

    Shmobi

    AdamQpzm if you really wan't a discussion with good reasons you can have it by contacting me per pm. But i won't keep talking about something this thread isn't about. You're free to contact me whenever you want :)
     
  24. Offline

    AdamQpzm

    Shmobi There's no need for further contact. If someone wants to argue that a variable looks better than a method like getConfig() as a fact rather than a personal opinion, I don't know what more I could possible say to explain that it's a personal preference not a fact.
     
  25. Offline

    Shmobi

    AdamQpzm believe me, there is for sure a reason why :) but it seems like you're no developer who has to watch something like this in his code. i'm working as a developer and i know why i say that there is a reason why you should do it. But i won't start a discussion about it here. if you are interested then contact me, otherwise stay with your opinion
     
Thread Status:
Not open for further replies.

Share This Page