There are many types of Bukkit plugins. Some of them require you to save data. By saving data, I am referring to saving information to the system's hard drive. This is needed if the information must stay intact, even after the server restarts. At this point, none of the plugins that we created have this requirement. Examples of plugins that will save data are as follows:
There are countless uses for saving data when a server is shut down. In this chapter, we will create a teleportation plugin that saves various warp locations to a file. Again, we will save these locations to a file so that we do not need to create them again after the server shuts down. You are already familiar with the YAML file format. Therefore, we will utilize the YAML configuration to save and load data. In this chapter, we will cover the following topics:
- The type of data that you can save
- The data in a plugin that is worth saving and the frequency of saving it
- Expanding a prewritten teleportation plugin
- Creating and using a
ConfigurationSerializableobject - Saving data in a YAML configuration
- Loading the saved data from the YAML configuration
You may recall, as discussed in the previous chapter, that only certain data types can be stored in a YAML file. These include primitive types, such as int and boolean, strings, lists, and types that implement ConfigurationSerializable, such as ItemStack.
For this reason, we can only save these specific types of data.
You may find yourself wanting to save other types of data such as a Player object, or in the case of the teleportation plugin, a Location object. These may not be stored directly, but they can usually be broken down in order to save the important values that are needed to load it later. As an example, you cannot save a Player object, but you can save the players'
UUID (Universal Unique Identifier), which can be converted into a string. Each Player has one UUID. Hence, it is the only information that we need to be able to refer to that specific player later.
A Location object also cannot be stored directly, but it can be broken down to its world, x, y, and z coordinates, yaw, and pitch. The x, y, z, yaw, and pitch values are simply numbers that can be stored. As for the world, it also has a UUID that will never change. Therefore, a location is broken down into one string (world uuid), three doubles (x, y, z), and two floats (yaw and pitch).
As you create your own plugins, you may have classes that you wish to store in a file, such as a BankAccount object. As mentioned earlier, we can do this with any class that implements ConfigurationSerializable. ConfigurationSerializable means that the object can be translated to a form that can be stored within a configuration. This configuration can then be written to a file. In the teleportation plugin, we will create a location object that does exactly this.