Speculation: inject LUA?

[Cypher]

Nice... that was fast. Gotta love those DX libs

It'll be interesting to see how easy it is to inject your own cfuncs, and whether/if you can interact smoothly with WoW's LUA. I wonder if you can make a semi-generic hook framework for your LUA scripts?

Currently I'm not interfacing with WoW's LUA interface. It's totally my own.

First I want to expose my entire API so I can infact do what you're suggesting and have a 'hook framework' available in LUA. That's the easy part, and is more on the 'time' side of things than 'effort'.

I mainly want LUA so I have a command interpreter for my console and I can run quick and dirty scripts to test code, game extensions, etc.

As far as interfacing with WoWs lua, its not something I'm currently looking at. I might do that as part of a WoW extension for my framework, but it obviously can't be part of the framework itself because that needs to be generic.

P.S. x64 support for LUA too!

[amadmonk]

You have some serious goals there. I've been contemplating about Wine, seems like it would be a fun project. Bit rusty with my unix though... I'm going to make a API(similar to WoW's, but with functions that are actually USEFUL) in Lua. Been waiting for an idea, and this seems feasable

I like to keep my plate full, especially with things that stretch (or exceed) my limits. Otherwise, how else will I grow as a coder? My day job (technically as a programmer, but in reality mostly a trained monkey) certainly doesn't stretch me much.

90% of my tasks I'm sure I'll never complete, but that's not the point. The Wine one is interesting to me just because Wine -- in theory -- lets you do all the stuff that a Windows kernel rootkit can do, without having to play in the kernel (which is a pain in the ass).

[amadmonk]

Currently I'm not interfacing with WoW's LUA interface. It's totally my own.

First I want to expose my entire API so I can infact do what you're suggesting and have a 'hook framework' available in LUA. That's the easy part, and is more on the 'time' side of things than 'effort'.

I mainly want LUA so I have a command interpreter for my console and I can run quick and dirty scripts to test code, game extensions, etc.

As far as interfacing with WoWs lua, its not something I'm currently looking at. I might do that as part of a WoW extension for my framework, but it obviously can't be part of the framework itself because that needs to be generic.

P.S. x64 support for LUA too!

Makes sense. I'm not playing any other games right now, so a generic framework isn't as interesting to me, but I can see why you'd want to keep things loosely coupled.

Of course, the beauty of a loose-coupled language like LUA is that unless you write the couplings in C(++), you never have to worry about ripping out one game-specific LUA module and replacing it with another, as long as the interfaces have duck-compatible types.

[amadmonk]

P.S. x64 support for LUA too!

Oh, almost forgot -- be careful of this last one. I'm not sure if it was a LUA thing, or if I had a 32-bit LUA embedded in my C# app (LuaInterface rocks, btw, for anyone wanting to host LUA in C# -- which, incidentally, makes an exceptionally nice out-of-process bot framework), but I had serious problems with 64-bit values; LUA wanted to truncate them to 32-bits. In LuaInterface I was able to get around this by boxing them in objects, but it was a pain and leaned me away from trying to do my packet parsing in LUA.

Just a suggestion: test to make sure that 64-bit values work properly before you get too deeply invested in a 64-bit LUA host

[Cypher]

Oh, almost forgot -- be careful of this last one. I'm not sure if it was a LUA thing, or if I had a 32-bit LUA embedded in my C# app (LuaInterface rocks, btw, for anyone wanting to host LUA in C# -- which, incidentally, makes an exceptionally nice out-of-process bot framework), but I had serious problems with 64-bit values; LUA wanted to truncate them to 32-bits. In LuaInterface I was able to get around this by boxing them in objects, but it was a pain and leaned me away from trying to do my packet parsing in LUA.

Just a suggestion: test to make sure that 64-bit values work properly before you get too deeply invested in a 64-bit LUA host

Will-do. Thanks for the heads up.

[Cypher]

Amadmonk, you've gotten me curious now.

How would you go about 'unifying' WoWs Lua setup and a custom Lua setup? Is it a reasonable feat or is it just to big and messy a job to pull off? I don't have much experience with Lua (what I'm doing now is pretty much my first experience) so I figure you might know better.

[Shynd]

Couldn't you, in the same way you enumerate WoW's LUA exports, run through the same function(s) that register all of those callbacks and register them all to your own Lua_State? Seems to me that something like that should be possible.

[amadmonk]

Cypher, you probably actually know this better than me, BUT, from what I understand, the entire LUA state (inc. call stack, globals and locals, and so on) is maintained in the state object. So, if you could intercept LUA calls into your own LUA, you could just (in your C(++) code) swap in the game's lua_State for your own, and then your LUA code should (in theory...) run as if it was in the WoW LUA context.

I'm not sure how the cfunc bindings play in this (in other words, are the bindings to the cfuncs part of the state object? If so, that might be interesting... you could dynamically intercept and swap out cfunc calls with your own "sanitized" or even "augmented" ones).

What this would gain you, aside from easier parsing of LUA globals and function parameters, I'm not sure.

(Edit: on further consideration, you wouldn't need to inject LUA just to monkey with the state object; it could be done purely in C(++). However, there are additional benefits to just having your own script engine...)

[Cypher]

Lua_Register is actually a macro:
http://pgl.yoyo.org/luai/i/lua_register

So yes, it is relative to the LUA state. It's stored in a global table. I think....

Obviously the main benifit of your own Lua engine is that you effectively bypass any stack traces done on Lua funcs. It would be pretty easy to throw a stack trace on FrameScript__Execute and catch most of the bots out there. If you have your own engine though you're safer.

[amadmonk]

Oh well then, there ya have it -- if even the cfuncs are just registered globals, then the lua_State rolls up the entire state of WoW's LUA at the time you yank it. What you could do with that state is really only limited by your imagination, I guess (modify the LUA stack? read/tweak globals?). In theory, you could hijack existing LUA functions (say the spell log stuff, or something), and "mark up" the results with additional info not normally available in-game.

In the end, it's not anything you couldn't do from C(++); you can intercept LUA calls from C++, you can poke memory values to your heart's content from any of a dozen languages, but ultimately it's got to be a helluvalot easier to manipulate LUA language constructs from within LUA. And it might be simpler to avoid some Warden checks this way.