Storing configuration values as variables

Retrieving a value from your plugin's config file requires more time and resources than is required to access a local variable. Therefore, if you will be accessing a specific value very often, it is best to store it as a variable. We will want to do just this with the GiveArmorToMobs Boolean value. It is also a good idea to store the ItemStack armor locally to prevent creating a new one every time it is used. Let's add the following variables above the methods of the main class:

private boolean giveArmorToMobs;
private ItemStack zombieHolding;
private ItemStack skeletonHolding;

We will only write the code to set the item that a zombie or skeleton is holding. You can add the rest of the armor yourself, as it will be done the same way.

We want these values to be automatically stored whenever the config file is reloaded. Note that when the config file is initially loaded, it is actually being reloaded. To ensure that our data is saved every time the config file is reloaded, we will add additional code to the reloadConfig method of the plugin. This is the method that we call to execute the /merl command. The reloadConfig method is already included in every Java plugin, but we will modify it by overriding it. This is a lot like how we override the onEnable method. Overriding a method will prevent the existing code from being executed. This is not an issue for onEnable, because the method has no prior existing code. However, reloadConfig has the code that we still wish to execute. Therefore, we will use the following line of code to execute the existing code that we are overriding:

super.reloadConfig();

This line of code is very important. Once we have it, we can add our own code before or after it. In our case, we want to store the values after the config file has been reloaded. Therefore, the additional code should be placed after the preceding line of code. The completed overridden reloadConfig method looks like this:

/**
 * Reloads the config from the config.yml file
 * Loads values from the newly loaded config
 * This method is automatically called when the plugin is enabled
 */
@Override
public void reloadConfig() {
    //Reload the config as this method would normally do
    super.reloadConfig();

    //Load values from the config now that it has been reloaded
    giveArmorToMobs = getConfig().getBoolean("GiveArmorToMobs");
    zombieHolding = getConfig().getItemStack("Zombie.holding");
    skeletonHolding = getConfig().getItemStack("Skeleton.holding");
}

The last code that we must write is to give armor to specific mobs. We will add this to the end of the onMobSpawn method. We only want to do this if giveArmorToMobs is set to true. Therefore, the block of code will be placed inside an if statement, as follows:

if (giveArmorToMobs) {

}

We can retrieve the entity's armor using the following code:

EntityEquipment equipment = event.getEntity().getEquipment();

This gives us their equipment slots even though they may not include anything in them at the moment. To know more about this object and what you can do with it, visit its API documentation at https://hub.spigotmc.org/javadocs/spigot/org/bukkit/inventory/EntityEquipment.html. Now that we have EntityEquipment, setting the pieces of armor is simple.

We have two distinct sets of armor. Therefore, we must first check whether the entity is either a zombie, or a skeleton. We can do this by using an if/else statement:

if (event.getEntityType() == EntityType.ZOMBIE) {
    //TODO - Give Zombie armor
} else if (event.getEntityType() == EntityType.SKELETON) {
    //TODO – Give Skeleton armor
}

However, using a switch/case block will be more efficient. Using switch/case in this scenario will look like this:

switch (event.getEntityType()) {
case ZOMBIE:
    //TODO - Give Zombie armor
    break;
case SKELETON: 
    //TODO - Give Skeleton armor
    break;
default: //Any other EntityType
    //Do nothing
    break;
}

The If/else statements are used to check multiple conditions (Is the entity a zombie? or Is the entity a skeleton?). A switch/case statement saves time by asking a single question (Which of the following is the type of the entity?). The code within the correct case condition will then be executed. When a break condition is fulfilled, the switch statement is exited. If you do not end the case with break, then you will fall through to the next case and begin executing that code. In some circumstances, that is a good thing, but we do not want that to happen here. The default case, that is, if none of the other cases match, does not need to be included because there is no code in it. However, it does make the statement more conclusive, and the Java coding standards released by Oracle state that the default case should always be included.

Within each of these cases, we will want to equip the correct set of armor.

We should check each piece of armor to ensure that it is not null before applying it using the following code. This will prevent the plugin from crashing due to an invalid configuration:

if (zombieHolding != null) {
    equipment.setItemInHand(zombieHolding.clone());
}

Tip

We used the clone method here on the ItemStack. We don't want to hand out a single ItemStack class to every mob. Instead, we will create its clones so that each mob can have its own copy.

Equipping the remaining armor and equipping an armor to a skeleton is very similar. The overall block of code will look like this:

if (giveArmorToMobs) {
    //Retrieve the equipment object of the Entity
    EntityEquipment equipment = event.getEntity().getEquipment();

    switch (event.getEntityType()) {
    case ZOMBIE: 
        //Set each piece of equipment if they are not null
        if (zombieHolding != null) {
            equipment.setItemInHand(zombieHolding.clone());
        }
        //TODO – Add rest of armor
        break;

    case SKELETON: 
        //Set each piece of equipment if they are not null 
        if (skeletonHolding != null) {
            equipment.setItemInHand(skeletonHolding.clone());
        }
        //TODO – Add rest of armor
        break;

    default: //Any other EntityType
        //Do nothing
        break;
    }
}

The clone method should be called on each ItemStack class so that the original items remain undamaged.

With this, the MobEnhancer plugin now supports giving armor to mobs. Try it out on your server to see how it works. We only discussed giving armor to zombies and skeletons because most mobs, including creepers, spiders, and cows, cannot wear armor. If you want, try adding armor and items to other mobs to see what happens. Also, try giving mobs unique items. For example, skeletons can be given a sword or zombies can be given a bow. There is also a skull item that comes in different looks; you can make a mob wear it as a mask.

You can even create skulls that represent a specific player, such as Notch, as shown in the following screenshot:

Storing configuration values as variables

The meta for the NotchSkull item is as follows:

NotchSkull:
  ==: org.bukkit.inventory.ItemStack
  type: SKULL_ITEM
  damage: 3
  meta:
    ==: ItemMeta
    meta-type: SKULL
    skull-owner: Notch

Play around with your new plugin to see what crazy items you can give to zombies and other mobs. The following screenshot illustrates an example of what you can accomplish by modifying the configuration:

Storing configuration values as variables
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.140.188.16