Register forum user name Search FAQ

Gammon Forum

Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the password reset link.
 Entire forum ➜ MUSHclient ➜ Suggestions ➜ Getting the currently-executing trigger/alias/timer
Getting the currently-executing trigger/alias/timer

It is now over 60 days since the last post. This thread is closed.     Refresh page

Pages: 1 2  

Posted by Twisol   USA  (2,257 posts)  Bio
Date Tue 13 Jul 2010 04:49 AM (UTC)
Message
Script callbacks for triggers/aliases/timers currently receive the label of the associated trigger/alias/timer, but there is no such functionality when using the Send box (or I haven't found it yet). The line-highlighting library I'm working on could really really use this to automate certain parts of the script, like determining the most reliable sequence numbers to use.

Clearly, the benefit wouldn't be to the trigger itself, but rather to functions it calls which need information about the trigger.
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
Top
Posted by Nick Gammon   Australia  (23,120 posts)  Bio   Forum Administrator
Date Reply #1 on Tue 13 Jul 2010 07:36 AM (UTC)
Message
I've added it to triggers and aliases, as %N (name of thing).

Timers don't currently have %-expansion, and I am reluctant to add something that may break existing timers (where something like %N in a timer will now have a different meaning).

In any case, probably it is more useful in triggers or aliases.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Twisol   USA  (2,257 posts)  Bio
Date Reply #2 on Tue 13 Jul 2010 08:03 AM (UTC)
Message
Yeah, probably. Thanks!
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
Top
Posted by Twisol   USA  (2,257 posts)  Bio
Date Reply #3 on Tue 13 Jul 2010 09:10 AM (UTC)
Message
You know, actually, I just realized that this doesn't do much to help here, for two reasons. One, if you're already in the Send box, you have nearly immediate access to the name just by moving your eyes down a few hundred pixels to the "Label" box. Two, %N doesn't apply to external functions called by the trigger, which is what my original suggestion was primarily aimed at. The only thing %N changes here is that you pass "%N" to my highlighter library instead of a hard-coded name, but that really doesn't save you much.
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
Top
Posted by Nick Gammon   Australia  (23,120 posts)  Bio   Forum Administrator
Date Reply #4 on Tue 13 Jul 2010 09:57 AM (UTC)
Message
It also works for triggers/aliases that don't have names in the label box.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Twisol   USA  (2,257 posts)  Bio
Date Reply #5 on Tue 13 Jul 2010 10:02 AM (UTC)

Amended on Tue 13 Jul 2010 10:04 AM (UTC) by Twisol

Message
Yes, but does it work like this?

-- library file
function foo()
  return GetTriggerOption("%N", "sequence")
end

-- in a trigger
Note(foo())


No, because the library isn't subject to the preprocessor. Hence my dilemma.


EDIT: Unrelated to the above, if you're going to mess with a trigger dynamically it's pretty much a given that it'll need a label, and using "%N" within the trigger itself doesn't save you much except not having to add one in the box that, as I mentioned, is only a couple hundred pixels below the send box.
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
Top
Posted by Nick Gammon   Australia  (23,120 posts)  Bio   Forum Administrator
Date Reply #6 on Tue 13 Jul 2010 10:26 AM (UTC)
Message 

-- library file
function foo(name)
  return GetTriggerOption(name, "sequence")
end

-- in a trigger
Note(foo("%N"))

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Twisol   USA  (2,257 posts)  Bio
Date Reply #7 on Tue 13 Jul 2010 05:33 PM (UTC)

Amended on Tue 13 Jul 2010 05:38 PM (UTC) by Twisol

Message
I still remain adamant that that doesn't provide much benefit, when you can just add a label and pass it manually. It's not like the contents of the Send box need to be generic; they're directly attached to a trigger, after all.

Ideally, the user shouldn't need to pass a thing here. Some kind of GetInfo selector would probably do just fine, probably indicating the "last trigger fired" (so long as it's set -before- each trigger is executed of course)
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
Top
Posted by WillFa   USA  (525 posts)  Bio
Date Reply #8 on Tue 13 Jul 2010 08:41 PM (UTC)
Message
You're writing a library. Stop thinking of "Users" and think of "Developers"... Coding is supposed to be more complicated than legos, that's why we've stopped playing with legos and started playing with code. It doesn't need to be baby proof.

If you're doing anything complicated enough to need a library, you shouldn't put that in the Send field. Use the script file.

If you're using the library in the send field regardless, look down 200 pixels and pass the label in as the first parameter.

Modifying a trigger while it is firing is unreliable and bad practice. Nick just fixed an issue where doing so to a timer caused MC to crash.



if BadDesign then
   SmackCoder()
end
Top
Posted by Nick Gammon   Australia  (23,120 posts)  Bio   Forum Administrator
Date Reply #9 on Tue 13 Jul 2010 09:10 PM (UTC)
Message
Twisol said:

Script callbacks for triggers/aliases/timers currently receive the label of the associated trigger/alias/timer, but there is no such functionality when using the Send box (or I haven't found it yet).
...

I still remain adamant that that doesn't provide much benefit, when you can just add a label and pass it manually.


You asked me to add something, I added it, and you complain it doesn't have much benefit. Am I missing something important here?
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Twisol   USA  (2,257 posts)  Bio
Date Reply #10 on Tue 13 Jul 2010 11:19 PM (UTC)

Amended on Tue 13 Jul 2010 11:32 PM (UTC) by Twisol

Message
Nick -
Nick Gammon said:

Twisol said:

Script callbacks for triggers/aliases/timers currently receive the label of the associated trigger/alias/timer, but there is no such functionality when using the Send box (or I haven't found it yet).
...

I still remain adamant that that doesn't provide much benefit, when you can just add a label and pass it manually.


You asked me to add something, I added it, and you complain it doesn't have much benefit. Am I missing something important here?


Yes: I asked for something and you implemented something that doesn't address the issue. I could always add a label and pass the literal text to the function, and I could (and have) done that so far. I'm asking for something that hides it altogether (i.e. via a GetInfo selector) and makes the resulting API simpler for a user (not developer, WillFa; see below) to use. I understand I might not have been clear at first.

I mean, %N works - the user doesn't need to provide a label - but I don't think it's as clean as it could be.


WillFa -
WillFa said:
You're writing a library. Stop thinking of "Users" and think of "Developers"... Coding is supposed to be more complicated than legos, that's why we've stopped playing with legos and started playing with code. It doesn't need to be baby proof.


But not everyone who uses MUSHclient is a developer. The power given to the developer makes it easier to build more expressive and functional addons, which tends to attract normal users who want the "cool stuff".

What I'm attempting to do is build a simple "highlighter" library that can be used in a trigger's Send box to paint parts of that line with different styles. This project came to mind after an Achaea player posted his method of painting a line (involving gagging and colourtells) on the Achaea forums, and then a thread here where I came up with the "gate" approach to selectively enable additional highlight triggers to do the coloring. The idea is to wrap it up into a simple API that lets you say "Lets make pie in this line red." I absolutely believe that this is something that anyone will want to use, even - and perhaps especially - normal users, which is why it should be as simple as possible.

As an aside, the actual technique isn't hard. I'm just creating one-shot triggers on demand, with the specific attributes requested. But the reason I have to do this at all is because the GUI coloring isn't expressive enough to do partial highlights; it can only apply it to the whole region matched by the line.

(The reason I need the trigger's name, FYI, is so I can get the trigger's sequence, and place the one-shots immediately after that trigger.)

<rant>

To be quite frank, I don't think much of this "who cares about complexity" attitude. The simpler something is, the easier it is to use. It makes the life of the user of the code (which could be a developer or an end-user) easier. It's all about API design, and sometimes it can and should be about puzzle pieces. Who really wants dense coupling? Why make it hard on yourself?

</rant>
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
Top
Posted by WillFa   USA  (525 posts)  Bio
Date Reply #11 on Tue 13 Jul 2010 11:45 PM (UTC)

Amended on Tue 13 Jul 2010 11:48 PM (UTC) by WillFa

Message
Your "Normal user" in this scenario needs:

To prefer lua.
Know to 'require "library"' (both how to, and that they can get it and want to)
Know to give the trigger a label in the first place (If "normal user" leaves label blank, %N or the upvalue to the 1st parameter in the calling function (btw, they're not consistently named) a GetInfo selector returning "" doesn't help you at all.


I don't know how you expect to code a library that can distinguish what needs to be colored, in what color while "Ideally, the user shouldn't need to pass a thing here."

They're going to need to pass somethings. Requiring the trigger name to be one of them isn't all that complicated.

If you're completely adamant about sparing this normal user this huge inconvenience; use GetTriggerList() to get the internal ID's of unnamed triggers (i.e. 14="*trigger9827") and make a table that's keyed on the match.


Alternatively, Nick, when sending to Script_After_Omit (another setting the Normal User will need to know to choose), TriggerStyleRuns is populated. Would it be feasible to push TriggerID at the same time?

(EDIT: Thinking about this, TriggerID accomplishes the same function as %N, and doesn't solve the script file issue of guessing what the upvalue might be named... So, never mind. )
Top
Posted by Nick Gammon   Australia  (23,120 posts)  Bio   Forum Administrator
Date Reply #12 on Tue 13 Jul 2010 11:50 PM (UTC)
Message
Twisol said:

... there is no such functionality when using the Send box ...

Yes: I asked for something and you implemented something that doesn't address the issue.


I misunderstood your request then. You seemed to be talking about something in the Send box, not something to do with a GetInfo function, when used in an external script file, that returned the name of the last trigger match. What does that have to do with the Send box?
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Twisol   USA  (2,257 posts)  Bio
Date Reply #13 on Wed 14 Jul 2010 12:03 AM (UTC)
Message
Nick Gammon said:
I misunderstood your request then. You seemed to be talking about something in the Send box, not something to do with a GetInfo function, when used in an external script file, that returned the name of the last trigger match. What does that have to do with the Send box?

Sorry about that; I probably wasn't thinking very clearly at the time. (It's an often inconvenient fact that my ideas get more fleshed out over time, but they start out in a rather sorry state.)

My logic was kind of that, I wanted the user to be able to use a library function directly from the Send box without having to provide the name or the sequence number. It's equally viable from a script callback, too, but I always figured that it would be most likely used from within the Send box. You're right, the Send box is irrelevant to the idea itself; I'm sorry that confused you.


WillFa said:
Your "Normal user" in this scenario needs:

To prefer lua.

It's the default language, and if they know enough to prefer another language, they can do it themselves. As I've said, this isn't a complex technique, but abstracting it into a simple "paint pie red" function makes it much easier for the less technically inclined. I've worked with plenty of people in the MUSHclient clan in Achaea, so I know exactly who I'm targeting.

WillFa said:
Know to 'require "library"' (both how to, and that they can get it and want to)

Not hard, because you can put it in a trigger safely. This is how the wait library is often used, from what I see.

WillFa said:
Know to give the trigger a label in the first place (If "normal user" leaves label blank, %N or the upvalue to the 1st parameter in the calling function (btw, they're not consistently named) a GetInfo selector returning "" doesn't help you at all.

Trigger callbacks return the internal label (ie. *trigger42), so a user-provided label is irrelevant.


WillFa said:
I don't know how you expect to code a library that can distinguish what needs to be colored, in what color while "Ideally, the user shouldn't need to pass a thing here."

I want to make sure that, to the greatest extent I can manage it, it's obvious what the function is doing.

highlight("pie", "red", "green")


Isn't that just incredibly simple? And the last argument can be a table providing other options like italic, bold, case sensitive, etc., so there's a lot of expressiveness there.


WillFa said:
If you're completely adamant about sparing this normal user this huge inconvenience; use GetTriggerList() to get the internal ID's of unnamed triggers (i.e. 14="*trigger9827") and make a table that's keyed on the match.

That doesn't work. It is very possible for two triggers t have the same match text, with different sequences, and if the library confuses the two, that constitutes a bug. (And quite a confusing one, at that.)
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
Top
Posted by WillFa   USA  (525 posts)  Bio
Date Reply #14 on Wed 14 Jul 2010 05:05 AM (UTC)
Message 
highlight("pie", "red", "green")


Why would a user set up a trigger to match pie, choose the UI settings, and then add scripting to do the same thing? Do this in the script file, sure, then you can addxml the whole trigger yourself.

"pie" (or even "\bpie\b"), reg ex, keep evaluating, name, sequence, the whole shebang.

Or a user can use the UI... 


<triggers>
  <trigger
   custom_colour="14"
   enabled="y"
   keep_evaluating="y"
   match="Twisol"
   regexp="y"
   sequence="100"
  >
  </trigger>
  <trigger
   custom_colour="3"
   enabled="y"
   keep_evaluating="y"
   match="tell"
   regexp="y"
   sequence="100"
  >
  </trigger>
</triggers>


Are you reinventing the wheel or something?
A regular expression of an unanchored literal will only color the literal (not the whole line).
Keep Evaluating will allow multiple highlight triggers to color (fragments of) the same line.
You can pick colors, bold, italic, underline etc right in the gui...

You can AddXML a trigger in scripting...


I'm sorry I'm sick and cranky today. Maybe this is just a Mistake of "Believing everything you read on the internet", and that the way the Achea user did it was the only/easiest way to do it.
Top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

43,862 views.

This is page 1, subject is 2 pages long: 1 2  [Next page]

It is now over 60 days since the last post. This thread is closed.     Refresh page

Go to topic:           Search the forum

[Go to top] top

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.

Home