Number of blocks mined in the last thirty minutes

Discussion in 'Plugin Development' started by InsertNameHere, Aug 17, 2019.

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


    The title says it all; I'm trying to code a plugin that counts the number of ores and blocks total mined by the player in the past thirty minutes. However, I'm having difficulty coming up with a way to record the number of ores.

    My initial thought was to have a custom class called User in an array list that has a hashmap for each block in-game. When a player mines a block, it adds a key to the hashmap along with a cooldown. Once the cooldown reaches zero, the game removes the key and adjusts the count for each ore accordingly. However, this approach is kind of resource-intensive and I'm wondering if there's an easier way to go about this.
  2. Offline


    The ArrayList and HashMap shouldn't be too resource intensive, but maybe instead of having a cooldown since timers are consuming, log the time that the user mined the block and then when they break the next block you can check that time (or all times previous if you've stored them) and run code accordingly.
  3. Offline


    @InsertNameHere Do you want to get the amount of blocks each player has mined in the last thirty minutes, or do you want to get the total amount of blocks mined?
  4. Offline


    Not quite sure, but maybe you can create a class with the follwing attributes:
    - UUID
    - coal ore
    - iron ore
    - etc.
    - every other block
    - a method which returns all mined blocks

    Depending on what you need it exactly for, you can create an ArrayList<User> and place all in there. If you the information for something, loop over the list and check if the current UUID equals the UUID from the ArrayList at the current position.
  5. Offline


    If you are worried about resource intensivity, you could update the global score every minute and keep the realtime block count as is. This way you can schedule a repeating task that removes only minute-data from your score list.

    So you would keep track of the blocks a player mines in a custom POJO. Every minute, you write either that object, or the values from the object to your list. Whichever suits you. I would recommend writing the whole POJO and this way, you would have 30 objects for every player in your score list at any given time.

    The best way to store blocks mined, in my opinion, is a HashMap<Block, Integer>. This way you can keep track of all blocks without being dependent on adding attributes to your POJO manually.
    wand555 likes this.
  6. Offline


    This is what I'd do:

    1) Make a class that saves data of the mined blocks:

    class MinedBlock{
      LocalDateTime minedAt;
      Material blockType;
    2) Make a HashMap to assign the objects to a user ID:
    HashMap<UUID, MinedBlock> blockMiningHistory;
    3) Check on an interval of 1 minute what blocks are mined longer than 30 mins ago and remove those.

    4) On command or when you want to see what blocks are mined in the last 30 mins just check for each object of MinedBlock that belongs to the corresponding user if it's mined less than 30 mins ago and count up how many you find. Maybe you can also remove older blocks here instead of leaving a counter running.

    This method is not resource intensive as the data is just kept in your RAM and is not affecting your processor of your server much. If you don't like that it's being kept in your RAM memory, you can also just save the objects to a yml or JSON file.

    I hope that helped.
  7. Offline


    I don't get this part. You are intending to keep an object in memory for every block mined by every player and you're saying this is not resourse intensive. Are you aware there is such a thing as garbage collection? Which needs to trace and sweep individual objects? And also compact memory.

    This is in fact resource intensive.
    Writing data into physical storage every time a block is mined does not help.

    He wants number data, there's no need to keep the blocks in memory.
Thread Status:
Not open for further replies.

Share This Page