This topic contains 20 replies, has 5 voices, and was last updated by  Samah 2 years, 10 months ago.

Viewing 15 posts - 1 through 15 (of 21 total)
  • Author
  • #1638


    So I wrapped Lua already, because I’m a fanboy.

    At the moment it’s just raw externs, so you kinda have to know the C API. A very simple example is included.
    Next step is to create some object-oriented wrapper classes to make it ezmode for developers.

    Only tested on OS X El Capitan, sorry. I don’t see why it wouldn’t work under Windows/Linux, though.




    Works here on Windows. I haven’t tried more than the example, though.



    Very nice! Wondered when you would get around to this!

    Now you just need to Monkeyised the commands πŸ™‚



    Awesome !
    In “monkey2-v1.0.0\modules\lua”, I launch the command “..\..\mx2cc_windows.exe makemods lua”.
    Everything works. After a few seconds, I have a desktop_debug_windows folder in “monkey2-v1.0.0\modules\lua\lua.buildv1.0.0”. I can load the sample in Ted2 and test it with [F5] (debug) but it doesn’t works with [F6].

    HowΒ to build a the “release” version module ?

    “..\..\mx2cc_windows.exe makemods -config=release lua” in “monkey2-v1.0.0\modules\lua”

    @samah : Very good job πŸ™‚
    I will try to add the socket library and to connect to zerobrane for debugging the lua code included in the Monkey2 app. (I process this way on mono with nlua).



    Cool. πŸ™‚
    Don’t go too crazy just yet, I still need to add the userdata/metatable magic to let you do stuff like:


    It’s most likely going to be something like:
    mx2lua_registermodule(L, New MojoLuaModule)
    Which will register all the functions and classes in the mojo module.

    I’ve been really busy at the moment with Infinity Evolved Expert. πŸ˜‰

    Edit: If you want to contribute, fork and make a pull request.
    Edit 2: Adding full debug support is non-trivial, since you’ll have to hook up all of the lua_Debug functions. They’re externed, but it’s not as simple as just switching it on.



    I will stay tuned πŸ™‚
    If I make signifiant progress, I will post comments (or ask for some help).



    Please Monkey-ize the API I would love to have a play !!



    I’ll set aside some time this weekend to get heavily into wrapping the core libraries and/or simplifying the Lua API for the less savvy amongst us. I just want to be careful how I implement it so that it’s as lightweight and extensible as possible.

    Edit: Just pushed some changes that let you push/pop MX2 structs and classes. It’s not at a scriptable stage yet, but it’s well on the way. πŸ™‚




    Have you tested using an extra lua script yet and reload on the fly?



    @therevills: That’s a while off, yet. There’s a lot of magic bridging I’d like to get working first. For example, I want tables to act as if they were MX2 containers. I should be able to index a Lua table and have it pass through to MX2 List[index], or Map[key]. I’m not sure how to handle mapping generics in that case, though.

    Mapping the existing MX2 modules is a huge task, and a little unnecessary at this stage. The primary reason for embedding Lua is to add scripting to your game logic (enemies, bullets, GUI, etc.), not to run your full Mojo game loop.

    I can only ezmode the embedded interface so much, though. At some point the developer will need to know how to bind objects. Just executing some Lua won’t do much for you.



    The primary reason for embedding Lua is to add scripting to your game logic (enemies, bullets, GUI, etc.),

    Thats what I’m after πŸ™‚



    WIP of a slightly more Monkeyish API, but still a ways to go (yuck at all the required pointers!)
    There’s now a LuaState class that wraps lua_State Ptr and makes it a little more object-oriented. However, you still need to call LuaState.NewState to create a new state rather than New LuaState. The reasoning behind this is that since function pointers still need to match Int(lua_State Ptr), you can use New LuaState(L) to avoid using the raw C functions.

    Short-term Roadmap:

    • Finish wrapping the C functions
    • Make it less verbose to push/pop MX2 objects and structs
    • Wrap the Lua table data type
    • Metatable black magic to allow back and forth mapping of methods/fields/functions when manipulating MX2 objects and structs in Lua
    • Bind Lua tables to MX2 Lists and Maps?

    Long-term Roadmap:

    • Introduce an easy way of binding full modules
    • Debug support
    • More to come?


    You can now execute scripts (use DoString(LoadString("asset::file.lua")) rather than DoFile, for now). Objects and structs will have a magic metatable assigned to them by default, but at the moment only objects can get/set fields. I’m having some issues trying to manipulate structs with an interface.

    Defining GetField/ SetField is a little verbose at this point, but eventually this should clear up if/when we get reflection. I’m using void pointers in the interface to avoid method generics at this stage.

    I’ll doc and zip and upload for the module manager at some point.




    When I download mx2lua via the GitHub zip link, the native/luadist is empty? Is it because you’ve directly linked to the Lua project instead of copying to your project?

    I would guess if they changed their code it might mess up your project… might be safer if you copy the current version of Lua into native/luadist and update it when needed.



    It’s linked as a git submodule, which also includes the commit hash. Even if they change something, it will still point to the same version.

    Edit: Technically I could grab the “pure” source from, but I like being able to link to it. I don’t think luadist is maintained by the Lua devs, but it seems to have the official source. If there are ever problems I’ll copy/paste it from, but for now it works.

Viewing 15 posts - 1 through 15 (of 21 total)

You must be logged in to reply to this topic.