Random Chitchat 2012-2016

[NiLSPACE]

Yea. math.random(min, max) also works.

[xoft]

I wanted something repeatably-random, to test out the possibility of Lua interacting with the chunk generator, as shown in this code sample: http://mc-server.xoft.cz/LuaAPI/OnChunkGenerated.html
I found out that the code sample actually doesn't work, because the pseudorandom calculation there doesn't work in Lua, so I wanted to find something that would work.

---

I'm beginning to like the plugin
Here's the code for anyone foolish enough to try:
https://github.com/madmaxoft/DoorMaze

It still doesn't load and save the mazes, so you'll be stuck with a non-functioning door maze after a server restart, but whatever.

[xoft]

I've noticed a weird thing that plugin-writers should be aware of:
When MCServer gives you an object of any class, it means that MCServer owns it and MCServer may destroy it between calls to your plugin. I used the following code to store player coords (Vector3d class) in a table:

local PlayerPos = a_Player:GetPosition();  -- Get the player's position
g_Maze.Center = PlayerPos;  -- Store it in a global table

Imagine my surprise when the player logged off the server and suddenly the g_Maze's Center's values were weird, coords like 10e-300 and such. Only then did I realise that MCServer has given me the player position in its own managed pointer and it has freed that pointer when the player logged off; but Lua still had references to that pointer. I was "lucky" enough that the server didn't crash, there was something else in the memory, it just wasn't a Vector3d anymore.

The solution to this is to make a copy for all instances that you'll be storing in the globals:

-- Get the player position and create a copy (through Vector3d's copy-constructor)
local PlayerPos = Vector3d(a_Player:GetPosition());

-- Now this is a Lua-managed copy and only Lua can destroy that object, once it's not used.
-- As long as it's stored in any table, it's safely existing.
g_Maze.Center = PlayerPos;

[FakeTruth]

Oohh, that is a good thing to know when writing plugins.

[NiLSPACE]

Would that not be fixed if we change

const Vector3d & GetPosition  (void) const { return m_Pos;     }

to

const Vector3d & GetPosition  (void) const { return Vector3d(m_Pos);     }

in Entity.h?

[xoft]

Bad news, everyone.
I've been trying to make MCServer work with LuaRocks. For those of you not knowing, LuaRocks is an online repository of Lua libraries that can be dynamically loaded into Lua. Those libraries provide an awesome range of stuff - socket communication, DB connectivity, filesystem access, encryption - you name it.
Unfortunately it won't work, either on Windows nor Unix, because those Rocks require dynamic linking to Lua's libraries.

[NiLSPACE]

Maybe even create a GetChangingPosition or something that is the same as the GetPosition now.

[xoft]

Would that not be fixed if we change [...]

No, that wouldn't probably even compile in C++, and even if it did, it would leak memory - there's no way to tell lua to take ownership of the object; and now everytime the C++ code queries entity's position, it makes a copy, thus putting quite a strain on the memory allocator.

It could be fixed by declaring

Vector3d GetPosition(void) const
{
  return m_Position;
}

This makes a copy and Lua / ToLua++ *might* know how to handle these. But it would still hurt the performance for C++ code.

[xoft]

Woohoo, luarocks on Linux is working for me.
Now for the Windows version...

[xoft]

Yay, LuaRocks on Windows is working for me in MCServer. I have successfully used the LuaSocket rock from within a MCServer script.
However, I cannot compile the rocks myself, that seems to produce invalid DLLs. Pity.

So, to sum up:
- we can use LuaRocks on Linux *if* we change the makefile to produce a dynamic executable ("-rdynamic" flag to link step). That linker flag may have other side effects, currently unknown. LuaRocks can be compiled and installed locally without any issue.
- we can use LuaRocks on Windows after some file-shuffling - the LuaRocks' lua DLLs need to be copied to MCServer's folder and the individual rocks' DLLs and lua files, too. We might avoid the need for the first one by compiling the Lua DLL for ourselves from the sources we have, it'd also be a cleaner solution. Still, the rocks have to be copied, because LuaRocks tries to use cygwin paths on all windows, even without cygwin installed. Also, I personally am unable to compile individual rocks.

---

Another windows update: When MCServer uses Lua as a DLL and LuaRocks is set up properly, including the environment variables, there's no need to copy any files, everything works out of the box, same as on Linux.