Zugg Software :: View topic

Novice Joined: 15 Mar 2005 Posts: 42

Hello

I'm using zMud for few years (about 5) and I find myself as quite experienced zMud scripter. For those 5 years I've played only one mud and my exported (ASCII) settings are quite big (I think) - 120KB.
And I always take care for good triggers patterns (almost no triggers without begin or end line indicator). Etc, etc...

I'm starting to get quite big performace issues using my settings - especially when mud is getting a little lagged (on PIII 700MHz notebook the average CPU is about 50% for zMud).

In the the debugger window I saw mainly one alias executed very often - this is for healing alias. It looks like:

Enchanter Joined: 05 Mar 2003 Posts: 593 Location: Canada

If you want an alarm that triggers in fractions of a second just use decimals
#ALARM -0.2 {do something}
that alarm would go off in approx 200ms

Novice Joined: 15 Mar 2005 Posts: 42

Heh... I even haven't tried to test if I can set alarms with decimal argument.

Thx - I need test this more with my settings.

Rgds, Yelayon

SubAdmin Joined: 18 Nov 2001 Posts: 5182

The smallest you can set an alarm to is .501 seconds. Also at this resolution you should expect a small amount of timing drift to accumulate each cycle. So it would be best to have a secondary timing unit to synchronize to if you want total precision.

Enchanter Joined: 05 Mar 2003 Posts: 593 Location: Canada

I'll have to disagree with your assesment of the minimum interval for an alarm Vijilante I have no problems setting timers for as low as 0.1 seconds, however as you say the drift at such low intervals is fairly significant.

Wanderer Joined: 23 Apr 2001 Posts: 53 Location: USA

Hey - can we get a definitive answer to this? Not long ago I was told by one of you two (Vij or Dhark) that #alarm could handle fractional timing with no issues, but I am seeing signs that the drift is a little more than I'm able to live with. Is anyone able to explain this in some more detail so I can understand how I should handle this?

Also, if I go the multi-state route, how precise is the timing for a wait state trigger?

Thanks!

Wizard Joined: 03 Mar 2001 Posts: 1127 Location: London

To be on the safe side use alarms greater than 0.5 seconds as mentioned in the help. I assume that any drift for <0.5 seconds is dependant on the other triggers, aliases etc that might be running and the speed of your PC.

Enchanter Joined: 05 Mar 2003 Posts: 593 Location: Canada

Hehe 'definitive' unlikely, there's always something else to be said is there not?
The difference between Vijilantes maximum resolution and mine is likely a question of hardware and OS; forgetting about hardware for a sec if Vijilantes using a version of Win98 then it makes sense that his maximum resolution is much lower (higher resolution = more accurate) than mine (I'm using XP Pro SP2).
sysinternals has a nice little applet that can tell you what your maximum
timer resolution is
http://www.sysinternals.com/ntw2k/source/misc.shtml#clockres
on my system its 15.625000 ms thus any timer event can be off by as much as 16 ms which concurs exactly with test that i've ran in zmud.
Also just because zmud recieved the timer event doesnt mean that the timer trigger gets processed right away, zmud maybe be busy doing something else at that time in which will of course cause even more loss of accuracy.

Wanderer Joined: 23 Apr 2001 Posts: 53 Location: USA

Ok, but there's a huge difference between 16ms and .5s. I'm looking for 50ms precision (ie, if I say 200 ms, I'll be closer to 200 than to 100 or 300). #WAIT, of course, delivers this with a BIG issue. The help file says 1/2 second as Guinn noted. You said 200ms which is intolerably inaccurate Laughing

for me. If I write code in C, I can get the sysinternals accuracy, but who wants to do that? So now I'm back to the same question: If I use a wait state trigger, will my timing be within 50ms of what I specify in the parameter?

Thanks again!

SubAdmin Joined: 18 Nov 2001 Posts: 5182

Yes the timing will be within 50ms consistently. When I speak of drift I mean if you have a reoccuring timed event each occurence will not be triggered until the time expires and could be off by a few ms (around 15 as Dharkael mentioned). Cummulatively that small error will total into seconds after a number of occurences. This is simply because the event is never triggered and reset prior to the time specified.

I don't believe the help actually states anywhere that .501 is the minimum that an alarm can be created for. In fact I can't really locate references to factional times in alarms right now, so it is something else to add. The specific time amount of .501 was a result of testing after Zugg first added fractional times to alarms. Some versions of windows simply refused to ever fire an alarm with a smaller duration. You can find some record of it back in the beta forum if your are interested in researching it.

Posted: Thu Mar 17, 2005 2:04 am

zMUD itself restricts the minimum timer value to 0.5 seconds. It has nothing to do with the version of Windows. Quicker timers just are not feasible since the processing of incoming text from the MUD prevents zMUD from triggering that quickly on a regular basis. Windows is *not* a realtime operating system and even setting a system timer in Windows to something like 100 ms doesn't guarentee that it fires exactly every 100 ms. You'll always see a lot of drift if you start adding up this kind of interval.

If you absolutely need something like this for some reason, you'll need to write a plugin. But there is rarely any real reason to do this kind of polling at small time intervals. Such things just slow down your system and are a bad way to accomplish tasks. It's usually better to set up some sort of expression trigger that fires when the value of a variable gets changed, or something like that.

The only other way to handle fast intervals like this is using a multi-state trigger where you can set delay values between trigger states in milliseconds.

Apprentice Joined: 10 Feb 2005 Posts: 158

#IF (@checkAHSemafor) {
#VARIABLE checkAHSemafor 0
#IF (@isAutoHealON) {
guildAutoHeal
}
#VARIABLE checkAHSemafor 1
}

Hmm, Ive read this snip like 3 times and I still dont get some of it.
Whats the point of setting checkAHSemafor to 0 when on the last line you set it to 1 anyway? To me this looks like it would constantly be firing all over the place... which could explain your high usage. Question

Enchanter Joined: 05 Mar 2003 Posts: 593 Location: Canada

for me #ALARM -0.08 {#echo %secs} fires no problem albeit 14 or so ms later.

Novice Joined: 15 Mar 2005 Posts: 42