Input/Output Area

The picture below shows you the main SMM window. The right part is dedicated for mudding. Text output is written into the above region and you give your input in the entry widget below the output area.

Input

By clicking into the output- or input-area the focus is set to the input. If it has the focus, you will see the input cursor. You can now type in your commands. The input widget will keep a history of your last commands.

The SMM input provides some more functionality, which is bound to key sequences. Below is the list of the most useful bindings:

<Return>
Sends it input so far to the SMM parser. If its 'normal' text the parser sends the text to the mud. For more detailed information about the parser please see below.
<Up>, <Down>
Cycles thrue your command history.

Hidden inputs - passwords e.g. - will not be put into the history. If the last and the previous command are the same, then the last command wont be put into the command history. And finally empty lines wont be put into the history either.

<Tab>
Will invoke the tabcompletition. Again, please see below for more detailed information.
<Ctrl-Tab>
Will put a <Tab> into your input.
<Ctrl-a>
Jumps to the beginning of the line.
<Ctrl-e>
Jumps to the end of the line.
<Ctrl-k>
Deletes the rest of the line.
<Ctrl-d>
Deletes one character.
<xyz>
try it out,..
<xyz>
Bonus! You can redefine any key sequence to invoke or send any commands! Have a look at the '#keycom' command in commands section.

The SMM Input Parser

The parser looks for several things and changes the input if needed:

Please keep in mind, that the parser works recursivly and the input is not checked for endless loops.

Tab completition

For the last lines on the output screen and the so called 'tab-list' tab-completition exists. If you type the beginning of a word and press the <Tab>-key the rest of the word is completed automatically. This esp. useful, when you are adventuring and are suddenly attacked by "Gorgymphula". Or if you are talking to someone, who has a ugly to type in name like "Phaidros": just type in 'P<Tab>'.

If more than one completition is possible you are asked to give in some more charakters. If you dont give in more characters but type in more <Tab>'s you begin to cycle thrue all possible completitions.

Processing of the text received from the MUD

When a MUD sends its output/text to the client it sends it in one or more packages without caring about the contents. This can cause some minor problems, when the client wants to process the recieved text, as it would process 'sequences' of characters, which could accidentially be broken up.

This problem is solved for ESC sequences as they are handeled by the SMM data processing as SMM just waits until the sequence is complete.

Problems may arise, if the user wants to process the text: e.g. for action triggers. Let me explain it in detail:

Normally you expect the text from the MUD comming line by line .

      You miss elite guard.
	Elite guard absolutely destroys you with his hit.
      ...(and so on in a fight)...
    
Now imagine, that you have an action on 'absolutely destroys you' which lets you flee, but you recieve the text in two packages splited right after 'absolutely':
  1. If I would parse all received packages of text separately, the action wouldnt be triggered at all.
  2. On the other hande side one doesnt want to wait, until the next newline really comes. Sometimes (e.g. password input) they never come and sometimes you just dont wait so long (just having a little hangup/lag). E.g. if your trigger would have been 'Elite guard absolutely' you would be really angry, if the trigger just dont trigger because of a missing newline.

Therefor I do two things:

  1. I do parsing after each received packet of data
  2. but also parse always the whole last line.
In the above case I would have parsed Please keep this behaviour in mind, when you build your action triggers/substitutions/highlights/notouch lines! There is more to say about text processing. Read on, please:

action triggers/substitutions/highlights/notouch lines

Please also refer to the corresponding sections in the commands part of this documentation.

Text parsing exists for the user in four flavors:

notouch lines:
These tell SMM not to do user parsing for this line of text.
action triggers
Invoke automatically actions depending on the received text.
substitutions
These are instructions to change the received text. This is something real and not just displaying; means: after substitution parsing continues with the substituted text.
highlightings
Colorizes parts of text.
Now all the parsing must be put into some order, as sometimes it depends on in which order actions are performed, parsing must be stopped only of some action triggers, etc...

Therefor 10 levels (0-9) exist for each of the above and parsing is done in the following way:

for (i=0; i<10; i=i+1) {
  if ( notouchline(i) ) break;         // ends the for loop at all
  actions(i);
  substitutions(i);
  highlightning(i);
}
    
So everything of level 0 is parsed first, then level 1 and so forth. If a notouch line of level 3 is detected, parsing in level 3, 4, 5,.. is not done!

If my explanations are not clear enough please, notify me! Even if this docu is already years old. I don't expect anybody to be able to program and that I write perfect docu.




Last modified: Sun Dec 19 20:08:59 CET 1999