Some ideas, questions, and so on.

I was told about this client and decided to check it out. There are a few things that bother me, or don't appear to be working.

First off, the command history doesn't appear to be working. I think I have it turned on (I haven't yet found any options for explicitly enabling or disabling it). The up key (I have the appropriate option for this) doesn't put in my previous command, and viewing the history shows nothing in there. Is this normal behaviour?

Speedwalks. Is there a way to have speedwalks work without a speedwalk prefix? I've gotten used to using the tintin version of speedwalks and there's no way I'd remember to keep typing in the prefix (especially when I stack a whole bunch of commands together like "stand;dnnneeenn;cast 'firey death' enemy;flee;ssswwwu". If I had to type in the prefix for each speedwalk command, I'd just die.

Backscroll. The client I use now has a nifty backscroll feature that splits the screen, but still lets you view the current mud content in the bottom portion, allowing you to check your backscroll while still keeping an eye on the mud for any important events. I'm assuming mushclient can't do this?

#commands. I don't know why these arent implemented (I'm sure there's a reason for it) but I find them incredibly convenient and fast. That's a key issue here. If I have a fraction of a second to get a trigger setup before some enemy comes and kills me, I want to do it as fast as possible - and waiting for the gui and navigating those buttons will result in my untimely death.

These are the primary concerns I have for this client. If none of these can be enabled in the client itself, are any of the possible candidates for scripting? I knew that the #commands wasn't around, I was actually toying with the idea of making a script that can handle #commands and convert them to the mushclient language. Could the other things I like be done via scripts also?

It works alright. Press Ctrl+H to view it. However there is one circumstance where commands don't appear in it. During the initial connection phase if a MUD sends "echo off" just before requesting your password, everything you type, until the MUD sends "echo on" are not stored in the command history. This is so someone can't just view your command history to see your password. However if, for some reason, the MUD doesn't send "echo on" nothing will be stored.

You can go to the Command configuration tab, and check "Ignore 'Echo Off' Messages" to stop this happening.



Yes, you can write a small alias to do that. There are circumstances where I think this would be undesireable, but if you are happy to have everything that matches a speedwalk be processed as one, you could do it.

Something like this should do it:



This will match anything consisting only of N, S, E, W, U, D and digits, and "send to speedwalk".



First, if you scroll back the screen is automatically paused, so you can read lengthy tells.

However you can also go to the Window menu -> New Window, and have another copy of the MUD output displayed. One copy can be resized and left in "scroll" mode (to check on recent messages) and the other copy can be scrolled back and paused to read old messages.



MUSHclient was designed from the ground up to be easy to use, and not another "tintin" clone. Hence the emphasis on the GUI interface.

However read this forum post:

http://www.gammon.com.au/forum/bbshowpost.php?bbsubject_id=6442

That describes a method of implementing adding an alias from a #alias command on the command line. You could easily do something similar to add triggers.



I have described how two of your concerns can be done via scripting. The scripting interface now supports over 300 script commands, plus a few more which are specific to Lua. Excepting major changes to the user interface, most things you might want to do can be scripted.

If you are planning to do this you might want to investigate the plugins concept. Things like the auto-speedwalk, #alias and #trigger idea are things that could usefully be made into plugins and thus easily incorporated into all worlds you need to connect to.

Thank you for the reply.

It seems I can do the majority of what I want, it's just a matter of how much effort and energy I wish to put into coding these plugins. Ah well.

One thing I wanted to know - I like to parse text from the mud, store it in a script variable (such as a hash, array, etc), and then use that information later on in some manner (which itself may be triggered by text from the mud, or even by a command from me). Is there going to be any issues with this?

Also, there are a couple of popups that (I thought) I turned off, but which keep recurring. Is there a way to turn off all popups? I can't remember which ones specifically, (I usually click them away right away because I'm too busy mudding), but I really don't like them interrupting me.

Oh, incidentally, I had to modify your speedwalk alias a bit. The regexp needed a little bit of tweaking. Also, I dont like how the speedwalker replaces 'n' with 'north'. It's a minor issue I know, but when I speedwalk, I'm used to seeing:

n
n
n
w
w

like that. It's a minor issue, but I've used my other client for about 8 years now and I'm pretty set in my way with what I like and don't like.

Not at all. You can either use script language variables (eg. Lua associative tables) or MUSHclient's internal variables. I recommend Lua as it is fast and powerful, and has keyed arrays (an example of which appears below).

However you can also use MUSHclient world variables, which are serialized to disk when the world is saved, which you may or may not want.

There is also a method of converting Lua tables into a string for saving in a MUSHclient variable, this is documented here on the forum and the code is supplied as part of the MUSHclient Lua example script file.



There is no "turn off all popups" option, however there aren't that many. Check out File -> Global Preferences for ones relating to lost connections. If you get a popup when attempting to up-arrow over a half-typed command, see world options -> Commands -> Keyboard Preferences -> "Confirm before replacing typing".



Well it is cosmetic isn't it? However if it worries you, you can modify the script a bit to do a "string.gsub" on the results from the speedwalk conversion, to convert "north" back to "n". Below is an example, using my original regexp:

I have a large number of scripts, (I just recently switched them all over to a new language that mushclient doesn't support, but converting them back to perl shouldn't be an issue). I'm hoping that once I learn the system things will go smoothly.

Also, I'll give lua a miss I think. I'm sure it's a great language, but I'm struggling trying to learn 4 other scripting languages at once atm, and I don't feel like adding one more to the list.

One last question. Are there internal variables to mushclient? Like, say $time (current time), $date (current date), etc. My commands at the moment depend on these variables, and it would be cool if they work. (If they don't exist, I'm sure I can setup a timer to automatically create a time variable every second - it's just a little more work that I'd like).

Edit: I thought of something else. When a line comes from the mud, and I use some scripting goodness on it, can I change that line before it gets sent to the screen? I know some clients lock the text so it can't be changed, but I like to change the line to do funky things based on my scripts calculations.

Double edit: I was reading through the forums. Is there a way to grab a hunk of text (over multiple lines) from the mud, based on a starting line and an ending line? At the moment I'm doing it in scripts using some clunky variables to turn on/off text parsing, and I'd like a neater way of doing it.

Triple Edit: While browsing the forum, I found a post that seemed to say that ANSI codes are stripped out of the raw line before you get a chance to do any scripting or triggers on them. Is this true? Is there any way to have a line of text with ansi still in it (I use the ansi codes as part of my calculations).

It seems that with enough work I can have mushclient behaving how I want it. I'll be sure to post any plugins I make if I feel others will find them useful (especially if I get that #commands converter working).

Thanks again.

Note: I am answering in some detail here to help the original poster, and also to document the internal processing of MUSHclient's incoming data handler, for the benefit of other scripters who may be wondering exactly how MUSHclient works.



There is a lot if internal information available to scripters. The MUSHclient scripting is not an "inline" scripting language which you might be used to, where you just refer to $date in a script line. For things like the date you simply use whatever method your script language (eg. VBscript) has for getting the date. I think all script languages support getting the date and time.

For information that MUSHclient would know, but not the raw script language, there are many script functions that return virtually every conceivable thing you might want to know. See this page for a summary:


http://www.gammon.com.au/scripts/doc.php?general=info


For world-wide information (eg. to a particular world), see GetInfo:


http://www.gammon.com.au/scripts/doc.php?function=GetInfo


This help information is identical to what ships in the MUSHclient help file, they are generated from the same database.

For a particular line of text in the output window you can get further information (including the date/time it arrived):


http://www.gammon.com.au/scripts/doc.php?function=GetLineInfo


And then for each style run you can find out more things:


http://www.gammon.com.au/scripts/doc.php?function=GetStyleInfo


So you can see you can obtain fine-grained information out about incoming data.



Well you can, but it is a bit fiddly. See my explanation relating to one of your other questions ...



Not exactly.

For a description of the exact process used for handling incoming text, see this post:


http://www.gammon.com.au/forum/bbshowpost.php?bbsubject_id=6554




The other approach to changing lines is simply to omit them with your trigger and then redraw them doing world "notes" changing the wording, colours etc. This is particularly easy using Lua because its trigger function is passed the original style runs from the originating line.




Two ways of doing this:

1. Use a multiple-line trigger. This is good for things with well-defined starting and ending points, like an inventory list.
   
2. To simply grab multiple lines, regardless of content, use the GetLineInfo script function mentioned earlier. With that you simply specify a line number, and can obtain, amongst other things, the text of that line. By calling that repeatedly you can find the contents of a sequence of lines.

I should point out that OnPluginPacketReceived is possibly more powerful than it looks.

What you can do is, when receiving incoming packets, do your own batching of packets until a complete line is received, then run regexps and whatever on the entire line. This forum post describes the general idea:


http://www.gammon.com.au/forum/bbshowpost.php?bbsubject_id=5020


Basically it uses OnPluginPacketReceived to build up a complete line. If the line is not complete, it remembers the partial line in a script variable, and then returns an empty string, effectively discarding the packet from MUSHclient's point of view.

When the line is finally complete, it returns the whole line (after any processing you might require), and saving any bits of the next packet for next time.

To Nick:
This is off-topic, but I'm requesting that the breakdown of MUSHClient's line and packet handling be posted somewhere prominent, perhaps its own page on the website. It's a good piece of reference, and I'd hate to lose it in the backlog of the forums. :)

The bulk of my reply has been moved to:

http://www.gammon.com.au/forum/bbshowpost.php?bbsubject_id=6554

There is a "sticky" for it at the top of the General section of this forum.