Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to "verify" your details, 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
➜ General
➜ Timer questions
It is now over 60 days since the last post. This thread is closed.
Refresh page
Posted by
| Shadoweave
(42 posts) Bio
|
Date
| Sun 23 Sep 2007 04:07 PM (UTC) Amended on Sun 23 Sep 2007 05:50 PM (UTC) by Shadoweave
|
Message
| A friend told me that timers in MUSH don't work exactly like they do in zMud, and since I had some problems with timers myself in the past, I thought it would be better to ask this. Sorry if this seems like senseless ranting to all of you. So, how do timers actually work? If you enable a timer, will it process the script then and again when it fires? If you disable it, you need to reset the timer too? A help file describing in detail how they work would be much appreciated.
Edit: And another question, in which order triggers with the same sequence are matched? Alphabetical? | Top |
|
Posted by
| Nick Gammon
Australia (23,057 posts) Bio
Forum Administrator |
Date
| Reply #1 on Sun 23 Sep 2007 09:31 PM (UTC) Amended on Mon 24 Sep 2007 08:55 PM (UTC) by Nick Gammon
|
Message
|
- If you add a timer, it fires when the time is up, not the moment you add it. For example, a 5-second timer fires, after 5 seconds, and again after another 5 seconds. However a "one-shot" timer (set the one-shot flag) fires once and then deletes itself.
- Disabling a timer stops it firing. If you re-enable it, then it will fire again when the time is up. If you want to change that time, reset it, then enable it. A disabled timer may well expire while it is disabled and fire the moment you re-enable it, so resetting it first is wise. [EDIT] You cannot reset disabled timers, so you really should enable a timer, then reset it, if you want it to restart its sequence once enabled.
- Triggers that have the same sequence fire in an undefined order. This is because they are stored internally by name in a "map" for fast access by name, however the map access uses hashing to get to a particular one. If the sequence of firing is important to you, use different sequence numbers.
- BTW, a quick way of adding things in scripts is to use Lua scripting, and the "addxml" script file. See this post for more details and examples:
http://mushclient.com/forum/?id=7123
|
- Nick Gammon
www.gammon.com.au, www.mushclient.com | Top |
|
Posted by
| Shadoweave
(42 posts) Bio
|
Date
| Reply #2 on Mon 24 Sep 2007 06:09 AM (UTC) Amended on Mon 24 Sep 2007 01:50 PM (UTC) by Shadoweave
|
Message
| Thank you very much for your help!
Quote:
Disabling a timer stops it firing. If you re-enable it, then it will fire again when the time is up. If you want to change that time, reset it, then enable it. A disabled timer may well expire while it is disabled and fire the moment you re-enable it, so resetting it first is wise.
So this is why my timers were firing when they shouldn't!
I just looked through the documentation about ResetTimer and this is what is says:
Quote:
Resets the named timer.
Also see ResetTimers to reset all timers.
WARNING - timers that are not enabled will not be reset. Use EnableTimer first to make sure the timer is enabled, before resetting it, if necessary.
It works if you reset the timer after you enabled it.
Edit: How do you check if a table is empty? I initialize all my tables with "table = {}" and I've tried comparing it to nil and {}, but to no avail. It must be a thread around here about this, but I haven't found it yet.
| Top |
|
Posted by
| Nick Gammon
Australia (23,057 posts) Bio
Forum Administrator |
Date
| Reply #3 on Mon 24 Sep 2007 08:57 PM (UTC) |
Message
|
Quote:
It works if you reset the timer after you enabled it.
Oops. I have amended my earlier post to make this clear.
Quote:
How do you check if a table is empty?
See the opening remarks on this page:
http://www.gammon.com.au/scripts/doc.php?general=lua_tables
|
- Nick Gammon
www.gammon.com.au, www.mushclient.com | Top |
|
Posted by
| Nick Gammon
Australia (23,057 posts) Bio
Forum Administrator |
Date
| Reply #4 on Mon 24 Sep 2007 08:58 PM (UTC) Amended on Mon 24 Sep 2007 08:59 PM (UTC) by Nick Gammon
|
Message
| By the way, I almost missed your new question about tables. I check the forum posts by the list of new posts which you see when you are logged in.
Thus, unless you are fixing spelling or other similar mistakes, if you have a new question, make a new post rather than editing an existing one. An edited post doesn't change the list. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | Top |
|
Posted by
| Shadowfyr
USA (1,788 posts) Bio
|
Date
| Reply #5 on Tue 25 Sep 2007 04:14 AM (UTC) |
Message
| Just one comment. Having to enable it, then reset it is sort of putting the cart before the horse. Thankfully, since execution of the clients own operations are suspended while script executes, this hasn't been a real problem. From the logic standpoint though, its backwards, since, in theory, you could have a condition where the reset happens "after" the trigger fires, if somehow, for some reason, the reset and the enable do not happen in the same script execution.
Its very minor, probably never going to come up, etc., but it is, as I said, a tad backwards. More to the point, if anyone should ever create a thread system, which can allow non-synchronous execution (i.e., it can respond to triggers, etc., but not execute commands that send things to the mud, say for storing database info, updating character stats on a web page, or other situations that currently may cause too much lag, then it "will" be a problem, since in parallel execution, it is actually possible to have to script enable a trigger, it fire, then reset it. Its a potential future bug, should someone mod the client to allow such a threading system at some point. | Top |
|
Posted by
| Shadoweave
(42 posts) Bio
|
Date
| Reply #6 on Tue 25 Sep 2007 06:44 AM (UTC) Amended on Tue 25 Sep 2007 06:46 AM (UTC) by Shadoweave
|
Message
|
Thank you very much, exactly what I was searching for!
Quote:
Just one comment. Having to enable it, then reset it is sort of putting the cart before the horse. Thankfully, since execution of the clients own operations are suspended while script executes, this hasn't been a real problem. From the logic standpoint though, its backwards, since, in theory, you could have a condition where the reset happens "after" the trigger fires, if somehow, for some reason, the reset and the enable do not happen in the same script execution.
Yeah, that was exactly what I was thinking, and I wasn't even going to try to do it that way. But some other person who plays the same mud as me said that that's the only way it works, so after I tried, it worked.
| 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.
28,182 views.
It is now over 60 days since the last post. This thread is closed.
Refresh page
top