05-27-2013, 06:06 AM
First code iteration
The first code has been written, it is the very skeleton, as mentioned before, plus a few things already implemented. I'm still feeling my way around Lua and MCS API, so it took lots of retries to get this actually right.
The code does nothing much - it keeps track of each user's two sets of wand coords (lclk and rclk); other than that, it is just a skeleton full of empty functions.
The important thing to notice here is the overall stucture.
The CommandHandlers.lua file will implement all the functions that are called by MCS as a response to commands. It also has the function InitializeCommandHandlers() that registers all the commands. The commands themselves are stored in a separate file, CurrentLng.lua, that is meant to be translateable in the future. THe only command currently implemented is the ProtWand command, which gives the predefined wand item. Note the use of a cConfig class for the actual wand item storage - this way we can centralise the wand item and make it configurable later on.
The CommandState.lua file implements a cCommandState Lua class. This class currently holds the two sets of coords, used for storing the rclk and lclk wand click coords. Each user is expected to have one object of this class, even if the user is not a VIP, because there are multiple permissions for the various commands, so rather than checking permissions, we'll process all users' rclk and lclk data, but only those with permissions can actually do something with the data stored here.
Of special note is the GetCommandStateForPlayer() function, it expects a cPlayer object and returns the cCommandState object for that player. If that player doesn't have a cCommandState object yet, the object is created and stored in the global map. Once created, this function will return the same object for that player.
Config.lua implements the cConfig class. Currently it only holds the specification of the Wand item, but it may hold other configuration in the future. It is expected to be extended in the future so that it loads the config from an INI file, rather than being hard-coded. The class also defines some useful access functions, notably IsWand, which checks if the given item is the correct Wand.
CurrentLng.lua, as already mentioned, stores all the strings that are to be translatable. For now, it holds the commands; it will be later extended for all the user-visible strings. Translators will make copies of this file and then translate the strings contained within; server admins will then overwrite this file with the language file of their choice. Note that the other language files must not have a ".lua" extension, otherwise MCServer will try to load them and they will clash together.
The HookHandlers file implements the various hooks needed to perform the plugin's function. Of most importance are the OnPlayerLeftClick() and OnPlayerRightClick() hooks, which will be used for blocking the unwanted users. Right now, only the wand interaction is implemented.
Also, when a player joins or leaves, their cPlayerAreas and cCommandState is created / deleted, as appropriate. Without this, the plugin will leak memory, especially with the cCommandState being allocated per each player logging in.
The PlayerAreas file implements the cPlayerAreas class, one instance of which will be assigned to each player. This class holds the list of protection areas near around the player, and whether the player is allowed interaction in them, or not. It already has a utility function CanInteract() that determines whether a player can interact with the specified block or not, based upon the stored areas. However, the implementation is still missing key components - modifying the list, creating and destroying.
ProtectionAreas.lua implements the Initialize() function called when the plugin starts. It doesn't do anything fancy, the work is offloaded to individual modules.
Storage.lua is currently empty, it will implement the cStorage class representing the abstraction for accessing the database.
The version attached to this post is also committed to the main MCS repository in rev 1518.
The first code has been written, it is the very skeleton, as mentioned before, plus a few things already implemented. I'm still feeling my way around Lua and MCS API, so it took lots of retries to get this actually right.
The code does nothing much - it keeps track of each user's two sets of wand coords (lclk and rclk); other than that, it is just a skeleton full of empty functions.
The important thing to notice here is the overall stucture.
The CommandHandlers.lua file will implement all the functions that are called by MCS as a response to commands. It also has the function InitializeCommandHandlers() that registers all the commands. The commands themselves are stored in a separate file, CurrentLng.lua, that is meant to be translateable in the future. THe only command currently implemented is the ProtWand command, which gives the predefined wand item. Note the use of a cConfig class for the actual wand item storage - this way we can centralise the wand item and make it configurable later on.
The CommandState.lua file implements a cCommandState Lua class. This class currently holds the two sets of coords, used for storing the rclk and lclk wand click coords. Each user is expected to have one object of this class, even if the user is not a VIP, because there are multiple permissions for the various commands, so rather than checking permissions, we'll process all users' rclk and lclk data, but only those with permissions can actually do something with the data stored here.
Of special note is the GetCommandStateForPlayer() function, it expects a cPlayer object and returns the cCommandState object for that player. If that player doesn't have a cCommandState object yet, the object is created and stored in the global map. Once created, this function will return the same object for that player.
Config.lua implements the cConfig class. Currently it only holds the specification of the Wand item, but it may hold other configuration in the future. It is expected to be extended in the future so that it loads the config from an INI file, rather than being hard-coded. The class also defines some useful access functions, notably IsWand, which checks if the given item is the correct Wand.
CurrentLng.lua, as already mentioned, stores all the strings that are to be translatable. For now, it holds the commands; it will be later extended for all the user-visible strings. Translators will make copies of this file and then translate the strings contained within; server admins will then overwrite this file with the language file of their choice. Note that the other language files must not have a ".lua" extension, otherwise MCServer will try to load them and they will clash together.
The HookHandlers file implements the various hooks needed to perform the plugin's function. Of most importance are the OnPlayerLeftClick() and OnPlayerRightClick() hooks, which will be used for blocking the unwanted users. Right now, only the wand interaction is implemented.
Also, when a player joins or leaves, their cPlayerAreas and cCommandState is created / deleted, as appropriate. Without this, the plugin will leak memory, especially with the cCommandState being allocated per each player logging in.
The PlayerAreas file implements the cPlayerAreas class, one instance of which will be assigned to each player. This class holds the list of protection areas near around the player, and whether the player is allowed interaction in them, or not. It already has a utility function CanInteract() that determines whether a player can interact with the specified block or not, based upon the stored areas. However, the implementation is still missing key components - modifying the list, creating and destroying.
ProtectionAreas.lua implements the Initialize() function called when the plugin starts. It doesn't do anything fancy, the work is offloaded to individual modules.
Storage.lua is currently empty, it will implement the cStorage class representing the abstraction for accessing the database.
The version attached to this post is also committed to the main MCS repository in rev 1518.