Storing and retrieving own block data

Discussion in 'Plugin Development' started by dadaemon, Oct 24, 2012.

Thread Status:
Not open for further replies.
  1. Dear developers,

    I've been making plugins for some time now and I can't figure out how to do the following in a way that is kind to the server.

    How to store my own data for blocks and retrieve them without heavy impact on the server.

    I have two cases that I will explain below where I need to store extra data of blocks. I know there is a meta feature implemented in Bukkit but is that the best way to go? I have access to flatfile (config), SQLite and MySQL. So any solution given can use those tools.

    Use case 1.
    I want to store player placed blocks and when a player breaks a block I need to check if it's a player placed block or not.

    How do I store the placed blocks and what is the best way to retrieve that data in the most server friendly way.

    Use case 2.
    I want torches to burn out after a certain amount of time.

    How do I store the place time of a torch for easy access on the break timer? And what is the best way to handle unloaded chunks. (Because I think it will give errors if I break a torch on an unloaded chunk.)


    I hope you can give me a good solution (or at least give me a good push in the right direction) to these problems and any help is much appreciated!
     
  2. I would use mysql or sqlite to store the placed blocks
     
  3. Well, for the first one, I'd go with a combination of them. Metadata will probably be really fast at runtime but lacks persistence. So for example, Player 1 places block. You apply the metadata on the block and (a)synchronously add the info to the database. When the server shuts down and loads back up, you load everything from the database and apply it to the blocks in the world. At the point where the block gets destroyed, just remove the info from the database (I'm not entirely sure if you need to remove the metadata from the block as well....).

    For the second one I'd go with a map like Map<Location, long> or something like that and a database as persistent storage. In the background a scheduled task would run at a specific interval (probably not every tick, or it'll probably lagg a lot when you have a lot of torches) that would iterate through the entries and check if the touch should burn out or not. Now, when the server shuts down you save all the remaining entries in the map to the database and load them on server startup again. This would be the best method if most of the torches would burn out before a server restart. If that's not the case, you might want to use the same save mechanism as I described for 1).

    Good luck and have fun!
     
  4. Thanks for the replies. I will go and use that for the plugins!
     
  5. Offline

    Infamous Jeezy

    Wait so is a blocks metadata basically a unique ID to retrieve a specific block?
    For my method I just store the location in a list and then call the block from that.
    The main issue with that though are physical blocks where when they move you have to predict their new location and remove the old old from the list.
     
  6. Metadata is data you can add and read from a block. The only problem with this is that it is not persistent. So after a restart of the server the data is lost. So storing the locations is still needed.

    I don't know if moving a block will keep the metadata. But on the other hand that metadata should stay on that moved block.
     
  7. Offline

    Infamous Jeezy

    Oh I understand, thanks for the information!
     
Thread Status:
Not open for further replies.

Share This Page