[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?
Question for scripters and others using timers

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

Pages: 1  2 

Posted by Nick Gammon   Australia  (18,769 posts)  [Biography] bio   Forum Administrator
Date Reply #15 on 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 Reply #16 on 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 Shadowfyr   USA  (1,774 posts)  [Biography] bio
Date Reply #17 on 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 Reply #18 on 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 Reply #19 on 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 Nick Gammon   Australia  (18,769 posts)  [Biography] bio   Forum Administrator
Date Reply #20 on 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

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,164 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]