Going crazy adapting to Mushclient... Help!

Now before a 100 angry people lash out at me for starting yet another zmud -> muschlient thread, I have read a whole bunch of them and none help me out much. Coding is not my problem figuring out how to use that code and where exactly to put it is.
Ok, here are my problems:

Just how exactly do you use a script? I mean I can and have gotten the basics of javascript down... but I have absolutely no clue where to put it, how to call it in the client, how to send parameters to it...
I keep seeing this, but with no explanation: send_to="x"
i think 12 means script? but just how does that work? I guess it kind of fits in with the question above.

Since I'm coming from zmud, I have been able to succesfully convert about 5% of my triggers to mushclient, basically those that just contain one or two simple commands like stand, and I've been able to set up a bunch of aliases. good so far...

just two quick examples of things I can not do.
ok look at this (I just copied from the edit trigger screen)
trigger = ^You draw back and balance into the Eagle stance\.$
send = world.SetVariable("stance", "egs");
world.tell("EAGLE");
world.note(\"This monster is worth avoiding!\"); //from the help files.

enabled=yes
sendto = script
omitfromoutput=yes

the variable is now set and works (whew!) but the none of the notes works... in zmud I just use #ECHO

second type of triggers that I have absolutlely no clue how to implement in mushclient: triggers that turn on/off groups of classes.
most of the other problems will really be solved once I understand how to make a trigger work with a script.

also if I dont echo commands. the output comes out all messed up. eg
blah blah wow did
you
just say that?

Its 4am i need to go but please help! i am so totally lost and the help documentation doesnt "help" me :)

Mushclient's scripting infractructure can be indeed confusing if you are used to the TinTin-like model, which is what Zmud's scripting is based upon. In Zmud, all scripting happens literally 'inside' the client, Zmud parses commands you type, figures out what they mean and processes them. Mushclient uses a newer model of embedded scripting, where the actual program (Mushclient in this case) does all of its scripting in a separate module. In Mushclient's case, this module is a Windows DLL representing an interface to a script interpreter, and Mushclient communicates with it using Microsoft's COM. In short - scripts are separate from Mushclient. Scripts can be loaded into Mushclient from a main script file, this is done by editing the file in any text/code editor (e.g. Notepad) and saving it, preferably with a standard extension (.js for javascript). Once you have a script file you need to go to the Scripting dialogue in File->World options (or by clicking on its button on the toolbar), check the 'Enable scripting' option, select a scripting language from the dropdown box, and then browse to your saved script file and open it. If the script file doesn't have any errors it will be loaded into Mushclient. From here on, Mushclient can access any procedure declared in your script file. If you want a trigger to access some procedure you simply put the procedure's name into the 'Script' box of the trigger's edit dialogue. When the trigger fires it will call the procedure with that name. When it does call it it will pass 3 arguments to it, so any procedure that needs to be accessed by a trigger/alias, needs to accept these:



name - is the name of the calling trigger/alias
output - contents of the trigger/alias's send box
wildcards - an array of wildcards, same as %-substitutions in Zmud or Mushclient's triggers/aliases: wildcards(0) = %0, wildcards(1) = %1, etc.

Timers are different since they only pass 1 argument - their name:



To call Mushclient from the script, you use callbacks. These are defined in a special object 'World', which is automatically made visible to the scripting engine, so to do an echo you use:



Another common way of using scripts is to put them directly inside triggers/aliases, just type the script in the Send box and select "Scripting" for the Send to option. Nothing needs to be put in the "Script" box in this case. This way you can do pretty much anything that could be done in the script file, it is especially useful for doing simple tasks, like enabling/disabling triggers/aliases/timers/etc, calling a procedure in the script file without having to make it accept the standard number of arguments, etc.

Confusion about the format of triggers/aliases/timers posted here is resolved quite simply - find some trigger with confusing formatting on these forums, copy it (from-to and including the <triggers></triggers> tags), then go to your Mushclient world window, open the Triggers dialogue and hit the Paste button in the lower right corner. The trigger will be added to the list. You can now open it for editing and see what all that syntax means. The same works in the reverse order - make a trigger in the Trigger edit dialogue, click Add, click Copy in the Triggers dialogue, now go to the forums, browse to this thread, and paste the contents of your clipboard into the text form. You will see the XML source of the trigger.

The reason why your example alias isn't working might be that you haven't changed the Send to option. If it's set to "World" then whatever you typed in the Send box will go directly to the mud as-is, and will be misunderstood there. Select "Scripting" and it should work just fine. You can try posting your alias here, using the method above, that way I can give a more specific diagnosis.

Regarding your second problem - enabling/disabling classes of triggers/aliases... I take it that by classes you mean groups of triggers/aliases. In Mushclient those are (conveniently enough) called "groups". To group a bunch of aliases you need to put the group's name in the Group box of every alias belonging to the group. Here's an example (you can copy it here and paste in Mushclient's Aliases dialogue to make more sense of it):


You'll notice that this alias calls a script in the script file. This could (but doesn't) look like this - vbscript here:


To enable the group this alias belongs to, I could (but don't) use this alias:

Also copy it here and paste in Mushclient. This alias demonstrates using scripting directly from a trigger/alias. Look at its 'Send' property in the dialogue - it has "Scripting" instead of the default value of "World". This means that the contents of the Send field will be processed as a script, instead of getting sent directly to the mud. You could use this alias to disable the 'BalanceLossCommands' group by simply typing in the command window:



By pure coincidence, this alias also demonstrates how scripting works in Zmud. This alias can be used from another alias, by selecting 'Execute' in the 'Send' dropdown, a trigger (using the same method), or a timer (same thing). This makes this alias a... *gasp* Zmud scripting instruction. If you really wanted to, you could emulate most of Zmud's scripting yourself by just putting everything into aliases, or invent your own scripting language. Unfortunately, this method of simplifying coding wouldn't be very efficient, thus better ways are normally used.

You have the general idea here - in fact you don't really need "world" for most things, as the script engine tries to use it if it can't make sense of what you have written anyway. eg. this would work in most cases:


SetVariable ("stance", "egs");
tell ("EAGLE");
note ("This monster is worth avoiding!");


Your problem with the notes not appearing is the "omit from output" bit. There is an idiosyncracy (bug?) in MUSHclient that when you check "omit from output" and do notes in a "send to script" the notes are also omitted.

I gather you are just testing here, but the work-around is to either:

• not "omit from output" if possible; or
  
• put the notes in a script file, not "send to script" - this will work.

To use a script file, do as Ked said:

• Make a separate file using Notepad, the built-in notepad, or any text editor. Call it something reasonable (eg. myscript.js)
  
• In the world's configuration screen go to the "script" tab and select the correct language (eg. Jscript) and then click Browse to select your script file as the file to hold your world's scripts (eg. "myscript.js").
  
• Check "enable script"
  
• Put the trigger script into your script file with three arguments as documented in various places. Your example would be:
  
  

  
  function MyTrigger (thename, theoutput, wildcardsVB)
  {
  var wildcards;
  
  
  // convert wildcards to Jscript variables from VB arrays
  // - not necessary if you don't want to access the wildcards
  
  wildcards = VBArray(wildcardsVB).toArray();	
  
  world.SetVariable("stance", "egs");
  world.tell("EAGLE");
  world.note("This monster is worth avoiding!");
  }
  

  
  
• Instead of doing "send to script" simply leave the "send box" blank and put the name of the script function into the trigger's "Script" box (in this case "MyTrigger")
  

Once you have done this and got it working to your satisfaction you can modularise your triggers, aliases etc. by turning them into plugins with the plugin wizard. This lets you share triggers, aliases, timers, scripts etc. between various worlds easily without having to load them into each one (you just load a single plugin).