Save Plugin Settings?

Discussion in 'Plugin Development' started by LRFLEW, Jan 29, 2011.

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

    LRFLEW

    I'm working on a plugin that controls blocks that have been activated for the plugin, but I ran into a little snag.

    I've got reading and writing to a settings file all set up, but I don't know the best organize the settings in the file. I need to save a block (where it is) and a boolean value for it.

    How would you recommend I go about this? All help is welcome.
    --- merged: Jan 30, 2011 8:19 PM ---
    really, nobody is helping?
     
  2. Offline

    Mixcoatl

    The layout of your settings file depends strictly upon the data you're writing to it. Some data are easily expressed as simple text, one line per record. Other data represent complex structures that cannot easily be expressed this way.
    If you only need to track coordinates you could use a text file containing one 3D coordinate per line. The individual components of the coordinate (x, y, z) could be separated by colons or commas. If you need to associate a coordinate with a name or id, you may have better luck using a properties file, storing the the property key as the name or ID and the value described previously in the simple text example.
    If you need more data that this you might be better off using YML or even a database (SQLite, MySQL, etc). As I said, it really depends upon the kind of data you're trying to persist.
     
  3. i have a question off of this, is there a way to save when the server is saving?
     
  4. Offline

    Mixcoatl

    I'm not aware of an event that fires when the server unloads a chunk or writes a dirty chunk.

    You have two options:
    1. Write your changes to disk immediate once they've been made; or,
    2. Schedule a timer to save changes periodically (for a naive implementation consider the java.util.Timer class).
     
  5. You sir are great help! I found a unload chunk event but didn't know what it did. Thank you so much!
     
  6. Offline

    Mixcoatl

    If you're using an unload chunk event, remember that chunks that are not unloaded won't (or shouldn't?) cause it to fire. I suspect the chunks around your spawn point will fall into this category. So you might still want to consider scheduling a timer to commit unsaved changes in chunks that have not recently been unloaded.
     
  7. Offline

    LRFLEW

    Thank, this helps (i think).

    I was thinking that, but how do I read something like that and find if an object has it's coordinates there, or to load it into a easier read system? I really don't know.
    how the heck do I create a properties file with three variables?

    I wouldn't even know where to start :p
    onDissable() runs on server stop as of somewhere around build #166 (not sure when though).
     
  8. Offline

    Mixcoatl

    I would recommend storing the details you read from your configuration file in some sort of data structure. Perhaps a Map, List, or Set, depending upon what you need. You would need to process your configuration file to build this data structure in memory.
    By formalizing the format of the values you will store into it. Consider the following:
    Code:
    class MyPluginClass {
        // Might want to use the Location class or
        // write your own to contain this data.
        static class Position {
            int x;
            int y;
            int z;
        }
        Position getPosition(String name) {
            final String value = properties.getProperty(name, "");
            final String[] split = value.split(":");
            if (split.length == 3) {
                try {
                    final Position position = new Position();
                    position.x = Integer.parseInt(split[0]);
                    position.y = Integer.parseInt(split[1]);
                    position.z = Integer.parseInt(split[2]);
                    // If we make it this far without
                    // an exception being thrown we're
                    // golden.
                    return position;
                } catch (NumberFormatException ex) {
                    // Need to do better exception handling than this.
                    ex.printStackTrace();
                }
            }
            return null;
        }
        void putPosition(String name, Position position) {
            final StringBuilder builder = new StringBuilder();
            if (position != null) {
                builder.append(position.x).append(':').
                        append(position.y).append(':').
                        append(position.z);
            }
            properties.setProperty(name, builder.toString());
        }
        // I won't cover how to load this.
        private Properties properties;
    }

    When you don't know where to begin, Google is the best place to start. But you don't even need to reach for Google to find the answer. There are already hundreds of posts about using databases for object persistence on these very forums.

    My experience was that onDisabled does not fire when the server shuts down. If it does now, that would be fantastic. I just updated my testbed server to b183 but I didn't check for this -- I was somewhere around b163 before tonight.
     
  9. do you know how to make a timer event without dragging down the server to much?
     
  10. Offline

    Mixcoatl

    There is no reason a timer event should ever take down a server.
    • Schedule your timer to run periodically, perhaps every few minutes.
    • Never invoke a Bukkit API method from within the timer task. There are workarounds for this, but your code will be much cleaner and easier to debug if you're not forced to use them.
     
  11. Offline

    NathanWolf

    You might want to check out my Persistence plugin- it simplifies data saving and loading.

    It uses SQLLite right now for storage, so for simple settings it may not be the way to go- but lists of blocks are not really something I'd consider a "setting", that's more like data :)

    Sorry for the shameless plug!
     
Thread Status:
Not open for further replies.

Share This Page