Zugg Software :: View topic

Magician Joined: 17 Oct 2001 Posts: 371 Location: USA

Okay, I'm developing something that I find really hard... a command buffer. There are 4 states that I've programmed zMUD for Script (Only triggers used in afk scripts immediately send their commands to the MUD), User (No triggers immediately send their commands to the MUD), None (All normal triggers immediately send their commands to the MUD), and Command Buffer (All commands that DIDN'T fire because the state was in Script or User are saved to a string variable and executed one at a time). Now I'd like you all to look at the ExecCommandBuffer alias that I've developed... I've worked really hard on it and I'd like some input before I start actually long-term testing it.
#ALIAS ExecCommandBuffer {
#IF (@ReservedControl =! "Command Buffer") {
#BEEP
#ECHO *****WARNING!!!!*****
#ECHO *****Control Allocation Error!!!*****
#ECHO *****WARNING!!!!*****
#ECHO *****Suggested to abort scripting routines and clear buffer manually*****
#ECHO *****Error Handling Methods suggested in 'Error Support' File ~(Type in ErrorHelp for access~).
#BEEP
#ABORT 1
} {#ECHO *****Clearing Buffer. No Apparent Errors*****}
#VAR BufferSize %numitems( @ComBuffer)
#Until (@BufferSize = 0) {
#VAR CCom %additem( %pop( @ComBuffer))
#IF (%numitems( @CCom) = 1) {
#IF (@RTBuffer = 2) {
#EXEC @CCom
#VAR CCom ""
} {
#IF (@RTBuffer < 0) {
#ADD Wait (%abs( @RTBuffer)+ 2)
#ALARM +@Wait {
#VAR Wait 0
#EXEC @CCom
#VAR CCom ""
}
}
#IF (@RTBuffer = 0|1) {#ALARM +2 {
#EXEC @CCom
#VAR CCom ""
}}
}
} {
#BEEP
#ECHO *****WARNING!!!!*****
#ECHO *****BUFFER OVERFLOW ERROR*****
#ECHO *****WARNING!!!!*****
#ECHO *****Buffer Overflow is generally caused due to excessive lag ~(over 7.5 seconds~). Suggested NOT to script under such conditions.
#ECHO *****Error Handling Methods suggested in 'Error Support' File ~(Type in ErrorHelp for access~).
#BEEP
#ABORT 1
}
#ADD BufferSize -1
#IF (@WAIT = 0) {#WAIT 7500} {
#MATH Wait (@Wait + 7.5)*1000
#WAIT @Wait
}
}
}

To know a bit more about whats going on... @RTBuffer is a variable which makes sure that I don't execute commands before the time delay of those commands is finished... Its constantly updated (to a maximum value of 2) by the tick timer. Whenever I'm told I have a time delay (called Roundtime (RT for short)) I set the RTBuffer to negative whatever the time delay is, then every second it adds 1 to it, until it hits +2, effectively giving a 2 second buffer between commands.

The variable @ReservedControl tells all triggers if they can immediately fire their commands, or if they have to save those commands to the Command Buffer.

Okay, if I could get input on how to change effiency or eliminate all those nasty bugs that I know are hiding in there, but I just can't seem 'em, I would REALLY appreciate it.

Belmyrddyn

SubAdmin Joined: 18 Nov 2001 Posts: 5182

Looks kinda neat.

First bug:
#ALARM +@Wait {
that line won't work as it will not expand Wait immediately. To correct this you must use the format:
#EXEC %expand (#ALARM +@Wait) {
You will have to combine everything for that alarm into one line for proper functionality.

Next, I am not sure about this:
#IF (@RTBuffer = 0|1) {#ALARM +2 {
I do not think the logic will preform exactly as desired. Two alternatives are.
#IF (@RTBuffer =~ "{0|1}") {#ALARM +2 {
#IF ((@RTBuffer = 0)|(@RTBuffer= 1)) {#ALARM +2 {

Another one I am concerned about:
#IF (@ReservedControl =! "Command Buffer") {
I think it might do better as:
#IF (@ReservedControl != "Command Buffer") {
But again I am not sure exactly how those will interpret as they stand.

Rather then using #WAIT you might want to consider an ALARM. A very nice way is to create the ALARM with an id.
#EXEC %expand(#ALARM "WaitTimer" {+@Wait} {})
Then you wrap your alias with
#IF (%trigger(WaitTimer)=1) {existing alias}
That allows you to completely stop the alias from running or you can lock out portions until the ALARM expires. I don't know how what is calling the alias so I can't say if the current WAITs at the end will do any good. You might wish to eliminate the UNTIL loop and just have the alias called again from an ALARM, that would also eliminate the need for the WAITs. As it is it seems there is a hazard of commands being added to the buffer while ExecCommandBuffer is running. Any such commands would be lost, unless it was called again. Another thing is that you currently have a 7.5+ second delay between commands whether it needs that long or not.

Magician Joined: 17 Oct 2001 Posts: 371 Location: USA

#EXEC %expand(#ALARM +@Wait){#VAR Wait 0;#EXEC @CCom; #VAR CCom ""}
Causes a syntax error. Something about the #ALARM command being in the %expand function. This seems to work:
#ALARM +%expand(@Wait) {#VAR Wait 0;#EXEC @CCom;#VAR CCom ""}

Altered the two other syntax errors, which I had overlooked.

The Alarm thing is interesting... but I'm not sure how it could work. What'll happen is that during certain phases of scripting (haven't written the scripts yet, so I'm not sure exactly when) the script will call the alias 'PassControltoCommandBuffer' which sets the @ReservedControl variable to 'Command Buffer' and makes sure that @CCom is empty, and a few other things. The alias is supposed to keep repeating until the buffer is emptied. Once it empties, I should have added a call to a function like "ReturnControl" which would retrieve the last state from a variable like @PreviousState, or something, and then have it pick up where it left off on scripting.

Belmyrddyn

SubAdmin Joined: 18 Nov 2001 Posts: 5182

#ALARM +%expand(@Wait) is as useless as #ALARM +@Wait. Since you are concerned about the syntax checker being stupid, use some quotes in the format I gave ya. Other then that have fun testing it.

The only way it will do what you want and not bug out the syntax checker:
#EXEC %expand("#ALARM +@Wait") {#VAR Wait 0;#EXEC @CCom; #VAR CCom ""}