How to make basic triggers/alias's/substitutes

I just started using MUSHclient, and i had gotten news about it from a friend. But the basics page isnt really helping me a whole lot. The most ive figured out how to accomplish is making highlights. But i would like to learn how to make substitutes/alias's/triggers and other things. If someone could just give me some basic learner tips, That would be awesome. Thanks

That is such a general question it is hard to answer it. Perhaps if you give a specific example of something you type, and what you want it to send (ie. an alias), or something that arrives, and what you want to do when it arrives (ie. a trigger), we can help more.

I get frustrated alot and i swap back to my older clients because i just cant figure out how to get the trigs to work for MC. For expample: #ac {^R.I.P.}{get all.coins corpse} 0
is a trigger i use to loot corpses after they die. And the R.I.P. line is what triggers it. I dont know how to do that for MC

I can also do alias's which i understand a bit more each time i try them on MUSH. but for instance:
#alias {VK_F4}{eat all;drink water}
(thats for wintin)
#hotkey {F4}{eat all;drink water}
(thats for JMC)

I also need to learn an easy way to highlight words/names/numbers etc. Instead of clicking on options or triggers or configurations or whatever. On the other clients its really simple. On both JMC/Wintin you can type
#highlight {green}{blahblah}

And i think if i could figure out a quicker/easier way to do those 3 functions, the rest would just fall into place.

Those are all quite easy to do if you flip through the documentation. These are both links off of MUSHclient's front page: http://www.gammon.com.au/mushclient/aliases.htm and http://www.gammon.com.au/mushclient/triggers.htm

For the alias, you just go to Game->Configure->Aliases (or press ctl-shift-9) and put VK_F4 in the "match" section, then enter the commands sent in the "send" field. Don't use command separators in the send field, an enter means sending a new line.

Hotkeys are set with Macros (ctl-shift-2) for any of the function keys. Keypad keys are set with the keypad menu (ctl-shift-1).

For highlighting, just set up a trigger (ctl-shift-8) and don't put anything in the send field, just modify the "Change colour and style to" part however you want. You can have the text bold, underlined, in italics, any colour for text and background you want.

You misunderstood Shaun, the VK_F4 is a "virtual key called F4", he is attempting to make a "macro" in this case...

Hope that clarifies something a little more.

Laterzzz,
Onoitsu2

I don't understand the confusion here. To make a trigger that matches "R.I.P.<something>" and sends "get all.coins corpse", you go into the trigger configuration dialog (Shift+Ctrl+8 is one way of getting there), and enter:


Match: R.I.P.*
Send: get all.coins corpse


Then hit OK to save the trigger. What is confusing about it?

The thing about MUSHclient is that it is not another Tintin clone, with a GUI interface wrapped around it. It was designed from the ground up to have a GUI interface, and hopefully be easier to use than having to memorise command-line commands.



Find the Macros configuration dialog (Shift+Ctrl+2 is one way), and scroll down until you see the line for F4.

Edit that, and put "eat all;drink water" into the "send" box.

For the semicolon to work the way you want make sure you have enabled Command Stacking in the Input -> Commands configuration dialog.

• Double-click the word you want to highlight (or click and drag to select it).
  
• Under the Game menu choose Highlight Word (Ctrl+Alt+H).
  
• The word(s) you selected are entered into the dialog box for you (or just type them in).
  
• Choose the colour you want to change it to (text and background colour).
  
• Hit OK.

This simple process actually creates a trigger - you can always edit the trigger later to change the word, or the highlighted colour.

Also I think if you are looking for on-the-fly triggers/aliases you can get that with addxml.

http://www.gammon.com.au/forum/bbshowpost.php?id=7764&page=2

Nick's first post there describes how to use addxml. It works fine for any simple trigger you want to create. If you want to create an alias this way you will have to make a few changes but it's basically the same.

Having been a long time MM user, I can sympathize with Jorake. It has taken me two days of goofing off, googling, and trial-and-error to figure out how things work. When you come from the old standby clients like Tin-Tin and MM, you have a certain expectation of how things should work.

Fortunately, Nick has managed to NOT make Yet Another Tin-Tin Clone (YATTC), but (IMHO) has made a first rate client with more power and options than I have ever seen. Unfortunately, the documentation has been written from the perspective of someone intimately familiar with the program, and with a slant on explaining syntax more than explaining procedures to do things.

I found it difficult to "figure" things out to begin with. This program is so ingeniously created, that it is hard to see the forest for all the trees in the way. I think a doc comparing how to do some basic things (create alias, create trigger, create gags, etc.) would be helpful. Example: The triggers section in the help file is very clear about syntax and options, but not so clear on how to implement them.



This gives the uninitiated a quick intro to a specific task without getting bogged down in syntax.

This has just been my humble opinion and should not be misconstrued as criticism in anyway. I found that after a little experimenting and perseverance, this will be my client of choice from now on and I thank Nick (and anyone else who may be responsible for this client) for a job well done.

isildur

PS I play on Aardwolf and Medievia and will help anyone as I am able with the muds and with the MUSHclient on those muds. I am a novice at both though, so your mileage may vary a great deal. :)

Good idea - I'll see if I can do some "getting started" posts.

The Online Documentation / help is already quite good. It just needs some better examples through screenshots in my opinion. Having links to whatever posts are put in for basic tutorials would help too, since you really don't want someone new searching through the forums forever trying to hunt down some help and giving up. It's why I like that help page setup. It's pretty easy to find things, and it's right off the forums page.

I think a combination between http://www.gammon.com.au/mushclient/aliases.htm and http://www.gammon.com.au/scripts/doc.php?general=aliases would be the most helpful. Very good descriptions coupled with uncluttered screen examples.

Shaun hit closer to the mark with the screen shot idea. A combination of screen shots with the help files would be a great start for those new to MUSHclient and new to MUDding in general.

I'd be glad to help with some rough draft ideas, but my lack of experience with the client would definitely need a more experienced eye to polish it up. On the other hand, someone once told me that the best teachers are ofttimes the ones who have just learned the material. :)

Anyway, count me in if you need a hand. Even if it is just proofreading and whatnot, I'd love to contribute anyway you need. It's a small price to pay for an excellent program.

isildur

I've been kicking around an idea of making a scripting tutorial for a while. I guess this should get me motivated to start up with something a bit simpler. I'm currently getting the Gimp to start mucking about with screenshots and such as I'm typing this post. Hopefully I can be a lot more eloquent than normal and come up with a coherent tutorial site. I'll post a link when I think I've started to make sense.

I figure Nick already has enough time dedicated to making our insane ideas work in the client... And I hope he doesn't mind me plagiarizing his previous posts.

Go ahead.

If someone really wanted to be ambitious, one could code a loop-back tutorial system... Hmm, OK, actually I can see one issue with that, there is not way that I know of letting the client "connect" to itself, as though it was connecting to a server. Though, maybe if you trapped the error from a failed connection, so you could set some arbitrary local address and port, which you know won't connect, detect the failure in a plugin, then proceed as though it "did" connect..

Do we have some way to turn off Mushclient's normal connection fail dialogs and detect if it fails when it tries one?

Anyway. Point is, you set up a tutorial, which feeds notes to the display, and uses "simulate" to make it look like you are connected to a mud. Then you step them through the process, like:

"Ok, lets start with getting you on a MUD. We are going to connect you to arbitrarymud.com, which doesn't really exist, but which will allow me to teach you the basics. First, go to ..."

This is where inline pictures would have been nice BTW, since you could add, "go to this menu item, or look for the [] symbol on the icon bar and click there.", se'la'vie...

But, basically, walk them through setting up their connection, logging in, making simple triggers for the text that arrives from the the fake mud, etc. Other than making it look like the connection is working, when its faked, this wouldn't be all that impossible to do with this client. And for that matter, Nick could even add some code to cause the client to "treat" the connection as though it did happen, when some predetermined, and unlikely "name" is in the field, like 'testmud.test', assuming there isn't a way already. I don't see one. Mind you, something like the loop-back proxy I made would work too, if included as part of the "tutorial" world file. That might even be easier, except that some people would be confused by using 127.0.0.1, instead of a name. Does "localhost" work the same by default, or do you have to make a program aware of what it means?

This would be imho, quite doable I think.

Sorry, you just triggered the Frenchman in me; that would be "c'est la vie", not "se'la'vie". :-) (Sorry, just couldn't resist.)

A tutorial like that wouldn't be hard to do through a plugin. The issue would be getting a new user to load the plugin in the first place.

Any of the faked input/output can be easily done through various callback functions. Describing some of the steps involved might be difficult to describe without graphical representation though.

To David - Tried to run a google on it, google wasn't smart enough to show me the right version. lol

As for using a plugin.. Wasn't thinking of a plugin, but a world file, so that the settings can be saved, without interfering with something the user may want to use for other worlds. A plugin, is more problematic, since unless you have it unload itself somehow and revert all the changes made during the tutorial before hand... And some of those settings may "not" be possible to reset via script. Then again, that could be solved by having the plugin/tutorial world create a *new* world, so the original isn't overwritten. Some things like that need to be considered.

Fun thing is, since you mentioned plugins, part of the tutorial could even include "how to make a plugin".

Now, one option for getting them to load it is, don't. Have mushclient look to see if its running a clean install (or no worlds are set to autoload), then have a default world be generated, which includes the plugin. First thing the plugin does is ask, "Do you want to run the tutorial?". If you say no, then instructions could be given for how to load it later, the world gets unloaded and you start from scratch. If yes, then it starts running it.

This of course would require such a tutorial to be supplied with Mushclient and some code changes made to make a world with the plugin start up when first installed.

I have created a loop-back server program using Autoit, because I wanted an easier way to test my triggers than entering them into the Test trigger, and remembering to set colors and things, and certain backslashes in places. I can connect to myself, and from that can use the coloring syntax used on Aardwolf the @X/@x format, and just type things into the input area. Did this mostly for color matching triggers, or ones that match only a certain part of the line, get the color, and if it is correct, do something.

I MIGHT be able to make a tutorial version, that allows many forms of input, AND can do all the things that you wanted. I would not be the one writing the tutorial, but if someone could tackle the layout, and presentation portion of it, I would be VERY willing to create such a thing so that it can be used interactively, without the need for ANY plugins, or any connection bypasses. Just run, and open a new world and have it connect to localhost on whatever port you set in the server program.

Let me know who will be working on this pet project, or if this idea tickled anyone's fancy for an aesthetically pleasing tutorial method.

Laterzzz,
Onoitsu2

Hrm... should have put "that's life" into Babelfish. Google is a great search engine, but it's a horrible language site.

And as for having a tutorial world file... Might be nice to have a zip of a world and the plugin tutorial so that people can load that up. They would load up the world, which loads the tutorial plugin in order to deal with the i/o of the examples.

Only issue I have with something like Autoit, Onoitsu2, is that you would have to have them install it too, and it takes up more space. My little echo program is only like 24KB. Autoit is 7MB (well 9MB in true space taken up under NTFS). I think a world file, with plugin, plus the echo program, would probably be no more than 200KB, if even that. Probably not any where close to 7MB, and even if it got over 1MB, most of that would be *in* the plugin, as tutorial scripts and functions. How big it might get all depends on how complex the tutorial was.

Its certainly an interesting solution, but it takes up way more space than strictly necessary, without really gaining anything.

I'd have to agree with Shadowfyr here. Installing a whole new program to do the same thing that can already be done through a plugin seems to be a bit of overkill. Granted, a tutorial plugin may need a bit of creative scripting, but I think it's easily possible. Not to mention the fact that anything wrong with the plugin can be fixed by the MUSHclient community, whereas anything wrong with a third party program would have to rely on response from the developer. And let's face it, it's rare to find someone that can consistently match Nick for feedback and bug fix response time.

Ok for one, learn what you are talking about, a person does NOT need to have AutoIt installed to use a program created by it. So you might want to get that notion out of your heads, and the size of the program needing to be included would only be about 200k or so ... so that is not too terribly bad for something that can be TOTALLY interactive. My little telnet echo thing is 203Kb and that is only due to extra crap from the standard libraries, and that can be scaled down by including only what I use. As well as MAXIMUM UPX compression can decrease it by about a dozen Kb's.

And as for feedback and response time, I am up there, just ask the users of my plugins on Aardwolf ... I constantly ask if anything has gone wrong, and correct anything that has, not that that happens often.

I was just saying that I could create the program that does this, someone else would be responsible for the actual content.

Laterzzz,
Onoitsu2

Adding another program, whether it's 50kb, 500kb, or 5mb... It's still adding another program, and will just start up a whole slew of questions like "But how do I install the tutorial?" It might be mind-numbingly easy, but some people won't notice what's right in front of their faces... like the people on a mush/mud who ask "how do I do foo" and the overwhelming response is "type help foo"

Having a world named tutorial that comes with MUSHclient would be a simple solution. Not the only solution, of course, and probably not even the best one, but it's going to be the easiest to start with. Especially since I'm willing to bet that at least 80% of everyone who has installed MUSHclient did not read the readme file before using the program, even though there is a prompt to see if you want to at the end of a successful install. Keeping this simple to start will probably help everyone out more in the long run.

If I remember correctly, AutoIt is a free software scripting program anyway, so if you do want to make a tutorial through that, it shouldn't be terribly hard for people to update it. No issues with proprietary libraries or anything like that.

If I might interject. "Some sort of" extra program is likely necessary anyway. We can't have scripts creating the localhost connection needed to do the echo, and there is no way to trap connection failures, so we can't "fake" it, short of altering the client to recognize a fake name and "act" like its doing something. Sounds like my little echo program or one compiled with Autoit could work. Now... A solution is to make it an activeX Exe, instead of just a stand alone. That way you could simple place code in the plugin/world script that executed something like:

set echo = createobject("tutorial_echo")

Then in the close functions, set that to nothing, to terminate the application (Hmm, I wonder if you need to also have a "close" command to make the application re-reference itself too though..). But point is, there should be ways to get around it. It might almost be easier to build such an echo into the client, which would probably increase its size by less than 5k, while eliminating the need for anything else. I just don't see any practical means for how you do it without an external echo right now, not and be able to have them "set" things like the mud name, port, etc., if you included that in the tutorial. If you simply skipped that...

We can most certainly have a plugin fake an echo. You just have OnPluginSend trap anything that would be sent out to the "mud" and OnPluginCommand trapping nearly everything else. A somewhat creative lua script could parse the input and spit back certain responses based on what's been sent. Doing this for a tutorial would be much easier than faking a whole mud, because the script would just have to look for one specific thing at a time instead of trying to prepare for going out and killing things.

GetInfo can also check to see if all the connection info is set up correctly and change it to 0.0.0.0 if the person tries to connect to whatever we have them set it to. Anything returned from this fake mud will just go through simulated output, like you suggested earlier.

I haven't played around with AutoIt in quite a while, since I gave up on Windows years ago. I'm not sure exactly how robust the scripting is now. There are many ways that this can be done, I just personally prefer to keep the number of executables to a minimum.

I've seen interactive demos a few times, and they are good for complex games where you want to show the player some tips about getting started (eg. Age of Mythology springs to mind).


However to keep things simple, I was just planning to make some simple examples (eg. making a connection, making an alias, making a trigger, setting up some macros) with screen dumps, a few arrows, and a few words of explanation.

Fine by us Nick I wasn't figuring on you doing the more complex one anyway. lol

Now, as to what you said Shaun: "GetInfo can also check to see if all the connection info is set up correctly and change it to 0.0.0.0 if the person tries to connect to whatever we have them set it to." Yes and no. I don't know any way to *prevent* them actually trying to connect, or detect that they did so. OnConnect is only called *if* a connection happens, not if its attempted (or am I wrong there?). OnPluginCommand also only processes what the user types in the command window. Not a problem, except that it can't intercept things like them clicking the "connect" icon, or other such things.

Mind you I forgot about the fact that we do have a dummy setting, which makes it work like a real world (sort of), but not connect to anything. The main issue would probably be stating something like, "NOTE: Once you click OK, this tutorial will restore the Name/IP to 0.0.0.0, since we are only demonstrating how to connect to a mud, but the example mud we are using doesn't really exist. '0.0.0.0' is used to make the client *think* its connected to something and behave like it is. Later in the advanced tutorial the reason for this, and how you can use it yourself, is explained."

Sadly, you have to think about such things, or someone is *bound* to report a non-existent bug. lol