Welcome to the Achaea Forums! Please be sure to read the Forum Rules.

mudlet trigger - lua function type

CaledCaled Posts: 77Member ✭✭ - Stalwart
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:  return testvar
Pattern 2, lua func type:  return not testvar
Trig options: default (i.e. this is an OR type trigger)

Script:
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...















Comments

  • CaledCaled Posts: 77Member ✭✭ - Stalwart
    edited February 22
    Never mind.

    if testvar then return true end

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

  • VadimusesVadimuses Posts: 1,091Member @ - Epic Achaean
    edited February 22
    =) if you could improve the wiki with an example, that'd be great
    Caled
  • CaledCaled Posts: 77Member ✭✭ - Stalwart
    Bugger - you got me. I'll look into it once I've figured out more of the ins and outs of this trigger type.
  • CaledCaled Posts: 77Member ✭✭ - Stalwart
    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). 

  • PyoriPyori Posts: 987Member ✭✭✭✭✭ - Grand Achaean
    You can just make your alias send a blank line.
    send(" ",false)


  • CaledCaled Posts: 77Member ✭✭ - Stalwart
    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.


  • KeneanungKeneanung Posts: 596Member ✭✭✭✭ - Eminent
    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
  • AtalkezAtalkez Posts: 4,771Member @@ - Legendary Achaean
    Huh, does this trigger setup fire without the need to fire off prompt? I’ve never seen code done like that.


    You hug Aurora compassionately.
  • KeneanungKeneanung Posts: 596Member ✭✭✭✭ - Eminent
    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).
  • VadimusesVadimuses Posts: 1,091Member @ - Epic Achaean
    Yeah - try benchmarking the setup to see if it scales.
  • AntoniusAntonius Posts: 4,625Member @@ - Legendary Achaean
    edited February 23
    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.
    KeneanungVadimuses
  • CaledCaled Posts: 77Member ✭✭ - Stalwart
    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.

  • KeneanungKeneanung Posts: 596Member ✭✭✭✭ - Eminent
    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.
Sign In to Comment.