The not-so ghetto way of getting ILuaInterface across states - CStateManager

Garry added a new function at some point to the undocumented CLuaShared interface in lua_shared.dll. This function is called GetLuaInterface and takes a uchar id as an argument.

What this means is that we can now get access to the client, server, or menu state from any module on any state without having to hook onto any ILuaInterface functions.

This means that client modules can access the menu state and menu state modules can access the client state freely, without any hooks that may break between updates.

I wrote a basic wrapper class called CStateManager. This class can replace Lua() and the lua_State* info given to you when the module loads.

Note: The client and server interfaces don’t exist until the game loads. Always check to see if client or server are NULL if you are trying to access them at a time where they may not be active.

Download the class here: V1

If your name is Garry Newman, please don’t break this function just because you can, thanks

I agree.

looks like sethhack has a new way of hooking interfaces

looks like someone is trying to derail a thread

What do you mean by “new”? This is not a new function.

This function didn’t exist during the time where mac binaries were first released


I see that function in the bins from March, perhaps nobody bothered to check?

I’m sure it was added when ToyBox was released… Probably for toybox.dll to have access.

It’s new because no one posted about it and I just bothered to check.

Ty been waiting for so long.

Even if you load the module with this, you’ll need to still bypass ScriptEnforcer.


To include files, it will say that script enforcer is enabled even if its from a module.

Scriptenforcer doesn’t block modules! :downs: Load from menu state

you must be retarded, you can’t load his module with this, its impossible because this is a c++ wrapper seth would have to recode and recompile his module using this, it was a joke more then anything, learn what you are talking about before you speak.

[editline]7th August 2011[/editline]

ScriptEnforcer does essentially TRY to block modules, by stopping lua files you can’t require. This is why the sqlite exploit came around.

ScriptEnforcer only blocks lua_run_cl, lua_openscript_cl, and include() in lua, modules.

You forgot the part where it stops entire files from loading

It doesn’t matter if it stops your precious faphack from loading, you can initialize modules in menustate.

I know, infact I have coded several modules that load from the menu state, I understand how it works(and most certainly do not need faphack). I am trying to explain to Gfoose really, that this is a c++ wrapper, not lua, and you can’t actually change the SethHack module to use this without recoding and recompiling like he seems to think against.

Why would Seth want to use something like this when his existing system seems to work without problems?

Yes Seth, why would you?

That’s not the point, I am just trying to show that Gfoose is dumb and doesn’t really know what he’s talking about.