Uknown Command

[Shadowraix]

It should create it on the initialize function,but all of my commands are unknown.

function Initialize(Plugin)
Plugin:SetName("AutomatedMessages")
Plugin:SetVersion(1)

local PluginManager = cPluginManager:Get()
PluginManager:BindCommand("/automessage add","automessage.add",AddMessage,"")
PluginManager:BindCommand("/automessage remove","automessage.remove",RemoveMessage,"")
PluginManager:BindCommand("/automessage edit","automessage.edit",EditMessage,"")
PluginManager:BindCommand("/automessage reload","automessage.reload",Reload,"")
PluginManager:BindCommand("/automessage interval","automessage.interval",EditInterval,"")
local MsgDB = sqlite3.open("AutomatedMessages.sqlite")
MsgDB:exec([=[
CREATE TABLE IF NOT EXISTS Messages
(
MessageName TEXT Primary Key NOT NULL,
Message TEXT NOT NULL,
Interval INT NOT NULL
);
]=])
Reload()
LOG("Initialized " .. Plugin:GetName() .. " v." .. Plugin:GetVersion())
return true
end

All of my command functions return true.

[xoft]

The cPluginManager:BindCommand() function doesn't support multi-word commands. You can only register the first word, and provide a handler that will handle the additional words.

A much better (and simpler) way is to use the Info.lua file: http://mc-server.xoft.cz/LuaAPI/InfoFile.html
There you can define multi-word commands and the helper library InfoReg.lua will take care of registering everything for you and providing the command handlers needed to make it all work. Not to mention that the Info.lua file makes a great documentation for your plugin.

[Shadowraix]

The cPluginManager:BindCommand() function doesn't support multi-word commands. You can only register the first word, and provide a handler that will handle the additional words.

A much better (and simpler) way is to use the Info.lua file: http://mc-server.xoft.cz/LuaAPI/InfoFile.html
There you can define multi-word commands and the helper library InfoReg.lua will take care of registering everything for you and providing the command handlers needed to make it all work. Not to mention that the Info.lua file makes a great documentation for your plugin.

Alright, I'll give the info.lua stuff a look. Quick question, I notice that the API has .BindCommand and :BindCommand what is the difference between the two?

[xoft]

The dot is there for historical reasons, static functions used the dot-binding before we decided to use the colon-binding for all functions.

As for Lua, the colon means that an invisible "self" parameter is passed to the function as its first parameter, so these two are equivalent:

object:SomeFunction(param)
object.SomeFunction(object, param)

[Shadowraix]

The dot is there for historical reasons, static functions used the dot-binding before we decided to use the colon-binding for all functions.

As for Lua, the colon means that an invisible "self" parameter is passed to the function as its first parameter, so these two are equivalent:

object:SomeFunction(param)
object.SomeFunction(object, param)

Alright, yeah, I know how the OOP stuff works with the self parameter. I was just confused on why you would have a .bind and :bind. While we are on the subject with API design, why does the API have a c in front of every object? cBlockArea, CPluginManager, why not just PluginManager and BlockArea?

[worktycho]

Because thats the coding convention in the c++ code. As for why c++ code uses a c in front of every object, you have to ask xoft.

[xoft]

Actually, you'll have to ask @FakeTruth, that's a convention inherited from him.
The problem is, we can't really change it now, because the plugins are already written with this. It would be possible to provide a "compatibility layer", simply doing the equivalent of

cPluginManager = PluginManager

This would work in most cases, but some plugins take param-checking seriously and do things like

if (tolua.type(a_Param) == "cPlayer") then

These would break.

Also, there are some people on the team who oppose the Java codestyle (CamelCase classes, almostCamelCase functions).

[Shadowraix]

Actually, you'll have to ask @FakeTruth, that's a convention inherited from him.
The problem is, we can't really change it now, because the plugins are already written with this. It would be possible to provide a "compatibility layer", simply doing the equivalent of

cPluginManager = PluginManager

This would work in most cases, but some plugins take param-checking seriously and do things like

if (tolua.type(a_Param) == "cPlayer") then

These would break.

Also, there are some people on the team who oppose the Java codestyle (CamelCase classes, almostCamelCase functions).

Hmm...Would it be practical to make a Lua file that when its required it returns a big string making this compatibility layer? Then in the initialize function I can just call loadstring?

Or, if there's an easy way for me to edit the source to do that, I could do so for my own personal use if I could be directed to the API files. My C++ knowledge is sub-optimal but if its just renaming things it wouldn't be too hard for me.

Edit:
I've been looking at the info.lua article. Do sub commands support permissions now? The article states that it doesn't, but I don't know if things have changed since then. If so, might want to update the article.

[xoft]

You can just put the reverse-compatibility layer (PluginManager = cPluginManager) to a separate file in your plugin and it will get loaded along with the other files. But as I said, the mapping will not solve everything, that's why it's not being done in the first place.

The subcommands have always supported permissions assigned to them, but they don't support inheriting permissions from their parent.
For example, consider you have a command "cmd" with a child "cmd sub". If you assign a permission to "cmd sub" it will not be checked for "cmd" (which is quite logical). But if you assign a permission to "cmd", it will not be checked for "cmd sub", which is somewhat counter-intuitive.

It doesn't matter much, because you can check any number of permissions inside the handler, using the cPlayer:HasPermission() function.

[Shadowraix]

You can just put the reverse-compatibility layer (PluginManager = cPluginManager) to a separate file in your plugin and it will get loaded along with the other files. But as I said, the mapping will not solve everything, that's why it's not being done in the first place.

The subcommands have always supported permissions assigned to them, but they don't support inheriting permissions from their parent.
For example, consider you have a command "cmd" with a child "cmd sub". If you assign a permission to "cmd sub" it will not be checked for "cmd" (which is quite logical). But if you assign a permission to "cmd", it will not be checked for "cmd sub", which is somewhat counter-intuitive.

It doesn't matter much, because you can check any number of permissions inside the handler, using the cPlayer:HasPermission() function.

Oh, cool. Neat to know that the file will get automatically loaded on top of my main plugin file. No need for require() then.

Ahh, I see. I didn't realize the parent part. Must of skipped past it in my head. I get it now.