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
➜ Lua
➜ how to delete a trigger by itself?
how to delete a trigger by itself?
|
It is now over 60 days since the last post. This thread is closed.
Refresh page
Posted by
| porridge cat
(16 posts) Bio
|
Date
| Wed 25 Apr 2007 05:49 PM (UTC) |
Message
| i want a trigger to be triggered only once...
so i put the following syntax to the very bottom:
1) DeleteTrigger("my_trigger") -- but it didn't work
2) DoAfterSpecial (1, [[DeleteTrigger("my_trigger")]], 12) --but it must wait 1 second
would it be possible to create a trigger that could delete it by itself?
| Top |
|
Posted by
| Shadowfyr
USA (1,788 posts) Bio
|
Date
| Reply #1 on Wed 25 Apr 2007 08:04 PM (UTC) |
Message
| An easier solution is to set up the trigger to either be:
Create the trigger as "Temporary", then the first time it fires, it will automatically delete itself on finishing.
Or, use "EnableTrigger" to disable it as the last thing it does.
The reason you can't have one delete itself using "DeleteTrigger" is because the script attempts to return to the trigger you just deleted, and in prior versions, that would crash the client. Instead of flagging the trigger for deletion "after" the trigger finished, Nick chose to simply not let them delete themselves at all using script functions.
Imho, Nick could have, if he had considered it, made the delete function, when it checked the trigger name, *instead* of ignoring the request, change the state of the trigger, timer, etc. that tried to delete itself to "temporary", which, I would presume, have had the same effect as a temporary trigger in the first place. I.e., once the script returned control, the client would note that the trigger was a temporary one, and delete it. Then again, I haven't looked at the code for that, so I have no idea when the deletion test for temporary ones happens. Its one of those things we didn't all 100% agree with Nick on, so had to live with the compromise. ;) | Top |
|
Posted by
| Nick Gammon
Australia (23,120 posts) Bio
Forum Administrator |
Date
| Reply #2 on Wed 25 Apr 2007 11:55 PM (UTC) |
Message
| The temporary flag is not a one-shot flag. Temporary means "don't save to disk".
I am adding the ability to do one-shot triggers and aliases into version 4.06, however for now, you should do what you are currently doing, plus Shadowfyr's suggestion:
- Disable it using EnableTrigger (with false as the argument) - that will stop it firing again
- Use DoAfterSpecial to delete it shortly afterwards
Once version 4.06 is released, you can simply make a one-shot trigger.
|
- Nick Gammon
www.gammon.com.au, www.mushclient.com | Top |
|
Posted by
| Shadowfyr
USA (1,788 posts) Bio
|
Date
| Reply #3 on Thu 26 Apr 2007 08:06 AM (UTC) |
Message
| Ah. Sorry, my mistake on what that meant. Thanks for the new trick though. Can I presume that with that change the behavior of delete could be adjusted to cause it to set the "one-shot" attribute instead when detecting its in the same trigger? Mind you, it might be a good idea to do something like adjusting the function so that it has an optional attribute, like:
DeleteTrigger(CStr[,bool])
Where the boolean defaults to "False", that being, "Ignore this command if executed on the trigger currently running script.", which "True" would be, "Change this trigger to 'one-shot', so that it self deletes on exit."
We don't really "need" this mind you, but its what some people are going to try to do, so its not too absurd to provide a way that it can work. And by making the attribute optional, you keep the existing behavior as is. Not sure if there was some sort of problem with that, which kept you from supporting that sort of overloading... I seem to remember some mention of such, but not in what context. Maybe it was only an issue with VB or something? | Top |
|
Posted by
| Nick Gammon
Australia (23,120 posts) Bio
Forum Administrator |
Date
| Reply #4 on Thu 26 Apr 2007 08:51 AM (UTC) |
Message
| With COM, you are not supposed to change the interface once it has been published.
|
- Nick Gammon
www.gammon.com.au, www.mushclient.com | Top |
|
Posted by
| Shadowfyr
USA (1,788 posts) Bio
|
Date
| Reply #5 on Thu 26 Apr 2007 07:46 PM (UTC) |
Message
| Sigh.. In other words no. Just one point though, this doesn't fix every case. Why? Lets say your trigger is designed to capture a number of lines and store them, then delete itself when you receive a "specific" line. You still can't do that, because its **not** a one shot trigger by definition. Its not just getting one match, then deleting, its waiting for a specific event, then killing itself. So, allowing one shot, but having no way to change that state, doesn't fix it.
As for changing interfaces.. Ok, I can see your point there, except its producing function hell imho, in that, much like some Windows API calls, we are getting things like Blah, BlahEx, BlahEx2, etc., etc. I think that is one major flaw with ActiveX, now that I think of it, since you can ask the interface manager for a "named" interface, but not if there is one with specific parameters, so as you say, overloading isn't possible, even if it makes more bloody sense.
Anyway, the only reason I even suggested it is to maintain existing behavior, but since the existing behavior was intended to prevent someone crashing the client, changing the behavior so it does work, but won't crash the client, doesn't change the interface at all. If you get my meaning. Instead it simply puts in place what imho, most of us thought when we first tried it would have been "expected" behavior in the first place. | Top |
|
Posted by
| Nick Gammon
Australia (23,120 posts) Bio
Forum Administrator |
Date
| Reply #6 on Thu 26 Apr 2007 08:30 PM (UTC) |
Message
| Sigh, indeed. The original poster in this thread wanted a one-shot trigger: "I want a trigger to be triggered only once.".
After a considerable amount of work I have added in the one-shot capability.
Now you want the "trigger that sometimes deletes itself".
All these more complex things can be handled by scripting, right now. All it has to do is disable itself and arrange to be deleted a moment later (like, 1/10 of a second). What is so hard about that? You are already scripting because the script is making a decision. There is a trade-off between having a "checkbox" or "special function" for every conceivable situation, and having the ability to do it in scripting, even if it takes a couple of lines of code.
|
- Nick Gammon
www.gammon.com.au, www.mushclient.com | Top |
|
Posted by
| Shaun Biggs
USA (644 posts) Bio
|
Date
| Reply #7 on Fri 27 Apr 2007 12:17 AM (UTC) |
Message
| Couldn't you just disable the trigger, then set up a one shot timer set up to delete the trigger after the minimum amount of time for a timer has passed? If this is something that needs to be done terribly often, then a quick function could be added to the script file to set this up easier. You'd just need to pass the name of the trigger. |
It is much easier to fight for one's ideals than to live up to them. | Top |
|
Posted by
| Nick Gammon
Australia (23,120 posts) Bio
Forum Administrator |
Date
| Reply #8 on Fri 27 Apr 2007 12:27 AM (UTC) |
Message
| That is exactly what I was trying to say. And in fact if you are doing it very often, why are you deleting it in the first place? Why not just re-use it? Disable it, and then re-enable when it is needed again. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | Top |
|
Posted by
| Shaun Biggs
USA (644 posts) Bio
|
Date
| Reply #9 on Fri 27 Apr 2007 05:11 AM (UTC) |
Message
| I honestly can't think of a reason to have a trigger delete itself that is not covered by making a one time trigger. |
It is much easier to fight for one's ideals than to live up to them. | Top |
|
Posted by
| Onoitsu2
USA (248 posts) Bio
|
Date
| Reply #10 on Fri 27 Apr 2007 10:22 AM (UTC) |
Message
|
Quote: I honestly can't think of a reason to have a trigger delete itself that is not covered by making a one time trigger.
I can, if it is a "multi-line" trigger, that is using the multi-line workaround.
things such as...
^((\+\-\-\-\-\-\-\-\+)|\|(.*?)\|)$
I use something similar to that in my bigmap catching trigger in my vidblain walker for Aardwolf, I have 1 trigger, that matches on the '\+\-\-\-\-\-\-\-\+' itself and enables a trigger like above, and disables itself, and then will catch EVERYTHING until it reaches the same '\+\-\-\-\-\-\-\-\+' again, and disables itself.
It may not be pretty, but it works quite well, because i never have a problem with the .*? over matching in any of my workaround "multi-line" triggers.
Laterzzz,
Onoitsu2 | Top |
|
Posted by
| David Haley
USA (3,881 posts) Bio
|
Date
| Reply #11 on Fri 27 Apr 2007 10:39 AM (UTC) |
Message
| That's just disabling, though, not actually deleting. |
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone
http://david.the-haleys.org | Top |
|
Posted by
| porridge cat
(16 posts) Bio
|
Date
| Reply #12 on Fri 27 Apr 2007 06:32 PM (UTC) |
Message
| thank everyone's kind heart of helping resolve my question!
now my thinking is:
loading a script from variales -> execute the loaded script and set the variable nil -> if loading again, nil returns: then just tell the killer machine to kill it! maybe kill twice or thrice, what bother, right?
but sometimes i think that it's some strange and not beautiful...
maybe there is a more formal method to solve?
| 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.
34,867 views.
It is now over 60 days since the last post. This thread is closed.
Refresh page
top