POC Class to Manage Lua Calls and Return Values

[Xarg0]

I've been a little bit bored today so I decided to finish up an old project I've found on my harddisk.
Here's the Code, it isn't a complete solution for executing lua functions but you can use it as a starting point if you've no Idea how to retrive lua return values:
CLua_Manager.h:

#ifndef _H_CLUA_MANAGER_
#define _H_CLUA_MANAGER_
#include <vector>
#include <boost/format.hpp>
#include "Lua/lua.h"
#include "WoWDefines.h"
typedef void (_cdecl *LUA_DOSTRING)(std::string, std::string, void*);
typedef void (_cdecl *LUA_REGISTER)(std::string, void*);
LUA_DOSTRING lua_DoString = reinterpret_cast<LUA_DOSTRING>(gpLuaDoString); 
LUA_REGISTER lua_Register = reinterpret_cast<LUA_REGISTER>(gpLuaRegister);
int MyCallback (lua_State *L);

class CLua_Manager{
    private:
        
        CLua_Manager();
        ~CLua_Manager();
        static CLua_Manager* singleton;
    public:
        static CLua_Manager* Get(){if(!singleton){singleton = new CLua_Manager();lua_Register("MyCallback",(void*)MyCallback);return singleton;}return singleton;}
        static void Destroy(){delete singleton; singleton = 0;}
        std::vector<std::string> vResults;
        void DoString(std::string& s);
        std::string GetResult(int n);
        
};


#endif 

CLua_Manager.cc

#include "CLua_Manager.h"

int MyCallback (lua_State *L)
{
      //clear the vector if its not empty
    
     if ( !CLua_Manager::Get()->vResults.empty() )
        CLua_Manager::Get()->vResults.clear();

     //get count of returns on stack
     int n = lua_gettop(L);

     //loop to retreive these
     for (int i = 1;i<=n; i++)
        {
              //using lua_tostring to get the result
              const char * pszResult = lua_tostring(L, i);
              //add result to vector
              CLua_Manager::Get()->vResults.push_back( pszResult );
             

        }


return 0;

}

std::string CLua_Manager::GetResult(int n){
    try{
        return vResults[n];
    }
    catch(std::string e){
        return e;
    }
}

void CLua_Manager::DoString(std::string& s){
    std::string Command = (boost::format("MyCallback(%1%)") % s).str();
    lua_DoString(Command.c_str(), Command.c_str(), 0);
} 

as you can see I don't provide the offsets for the two wow functions I'm using, but I guess you can figure them out yourself.
I also leave it up to you to bypass the IsFunctionInRange check.

The Code is quick and dirty but I guess it's enough to make the concept understandable.

[Azzie2k8]

Although this is not C# it made some things clearer for me thanks alot +Rep

[amadmonk]

This is one of the more common ways to get data back from a call to Lua's DoString: register a callback, and pipe all of your results through the callback.

The other method is to reverse the DoString function (it's not really that hard) and reimplement it to return values.

[lanman92]

This isn't thread-safe, is it? I see conditions that could happen accessing the vector.

[amadmonk]

It's not thread-safe. Of course, for the most part, WoW's Lua engine isn't thread-safe either, so... it's not a huge loss.

For an example of why it's not thread safe consider:

1. WoW uses a global Lua state object. It's stored in a static and fairly easy to look up.
2. You can have Lua processing at almost any time in the render thread (not just during EndScene). I've discovered this to my dismay.

When you're processing a Lua call in another thread, and you're in between the evaluation of the call and the return of the result to your function, and the render thread signals a framescript event (which uses the global stack), Very Bad Things happen.

So, in general, I think it's safe to say that WoW's Lua engine is not threadsafe. Some people get away with calling it from another thread, but they're just lucky. Do it hundreds of times a second and you'll very quickly trap.

[tanis2000]

I agree with madmonk. I've been using LUA calls extensively in my bot lately and it's almost impossible not to end up crashing the client if you call LUA functions at a high rate.

Have you ever found a way to solve this issue madmonk?

[Xarg0]

if you're worring about thread safty create a lock around the vector or something, no one prohibited you to change the code as you like
It's public domain so you can use it however you want

[amadmonk]

I agree with madmonk. I've been using LUA calls extensively in my bot lately and it's almost impossible not to end up crashing the client if you call LUA functions at a high rate.

Have you ever found a way to solve this issue madmonk?

Sadly, no. Namreeb and I toyed with the idea of using a custom Lua state, but I'm not sure that this is safe (from a Warden point of view) or feasible (the "constructor" for the Lua state is fairly complex, when you flush out all of the call trees).

So unfortunately, it appears that we're stuck just trying to not call Lua outside of the bounds of the render thread's EndScene.