Gammon Forum : MUSHclient : General : Question for scripters and others using timers

Log on

Gammon Forum

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 (22,975 posts) bio Forum Administrator

Date

Reply #15 on Fri 03 May 2002 01:30 AM (UTC)

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

top

Posted by

Magnum Canada (580 posts)

bio

Date

Reply #16 on Fri 03 May 2002 08:38 AM (UTC)

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.

top

Posted by

Shadowfyr USA (1,786 posts)

bio

Date

Reply #17 on Fri 03 May 2002 05:52 PM (UTC)

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

top

Posted by

Magnum Canada (580 posts)

bio

Date

Reply #18 on Fri 03 May 2002 06:48 PM (UTC)

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.

top

Posted by

Shadowfyr USA (1,786 posts)

bio

Date

Reply #19 on Fri 03 May 2002 07:18 PM (UTC)

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.

top

Posted by

Nick Gammon Australia (22,975 posts)

bio Forum Administrator

Date

Reply #20 on Fri 03 May 2002 10:37 PM (UTC)

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

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.

45,585 views.

This is page 2, subject is 2 pages long: 1 2

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

Go to topic: Search the forum

top

Quick links: MUSHclient. MUSHclient help. Forum shortcuts. Posting templates. Lua modules. Lua documentation.

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