Register forum user name Search FAQ

Gammon Forum

Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the password reset link.

Due to spam on this forum, all posts now need moderator approval.

 Entire forum ➜ MUSHclient ➜ General ➜ Question for scripters and others using timers

Question for scripters and others using timers

It is now over 60 days since the last post. This thread is closed.     Refresh page


Pages: 1 2  

Posted by Nick Gammon   Australia  (23,133 posts)  Bio   Forum Administrator
Date Tue 30 Apr 2002 09:47 PM (UTC)

Amended on Tue 30 Apr 2002 09:49 PM (UTC) by Nick Gammon

Message
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?

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top

Posted by Nick Gammon   Australia  (23,133 posts)  Bio   Forum Administrator
Date Reply #1 on Wed 01 May 2002 04:35 AM (UTC)
Message
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

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top

Posted by Nick Gammon   Australia  (23,133 posts)  Bio   Forum Administrator
Date Reply #2 on Wed 01 May 2002 04:37 AM (UTC)
Message
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

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top

Posted by Storm Dragon   Denmark  (45 posts)  Bio
Date Reply #3 on Wed 01 May 2002 02:51 PM (UTC)
Message
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
Top

Posted by Magnum   Canada  (580 posts)  Bio
Date Reply #4 on Wed 01 May 2002 04:51 PM (UTC)
Message
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 ~ .

Get my plugins here: http://www.magnumsworld.com/muds/

Constantly proving I don't know what I am doing...
Magnum.
Top

Posted by Shadowfyr   USA  (1,790 posts)  Bio
Date Reply #5 on Wed 01 May 2002 05:53 PM (UTC)

Amended on Wed 01 May 2002 05:54 PM (UTC) by Shadowfyr

Message
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.

---------------------------------------------------------
|tell someone I have found a nice whatever at E-Bay item|
|#24826487.                                             |
---------------------------------------------------------


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
Top

Posted by Nick Gammon   Australia  (23,133 posts)  Bio   Forum Administrator
Date Reply #6 on Wed 01 May 2002 10:06 PM (UTC)

Amended on Wed 01 May 2002 10:07 PM (UTC) by Nick Gammon

Message
Quote:

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.


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.

Quote:

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 ;


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. :)

Quote:

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.

Quote:

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.


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.

Quote:

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.

         ---------------------------------------------------------
         |tell someone I have found a nice whatever at E-Bay item|
         |#24826487.                                             |
         ---------------------------------------------------------


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. ;)


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.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top

Posted by Nick Gammon   Australia  (23,133 posts)  Bio   Forum Administrator
Date Reply #7 on Wed 01 May 2002 10:09 PM (UTC)
Message
Quote:

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?


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.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top

Posted by Shadowfyr   USA  (1,790 posts)  Bio
Date Reply #8 on Wed 01 May 2002 11:01 PM (UTC)
Message
>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. ;)
Top

Posted by Nick Gammon   Australia  (23,133 posts)  Bio   Forum Administrator
Date Reply #9 on Wed 01 May 2002 11:20 PM (UTC)
Message
Quote:

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



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).

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top

Posted by Shadowfyr   USA  (1,790 posts)  Bio
Date Reply #10 on Thu 02 May 2002 03:06 AM (UTC)

Amended on Thu 02 May 2002 03:11 AM (UTC) by Shadowfyr

Message
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.
Top

Posted by Nick Gammon   Australia  (23,133 posts)  Bio   Forum Administrator
Date Reply #11 on Thu 02 May 2002 06:03 AM (UTC)
Message
I am a bit worried about Magnum's comment:

Quote:

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).

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top

Posted by Kalahn   United Kingdom  (138 posts)  Bio
Date Reply #12 on Thu 02 May 2002 08:26 AM (UTC)
Message
[/q]
eg.

10: west
grab gem
east


All 3 lines would be done in 10 seconds.



I think you are better to separate the delay/pause/sleep feature from the first delayed command.
eg.


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



There are a few possible names for pause - pausescript, sleep, sleepscript, delay, delayscript, delayexec ...

One advantage of using a separate command is you are moving away from needing another special character. You could allow the use of things like:


pause 10 say this is said in ten seconds.


Which would allow your one liners.

- Kal

Kalahn
Developer of the Dawn of Time codebase
http://www.dawnoftime.org/
Top

Posted by Shadowfyr   USA  (1,790 posts)  Bio
Date Reply #13 on Thu 02 May 2002 07:18 PM (UTC)

Amended on Thu 02 May 2002 07:20 PM (UTC) by Shadowfyr

Message
>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:

LDA buffer + X        - Get character.
CMP A, &h3A           - Compare Accumulator to :
BEQ success_address   - if = then branch. 

compared to:

LDA buffer + X
CMP A, &h70           - p
BNE fail_address      - if not = then branch.
INC X
LDA buffer + X
CMP A, &h61           - a
BNE fail_address
INC X
LDA buffer + X
CMP A, &h75           - u
BNE fail_address
INC X
LDA buffer + X
CMP A, &h73           - s
BNE fail_address
INC X
LDA buffer + X
CMP A, &h65           - e
BNE fail_address


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.
Top

Posted by Magnum   Canada  (580 posts)  Bio
Date Reply #14 on Thu 02 May 2002 09:16 PM (UTC)
Message
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. :) :)

Get my plugins here: http://www.magnumsworld.com/muds/

Constantly proving I don't know what I am doing...
Magnum.
Top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.


52,762 views.

This is page 1, subject is 2 pages long: 1 2  [Next page]

It is now over 60 days since the last post. This thread is closed.     Refresh page

Go to topic:           Search the forum


[Go to top] top

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.