Question for scripters and others using timers

I am planning to make it easier to do "timed" events in MUSHclient, particularly in triggers. Here is what I have in mind, from the release notes for 3.18. What is described below is implemented already, and works, but I am wondering if there is a slightly better way of doing it? Any comments from users would be appreciated.

---

Added "send delayed" option for triggers. This lets you do delayed sending with a minimum of fuss. To use this, set up a trigger, and set the trigger to send to "world (delayed)". Then in the "send" text specify each line with a delay in front of it, like this:


say See you soon
east
;
; go to shop
;
1; west
2; north
3; west
;
; get some food
;
4; buy food
;
; go back
;
5; east
6; south
7; east


(You may find the new "trigger edit" box helpful for entering such a long command. Press Ctrl+Enter to start a new line).

The syntax for this delayed sending is:

• The "send" text is broken into lines
• Blank lines are ignored
• Lines starting with a semicolon are ignored (treated as comments)
• Lines with a number followed by a semicolon are treated as a delayed send - the command after the semicolon is queued to be sent after the nominated number of seconds (using a temporary, unlabelled, one-shot timer)
• Lines which do not start with a number followed by a semicolon are sent immediately (eg. "east")
• Lines with zero seconds are sent immediately (eg. "0; west")
• If you want to send a semicolon at the start of a line, you can do that by something like this:
  
  
0; ; sigh <-- immediate send
5; ; sigh <-- delayed send

• The time must be in the range 0 to 86,399 (23 hours, 59 minutes and 59 seconds).
• Leading and trailing spaces are discarded.
• If the command (after the semicolon if any) starts with the speed walk prefix, then the command is queued as a speed walk.
  
  eg. If the speed walk prefix is "#" ...
  
5; # 5n3e4s

  

The times are not cumulative, the are all measured from the time the trigger fired. The example above shows how to make things happen every second. It is possible to make things happen in reverse order, like this:


5; north
3; south
1; east


In that example, the commands would be sent in the order east, south, north.

---

My questions are - while there is still time to change it ...

1. Is semicolon the best delimiter? Maybe colon (":") or something else?
2. It might be handy to have an option to do a world.note when the time elapses?
3. What would be the syntax for that? Maybe this:
   
   

   
       5; go west                //  normal send
       6 >N;  Spell time is up   //  >N means "Note"
       10 >S; 3e 4s 5w           //  >S means "speed walk"
       

4. Any other suggestions?

And, maybe to set multiple variables, something like this ...


0 >V target; %1
0 >V destination; %2
0; @destination; kill @target
1; cast heal self


The intention here, in case it is a bit obscure, is that the notation ">X" means "send to X", where the default is the MUD, however it could be:

V - variable
S - speedwalk
N - note (output window)

In the case of the variable, the V is then followed by the variable name.

Thus, the above would, using just one trigger:

Set variable "target" to wildcard 1
Set variable "destination" to wildcard 2
Go to the destination, and kill the target
(eg. west; kill dragon)
After 1 second, cast a spell to heal oneself

Thinking about it, I'm not sure I want to support the notion of "delayed" setting of variables, so maybe the variable setting has to be done now. eg.


0 >V target; %1 <--- is OK
20 >V target; %2 <---- is NOT ok


or, simpler:


>V target; %1 <--- no time needed


I dont think a semi colon would be the best delimiter
because on the mud I play it is used as the short version of grouptell, a colon would be better perhaps even make it so the user can choose his/her own like with scripting

To be frank, I probably won't use this much. I see it's appeal for those who don't know how to script, but since I am confortable scripting, I prefer the current method.

Seems to me, you may end up building a scripting language of your own, as you add more and more actions that can be done directly with the "Send" box. That's more to learn for the newbie, and I don't know if that is such a good thing.

...What you will probably end up with, is people who only use the "Send" box, and people that script, and not much of a mixture. It may be that this is already the case...

Anyway, I don't see much harm in doing things this way, however, I agree, if you need a special character, it may be a good idea to allow the user to customize the character. Most of the punctuation marks are shortcuts on various muds. For example, both ; and : are used on the mud I play. My preference would be the ~ .

Blank lines are ignored when?? Always or only when a 'delayed' send is used? If only when using a delay, then had do you send a blank line if you need one?

Sometimes you may need to use a blank line in a send, like my trigger on a previous post that sends a shop list. As for delimiters... That is a hard one. It would be better to use a two character combo, since any single character is likely to be employed for other purposes. While most clients default (for some incomprehensible reason) to one of the fixed width fonts that they scrambled, some muds may actually choose to use the real ASCII standard you get in DOS and even Linux. That font (called Terminal) has characters even for the unprintable control characters under 32. With any single key combo someone is going to end up wanting to use it for some other purpose.

For instance I am using ` (the symbol above ~) for command stacking because both ; and : are used for types of emotes on channels. Not to mention that : is far more commonly used for other purposes in normal chat, tells, etc. than ;.

My original thought on such an addition when it was suggested was that they would be implimented in the script as a world.delaysend command, where you would expect to have some way to do such a thing by doing world.delaysend(text,time). Doing it in the triggers send command is in my opinion more likely to cause confusion. Regular expressions are bad enough when you can't test them 'while' editing them. However if you do add it then as I said a two letter command of the \x sort is both more unlikely to be used by accident and more 'standard' when adding commands of this type. I would suggest however also making it so that any command directly entered into the command window or through macros would override any queued commands in the delay list, since you may need to react suddenly to something and having to wait for all of them to process before using another one could be very bad.

Of course rereading a bit it looks like you want the delay to work even if you do something else (as with the

6 >N; Spell time is up // >N means "Note"

but this opens an entirely different can of worms.. Maybe two /x commands one for delayed (but interruptable) and one to send even if new commands are sent by something else. Being able to send a note or similar is definitely interesting though, but again I would suggest \>, since that is much less likely to be used than -> or > as part of the normal text people will want to send. It is a lot easier to require that people use \ for a \ than \>, \;, etc. for all the other standards characters you may decide to use as commands. ;)

NOTE!! (a bug I forgot to report): I even had to set the immediate script command to ## because A) I use / sometimes where it might be mistaken for a script request (in things like 'to tell') and B) a bug I resently came across in MUSHclient treated a single # as a command request, even though it was part of the same continuous line. Looks like it incorrectly used the line break where the text wrapped as a hard break, instead of as a wrap like it should have. i.e.


produces a tell of the first line 'and' an error saying that it couldn't execute the non-existant script routine called 24826487. This is as I said easy to fix by making immediate commands start with ## instead of # or the default /, but it is definitely a glitch. ;)

As a side note: I would love to know the logic behind abandoning the original ASCII since it means that 'all' text based systems display virtually every text doc based on the changed font incorrectly when using other than A-Z, a-z and 0-9. :p If they wanted to mess people up they should have just switched to EBCDIC. lol

There was a recent post from someone who wanted to detect a spell cast with a trigger, and tell himself 30 seconds later when it had worn off. At present you can only do that by:

1. Making a trigger to match the text - OK, so far so good
2. The trigger calls a script
3. The script adds a timer with AddTimer
4. The timer calls a second script
5. The second script does a world.note
6. Plus, maybe he has to enable scripting, and create a script file, and point the scripting configuration to that file

This seems like a lot of work for what he wanted to do. My proposed solution would be something like this:


Trigger: You have cast spell *!
Send: 30 >N ; Your spell has worn off!
Send to: Delayed send


A lot simpler and easier to explain, I think.



I understand that for command stacking, but as I was trying to describe, only the first instance of the delimiter would have any effect, and then only on the "delayed send" option. For example, to send a semicolon you would just do it like this:


30 ; ; sighs


The first one is the "time -> message" delimiter, the second and subsequent ones are just part of the message.

However I am happy to use one that is less likely to confuse, such as ~

Right now I am out of string space in the world file, and until that is revamped I need a fixed delimiter. Later on it could be made variable, although that conceivably would cause problems for people who share triggers, and use different delimiters. :)



I am using timers for this purpose for this reason, not the queued commands previously used for speedwalks. For speedwalking, I assumed that you would want to get to your destination before doing whatever it was you wanted (eg. buy bread) however for delayed commands, I assume that this is not an issue. Thus, the example of "your spell has worn off" is simply added as a timer, which will fire in (say) 30 seconds, however you can still do other things in the 30 seconds.



Again, this delimiter would only apply in the first part of the message. Thus you could do this:


30 >N ; --->Note: your spell has worn off; run away <---


Note how the >N only has effect before the semicolon, and only the first semicolon has any meaning. I think this is fairly bulletproof.



I cannot reproduce that. I have tried three possibilities:

1. Hard wrap (Ctrl+Enter in command window):
   
   
# script line 1 (newline)
script line 2

   
   In this case the single script character makes the whole multi-line command be treated as a script.
   
2. Soft wrap (narrow window)
   
   
say hi there someone (wrap at window edge here)
#world.note "blah"

   
   World displays:
   
   
You say in human 'hi there someone #world.note "blah"'

   
3. Multi-line command, with script on second line
   
   
say hi there someone (newline)
#world.note "blah"

   
   Script prefix is ignored, as it is only tested at the start of the command window, not on a per-line basis.

Blank lines are ignored in the delayed send option. To send a blank line you would do this:


30;
0;


The first line sends a blank line in 30 seconds, the second sends a blank line now. However a totally blank line is ignored.

>I understand that for command stacking, but as I was
>trying to describe, only the first instance of the
>delimiter would have any effect, and then only on the
>"delayed send" option. For example, to send a semicolon
>you would just do it like this:

>30 ; ; sighs

Ah.. Well that would work then. I was asssuming it acted
more like a command delimiter that could let you 'compress' commands into a single line.

>However I am happy to use one that is less likely to
>confuse, such as ~
Well if it only acts on the first instance then this is not
a major problem. It is only hepful to use a rare symbol like ~ if real complicts can result. In this case it probably doesn't matter, though ~ is more distinct and thus probably easier for people to see and say, 'Ah.. It's doing something special'.

>>I would suggest however also making it so that any
>>command directly entered into the command window or
>>through macros would override any queued commands in the
>>delay list, since you may need to react suddenly to
>>something and having to wait for all of them to process
>>before using another one could be very bad.

>I am using timers for this purpose for this reason, not
>the queued commands previously used for speedwalks. For
>speedwalking, I assumed that you would want to get to your
>destination before doing whatever it was you wanted (eg.
>buy bread) however for delayed commands, I assume that
>this is not an issue. Thus, the example of "your spell has
>worn off" is simply added as a timer, which will fire in
>(say) 30 seconds, however you can still do other things in
>the 30 seconds.

Well.. I still think you should be able to interrupt it. For instance if hypothetically you did this:
0; pull lever
5; grab gem
0; south
0; east

and then while waiting those 5 seconds something that can kill you enters the room and you flee south, it would be real inconvinient if there was also a dangerous mob in the room 2 south from the lever and your timed command threw you in with it. Sometimes you "don't" want it to continue as planned when things go wrong. ;) Of course if you are in such a dangerous place you may not want to be using that sort of thing anyway. lol

>>NOTE!! (a bug I forgot to report):
>I cannot reproduce that.

It occures to me that I may have copied the text from the output window. I have several triggers set up to warn party member that spells have fallen and sometimes when trying to type a post it dumps one of these warnings into the message. As a result I sometimes abandon the post in favor of reentering it. In that case each line cut and pasted to the command area in a block is treated as a seperate command. This was problably what happened with the odd call. If it does it again I'll try to pay better attention to how and when it occured. ;)

In your example, it would have sent:


pull lever
south
east

and then sent "grab gem" 5 seconds later.

However I think this confusion is showing me the path to a simpler solution. :)

How about this?

• 3 different trigger actions:
  
  • Delayed send
  • Delayed note
  • Delayed speedwalk
• Each one has a very simple syntax:
  
delay-in-seconds: rest of command line(s)

  
  Delay must be between 1 and 86399 seconds. ie. no zero delay.
  
• No "comment" lines
• No special treatment of blank lines

eg.


10: west
grab gem
east


All 3 lines would be done in 10 seconds.

As for changing your mind, I have added new script routine: DeleteTemporaryTimers. This could be called to scrap outstanding events like this (assuming you didn't have others of your own queued up).

Hmm. Yeah, was still thinking one after another. You suggested change is better. It means using multiple triggers if you want to send to note, send to world and do a speedwalk all delayed, but it is certainly a lot less complicated. lol It does however mean extra triggers if you want to delay some actions longer or shorter than others, unless you still allowed ; and ;;, but used it as a command delimiter. So you could do:

10: west;grab gem;east
5: say Getting the gem in five seconds.;; be ready!
look west

With blank lines and non-specified lines like the 'look west' counting as part of the prior line, as though seperated by ;.

Of course the odds of anyone using ; 'in' a sentence is quite low, but yah gotta give them a way to do it. ;)

This would be the best of both worlds, since you can delay commands and still use only one trigger for several commands, including 0: immediate ones. Doing it this way would also mean you could still use the other send types, but they probably should still be set up as different triggers, if for no other reason than being able to display a small icon in the trigger list indicating 'where' the output is actually being sent. ;) Or even a desriptive word/phrase, but that takes up a lot more space in what can be a cramped window.

I am a bit worried about Magnum's comment:



I think he's got a good point. :)

My revised solution would let me amend to eventually put the number outside the text (once the world file format is enhanced) and it would be quick to strip the "seconds" portion from the start of the field and move into a separate field.

Whereas other ideas (like my original one <eg>) don't lend themselves to that (eg. different delay lengths).

[/q]
eg.

10: west
grab gem
east


All 3 lines would be done in 10 seconds.

say this is done immediately
pause 10
say this is done in 10 seconds
west 
grab gem 
east 
pause 7
say this is done in 17 seconds
smile

pause 10 say this is said in ten seconds.

>I am a bit worried about Magnum's comment:

>>Seems to me, you may end up building a scripting language
>>of your own, as you add more and more actions that can be
>>done directly with the "Send" box. That's more to learn for
>>the newbie, and I don't know if that is such a good thing.

>I think he's got a good point. :)

>My revised solution would let me amend to eventually put the
>number outside the text (once the world file format is
>enhanced) and it would be quick to strip the "seconds"
>portion from the start of the field and move into a separate
>field.

>Whereas other ideas (like my original one <eg>) don't lend
>themselves to that (eg. different delay lengths).

Hmm. Yeah he does have a point, but as I said, if you needed to make 5 different delays for commands + a note + a speedwalk, etc. it starts to get really insane keeping track of all the triggers that are specific to those commands. As long as a similar delay function is supported in actually scripting, then go for it. But keeping track of a lot of triggers is a real nightmare and having to seperate every different delay into a seperate trigger only makes things more complicated imho. Being able to set up such delays easilly in scripts would ironically let you use a single trigger to do things the way you suggested, so is likely for me to be the better choice. Building the same ability into the triggers themselves has drawbacks no matter how you impliment it. Either you have to sort through multiple identical triggers (ugh) or set it up in the send box (slightly less ugh imho). However, this is no more complicated (and actually less so) than using regular expressions. And in retrospect.. Being able to stack the commands on the same line as the time is probably not a good idea. I even got the example wrong, since I failed to account for : being used, which would require :: for the normal one. So make each command be a seperate line, but allow one ##: to set the delay for those that follow, so:

0: west
grab gem
east
5: say Getting the gem in five seconds:: be ready!
0: look west

would make more sense than what I had. ;) Other than the :: there is nothing about this that is terribly confusing. Certainly less than regular expressions and most newbies (and even non-newbie like me) have trouble with those. By comparison the above syntax is as clear as glass. lol

To Kalahn -> I think you made the same ussumption I did. The delay command 'only' delays the commands that follow it (in it's original form only the one on the same line. All other lines would send immediately or at some other delay. The suggestion I made was that the command would set a delay, then all commands after it (same line or not) would be delayed, but you could set different delays for different sections. Which is less confusing since you can simple look for the ##: command to see what that and any following lines would delay at. The suggestion of using ; was precisely so that if someone wanted to they could 'stack' the commands on a single line, but.. that may not necessarilly be a good idea anyway. Using a full command like pause, etc. would make the parser operate a tiny bit slower, which is not necessarilly a good thing. from a ML stand point you are looking at:

compared to:


And actually it is worse than the above since this is a drastic simplification that uses Apple ][ assembly. Even something like C adds additional overhead and the above is over simplyfied. But assuming the first example took 7 clock cycles then the second version uses more like 39. In the real world you can probably triple the time of the second one and double the first for 117 and 14 cycles. It adds up fast when you start processing strings instead of doing a simple one byte comparison.

Nick, I feel I understand what you are doing here, even though it seems there is confusion among the other readers...

(Shadowfyr - You wouldn't need :: because the : is not the first : on the line. Only the first : would be examined by mushclient, as the symbol to parse the 'front' and 'back' end of the line.)

I think the confusion here serves as an example of the point I was making. For me, it seems pointless to teach new users this new 'scripting' language when you already allow for one of three to be used. VBS is not that hard to learn.

However, that said, I DO see value in allowing users to perform advanced actions directly via the "Send" box... but this syntax thing is a bit of a nightmare. Perhaps what would be more user friend is multiple send boxes, the first being "Send immediately", and then an option to "Send Dalayed", where the user enters the delay period in an appropriate box, then ALL of the commands they want send after that delay in a seperate "Send" box.

You might format it in this way:

"Send Later" button.
-when pressed, user is prompted to enter delay.

"Send", "Send in ## seconds", "Send in ## seconds" pulldown menu.
-The contents of the "Send" box are variable, and depend on what is currently selected in the pulldown menu. The user can clock the "Send Later" button to add a new time frame, which will be added to the pulldown menu, and that time frame will be made the "current" one shown.

Optionally, tabs could be used instead of a pulldown menu.

On a slightly different note, I've never been thrilled about configuration windows with sub windows inside them, which need to be scrolled. You can't increase the size of the configuration window [They are usually hard coded in size], thus you can't use your screen real estate to 'get rid of the scroll bars'. Should you decide to implement this idea, it may be wise to make the alias/trigger configuration windows larger, weather you make them resizable or not. :)

The suggestion above only takes into account "Send" lines, not "Note" lines... I don't know offhand how to work that out... but I feel that if you really want to make life easier for newbies, it should be mostly point and click, NO coding in the Send box. Find a way to do it with tabs/pulldowns/buttons etc, otherwise, just teach them to script. :) :)

Kalahn, the problem I have with this is that "pause" (or any other word you might reasonably come up with) may have meaning on the MUD, and thus your example would not allow you to send "pause 10" to the MUD.

Thus it is probably better to have this:


say this is done immediately
#pause 10
say this is done in 10 seconds
west
grab gem
east
#pause 7
say this is done in 17 seconds
smile


Once you do that you are back to a prefix, and the question about what happens if the prefix has meaning on the MUD - which it might. :)

I suppose, you could say, 'well if "#pause has meaning", and you want to put it in the send box, then you would put "##pause" where the two "##" get changed back to "#"'.

In any case, we seem to be heading here to a inline scripting language, something I was thinking about, and which - if I do that - I want to implement after some lengthy discussions with interested parties.

If you accept a prefix, then I think actual words are simpler to follow than my original syntax, and then you can use other words as well. Here is an example ...


#note tick // note in output window
say hi there // sent direct to MUD
#doafter 5, "eat drink" // queued command
#addtrigger "@target leaves *", "%1" // make a trigger
#sound "ding.wav"


Probably the simplest way of doing this would be to simply allow an inline interface to existing script commands, effectively allowing you to use all the functions documented already as "exposed" script functions, however inline (as in most of the examples above). This saves a whole lot of extra documenting.

The nice part about this is it would be "language neutral". That is, to the extent that you can solve problems with inline scripting, you don't have to care if the player is using VBscript, Jscript or Perlscript.

My tentative plan now would be to de-implement the "delayed send" in trigger and aliases, release version 3.18 so the other nice enhancements are available for playing with, and make inline scripting available in the next major release.

Seems like a good idea. :)

Yes.. Being able to access the built in features directly would be a lot nicer. Only... you would need to make it consistant with existing command windows use to avoid confusion. So, it would need to use the user defined command identifier, wether '/', '#', '##", etc. And you run into the problem where from the command window you have to use 'world.command', but in the send you only use 'command'. Obviously this requirement was intended to avoid collisions in cases where some fool named their script the same thing as a inbuilt command, but it would make things a great deal more confusing if the syntax changed depending on command and send windows. Perhaps making 'command' default as the inbuilt and making it 'script.command' for cases of collision would make more sense when using them from the command window.

Alternatively, you can make it a requirement that the client always calls the internal command and ignores any with the same name in the script. It is not likely to happen often and fixing one for use from the command window would be as simple as making 'sub command' into 'sub mycommand'. I never saw the point of having to use 'world.' in front of inbuilt commands when called from the command windows in any case, beyond what any decent coder should know not to do anyway. ;)

ShadowFyr, I think the point is, you can only call Mushclient Funtions\Subroutines (The ones listed on the functions page), NOT your own Funtions\Subroutines.

One thing I AM curious about, in his example, Nick puts:

#note tick

But perhaps is should be:

#note "tick"

?

I got the point. I am jsut saying that it could be confusing to have to use just the name in send boxes, but world.name from the commmand window (where you can call you own scripts). It is an inconsistency and not something that I think should have worked the way it does even in the command window. In scripts you 'have' to use world.name to distinguish commands, there is not any real reason to require it in immendiate mode and making it so the same commands in send boxes don't need it at all is potentially confusing and very inconsistant.

This was done to get access to the MUSHclient interface, which VBscript (and Jscript etc.) do not natively know about. I export into the scripting engine the "world" COM object, and then the various interfaces from that object (eg. world.send) can then access it.



Same reason.



Ah well, I was assuming that the MUSHclient parser - in the process of preparing what you typed for the script routine - might make some assumptions. One might be that for a single argument (eg. send, note, tell) that it isn't necessary to quote it, which would be more consistent with other clients anyway. It also gets around the problem of using quotes inside the message. eg.

#note You see a "dragon" here
#send Type "enter" now