mudlet trigger - lua function type

Caled

It's been too long since I used these, and I can't get them to work beyond just the basics, and I can't find any of my old scripts that did it. The mudlet manual is pretty vague when it discusses them. So.

I wish to monitor a simple variable. True/False, running the triggers script when there is a change in the value.

Pattern 1, lua func type:&nbsp; return testvar<br>Pattern 2, lua func type:&nbsp; return not testvar<br>Trig options: default (i.e. this is an OR type trigger)<br><br>Script:<br>echo(tostring(testvar))

Very simple. The actual script will set the CSS of a label, giving me a toggle style button that displays some information, without requiring me to delve into someone else's code (say I am using wsys, svof or trex - at the moment I am leaning more toward wsys for its simplicity). If I can get the above to work, then I can use more complex expressions as well, and easily monitor how/what these other scripts are doing.

I've tried various connotations of 'return testvar', such as
return true testvar
if testvar then return true end

etc

Also, my testing has been with a single pattern, forgetting the OR part - figured I should get a single one working first.
But it won't fire...

Caled

Never mind.

if testvar then return true end<br>

did actually work, not quite sure what I did wrong the first time I attempted that version. 

Vadimuses

if you could improve the wiki with an example, that'd be great

Caled

Bugger - you got me. I'll look into it once I've figured out more of the ins and outs of this trigger type.

Caled

While I have these working:





I had forgotten that the expressions are only tested on each line from the mud, which means that these work okay, but I also can't say I particularly like them. If I change a setting with an alias, the label doesn't reflect the change immediately. Not an issue when actively doing stuff in the mud, so easy to put up with, but at the same time I'd love a more elegant solution.

I am essentially looking for the equivalent of the ability to raise an event when the value of a specific variable changes. I don't care what it changes to or from, I just want to monitor it, and the moment it changes, run a function of my choosing. 

So if anyone knows of a better way for me to do this, please let me know!

@Vadimuses
(fyi the recaptcha for the mudlet wiki is either broken or beyond ridiculous. I have given up for the time being, apologies). 

[Deleted User]

You can just make your alias send a blank line.

send(" ",false)

Caled

Pyori said:

You can just make your alias send a blank line.

send(" ",false)

Right. Although, I could also have the alias directly invoke the live feedback, so I guess that without context my question doesn't make sense.

I'm creating a 'button' bar that can be easily added to anyone's system, and (easily) configured to monitor (and set) variables belonging to other scripts in that system, without modifying the scripts themselves.

I currently have it abstracted to the point where adding a clickable button to monitor a config setting for Wsys is as easy as adding one item to a list, and creating the one trigger (in my screenshot above). It isn't system independent yet, but I intend it to be eventually, and then I'll share it.

Keneanung

I am currently not sure about the details, but I guess you could use metatables to monitor access (and thus inserts and updates) to a table: https://www.lua.org/pil/13.4.4.html

Atalkez

Huh, does this trigger setup fire without the need to fire off prompt? I’ve never seen code done like that.

Keneanung

Lua triggers are the least performant type of triggers and are run completely on every line. So they should be used sparingly (and you usually can do without them, now that we have real "Prompt" triggers and don't need lua triggers for that).

Vadimuses

Yeah - try benchmarking the setup to see if it scales.

Antonius

Atalkez said:

Huh, does this trigger setup fire without the need to fire off prompt? I’ve never seen code done like that.

Technically you have, since every prompt trigger prior to Mudlet 3.6 (and the addition of the separate "prompt" trigger type) used the Lua function type. Just in that case the check being run on every line of output was "Is this line a prompt?" If the check succeeded, the pattern passed and the trigger executed its code. If the check failed, the pattern failed and the trigger didn't execute its code.

@Caled Monitoring Lua variables directly isn't possible. It's possible for tables - as mentioned by Keneanung - but you'll quickly run into the issue that a lot of script authors for Achaea don't understand tables, and therefore don't use namespacing (the original version of Wundersys had this problem). Using individual Lua function triggers for every option you care about is also going to be a scalability nightmare.

I'd suggest you ditch the triggers entirely and use a timer that runs on a short interval - you could probably get away with once every second, though could likely make it faster than that without a noticeable effect on performance (I'm just not sure it would be necessary) - and checks all of the settings you're interested in against previously stored values, updating buttons as required.

Caled

Thanks for all the replies. I'm a little sad to hear about the lower performance of function type triggers. If I were to do a single prompt trigger, and then a series of if statements, would that result in the same or better performance? Or is that something I should try and benchmark myself?

A nice article on tracking with metatables, Keneanung, thanks. I tried to wrap my head around metatables a few years ago, and failed, but that article makes a lot of sense so I'm going to revisit them now. 

 I can imagine using that tracking to:

1. manage sipping, if we did not have server-side sipping
2. Create events on changes to specific gmcp data there is not already events for

I can't imagine WHY I'd need to do those things that way yet, but that's not the point


Out of curiosity, comparing classes in python to metatables in lua - metatables can be used to achieve a similar result, even though they aren't strictly the same thing. Is that correct? Geyser.Label:new(), for example, seems to behave similarly to instantiating a class in python, and I'm assuming that's how we're meant to do that kind of thing?

Having started using python at a level somewhere between basic and intermediate for work, I'm finding that knowing a bit of lua helped me a lot when learning python, but now going back to lua I'm getting stuff mixed up.

Keneanung

Having a prompt trigger with ifs is definitely faster.

One thing to know about the tracking solution is, that you can't use pairs/pairs on them, so they are not universally usable.

gmcp events are generically created from the gmcp modules, so they are accounted for.

I can't say anything about python, but lua metatables are very similar to javascript object prototypes and don't really have much in common with classical OOP.