Java Reference
In-Depth Information
In this chapter we'll look at how plugins are constructed, and add
these abilities to your toolbox:
• Add a command to a plugin
• Add new command annotations and code
• Work with Minecraft coordinates (
Location
)
• Find blocks or entities (
BlockIterator
)
CHAPTER
6
Add a Chat Command,
Locations, and Targets
How Does Minecraft Know About Your Plugin?
We've been using a bunch of objects in the Minecraft code. For example, you
know that a player is represented as a
Player
object and the server is a
Server
object.
So it shouldn't be too surprising to realize that our plugins are, in fact,
Plugin
objects. Canary has kindly defined a basic “recipe,” a basic
Plugin
class that
it knows about. I've added an additional
EZPlugin
class to make things a little
easier. Our job, as plugin writers, is to provide our own plugin code that fits
into that framework.
As we've seen, the first line of a plugin declares the plugin's name and then
adds the magical phrase
extendsEZPlugin
:
import
net.canarymod.plugin.Plugin;
import
com.pragprog.ahmine.ez.EZPlugin;
public class
MyFavoritePlugin
extends
EZPlugin {
That makes
Plugin
and
EZPlugin
parents of your class
MyFavoritePlugin
, just like
the examples in the last chapter.
The Minecraft server already knows how to work with a
Plugin
, and since that's
your plugin's parent, it now knows how to work with your plugin—even though
your plugin didn't exist when Canary was created. It's counting on the fact
that you'll write a couple of functions that it knows how to call.
