Previous Thread
Expand All
Collapse All
Ignore Author
Reply
I have an RT gauge that I copied from the yahoo DRzmud group (I think).
#TRIGGER {Q} {} "" {gsl}
#COND {q} {roundtime = %eval(%gsl(Q)-%gsl(q));gaugemax=@roundtime} {gsl}
#TRIGGER (@roundtime>0) {}
#COND {} {#ADD roundtime -1} {wait|param=1000}
#BUTTON 3 {@roundtime} {} {} {} {@roundtime} {} {} {Size} {100} {23} {Pos} {32} {1} {12} {} {Gauge||8|@gaugemax||7} {} "" {Explore|Inset} {} {}
I am using @gaugemax to input the RT in an #ALARM command for triggers that will need to wait, such as.
#TRIGGER {You scrape your blah blah blah} {#ALARM +@gaugemax {command to execute}}
The thing is that this is not enough. I tried to use an #ADD command to add 1 to the @gaugemax var and also I tried to make another variable and add 1 to that. The problem here is that the variable was not resetting. Instead it was constantly adding 1. I was ending up with an alarm that was climbing and climbing as high as half a minute or more.
I took a look at roundproof but that will not do the trick. I have my prompt set a certain way and I am too stubborn to change it in order to make that work.
I am at a loss here.
Help please and thank you for any help offered.
"Never be afraid to laugh at yourself, after all, you could be missing out on the joke of the century."
- Dame Edna Everage
I've never used ZMud but from what you posted it looks as if you need to utilize two variables..
1. The current system time (you can usually set a variable to the time using the system clock)
2. Set the RT expires to (TIME + Roundtime)
Example, if the system clock is set to 03:05:42 and you have an incoming 5 second roundtime you want the roundtime expires variable to be set to 03:05:47 (5 seconds into the future). Then compare the value in #2 with the current system time and that should get you in the ballpark of when your RT expires. If the RT Expires variable is less than the system time, then instruct Zmud to continue. If you see "...wait" you'll want to increase the RT Expires variable and then compare it to the system time until you're free from the RT.
For good measure it would probably be wise to set the expiration as (TIME + 1 second + Roundtime) so you have a buffer.
That's one way to avoid the infinite loop. I hope it helps.
-Ssra
The evil that men do lives after them; The good is oft interred with their bones. - Shakespeare: "Julius Caesar" Act 3, Scene 2.
1. The current system time (you can usually set a variable to the time using the system clock)
2. Set the RT expires to (TIME + Roundtime)
Example, if the system clock is set to 03:05:42 and you have an incoming 5 second roundtime you want the roundtime expires variable to be set to 03:05:47 (5 seconds into the future). Then compare the value in #2 with the current system time and that should get you in the ballpark of when your RT expires. If the RT Expires variable is less than the system time, then instruct Zmud to continue. If you see "...wait" you'll want to increase the RT Expires variable and then compare it to the system time until you're free from the RT.
For good measure it would probably be wise to set the expiration as (TIME + 1 second + Roundtime) so you have a buffer.
That's one way to avoid the infinite loop. I hope it helps.
-Ssra
The evil that men do lives after them; The good is oft interred with their bones. - Shakespeare: "Julius Caesar" Act 3, Scene 2.
>>That's one way to avoid the infinite loop. I hope it helps
It isn't really a loop issue. I have not gotten one with the triggers I mentioned before. I am not even really sure that the method you mentioned can be used within the confines of Zmuds program language.
What I was I was hoping to find a way to do is to simply add another command at the end of the trigger that will reset the variable back to a zero state. The positioning of such a command will be key, as it would either totaly scew the system or work beautifly.
#Trigger {text to match} {command(s) to execute}
Were Zmud chronological rather than event driven, this would not be an issue. However, I do prefer the event driven structure. I see more possibility with it.
Please forgive me if this post seems a bit terse or offensive. It was and is not meant to be such.
"Never be afraid to laugh at yourself, after all, you could be missing out on the joke of the century."
- Dame Edna Everage
It isn't really a loop issue. I have not gotten one with the triggers I mentioned before. I am not even really sure that the method you mentioned can be used within the confines of Zmuds program language.
What I was I was hoping to find a way to do is to simply add another command at the end of the trigger that will reset the variable back to a zero state. The positioning of such a command will be key, as it would either totaly scew the system or work beautifly.
#Trigger {text to match} {command(s) to execute}
Were Zmud chronological rather than event driven, this would not be an issue. However, I do prefer the event driven structure. I see more possibility with it.
Please forgive me if this post seems a bit terse or offensive. It was and is not meant to be such.
"Never be afraid to laugh at yourself, after all, you could be missing out on the joke of the century."
- Dame Edna Everage
<<Please forgive me if this post seems a bit terse or offensive. It was and is not meant to be such.>>
No offense taken. You're speaking to someone who is very ZMud ignorant.
Let's look at the variable.
#COND {q} {roundtime = %eval(%gsl(Q)-%gsl(q));gaugemax=@roundtime} {gsl}
That is setting the RT. You state the timer always ends a bit too early, correct? If so we need to increase it. It looks to me as if ZMud is using integer math with gsl(Q) and GSL(q) as the origin and destination.
Try manipulating the equation so it adds a 1 or 2 second buffer.
Example:
#COND {q} {roundtime = %eval(%gsl(Q)-(%gsl(q) + 1));gaugemax=@roundtime} {gsl}
You may need to use addition/substraction according to how this data is sent to ZMUD, on the basis of what (Q) and (q) are exactly (I don't know, sorry.), and the outcome of that tweak.
Best of luck.
-Ssra
The evil that men do lives after them; The good is oft interred with their bones. - Shakespeare: "Julius Caesar" Act 3, Scene 2.
No offense taken. You're speaking to someone who is very ZMud ignorant.
Let's look at the variable.
#COND {q} {roundtime = %eval(%gsl(Q)-%gsl(q));gaugemax=@roundtime} {gsl}
That is setting the RT. You state the timer always ends a bit too early, correct? If so we need to increase it. It looks to me as if ZMud is using integer math with gsl(Q) and GSL(q) as the origin and destination.
Try manipulating the equation so it adds a 1 or 2 second buffer.
Example:
#COND {q} {roundtime = %eval(%gsl(Q)-(%gsl(q) + 1));gaugemax=@roundtime} {gsl}
You may need to use addition/substraction according to how this data is sent to ZMUD, on the basis of what (Q) and (q) are exactly (I don't know, sorry.), and the outcome of that tweak.
Best of luck.
-Ssra
The evil that men do lives after them; The good is oft interred with their bones. - Shakespeare: "Julius Caesar" Act 3, Scene 2.
We're trying to increase the value assigned to "roundtime" by 1, so we should probably put the plus on the first operand, not the second. I think you'll also probably have to nest an "eval" statement:
#COND {q} {roundtime = %eval(%eval(%gsl(Q) + 1) - %gsl(q));gaugemax=@roundtime} {gsl}
Last I knew, ZMud doesn't parse arithmetic in a very natural way. One of the reasons I never used it for very long.
Marksman Ahmir Nam'al
[pi]
#COND {q} {roundtime = %eval(%eval(%gsl(Q) + 1) - %gsl(q));gaugemax=@roundtime} {gsl}
Last I knew, ZMud doesn't parse arithmetic in a very natural way. One of the reasons I never used it for very long.
Marksman Ahmir Nam'al
[pi]
You both may as well be speaking Chinese. I am just getting to the point where I am able to write simple 'scripts' and alias or trigger them. Nest eval?
All I want to do is create a variable using the value of the RT start GSL (Q) I believe and add 1 (temp) second to it. Thereby giving me something to use for commands that require roundtime.
Color me lost
"Never be afraid to laugh at yourself, after all, you could be missing out on the joke of the century."
- Dame Edna Everage
All I want to do is create a variable using the value of the RT start GSL (Q) I believe and add 1 (temp) second to it. Thereby giving me something to use for commands that require roundtime.
Color me lost
"Never be afraid to laugh at yourself, after all, you could be missing out on the joke of the century."
- Dame Edna Everage
Ok, I fould a solution. It was so simple that I am beating myself in the head over it.
In the root class folder I created a trigger as follows.
#TRIGGER {^Roundtime~:%s&rt [sec~.|seconds]} {#ADD rt 1}
What this does is Trigger off of "Roundtime: xx sec." or "Roundtime: xx seconds"
Now all I have to do is insert @rt into an alarm anytime I want a command to wait for the given roundtime +1 additional second.
"Never be afraid to laugh at yourself, after all, you could be missing out on the joke of the century."
- Dame Edna Everage
In the root class folder I created a trigger as follows.
#TRIGGER {^Roundtime~:%s&rt [sec~.|seconds]} {#ADD rt 1}
What this does is Trigger off of "Roundtime: xx sec." or "Roundtime: xx seconds"
Now all I have to do is insert @rt into an alarm anytime I want a command to wait for the given roundtime +1 additional second.
"Never be afraid to laugh at yourself, after all, you could be missing out on the joke of the century."
- Dame Edna Everage
>>You might want to add another trigger along the lines of:
I would prefer not to add anymore until I have more understanding of Zmud. I have been using it off and on since 2001 but more off than on. This time I hope I will stick with it. I have learned more than I did in the past.
But, as for the trigger, it is easy enough for me to adjust it in order to allow for network/server latency. All I need to do is change the {#ADD rt 1} by increasing 1 to 2 or 3.
"Never be afraid to laugh at yourself, after all, you could be missing out on the joke of the century."
- Dame Edna Everage
I would prefer not to add anymore until I have more understanding of Zmud. I have been using it off and on since 2001 but more off than on. This time I hope I will stick with it. I have learned more than I did in the past.
But, as for the trigger, it is easy enough for me to adjust it in order to allow for network/server latency. All I need to do is change the {#ADD rt 1} by increasing 1 to 2 or 3.
"Never be afraid to laugh at yourself, after all, you could be missing out on the joke of the century."
- Dame Edna Everage
