Writing a MCServer plugin

Writing a Cuberite plugin

This article will explain how to write a basic plugin. It details basic requirements for a plugin, explains how to register a hook and bind a command, and gives plugin @@ -20,12 +20,12 @@

Let us begin. In order to begin development, we must firstly obtain a compiled copy of MCServer, and make sure that the Core plugin is within the Plugins folder, and activated. - Core handles much of the MCServer end-user experience and gameplay will be very bland without it. + Core handles much of the Cuberite end-user experience and gameplay will be very bland without it.

Creating the basic template

Plugins are written in Lua. Therefore, create a new Lua file. You can create as many files as you wish, with - any filename - MCServer bungs them all together at runtime, however, let us create a file called main.lua for now. + any filename - Cuberite bungs them all together at runtime, however, let us create a file called main.lua for now. Format it like so:

@@ -60,12 +60,12 @@ end
 					This global variable is only needed if you want to know the plugin details (name, etc.) when shutting down.
 				function OnDisable is called when the plugin is disabled, commonly when the server is shutting down. Perform cleanup and logging here.
 			
-			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.
+			Be sure to return true for this function, else Cuberite thinks you plugin had failed to initialise and prints a stacktrace with an error message.
 			
 			
 			Registering hooks
 			
-			Hooks are things that MCServer calls when an internal event occurs. For example, a hook is fired when a player places a block, moves,
+			Hooks are things that Cuberite calls when an internal event occurs. For example, a hook is fired when a player places a block, moves,
 			logs on, eats, and many other things. For a full list, see the API documentation.
 			
 			
@@ -85,7 +85,7 @@ cPluginManager.AddHook(cPluginManager.HOOK_NAME_HERE, FunctionNameToBeCalled)
 			

 				cPluginManager.AddHook registers the hook. The hook name is the second parameter. See the previous API documentation link for a list of all hooks.
 			
-			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
+			What about the third parameter, you ask? Well, it is the name of the function that Cuberite calls when the hook fires. It is in this
 			function that you should handle or cancel the hook.
 			
 			
@@ -140,11 +140,11 @@ cPluginManager.BindCommand("/commandname", "permissionnode", FunctionToCall, " ~
 			
 			Parameters
 			
-			What parameters are in the function MCServer calls when the command is executed? A 'Split' array and a 'Player' object.
+			What parameters are in the function Cuberite calls when the command is executed? A 'Split' array and a 'Player' object.
 			
 			The Split Array
 			
-			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,
+			The Split array is an array of all text submitted to the server, including the actual command. Cuberite 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:


 				   /derp (Split[1])

 				   zubby (Split[2])

@@ -206,7 +206,7 @@ function Explode(Split, Player)
 		return true
 	end
 
-	-- Create a callback ExplodePlayer with parameter Explodee, which MCS calls for every player on the server
+	-- Create a callback ExplodePlayer with parameter Explodee, which Cuberite calls for every player on the server
 	local HasExploded = false
 	local ExplodePlayer = function(Explodee)
 		-- If the player we are currently at is the one we specified as the parameter
@@ -215,11 +215,11 @@ function Explode(Split, Player)
 			Player:GetWorld():DoExplosionAt(Explodee:GetPosX(), Explodee:GetPosY(), Explodee:GetPosZ(), false, esPlugin)
 			Player:SendMessageSuccess(Split[2] .. " was successfully exploded")
 			HasExploded = true;
-			return true -- Signalize to MCS that we do not need to call this callback for any more players
+			return true -- Signalize to Cuberite that we do not need to call this callback for any more players
 		end
 	end
 	
-	-- Tell MCS to loop through all players and call the callback above with the Player object it has found
+	-- Tell Cuberite to loop through all players and call the callback above with the Player object it has found
 	cRoot:Get():FindAndDoWithPlayer(Split[2], ExplodePlayer)
 	
 	if not(HasExploded) then
@@ -239,7 +239,7 @@ function OnCollectingPickup(Player, Pickup) -- Again, see the API docs for param
 end

- Make sure to read the comments for a description of what everything does. Also be sure to return true for all command handlers, unless you want MCS to print out an "Unknown command" message + Make sure to read the comments for a description of what everything does. Also be sure to return true for all command handlers, unless you want Cuberite 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, and finally, the API documentation is your friend!

-- cgit v1.2.3