<li><b>function Initialize</b> is called on plugin startup. It is the place where the plugin is set up.</li>
<li><b>Plugin:SetName</b> sets the name of the plugin.</li>
<li><b>Plugin:SetVersion</b> sets the revision number of the plugin. This must be an integer.</li>
<li><b>LOG</b> logs to console a message, in this case, it prints that the plugin was initialised.</li>
<li>The <b>PLUGIN</b> variable just stores this plugin's object, so GetName() can be called in OnDisable (as no Plugin parameter is passed there, contrary to Initialize).</li>
<li><b>function OnDisable</b> is called when the plugin is disabled, commonly when the server is shutting down. Perform cleanup and logging here.</li>
</ul>
Be sure to return true for this function, else MCS thinks you plugin had failed to initialise and prints a stacktrace with an error message.
</p>
<h2>Registering hooks</h2>
<p>
Hooks are things that MCServer calls when an internal event occurs. For example, a hook is fired when a player places a block, moves,
<li><b>cPluginManager.AddHook</b> registers the hook. The hook name is the second parameter. See the previous API documentation link for a list of all hooks.</li>
</ul>
What about the third parameter, you ask? Well, it is the name of the function that MCServer calls when the hook fires. It is in this
function that you should handle or cancel the hook.
</p>
<p>
So in total, this is a working representation of what we have so far covered.
<li><b>PluginManager:BindCommand</b> binds a command. It takes the command name (with a slash), the permission a player needs to execute the command, the function
to call when the command is executed, and a description of the command.</li>
</ul>
The command name is pretty self explanatory. The permission node is basically just a <b>string</b> that the player's group needs to have, so you can have anything in there,
though we recommend a style such as "derpyplugin.explode". The function to call is like the ones with Hooks, but with some fixed parameters which we will come on to later,
and the description is a description of the command which is shown when "/help" is typed.
</p>
<p>
So why are there two? Standards. A plugin that accepts a parameter MUST use a format for the description of " ~ Description of command and parms"
whereas a command that doesn't accept parameters MUST use " - Description of command" instead. Be sure to put a space before the tildes or dashes.
Additionally, try to keep the description brief and on one line on the client.
</p>
<h3>Parameters</h3>
<p>
What parameters are in the function MCServer calls when the command is executed? A 'Split' array and a 'Player' object.
</p>
<h4>The Split Array</h4>
<p>
The Split array is an array of all text submitted to the server, including the actual command. MCServer automatically splits the text into the array,
so plugin authors do not need to worry about that. An example of a Split array passed for the command, "/derp zubby explode" would be:<br/><br/>
   /derp (Split[1])<br/>
   zubby (Split[2])<br/>
   explode (Split[3])<br/>
<br/>
   The total amount of parameters passed were: 3 (#Split)
</p>
<h4>The Player Object and sending them messages</h4>
<p>
The Player object is basically a pointer to the player that has executed the command. You can do things with them, but most common is sending
a message. Again, see the API documentation for fuller details. But, you ask, how <i>do</i> we send a message to the client?
</p>
<p>
Remember that copy of CoreMessaging.lua that we downloaded earlier? Make sure that file is in your plugin folder, along with the main.lua file you are typing
your code in. Since MCS brings all the files together on JIT compile, we don't need to worry about requiring any files or such. Simply follow the below examples:
-- Use: Failure message, like when a command was entered correctly but failed to run, such as when the destination player wasn't found in a /tp command
SendMessageFailure(Player, "Player Salted was not found")
Those are the basics. If you want to output text to the player for a reason other than the three listed above, and you want to colour the text, simply concatenate
"cChatColor.*colorhere*" with your desired text, concatenate being "..". See the API docs for more details of all colours, as well as details on logging to console with
LOG("Text").
</p>
<h2>Final example and conclusion</h2>
<p>
So, a working example that checks the validity of a command, and blows up a player, and also refuses pickup collection to players with >100ms ping.
Make sure to read the comments for a description of what everything does. Also be sure to return true for all <b>command</b> handlers, unless you want MCS to print out an "Unknown command" message
when the command gets executed :P. Make sure to follow standards - use CoreMessaging.lua functions for messaging, dashes for no parameter commands and tildes for vice versa,
