Replies: 3 comments
-
Unfortunately, this isn't something I'm willing to add, for a variety of reasons. I'm willing to link to your fork from the tintin webpage, though you'd probably want to update the README with some information for people to get started. |
Beta Was this translation helpful? Give feedback.
-
I'm curious what those reasons are. Not that you have to defend not wanting to add it or anything like that, that's perfectly understandable, but just in case they're useful to know as I work on adding it for myself anyway. It's still pretty unstable, I even managed to find a few major issues since writing the original post, so it might be good to hold off on linking it until I've had a chance to iron it out a bit more. Thanks though! Once it's a bit more stable, besides filling in the README, I'd probably also want to write some examples of using the Lua side of things. I'll be happy to update you if/when it reaches that point. |
Beta Was this translation helpful? Give feedback.
-
For similar reasons that mudlet doesn't add tintin scripting, even if they should. 😛 Will be interesting to see some example scripts once you got them ready. |
Beta Was this translation helpful? Give feedback.
-
I wrote a patch that adds optional Lua 5.1 support over here.
The focus was on getting Lua and tintin++ ways to communicate, rather than to re-implement all of tintin++ scripting in Lua.
As a result, mostly of the Lua API was written to retrieve information or to set hookpoints to call Lua functions. For example, you still need to call the tintin++ commands to remove nodes (e.g.
tt.exec("#unaction", match)
) or to create/update map-related stuff.All triggers have been updated to handle Lua functions, but otherwise the changes to the core tintin++ code was pretty minimal. This is intentional to hopefully make it easier to keep the patch in sync with the core tintin++ code, since I plan to use it, and touching the core tintin++ code would make it harder to merge in any upstream changes. This also means there's a fair bit of redundant code in the Lua modules, because I essentially rewrote what the tintin++ equivalent commands did but for Lua, to avoid overly touching the tintin++ side.
I chose Lua 5.1 specifically, partly to support LuaJIT, and partly because the ability to set environments to threads allowed me to have different sessions have a shared Lua state while having differing environments and threads. This was necessary to keep the copy behavior from gts to newly opened sessions without them all just straight up sharing the same environment, which I thought went against the spirit of tintin++'s overall design. It also serves as a happy medium for allowing different sessions to communicate on the Lua side of things.
One thing I noticed while doing this work was that there are no
const char*
arguments in tintin++'s code despite many functions havingchar *
arguments they don't touch. I think changing this might have some benefits, because all the strings coming out of Lua areconst char*
, presumably due to Lua's string internment. For now, I'm copying them into stack strings (str_alloc_stack()
), which is probably good enough for a patch. I hesitantly added one in the patch tostr_cpy()
just because the only thing it's internally calling isstrcpy()
, but I didn't want to do any more than that.If you want to try it out,
./configure
now supports a few extra options:LUA=luajit
or whatever to specify which Lua library to use (it checks for the existence oflua_setfenv
so it won't let you accidentally use Lua 5.2+).--with-lua
to tell it you want Lua, in which case it'll fail if it's unable to figure out how to get it for you.--without-lua
to prevent it from compiling in Lua functionality, even if you have it available on your system.--include-dir=<path>
to point to the correct includes.If you don't pass in
--with-lua
or theLUA
environment variable, it will default to compiling in Lua support if it finds 5.1, and not compiling it in otherwise. The added#LUA
command will still exist, but only#lua check
will work properly.I've also added in the very barebones
#PROCEDURE
and#CALL
commands into this patch as a way of allowing tintin++ to call Lua functions directly. Aliases could already be used for this purpose, but I think it's a bit cleaner this way, since you can avoid clouding user input. Of course, they also support running tintin++ scripts, even if the main purpose for adding them is tintin++ to lua communication.If it looks like an interesting addition to tintin++, I'd be happy to help with any issues there.
Although I did a fair bit of local testing, I really can't guarantee there aren't major bugs or crashes in the patch, so use it at your own risk. The various Lua stuff can be found at
#help lua
,#help tt api
,#help map api
, and#help lua getters
.Beta Was this translation helpful? Give feedback.
All reactions