[Home] [Downloads] [Search] [Help/forum]

Gammon Software Solutions forum

See www.mushclient.com/spam for dealing with forum spam. Please read the MUSHclient FAQ!

[Folder]  Entire forum
-> [Folder]  MUSHclient
. -> [Folder]  General
. . -> [Subject]  Question for scripters and others using timers
Home  |  Users  |  Search  |  FAQ
Username:
Register forum user name
Password:
Forgotten password?
(New message)
Subject: Question for scripters and others using timers
Name:
Your forum user name.
Register forum user name
Password:
Your forum password.
Forgotten password?
Message:
Message to be posted (in English, please).
Forum codes:
Check this if your message uses 'forum codes' or templates (auto-detected for new posts).
Forum codes Templates

Save this message ...

Subject review (reverse sequence)

Pages: 1  2 

Posted by Nick Gammon   Australia  (18,798 posts)  [Biography] bio   Forum Administrator
Date Fri 03 May 2002 10:37 PM (UTC)  [ quote  ]
Message
Quote:

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.


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.

Quote:

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


Same reason.

Quote:

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

#note tick

But perhaps is should be:

#note "tick"


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
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Shadowfyr   USA  (1,774 posts)  [Biography] bio
Date Fri 03 May 2002 07:18 PM (UTC)  [ quote  ]
Message
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.
main {
__if (Schrodinger_Cat is Alive or version >= "XP"){
____if version = "Vista" then Performance /= Number_of_Cores;
____call Functional_Code();}
__else
____call Crash_Windows();}
[Go to top] top
Posted by Magnum   Canada  (580 posts)  [Biography] bio
Date Fri 03 May 2002 06:48 PM (UTC)  [ quote  ]
Message
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"

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

Constantly proving I don't know what I am doing...
Magnum.
[Go to top] top
Posted by Shadowfyr   USA  (1,774 posts)  [Biography] bio
Date Fri 03 May 2002 05:52 PM (UTC)  [ quote  ]
Message
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. ;)
main {
__if (Schrodinger_Cat is Alive or version >= "XP"){
____if version = "Vista" then Performance /= Number_of_Cores;
____call Functional_Code();}
__else
____call Crash_Windows();}
[Go to top] top
Posted by Magnum   Canada  (580 posts)  [Biography] bio
Date Fri 03 May 2002 08:38 AM (UTC)  [ quote  ]
Message
Seems like a good idea. :)
Get my plugins here: http://www.magnumsworld.com/muds/

Constantly proving I don't know what I am doing...
Magnum.
[Go to top] top
Posted by Nick Gammon   Australia  (18,798 posts)  [Biography] bio   Forum Administrator
Date Fri 03 May 2002 01:30 AM (UTC)  [ quote  ]

Amended on Fri 03 May 2002 01:31 AM (UTC) by Nick Gammon

Message
Quote:

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


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.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Magnum   Canada  (580 posts)  [Biography] bio
Date Thu 02 May 2002 09:16 PM (UTC)  [ quote  ]
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.
[Go to top] top
Posted by Shadowfyr   USA  (1,774 posts)  [Biography] bio
Date Thu 02 May 2002 07:18 PM (UTC)  [ quote  ]

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.
main {
__if (Schrodinger_Cat is Alive or version >= "XP"){
____if version = "Vista" then Performance /= Number_of_Cores;
____call Functional_Code();}
__else
____call Crash_Windows();}
[Go to top] top
Posted by Kalahn   United Kingdom  (138 posts)  [Biography] bio   Moderator
Date Thu 02 May 2002 08:26 AM (UTC)  [ quote  ]
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/
[Go to top] top
Posted by Nick Gammon   Australia  (18,798 posts)  [Biography] bio   Forum Administrator
Date Thu 02 May 2002 06:03 AM (UTC)  [ quote  ]
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
[Go to top] top
Posted by Shadowfyr   USA  (1,774 posts)  [Biography] bio
Date Thu 02 May 2002 03:06 AM (UTC)  [ quote  ]

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.
main {
__if (Schrodinger_Cat is Alive or version >= "XP"){
____if version = "Vista" then Performance /= Number_of_Cores;
____call Functional_Code();}
__else
____call Crash_Windows();}
[Go to top] top
Posted by Nick Gammon   Australia  (18,798 posts)  [Biography] bio   Forum Administrator
Date Wed 01 May 2002 11:20 PM (UTC)  [ quote  ]
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
[Go to top] top
Posted by Shadowfyr   USA  (1,774 posts)  [Biography] bio
Date Wed 01 May 2002 11:01 PM (UTC)  [ quote  ]
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. ;)
main {
__if (Schrodinger_Cat is Alive or version >= "XP"){
____if version = "Vista" then Performance /= Number_of_Cores;
____call Functional_Code();}
__else
____call Crash_Windows();}
[Go to top] top
Posted by Nick Gammon   Australia  (18,798 posts)  [Biography] bio   Forum Administrator
Date Wed 01 May 2002 10:09 PM (UTC)  [ quote  ]
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
[Go to top] top
Posted by Nick Gammon   Australia  (18,798 posts)  [Biography] bio   Forum Administrator
Date Wed 01 May 2002 10:06 PM (UTC)  [ quote  ]

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
[Go to top] 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.

5,290 views.

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

[Reply to this subject]  Reply to this subject   [New subject]  Start a new subject   [Refresh] Refresh page

Go to topic:           Search the forum

[Go to top] top

[Home]

Written by Nick Gammon - 5K

Comments to: Gammon Software support
[RH click to get RSS URL] Forum RSS feed ( http://www.gammon.com.au/rss/forum.xml )

[Best viewed with any browser - 2K]    [Internet Contents Rating Association (ICRA) - 2K]    [Web site powered by FutureQuest.Net]