Zugg Software :: View topic

Novice Joined: 18 Aug 2001 Posts: 43 Location: USA

Hi again,

I've got two skills of note on the MUD I use with long delays on them. One is a heal skill with a 10 minute delay, the other is a skill which allows me to construct an ammo cartridge for a ranged weapon, that one has a 2 minute delay.

I have two very simple gauges set up to display a variable which says either 'available' or 'unavailable', depending on the availability of each skill (the button image also changes via the %btnimage variable).

I use alarms for these gauges, and the delay is usually spot on between the MUD and my alarm updating the gauges in zMUD (I've never seen a difference of more than +/- 1 second, which I've written off as latency).

Anyway, for a while I've wanted to make the gauges a bit more complex. I want them to become 'full' when I use the skill, then I want the gauge to 'empty' as the delay counts down. My friend who also uses zMUD (and I believe somebody on these forums) suggested I use a variable plus the #WAIT command to acomplish this, so I've created the following settings (these are temporary settings which I plan to use as a template if/when I get this working properly, so the names are a bit generic):

#VAR A {0} {_nodef} "Temp"

#VAR B {available} {_nodef} "Temp"

#TRIGGER {Omgzor.} {#VARIABLE A 599;#VARIABLE B unavailable;#ALARM TempAlarm1 +10:00 {#SAY Weee!;#VARIABLE B available};#UNTIL (@A = 0) {#SHOW @A;#ADD A -1;#WAIT 1000}} "Temp"

#BUTTON 16 {Skill @B} {} {} {} {@A} {} {} {Size} {120} {15} {} {} {} {32768} {} {Gauge||12|599|15|7} {} "Temp" {Explore|Inset} {} {} {2}

Everything seems cool, and when I tested this on a 59 second alarm, or even a 119 second one, it was all good.

The problem arises when I actually use the 10 minute (well, 599 second) delay for testing. I've included in my settings a #SHOW command so I can keep track of where the delay is while I'm testing, and every now and then I type #ALARM to see how in synch things are. Early on the numbers are in synch, but after a few minutes, they get farther and farther apart.
When there were 540 seconds left, I got the following:

540
Alarms:
+ Temp: +10:00 -> #SAY Weee!~#VARIABLE b available [in 9:00]

When there were 120 seconds left, I got this:

120
Alarms:
+ Temp: +10:00 -> #SAY Weee!~#VARIABLE b available [in 1:53]

When the alarm trigger fired, it was about 7 seconds before my #WAIT countdown was finished:

8
Weee!
7
6
5
4
3
2
1

So obviously, #WAIT and #ALARM are counting one second a bit differently.

My question is why?
The help files led me to believe #WAIT uses ms, thus 1000 should = the same thing as 1 second in an #ALARM. Is the value for the miliseconds off slightly, or does it have something to do with the way my computer counts time? I'm not sure how it could since #ALARMs count properly.
Most importantly, is there a way to fix it? I would really like my gauges to update visibly, but I also want them to be accurate.

Thanks in advance.

P.S. The help file mentions it's not a good idea to use #WAIT if the same trigger could fire twice before the delay is up. Since I have two skills it's possible both could trigger a #WAIT delay at the same time. Would this cause a problem?

P.P.S. Can anybody think of any other method to acomplish the same result of the gauge emptying with the delay?

P.P.P.S. Yes, I actually sat there while 599 numbers scrolled on my screen ;)

MASTER Joined: 28 Nov 2000 Posts: 4817 Location: USA

Don't use #WAIT in triggers. #ALARM is a trigger. So is #TRIGGER, of course. For an explanation, read Zugg's article, Timers, Alarms, and the WAIT command, in the Support Library (use the Support link).

Since your gauge width is 120, it probably can't display more than 120 positions so a 1-second timer is overkill. You might want to use a larger interval.

#TR {Omgzor.} {#VAR A 600;#VAR B unavailable;#ALARM TempAlarm1 *1 {#ADD A -1;#IF (@A = 0) {#T- Tempalarm1;#VAR B available}}}

Novice Joined: 18 Aug 2001 Posts: 43 Location: USA

Ok, thanks for your help, I'm working with what you've given me.
I take it that since I have a small gauge, you suggest something more like this:

#TR {Omgzor.} {#VAR A 120;#VAR B unavailable;#ALARM TempAlarm1 *5 {#ADD A -1;#IF (@A = 0) {#T- Tempalarm1;#VAR B available}}}

So the gauge updates every 5 seconds?

This also raises another question for me =)

I have a couple triggers that use the #CLASS <name> 0 and #CLASS <name> 1 commands, is there any reason to prefer using #T+ <name> or #T- <name> over those commands, or does it not make any difference? I ask because I've never used the +T commands, and when there are multiple ways to do something, there tends to be a 'preferred' way for some reason or another (which is usually not obvious to a newbie like me ;)).

Thanks a bunch, Lightbulb, I appreciate the help you and everybody else give on these forums =)

[EDIT]
Putting my re-posts into one post.

I just tested my 120 * 5 version, along with a +10:00 alarm. The +10 alarm actually fired 5 seconds (1 value of A) before the *5 alarm. The obvious solution to this is to set my variable to 119 or my #IF to @A = 1. I take it this means the +10:00 timer fires on '1' while my other one was set to stop at 0 (and thus counting an extra second)?

By the way, is there any way for us to edit our own posts on this forum?

--

I just did some more testing, and once I set the #IF to @A = 1, using both a +10:00 alarm and the *5 alarm were in synch (with a variable of 120).

However, when I tried using the same code for a 2 minute alarm, it didn't work. I left everything the same, except I changed the *5 to a *1 in the code. Variable remained 120 and #IF remained @A = 1.
When I ran this one, my +2:00 alarm fired 6 seconds before my *1 alarm (based on the 120 variable). Since this one is only 120 seconds I would like the gauge to update every second (since there would be a visible change each time), why is there a time difference like this?

The trigger I used is:

Pattern: Omgzor.

Value:
#VARIABLE A 120
#VARIABLE B unavailable
#ALARM Tempalarm2 +2:00 {#SAY WEEE+!}
#ALARM TempAlarm1 *1 {
#ADD A -1
#SAY @A
#IF (@A = 1) {
#SAY WEEE*!
#T- Tempalarm1
#VARIABLE B available
}
}

Ended up with:

7
WEEE+!
6
5
4
3
2
1
WEEE*!

[/EDIT]

=(

MASTER Joined: 28 Nov 2000 Posts: 4817 Location: USA

You are probably reaching the point where you occasionally give zMUD more to do than it has time for, causing it to occasionally miss a second on your 1-second alarm (just a guess).

Nothing but personal preference as far as #T+/- versus #CLASS class 1/0. I prefer #T+/- because it's shorter and less likely to do anything undesirable in case of typo.

Editing posts is done by clicking on the Edit Reply icon (hover the mouse). It looks like a page with a pencil over it.

Novice Joined: 18 Aug 2001 Posts: 43 Location: USA

Hrm, when I'm testing these things, I have all my other classes disabled, so should 2 alarms really be 'bogging down' zMUD to the point where it loses time? And if it does, how come it loses time on one of the alarms but the other counts as normal? Curious-er and curious-er ;)

Btw the reason I didn't see the edit button is I wasn't logged in, I had been putting my name/pass in with each new post.

MASTER Joined: 28 Nov 2000 Posts: 4817 Location: USA

I don't spend time trying to figure out the mechanics of the code. I just take note of what happens -- short, repetitive alarms get behind the clock after awhile -- and avoid using them. The reason why is probably important to Zugg but doesn't matter at all to me. My general recommendation would be to never rely on 1-second repeating alarms (one-time alarms are fine).

This is all just conjecture, but I'd guess that with a repeating alarm (*1) the time of the next repetition doesn't get figured until after the current one has fired. Thus, if your computer is busy doing something (retrieving data from the hard-drive for instance) at 3:46:27, and the 1-second alarm that's supposed to go off at that time can't be processed until 3:46:29.13, the next alarm will probably be scheduled for 3:46:30 instead of 3:46:28 -- skipping two seconds. On the other hand, the 2-minute alarm that's scheduled to fire at 3:47:11 won't be affected at all and will still go off on time. Nothing at all "curious" about one alarm losing time while the other doesn't.

This is way off-topic.

Novice Joined: 18 Aug 2001 Posts: 43 Location: USA

Not all that off topic, it at least explains to me why one would be off and the other wouldn't be. Makes sense, now that I think about it.

Although I wasn't doing anything else when I tested this, perhaps it's not so much the CPU being busy as it is a slight error in the way repeating 1-second alarms are handled.

Think I should bug report it? Or mention this thread to Zugg? Or what?

Btw thanks for your help, I at least got the 10 minute gauge working pretty well =)