require

[NiLSPACE]

Something I've been seeing is that when you use require the library should be in the root folder. Can't we do something wich makes developers able to put those things in their plugins folder? Because now my root folder gets full with other folders:

[xoft]

Actually when you set up LuaRocks properly the things you "require" will be loaded from the LuaRocks folders, not from MCS at all.

[NiLSPACE]

But it does make sense to have everything a plugin in their own folder (exept Inter-plugin communication)

[xoft]

Yes, unless that "everything" is a shared library that is used by multiple plugins. You shouldn't put that into the plugin's folder anyway, because the library will contain platform-specific binaries that will be different for Windows, Linux, RasPi, Android... That's the point of LuaRocks - they take care of managing the system-level libraries, compiling them for the appropriate platform.

[NiLSPACE]

Do you have a step by step tutorial to install LuaRocks because I don't get any wiser from the "tutorial" on the LuaRocks site.

Also does the Android version look in the sdcard/mcserver folder when using require?

[xoft]

I have no idea if there even is an Android version. And no, there's no more detailed tutorial, I followed that one and improvised when it didn't work or didn't provide enough info. I don't remember much, it's been some time since then, but I think I had to use a visual studio command prompt (find it in the start menu) so that LuaRocks can find the VC compiler, and had to specify the prefix, I just used the folder c:\LuaRocks as the prefix.

[NiLSPACE]

Sounds like such a hassle if someone want's to install an plugin for the first time.

[xoft]

Yes, I don't like it either, so I'm again reconsidering pulling some of the functionality directly into MCS. So what rocks are you using? I expect MySQL to be a fairly often requested addition, then perhaps socket access and SSL, once we obtain that.

[NiLSPACE]

I'm not using any rocks, but I have tried some libraries. Maybe there are some rocks that do the same.

• LuaFileSystem
  
• LuaSocket
  
• llthreads
  

[xoft]

Is there anything in particular in LFS that you think the cFile API doesn't provide? I'd like to think that we already cover that one in MCS.

LuaSocket is a natural choice; however it doesn't play too well with MCS architecture, because it uses blocking IO, and MCS plugins cannot afford to block - they'd block the entire server. We need to implement our own socket library, built on asynchronous events, something like this:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

-- Client example: g_Socket = cSocket() local function OnConnect(a_Socket)   a_Socket.Send("hello") end local function OnReceiveData(a_Socket, a_Data)   LOGINFO("Received: " .. a_Data) end local function OnDisconnect(a_Socket)   LOGINFO("Socket disconnected") end g_Socket:Connect("hostname", port, OnConnect, OnReceiveData, OnDisconnect)   -- Server example: g_Socket = cSocket() -- TODO: Define the handler functions g_Socket:Bind("LocalIP", port, OnClientConnected, OnClientReceiveData, OnClientDisconnect)

As for threading, I was considering various alternatives, this one looks really good, we can make a similar interface in MCS. Instead of giving it a string of code to run, though, I would prefer giving it an entire disk file, how about that? Of course, the child thread won't have access to most MCS API, I think only the cFile API is safe enough, maybe cBlockArea (but without cWorld). It will be possible to "TryJoin" a thread that will join the thread if it has ended or return no value if the thread is still running.