Hi,

for my current Allegro project I want to use Lua as scripting language. But for the moment I have an issue with calling Lua functions in C/C++. It seems that the metatable of an object is overwritten or deprecated when a second object with a different metatable is used in the same script.

I want to implement a Lua function 'update(m,h)' which is called from C/C++ in my project. This function will expect two light userdata objects of different types (this means two different metatables):
m: map object
h: hero object
Then I tested three scenarios:

Scenario 1)

function update(m)
  print("[Lua] map-id: "..m:get_id())    -- this works
end

Scenario 2)

function update(h)
  print("[Lua] hero name: "..h:name())  -- this works
end

Scenario 3)

function update(m,h)
  print("[Lua] hero name: "..h:name())  -- this works
  print("[Lua] map-id: "..m:get_id())    -- this does not work anymore! m is available, but get_id() cannot be called.
end

On C/C++ side, this Lua function is called the following way:

NOTE: Both metatables 'L_map' and 'L_hero' have been created in an earlier init phase.

Does anybody have some advices how to solve this issue, so that both map and hero object can be accessed within the Lua script?

Best regards

According to the docs, a table (like the one for update) can only have one metatable. So you're overwriting the metatable for your update function when you call setmetatable(L , -2) twice. Somehow you need to bind the metatable for each object to a separate object.

I'm confused by what this __lua_update function is supposed to do. It doesn't seem to make sense to associate a metatable with a table during an "update" function. I've barely learned the basics of Lua and that was probably 8 years ago, but this C function appears to:

• Load the global variable "update" onto the stack (presumably your update function in Lua).

• Load a 'userdata' object (pointer) to your C object onto the stack.

• Load the "L_map" metatable from Lua onto the stack (I'm not sure if that means loading a typed-variable or something more specific).

• Associate this userdata object (at -2 index on the stack?) with the metatable on the top of the stack? I'm not sure anymore how this works... It's been too long. This also pops off the metatable, I think.

• Now load the second 'userdata' object onto the stack (the first is still there, along with the "update" function).

• Associate that userdata object with another metatable and pop the metatable off of the stack.

• Finally attempt to call the function with the two userdata objects as arguments.

It sounds vaguely like it should work, assuming that you don't care about destroying any other "metatable" associated with these objects whenever you call this function... Presumably, if it's the same one there's no harm done if Edgar is right about overwriting (as opposed to chaining) them. It also sounds like a very strange pattern. If anything, if you were to do this kind of "hack", I'd expect you to restore the original metatables before returning...

So tell me, how far off am I compared to your understanding?

Without looking at the code:

IIRC, light userdata cannot even have individual metatables.

Maybe it would be better to use a full userdata object for storing your pointers.

Your code looks fine to me, although I am a bit confused by your update variants.

Generally, it could be a good idea to keep important Lua values in the registry using luaL_ref and luaL_unref. Pushing them again is quite fast, so you don't have to recreate the metatables on every update.

Interfacing Lua can be a pain... A hack that I used once was to use light userdata values as index to a table with weak values. So the C++ pointers were the keys and full userdata with proper metatables set that referenced the same objects were the values. So I could push those by pointer. Not elegant, not very fast, but it worked...

Thanks a lot for your advices. I have not that much experience in Lua and binding to C/C++.

I will check my code and rework it.