MCServer Lua implementation

[Revolucas]

Just reuse code for each one? If you release three plugins, not everyone is going to use all three. So if you are calling to other functions within those files it will not work. It's bad practice to do that. This really only affects someone who wants to customize their plugins for own use (You?).

[FakeTruth]

I'm just gonna go with giving each plugin a separate stack for r174 (like it always was), which means you cannot access other plugins. I think there are too many issues that haven't been resolved yet when using a single stack for all plugins. I still don't really see a problem with my CustomFunc() suggestion though, that would work just fine I suppose it's not the fastest thing in the world, but Lua isn't the fastest thing anyway (though it's pretty fast).

[Tybor]

Just reuse code for each one? If you release three plugins, not everyone is going to use all three. So if you are calling to other functions within those files it will not work. It's bad practice to do that. This really only affects someone who wants to customize their plugins for own use (You?).

Oh boy!
Reusing code in every plugin is bad practice! What do you think, why are there so called Runtime Libraries (*.dll or *.so) ?

The advantage about this programming practice is, that you can optimize, bugfix, change, add new features to the library without having to reimplement it in every plugin!

[Revolucas]

Just reuse code for each one? If you release three plugins, not everyone is going to use all three. So if you are calling to other functions within those files it will not work. It's bad practice to do that. This really only affects someone who wants to customize their plugins for own use (You?).

Oh boy!
Reusing code in every plugin is bad practice! What do you think, why are there so called Runtime Libraries (*.dll or *.so) ?

The advantage about this programming practice is, that you can optimize, bugfix, change, add new features to the library without having to reimplement it in every plugin!

I'm saying if you are going to make plugin1.lua use functions or variables from plugin2.lua with the way you currently name functions and variables, unless it's just you who plans on sharing information between the two plugins. Because it's going to cause huge problems with name conflictions for other plugin makers. You have to make sure you don't let any variable names leak or Johnny Smith is going to flip out when he tries to make his plugin compatible with your economy plugin. Yeah, dlls...what does that have to do with trying to use functions from another plugin? You can require a .dll and use them just fine in lua. You could make make plugin1.lua and plugin2.lua require the same .dll file. You can even use a header.lua file and share functions between the plugins.

If you simply want to create an economy sort of plugin and use it in other plugins I suggest using SQlite. Plugin1 can check or alter the balance of a player directly if it also using SQlite or by calling the global functions within economy plugin if economy.lua is required, as long as it was implemented to do so. SQlite is more efficient and less messy then flatfile ini reading. In fact I insist you use it with your Area plugin, as flatfile reading for each area is very inefficient. SQLite is the best you can do without going to a full blown database.

[Tybor]

If you simply want to create an economy sort of plugin and use it in other plugins I suggest using SQlite. Plugin1 can check or alter the balance of a player directly if it also using SQlite or by calling the global functions within economy plugin if economy.lua is required, as long as it was implemented to do so. SQlite is more efficient and less messy then flatfile ini reading. In fact I insist you use it with your Area plugin, as flatfile reading for each area is very inefficient. SQLite is the best you can do without going to a full blown database.

That's what I want to prevent that each plugin which eventually wants to get or alter a players balance needs to know something about how this is stored somewhere.
Additionally there might be other checks or things to be done when accessing the balance of a player.

Therefor Plugin1 should only need to call the global "EconomyGetBalance(Player)" which is provided by the economy.lua plugin.

But that is currently not possible with MCServer because it uses own stacks for each plugin!

[Revolucas]

I forgot it's not a good idea to require another plugin directly. But you can still share functions between them if you use them from another lua file used similar as a header file.

If you want to know how to use SQLite with lua and have Lua 5.1 installed on your PC there should be a luasql folder in the lua/5.1/clibs folder. Place the folder luasql with the sqlite3.dll into the main directory of MCServer. I attached an example (sqlite-test.lua) on how to use sqlite3. You can test it with SciTE included with Lua or some similar lua compiler.

There are some issues though. Such as crashing when reloading plugins and an issue with passing a table to Fetch to retrieve an entire row. It would be awesome if FakeTruth includes a wrapper for SQlite in API because the lua version lacks a lot of things like virtual tables and R*Tree implementation (The best way to do area indexing for a cuboid plugin!) And it's a hell of a lot faster then using ini files.

I've also included an example of how to make your plugin using SQLite. With a link containing the sqlite3.dll incase you dont' have it in your lua library.

Just download attached files (TestEconomy1,TestEconomy2 and economy_data_manipulation) and place them in the Plugins folder. Add TestEconomy1 and TestEconomy2 into settings. Put luasql folder into the main MCServer.



Basic use:

TestEconomy2 creates a new database and table that adds a default balance of 300 when a player joins. use /money command to check balance. The check balance function is in economy_data_manipulation

TestEconomy1 is a separate plugin. Does not require sqlite3.dll. But It does need to require economy_data_manipluation. with /addmoney you can add money to your balance and displays the new balance.

The whole point of this example is if another plugin does not use SQlite3 it can require economy_data_manipulation.lua and be able to alter the balance or manipulate the database created by TestEconomy1 without the need to rewrite code or use sqlite3.dll.

This was all tested. If you run into an Issue while testing this, tell me.

Oh and I recommend using SQLite Browser to easily view database files:
http://sqlitebrowser.sourceforge.net/

I suppose you can all do this Flatfile too if you don't use SQLite. Just read from an INI.

Soo....if this isn't what you want to do then I have no idea how you intend on making your plugin. Just trying to help you.

[Tybor]

Thanks Revolucas for your offered help.
But this whole discussion was not about implementing a single plugin and was not focused on my Economy plugin example.

I started this discussion to get details on MCServer Lua implementation (as the title would suggest ).
So back to my first post:

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?

All questions are already answered by FakeTruth.

So basically it is possible to share common or interface functions by requiring additional lua files, but i don't like this method.
Its because the functions need to be recompiled in every plugin which needs them, and this method is what i don't like.
And that was also my intention to demonstrate with my reference to .dll or .so runtime libraries.

[Revolucas]

Whatever. You acted as if it's impossible to share data between plugins. You've also stated you didn't want to rewrite code in every plugin. My suggestion solves both of those problems. So don't be a smart ass. I was on topic. Also, I was showing you how to implement luasql to use databases such as MySQL, SQlite and ODBC in the example. Since you claim efficiency is all you care about.

Since I doubt you even tried the examples I'll delete them and you can continue using flatfile, or just figure it out yourself.

[Tybor]

Whatever. You acted as if it's impossible to share data between plugins. You've also stated you didn't want to rewrite code in every plugin. My suggestion solves both of those problems. So don't be a smart ass. I was on topic. Also, I was showing you how to implement luasql to use databases such as MySQL, SQlite and ODBC in the example. Since you claim efficiency is all you care about.

Since I doubt you even tried the examples I'll delete them and you can continue using flatfile, or just figure it out yourself.

Yes.

P.S.: I read your opinion about my Area Plugin. Calm down! This is nothing to bother.
As Faketruth always states "It has to be fun".

[FakeTruth]

I think the best solution for this is to simply write your own Lua "libraries" in a separate .lua file which can then be included in each plugin that uses this shared code. If I would run all plugins on a single stack and plugin B is dependant on plugin A for a certain function, what will happen if plugin A gets disabled? I think the system will be far more robust if plugins just load each "library" in their own stack so they wont interfere with each other. If there is a certain need to call a function on an other plugin, it can be done by calling a C++ function ( not right now, but in the future ).

Since I can call a Lua function from C++ by simply giving the name of a function as a string, so can you from Lua.