On a second thought, pushing/popping like that would be a bad idea. Then someone could afflict you and illusion you curing that affliction, resulting in trouble.
But any problem can be solved by making its solution more complicated :) Create a third table with "action names" as keys and function as values. These functions would be called whenever one of the "action" patterns matches. For afflictions and their cures you'd need only one such function, as long as you choose the naming scheme wisely. Supposing that you store afflictions in a table "afflicts" and name afflictions "affl_name" and cures "cure_name", such a function could look like:
function (name)
local t = utils.split(name, "_")
if t[1] == "affl" then
afflicts[t[2]] = false
elseif t[1] == "cure" then
afflicts[t[2]] = true
end
end
Then a function for saving/removing afflictions - presuming that the stack table is called "stktab", and you name your affliction/cure triggers the same way as above (for simplicity's sake) - would be:
function (name,...)
local t = utils.split(name, "_")
if t[1] == "affl" then
if not afflicts[t[2]] then
table.insert(stktab, name)
afflicts[t[2]] = true
end
elseif t[1] == "cure" then
if afflicts[t[2]] then
table.insert(stktab, name)
afflicts[t[2]] = false
end
end
end
That would basically push messages for both afflictions and cures, leaving you with the task of preventing the stack from bloating up with values, which task can be fairly easily solved by limitting its length. I think PIL has examples of doing that.
The rest of the mechanics remain the same: the multiline trigger still calls a function that parses the captured lines, only when a match occurs it would pop the value and use the name to call the function saved in the third table. |