[MUD-Dev] Clients

[Matt Chatterley]

On Tue, 13 Jan 1998, Shawn Halpenny wrote:
> On Sun, 11 Jan 1998, Matt Chatterley wrote:
> 
> My two cents:
> 
> > I think the most popular client features which people have described to me
> > are an easy to view command line for entering commands (with no limit on
> > length of lines), and a command history as well as a 'scroll back' of
> > sorts (aka tf's /recall).
> 
> I would consider a toggleable vi-mode for the command line practically
> a necessity.  Actually, a number of useful features from shells would be
> nice:

Hmm. I'm not sure exactly what you mean by 'vi' mode (one which responds
instantly to keypresses in a char-by-char mode rather than typical line
based approach?).
 
> - '!' syntax for recalling old commands
> - an intelligent history list (as more commands are added, the user-visible
>   offset of previous commands does not change)
> - etc.

I'm planning on allowing the binding of various keys (and macros) to
client functions as well as commands to execute, so aliasing ! to 'last
command' shouldn't be too hard (even to have it require an enter).

For history list, I was originally pondering a two-fold system - a set of
'cycling' keys eg 'back one, forward one' etc, along with a scroll/click
option, but decided it wouldn't be too bad to also extend this so you
could have a separate window appear containing the last X commands
executed to be clicked on too. This seems a logical extension.
 
> > The ability to make log files of events, connect to multiple worlds
> > simultaneously and macros are also popular.
> 
> Session log files are always nice.  In plain text, too.  If the mud is

Definitely in plain text!

> sending me ANSI color, I don't want to deal with stuff like 
>   ^[[1;32mBoy does ^[[2;31;42mthis^[[1;32m^[[40m suck to read.^[[m
> in my session logs.  Macros are a must.  And it's awfully nice not to be

Re: restriction in macros, I'm unsure how I'll handle macros, and infact
they are unlikely to be a 'mainstream' feature (I'm actually considering a
JavaBeans type approach to this and going entirely modular), or one added
soon; since again at least a twofold approach seems in order (a 'simple'
approach and a 'flexible' approach - to a degree the two are exclusive of
each other, the latter more inline with an interpreted language). Perhaps
if perl is available on the users machine, perl can be used to provide
macros as a 'helper application'. Hmm.

> restricted in what one can write a macro for.  Specifically, something that
> allows me a certain regular-expression matching ability.  Tintin-esque
> example assuming Perl regexps:
> 	# make "'<language> <text>" map to "say in <language> <text>"
> 	#alias {^'\s*(.*?)\s+(.*)} {say in $1 $2}

Definitely nice to be able to do. :)
  
> And triggers are handy...regexps are a must there too.

Triggers. Hmm. Never used them myself, but I can see them being useful in
some situations.
 
> > I'm interesting in hearing not only which software you folks use, but also
> > *why you use it* - what does the software have that you like? What is
> > missing? Personally I use tf since it is straightforward to use and has a
> > nice, uncluttered display (something I will strive to recreate!).
> 
> I wrote my own client in Perl since I lusted after what I could do if I had
> real regular-expression matching at my disposal.  And another plus was that
> I could evaluate Perl while I was playing, should I need any extra
> functionality.

Excellent!
 
> [ ... ]
> 
> > Also a simple information communication system so that screens such as
> > 'score' and 'stats' which are popular names for similar things on many
> > games can be permanently displayed or toggled (dynamically updated via
> > communication from the server to the client), perhaps on an 'information
> > window' which works as a 'pinboard' allowing iconisation of each window
> > and such.
> 
> I would like to be able to control the positions and sizes (within reason)
> of all user interface elements.  The information the MUD may be sending is
> fine, but I'd like more control over where I have to look to get it.

This is high on my list - something I really want to go for with this
'extra information' is 'extra control'. If the mud offers to send
graphics, you should be able to y/n each transfer, and also to set
parameters for automatic acception/refusal (eg: Accept all graphics of 20k
or less which are in gif or jpg format).

Regards,
	-Matt Chatterley
	ICQ: 5580107
"We can recode it; we have the technology."