GM Command Script Explaination (As of rev4322)
Posted: Sat Dec 28, 2013 7:23 pm
Revision information:
https://code.google.com/p/onetimexi/sou ... ail?r=4322
I have decided to refactor / recode the entire command handler to be more dynamic last night.
That being said, the command handler no longer requires the commands.conf to define the GM commands for DSP.
Instead, all commands that are found in the scripts/commands folder are automatically loaded/used when requested.
This allows GMs to add and remove commands during runtime of the server without having to restart the server or edit the commands.conf file at all.
New File Format
Instead of relying on the commands.conf file to store the permission level and parameter types for each command, the command files now have this stored within them.
A new command file has this format:
Each command file has a table that lists its information: cmdprops
cmdprops holds, as of this check-in, two values:
- permission = The GM level required to use this command.
- parameters = The parameters to be passed to this command. (i = integer, d= float, s = string)
onTrigger
The onTrigger command has not changed at all. This function is still invoked in the same manner and the first argument passed to it is always the player entity that invoked the command.
Each argument after that is based on what you define in the parameters field of the cmdprops table.
Keep in mind; the command handler is not responsible for making sure that all arguments are pushed properly.
The command line passed from the players input (in chat) to the script is not guaranteed to contain all arguments your script requires.
You should always perform checks and validation on each of your arguments to ensure everything is valid. Not doing so can lead to crashes as well as debug breaks!
https://code.google.com/p/onetimexi/sou ... ail?r=4322
I have decided to refactor / recode the entire command handler to be more dynamic last night.
That being said, the command handler no longer requires the commands.conf to define the GM commands for DSP.
Instead, all commands that are found in the scripts/commands folder are automatically loaded/used when requested.
This allows GMs to add and remove commands during runtime of the server without having to restart the server or edit the commands.conf file at all.
New File Format
Instead of relying on the commands.conf file to store the permission level and parameter types for each command, the command files now have this stored within them.
A new command file has this format:
Code: Select all
---------------------------------------------------------------------------------------------------
-- func: addallspells
-- auth: <Unknown> :: Modded by atom0s.
-- desc: Adds all valid spells to the given target. If no target; then to the current player.
---------------------------------------------------------------------------------------------------
cmdprops =
{
permission = 1,
parameters = "s"
};
function onTrigger(player, target)
if (target == nil) then
player:addAllSpells();
else
local targ = GetPlayerByName(target);
if (targ == nil) then
player:PrintToPlayer(string.format( "Player named '%s' not found!", target ));
else
targ:addAllSpells();
end
end
endcmdprops holds, as of this check-in, two values:
- permission = The GM level required to use this command.
- parameters = The parameters to be passed to this command. (i = integer, d= float, s = string)
onTrigger
The onTrigger command has not changed at all. This function is still invoked in the same manner and the first argument passed to it is always the player entity that invoked the command.
Each argument after that is based on what you define in the parameters field of the cmdprops table.
Keep in mind; the command handler is not responsible for making sure that all arguments are pushed properly.
The command line passed from the players input (in chat) to the script is not guaranteed to contain all arguments your script requires.
You should always perform checks and validation on each of your arguments to ensure everything is valid. Not doing so can lead to crashes as well as debug breaks!
