MCServer Lua implementation

[Tybor]

How is Lua implemented in MCServer?
Does each Plugin has its own Lua Stack?

How to call functions between Plugins?
How to exchange data between Plugins?

[FakeTruth]

Each plugin (read .lua file, each .lua file can have multiple plugins) has its own stack.

I don't know if it's possible to call functions between plugins, I haven't tried this yet. I believe it is possible to include other .lua files in your .lua file, then use cPluginManager:GetPlugin( Plugin Name ) to get a pointer to a cPlugin object, then you might be able to call functions on it... though I'm not sure.

[FakeTruth]

OK.

I did some testing, and thinking, and I don't think it's possible to call newly declared functions on a plugin because you can't typecast in Lua AFAIK and what you do in Lua isn't really extending/inheriting the cPlugin class but faking it.

I think I will add one basic function to cPlugin:

Code:

virtual Lua_Table CustomFunc( string a_SomeParameter );

I suck at coming up with function names, so it's open for discussion lol.

Anyway, this allows you to do ... anything?

PluginOne:

Code:

function PluginOne:CustomFunc( Params )
    Split = StringSplit( Params )
    if( Split[1] == "MakeGod" )
        MakeGod( Split[2] ) -- Blabla, this function makes dude in Split[2] god
    end
end

PluginTwo

Code:

function PluginTwo:OnChat( Message, Player )
    PluginManager = cRoot:Get():GetPluginManager()
    OtherPlugin = PluginManager:GetPlugin("PluginOne")
    if( OtherPlugin ~= nil )
        OtherPlugin:CustomFunc("MakeGod " .. Player:GetName() ) -- Make all chatting players god! whee~
    end
end

----
On second thought, I might make the parameter for CustomFunc a Lua table as well, this makes it much easier to send complex data to the plugin.

Discuss!

[Tybor]

Each plugin (read .lua file, each .lua file can have multiple plugins) has its own stack.

I don't know if it's possible to call functions between plugins, I haven't tried this yet. I believe it is possible to include other .lua files in your .lua file, then use cPluginManager:GetPlugin( Plugin Name ) to get a pointer to a cPlugin object, then you might be able to call functions on it... though I'm not sure.

Yeah, that's the problem/limitation that each plugin has its own stack.
If all share same stack sharing data or functions between the plugins would be no problem (altough other problems may arise).

I'm in need of such mechanism as i plan to build plugins on each other.
e.g. AreaPlugin connects with a Economy Plugin to sell land. Also it might be the matter that some plugin checks the permissions of the AreaPlugin (like ItemDrop has to check a locked area).

---

OK.

I did some testing, and thinking, and I don't think it's possible to call newly declared functions on a plugin because you can't typecast in Lua AFAIK and what you do in Lua isn't really extending/inheriting the cPlugin class but faking it.

I think I will add one basic function to cPlugin:

Code:

virtual Lua_Table CustomFunc( string a_SomeParameter );

Please no C/C++ interface between Lua Plugins!
This would limit all benefits you have from Lua.

I strongly suggest using one common stack.

[codename_B]

Why not save the monetary values in an ini file like I'm doing? Then you can write one big plugin for area and store (and anything else that costs money)

[Tybor]

Why not save the monetary values in an ini file like I'm doing? Then you can write one big plugin for area and store (and anything else that costs money)

The matter is not getting some values out of an ini file but rather reusing existing code functionality.
I don't want the same code of area checking in all plugins which need it.
The code is always the same and already live in AreaPlugin.

So just calling AreaPLugin:IsOwner(...) or AreaPlugin:GetArea(...) would be much easier and more efficient than reimplementing in new plugin.

[FakeTruth]

So I tested using a single Lua instance/stack and it works, but it's not perfect. For instance values stored in the 'self' table cannot be accessed from anywhere outside of a plugin function, or it'll try to access its own self table. Meh this doesn't sound very clear. Basically you need to put everything in global variables if you want to be able to access it from a different plugin, this brings the issue of name collisions....

[Tybor]

So I tested using a single Lua instance/stack and it works, but it's not perfect. For instance values stored in the 'self' table cannot be accessed from anywhere outside of a plugin function, or it'll try to access its own self table. Meh this doesn't sound very clear. Basically you need to put everything in global variables if you want to be able to access it from a different plugin, this brings the issue of name collisions....

Yeah, name collisions, that's true. But self is only a reference to its own table.
AreaPlugin:IsOwner(...) would translate to AreaPlugin.IsOwner(AreaPlugin, ...).
so using self works as expected. If you would need to access/store variable use
AreaPlugin.mytable = {} which should be acessable from all other plugins in same way.
So dunno whats wrong with self.

[FakeTruth]

'self' is actually created and filled in on the C++ side when calling a plugin function, it allows you to call C++ functions on itself like SetName and GetName. Those functions are inaccessible from outside the plugin function call itself. You cannot do AreaPlugin:GetName() or AreaPlugin.GetName() or AreaPlugin.self:GetName(), they will all fail.

[Tybor]

Ah, OK.

So some sort of "Good Plugin Programming Practice" should be written? Use global Plugin Table for storing every global which plugin needs. Use local for functions etc.

Perhaps a switch in settings.ini to change MCServer behaviour between multiple/single stack would be good? Or is this not possible?
So admins can decide how they want plugins act.