tempLineTrigger help

Post Reply
chazz
Posts: 3
Joined: Fri May 27, 2022 8:35 pm

tempLineTrigger help

Post by chazz »

Hello,

tempLineTrigger appears to fire once and then disables itself.

For example

Code: Select all

tmp_trig = tempLineTrigger(1, 3, function() print(" trigger matched!") end)
After the trigger fires, it will no longer trigger and disableTrigger(tmp_trig)/enableTrigger(tmp_trig) both return false - even though display(tmp_trig) returns the id of the trigger. How do I keep it from being destroyed/disabled, as described here:

"The function returns the trigger ID for subsequent enableTrigger(), disableTrigger() and killTrigger() calls. The trigger is temporary in the sense that it won't stay when you close Mudlet, and it will go off multiple times until you disable or destroy it."

?

expireAfter parameter also appears to not work as well.

User avatar
demonnic
Posts: 884
Joined: Sat Dec 05, 2009 3:19 pm

Re: tempLineTrigger help

Post by demonnic »

It seems to be working for me.
tempLineTrigger.png
the longer first line is line 0, it fires on lines 1-3 (the next 3 lines), and then does not on line 4.

chazz
Posts: 3
Joined: Fri May 27, 2022 8:35 pm

Re: tempLineTrigger help

Post by chazz »

demonnic wrote:
Wed Jun 01, 2022 4:06 pm
It seems to be working for me.

tempLineTrigger.png

the longer first line is line 0, it fires on lines 1-3 (the next 3 lines), and then does not on line 4.
Thanks for the reply.

In your example, what happens when you call enableTrigger(tg) after it has fired? Where did the trigger go? :cry: Try using the expireAfter parameter, and try returning true to keep the templinetrigger from disappearing - neither of them work.

User avatar
demonnic
Posts: 884
Joined: Sat Dec 05, 2009 3:19 pm

Re: tempLineTrigger help

Post by demonnic »

I'm not sure tempLineTriggers have an expire after, though I see one listed in the docs. It doesn't make sense in this case, as it's literally a trigger whose only purpose is to fire on lines X through Y. It already self-expires, unlike other temp* trigger types which did not ship with expireAfter functionality.

You're not really meant to enable/disable them, but rather create them when needed and kill them if you need to bail from them prior to the howMany line being reached. Then you make a new one the next time you need one.

I think it's possible the docs were updated when expireAfter was added to the rest of the temp*Trigger types and shouldn't have been, though I'd need to check the code/hear from one of the c++ devs involved with the expireAfter change to say for sure.
tlt-usage.png

chazz
Posts: 3
Joined: Fri May 27, 2022 8:35 pm

Re: tempLineTrigger help

Post by chazz »

demonnic wrote:
Thu Jun 02, 2022 5:04 am
I'm not sure tempLineTriggers have an expire after, though I see one listed in the docs. It doesn't make sense in this case, as it's literally a trigger whose only purpose is to fire on lines X through Y. It already self-expires, unlike other temp* trigger types which did not ship with expireAfter functionality.

You're not really meant to enable/disable them, but rather create them when needed and kill them if you need to bail from them prior to the howMany line being reached. Then you make a new one the next time you need one.

I think it's possible the docs were updated when expireAfter was added to the rest of the temp*Trigger types and shouldn't have been, though I'd need to check the code/hear from one of the c++ devs involved with the expireAfter change to say for sure.

tlt-usage.png
The development branch, at least, has expiry count for temp line triggers:
https://github.com/Mudlet/Mudlet/blob/d ... .cpp#L7477

I can see how temp line triggers have mIsLineTrigger set to true via TLuaInterpreter::startTempLineTrigger, which causes TTrigger::match to mark them for deletion. I am not sure why giving the garbage collector something to remove is advocated so much. :?

Thanks anyway, though, I'll just avoid using them.

User avatar
Vadi
Posts: 5035
Joined: Sat Mar 14, 2009 3:13 pm

Re: tempLineTrigger help

Post by Vadi »

I've removed it from the docs and we'll remove the no-op argument (as it had no effect right now anyway) from a future version in Mudlet. Backwards compatibility is our promise in Mudlet and given how nobody found this for the last 4 years - plus the fact that it had no practical effect in scripts - I think this is a fine change that we'll be testing out in PTBs shortly.

Thanks for raising this!

Post Reply