VBScript (HTML) vs VBScript (MUSHclient)

Is it the EXACT same thing or are the some differences between the two?

Just need to know because I'm learning VBScript for webpages and I'm picking up on it rather well and I was hoping that what I'm learning is exactly the same as what's used in MUSHclient.

They're exactly the same thing. Just make sure you understand the difference between VBScript the language and the DOM. You obviously won't be interacting with the DOM when you use VBScript through MushClient.

Umm.. Yes and no. lol

The main differences are fairly obvious.

1. Things that require IE's method of using objects by specifying the CLSID won't work. This is not really a script 'feature', but an IE one that no one else uses, let alone supports. The same rule applies to the hand full of other methods that exist in browsers to use such things. As a result any such object needs to be created using CreateObject, which you almost never see used in web pages or even very often in full VB apps.

2. Things like this:

are a major no-no. In a browser the script runs parallel with the browser, so you can infinite loop things and perform other type of activities and the browser will usually keep working. In Mushclient trying to do something like that will hang the client and force you to use Ctrl-Alt-Del to get out of the situation. Unless the loop is short and simply does something, then exits, you have to code things so that you call them over and over to perform the task instead. In the case of the above, you would use a timer to call the code over and over forever, rather than looping it. Same is true of delays that are intended to make something 'pause' for a certain time before taking action. Anything that prevents the code from exiting will prevent Mushclient from regaining control and functioning.

3. Forget about any fancy tricks that use text boxes or other 'built-in' features that are common to browsers. With the exeption of the MessageBox and alerts, which are built into the script, these things don't exist in Mushclient.

4. Things that the script does in Mushclient won't happen until 'after' the script has exited (this is the non-parallel issue again). In other clients and in browsers, a second script could begin responding to the results of a command sent by the first script or some other event, even before the first script finishes. With Mushclient you have to keep track of everything you want done 'after' all the events have been dealt with, before you can post output or expect the client to respond to certain results or the commands your script sent. Example"

send "Stats sword"
setvariable "sw_str",""
setvariable "sw_type",""
...

There may be legitimate case in HTML where this 'can' work and it apparently will in some other clients. I can't see how without risking lag eating the results, but it apparently can and does. If you are in the habit of expecting this to work, break the habit now. It is imho a bad practice, even if it can work in some clients or on a web page (the later of which I am not sure about).

Can't think of any more glaring differences right now. It is definitely different in the sense that it won't work 'quite' the same way as a web page may. In terms of if it is identical in terms of the code itself and how vbscript works in general, then it is identical, since it uses the same engine to run it.

VBScript is the same no matter where you use it. What changes is the surrounding "API calls" (to MUSHclient functions, or to IE functions, or whatever environment is calling the script.) What also changes is the mechanism in which the script is run, i.e. when control is passed back and forth, etc. This is all, however, completely dependent on whatever is calling the script.

So basically, VBScript (or any other scripting language, such as Javascript or Perlscript) will have the same syntax and mostly the same behavior, but any functions that aren't built in to the language (i.e. accessing the world entity in MUSHclient, or some internet thing in IE) will most likely no longer function - unless the environments each implement their own version of the function, independent from the core set of built-ins.

It's actually a lot like normal programs and the OS they run in. A C program will function more or less the same everywhere, unless you use OS-specific behavior (for example, Windows API calls.) The OS also determines which programs are run when. So while it's not exactly the same situation for scripts, it's quite similar.

Most things happen immediately, however you can't do (say) "send <something>" and hope to get a response immediately. This is because the send itself may be queued, and the response may not arrive for a few seconds. Thus in that sort of situation you would set up a trigger to handle the response.