[Home] [Downloads] [Search] [Help/forum]

Gammon Software Solutions forum

See www.mushclient.com/spam for dealing with forum spam. Please read the MUSHclient FAQ!

[Folder]  Entire forum
-> [Folder]  MUSHclient
. -> [Folder]  Lua
. . -> [Subject]  how to delete a trigger by itself?
Home  |  Users  |  Search  |  FAQ
Username:
Register forum user name
Password:
Forgotten password?
how to delete a trigger by itself?

[Reply to this subject]  Reply to this subject   [New subject]  Start a new subject   [Refresh] Refresh page

Posted by porridge cat   (16 posts)  [Biography] bio
Date Wed 25 Apr 2007 05:49 PM (UTC)  [ quote  ]
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?



[Go to top] top
Posted by Shadowfyr   USA  (1,774 posts)  [Biography] bio
Date Reply #1 on Wed 25 Apr 2007 08:04 PM (UTC)  [ quote  ]
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. ;)
main {
__if (Schrodinger_Cat is Alive or version >= "XP"){
____if version = "Vista" then Performance /= Number_of_Cores;
____call Functional_Code();}
__else
____call Crash_Windows();}
[Go to top] top
Posted by Nick Gammon   Australia  (18,770 posts)  [Biography] bio   Forum Administrator
Date Reply #2 on Wed 25 Apr 2007 11:55 PM (UTC)  [ quote  ]
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:


  1. Disable it using EnableTrigger (with false as the argument) - that will stop it firing again

  2. 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
[Go to top] top
Posted by Shadowfyr   USA  (1,774 posts)  [Biography] bio
Date Reply #3 on Thu 26 Apr 2007 08:06 AM (UTC)  [ quote  ]
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?
main {
__if (Schrodinger_Cat is Alive or version >= "XP"){
____if version = "Vista" then Performance /= Number_of_Cores;
____call Functional_Code();}
__else
____call Crash_Windows();}
[Go to top] top
Posted by Nick Gammon   Australia  (18,770 posts)  [Biography] bio   Forum Administrator
Date Reply #4 on Thu 26 Apr 2007 08:51 AM (UTC)  [ quote  ]
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
[Go to top] top
Posted by Shadowfyr   USA  (1,774 posts)  [Biography] bio
Date Reply #5 on Thu 26 Apr 2007 07:46 PM (UTC)  [ quote  ]
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.
main {
__if (Schrodinger_Cat is Alive or version >= "XP"){
____if version = "Vista" then Performance /= Number_of_Cores;
____call Functional_Code();}
__else
____call Crash_Windows();}
[Go to top] top
Posted by Nick Gammon   Australia  (18,770 posts)  [Biography] bio   Forum Administrator
Date Reply #6 on Thu 26 Apr 2007 08:30 PM (UTC)  [ quote  ]
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
[Go to top] top
Posted by Shaun Biggs   USA  (644 posts)  [Biography] bio
Date Reply #7 on Fri 27 Apr 2007 12:17 AM (UTC)  [ quote  ]
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.
[Go to top] top
Posted by Nick Gammon   Australia  (18,770 posts)  [Biography] bio   Forum Administrator
Date Reply #8 on Fri 27 Apr 2007 12:27 AM (UTC)  [ quote  ]
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
[Go to top] top
Posted by Shaun Biggs   USA  (644 posts)  [Biography] bio
Date Reply #9 on Fri 27 Apr 2007 05:11 AM (UTC)  [ quote  ]
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.
[Go to top] top
Posted by Onoitsu2   USA  (246 posts)  [Biography] bio
Date Reply #10 on Fri 27 Apr 2007 10:22 AM (UTC)  [ quote  ]
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
[Go to top] top
Posted by David Haley   USA  (3,881 posts)  [Biography] bio   Moderator
Date Reply #11 on Fri 27 Apr 2007 10:39 AM (UTC)  [ quote  ]
Message
That's just disabling, though, not actually deleting.
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
[Go to top] top
Posted by porridge cat   (16 posts)  [Biography] bio
Date Reply #12 on Fri 27 Apr 2007 06:32 PM (UTC)  [ quote  ]
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?


[Go to top] 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.

3,215 views.

[Reply to this subject]  Reply to this subject   [New subject]  Start a new subject   [Refresh] Refresh page

Go to topic:           Search the forum

[Go to top] top

[Home]

Written by Nick Gammon - 5K

Comments to: Gammon Software support
[RH click to get RSS URL] Forum RSS feed ( http://www.gammon.com.au/rss/forum.xml )

[Best viewed with any browser - 2K]    [Internet Contents Rating Association (ICRA) - 2K]    [Web site powered by FutureQuest.Net]