No idea why rust is doing this... I can't even import printgm!... Oh well, I guess it isn't necessary for the project so I'll just leave an issue here for now. Of course it'll need to be resolved by the time I bother to get this on crates.io.

Maybe Engine, Lua State, etc can be unified into one "Gmod" state object. I don't know the extent of proc-macros but I hope this can happen.

Example clientside binary module

use rglua::prelude::*;

// Either #[rglua::open] or #[rglua::open(interfaces..)]
// In this case, it tries to load the engine interface to add functions like is_connected
// Additionally maybe it can return a result?
#[rglua::open(engine)]
fn start_module(g: Gmod) -> i32 {
    printgm!(g, "{}", g.is_connected());
    0
}

#[rglua::close]
fn close_module(g: Gmod) -> i32 {
    0
}

Like lua_getglobal

Need to look into this, functions like IsInCommentaryMode just crash.

Might want an alternative that returns "" instead of panicking or see if there's a better way to go about it. Right now there's way too many crashes from it and I don't really know why.

Has much less dependencies I think & we don't need all of the extra stuff that dlopen provides.

Something like

#[lua_hook("Think")]
fn think() {}

Which would be called inside gmod13_open, would register a hook like:

hook.Add("Think", "module." .. file!() .. ".rs", think_fn)

This is on crates.io now so it's kinda redundant and spams the gitlog. Also takes up CI time

Not sure if lua would handle panics properly. Need to test, if it does then it can stay how it is, otherwise it should be changed to use lua_error / luaL_error

Make a ThreadHelper struct to pass a LuaState between threads using Arc and Mutex

Allow functions without return values to be used as lua functions or entrypoints. Just return zero in the outer exposed function.

Only attempt to find lua_shared with a .dll extension in the wrong locations.

Use: https://github.com/danielga/garrysmod_common/blob/9981d4aaee15452a9b0f53436c1aa807f81f3fd6/lua_shared/source/LuaShared.cpp#L49

Should be pretty easy to do with std::panic::catch_unwind and std::panic::set_hook.

This is sort of related to #10, although instead there it openly .unwrap()s so it is our fault that it kills the program.