cPluginManager:GetLuaPlugin() and lua_State

[Taugeshtu]

Oh my God! - that was first thought I had when I found GetLuaPlugin(). In the Bindings. So, it's a function, seems like it should return Lua Plugin instance (looked into source: a-ha! it does!), and it's exported to Lua. Brilliant!

"Hold on, boy, look what this function needs as arguments..."

Damn! Some lua_State pointer, and I HAVE NO IDEA (remembered Meet Medic from TF2... nevermind) what that thing is...

FakeTruth, I need your torch there!
(because the idea of grabbing plugin instance in another plugin seems to be VERY desired by me)

[FakeTruth]

lua_State is automagically passed when you call a function from Lua. Or something like that..
But even if you did get a plugin reference, you still can't call Lua functions on it ( you can call the c++ functions, but why would you )

All plugins have their own 'sandboxed' lua_State (own stack, memory, etc.) which means they cannot interact with each other in a normal fashion.

I don't think you can easily forward Lua functions with any number of arguments/return values called from one state to the other.
The easiest way is to add a generic function to plugins that accepts a string and returns a string

[Taugeshtu]

Thank you for reply I thought that there will be some hidden stones, but I was still hoping
Well, I have to think and design some common data storage for plugins then, I suppose And then suggest it to be implemented.

[FakeTruth]

Like I said, a generic string function can be added which can be called on plugins by other plugins, but it's hardly ideal

[Taugeshtu]

Just string isn't enough, IMO - I would prefer to have similar to cIniFile possibilities...

It could be done through modifying existing cIniFile code: instead of creating new instance (new object) of cIniFile on such code:

Code:

PLUGIN.IniFile = cIniFile("ChunkWorx.ini")

server could give a pointer to existing one (and create only if cIniFile instance with such name wasn't created before)

In other words, plugin1 requests cIniFile instance, server had no instances referencing to that exact ini file, server creates new cIniFile instance and return a pointer on it to plugin1
Then plugin2 requests cIniFile instance for same .ini, server found that it has such cIniFile instance and return a pointer to it.

This way plugins could share some ammount of data of differend kinds.

[FakeTruth]

In Lua a string is a number and/or string, it converts automagically. So it's pretty much the same as your IniFile idea

[Taugeshtu]

Damn type conversion
I got to get used to that
Then you're right. Generic string function with an ("key", "valuename") arguments (double-layer addressation)

[FakeTruth]

Like I said, a generic string function can be added which can be called on plugins by other plugins, but it's hardly ideal

I'm starting to doubt this is even possible.

Plugin hooks are called from various threads, and Lua is not threadsafe by itself (at least that's what I gathered). MCServer locks a CriticalSection for each plugin separately when a hook is called on the plugin. If two plugins from two different threads were to call a function on each other at the same time it would result in a deadlock.

[xoft]

I guess with the separate lua_state we have effectively sandboxed each plugin and it's now quite impossible for two of them to communicate directly. I, however, think that it should be possible to pass simple "messages" between them, somewhat like Windows' PostMessage() and maybe even SendMessage().

[FakeTruth]

Yeah, sending messages is totally possible, because you can queue them and handle them in the tick function or something. But that means you cannot immediately get a value back