I find object-oriented syntax to be oftentimes more readable, but the reason I ended up making this package is much more practical. When creating "temporary", i.e. dynamic Mudlet triggers and timers I found it very annoying that they keep hanging around even when I do not need them. I was more than once buried in the avalanche of responses from a bunch of identical triggers
Luckily, I thought of a way to properly garbage-collect them when no longer in use, which I think is the main functional advantage of using this library as opposed to native API. It relies on a feature introduced in Lua 5.2 which I think is reason enough to ponder moving to 5.2, but that's another story. Fortunately there is an undocumented bit put into Lua 5.1 that allows for a workable kludge (see __gc.lua shared library available from luarocks). Another useful enhancement of this library is that it keeps track of enabled/disabled state of the timers and triggers.
ENABLING THE LIBRARY:
Adding the line above should be enough as long as the "MLObj.lua" and "__gc.lua" files are visible to Lua (for example, are in the profile directory).
DEFINING A TIMER:
Code: Select all
-- defining all the parameters of a Timer object
timerDef1s = {
timerLabel = "my 1 second timer",
interval = 1.0,
code = function() echo("Another second passed!\n") end,
repeating = true
}
timerLabel (and triggerLabel below) are ways to keep track of the objects in a human-readable and searchable way. Labels are not required to be unique, but it could help when keeping track of the objects. In present form the library keeps a list of the timer/trigger objects that are created through its code, and there is a way to search that list. I see this as a debug feature that may fade away, or kept, depending on how useful it is.
DEFINING A TRIGGER:
Code: Select all
-- supported trigger types: SUBSTRING, REGEX, PROMPT, LINE, EXACT, HEAD, COLOR
-- unsupported: COMPLEX (the code is commented out because I saw some issues with underlying Mudlet API mentioned)
triggerDef2 = {
triggerLabel = "Super useful trigger from levitation module",
triggerType = "REGEX",
regex = "^Some regex to (fire|FIRE) the trigger on$",
code = function() echo("Something super useful just happened...\n") end,
-- if the definition table doesn't have "expireAfter" defined in it,
-- the trigger is understood as perpetual, it will exist until disabled/deleted
expireAfter = 100,
}
I was actually debating if it makes sense to include support SUBSTRING, EXACT and HEAD types. After all, their functionality is easily covered by REGEX type trigger. Maybe supported but discouraged?
CREATING TRIGGER AND TIMER
Code: Select all
timer1s = MLObj.Timer:new(timerDef1s)
triggerSuper = MLObj.Trigger:new(triggerDef2)
SEARCHING EXISTING TRIGGERS AND TIMERS
Code: Select all
trigList = MLObj.Trigger:getList("^Super")
-- trigList now contains a table of all trigger labels that start with the word "Super", indexed by their triggerid
This could be useful for debugging, especially if one has some sort of convention for trigger labels. For example, all triggers from the same logical code portion could share same prefix in their label string.
ENABLING AND DISABLING
Code: Select all
timer1s:enable() -- enables the timer
triggerSuper:disable() -- disables the trigger
CHECKING ON ENABLED STATUS
Code: Select all
if triggerSuper:isEnabled() then
echo("Super trigger is watching you!\n")
end
DELETING
Code: Select all
-- triggerSuper will be killed and deleted in the next garbage collection cycle
triggerSuper = nil
-- if one needs to incapacitate the object immediately, use :disable, like this
timer1s:disable()
timer1s = nil
-- Mudlet object existence has the same scope as the variable that references it
do
local sometimer = MLObj.Timer:new(sometimerDef)
...
...
end
-- the timer created by code will disappear shortly after the block execution