Fixing line breaks from commands..

"Sticks and stone can break my bones, but commands can really kill me..." or did I get that wrong. ;)

Having thought about this quite a bit I have come to the conclusion that no real method can be used to fix 'where' a command is displayed as it is sent. Any method used to fix it is likely to only make matters worse. However, I have also come to the conclusion that there is a serious flaw in your programs logic with respect to how incoming text is handled. Currently it seems that mushclient will read data in, attempting to match it to triggers and then when interupted treats the command as a CR-LF recieved from the stream. This is of course because necessity both the inbound and outbound data must be displayed in the same output window, but outbound text should not interfer with the structure or nature of the inbound data imho. For triggers to work reliably they either need to ignore any changes that a sent command may make to the apparent output displayed or process the incoming stream in parallel and seperate from what the rest of the client may be doing. The current method does neither and in some situations can fail to work at annoying or even, from a game playing point of view, dangerous times.

Fixing this may require a slight change to the way that color triggers work, but would require mearly coloring all lines across which the trigger text was broken. A situation that would be far easier to test for and handle than preventing such breaks from happening to begin with (I haven't noticed it break across more than two lines anyway, though I can't be sure.). It would likely require little more than setting a flag when a command is sent, checking to see if it is set when a color trigger match is found, and otherwise setting it back to false after all triggers are processed. Something similar would probably be needed for 'omit from output', but in both cases mearly keeping track of when the collision happened and coloring/removing the text is all that is necessary. In fact making the omit work right would be little more than deleting the buffered text on the split lines (but not the command) and performing a quick refresh of the display.

I unfortunately can't think of any better solution, since the only other option would be to cause normal triggers to work 'across' those false breaks and leave color triggers with their current behaviour (and an appropriate warning about it in the docs). Since you can now have more than one that matches on the same thing, the color trigger could simply color the line, while the duplicate does any other things like sending text, calling scripting, etc. This however won't work with 'omit from output', which I assume suffers from the same problem.

NOTE:
For anyone who wonders why any of this would be necessary.. the problem with simple fixing when/how commands display has to deal with the client being able to tell when an end of line is. In general that is only possible in two cases, when mushclient auto-wraps a long line itself or it recieves a charage return. On prompt lines where the mud waits for user input there is no CR-LF sent from the mud, so you would be relying on the CR-LF from the 'next' line recieved and that would probably make things worse. It still remains a possible option, but would mean that the command you sent would appear as:

A Tiny Room
south
This very small room...

instead of

south
A Tiny Room
This very small room...

and I don't think that would make a lot of sense.

My first comment is that some of this behaviour is for historical reasons. The early versions of MUSHclient didn't echo commands in the output window, and there was no "world.note", so the problems you describe didn't exist in the same way.

However looking at it today, the main problem - as you recognise - is that it is hard to know when a line has really ended, as it can come down in parts, and in the case of prompt lines, are not ended until the cr/lf is sent some time later (ie. on the next line).

It would be difficult to match literally on incoming text, because it will be filled with "junk" like ANSI codes, MXP codes, telnet negotiation options, and so on.

Thus, MUSHclient processes all that stuff (eg. colour codes) and assembles the finished (text) result in the output buffer. Then, when a cr/lf finally arrives, it is processed for triggers. Or, if either a world.note, or a command being echoed, is received, that "closes off" the current line and then triggers are processed.

I use the word "line" loosely, it is really "paragraph" as triggers can match multiple lines providing they do not have a cr/lf in them.

A couple of early suggestions will be hard to implement. One was to delay the command echo until a cr/lf is received. The problem here is that if the last line was a prompt (highly likely) and then MUD is lagging (reasonably likely) then the command will not be echoed, (since the cr/lf will not have been received yet) giving the appearance that the client has somehow hung or failed to process the command.

Thus you would go from:

<prompt> north
(pause here)
New room description now.

to

<prompt>
(pause here)
north
New room description now

Which would be a bit weird - it moves the lag to a place where it looks silly.

The other problem is with things like world.note - say the last line is a prompt line (likely) and a script (eg. a timer, or in response to an alias) tries to echo text to the screen - does all that get queued as well? If so, any script that does displays will appear to do nothing, until the MUD sends text, whenever that is.

I agree it isn't easy to fix this problem, although I hesitate to describe it as a "serious flaw". :)

It is a side-effect of how MUDs behave - perhaps if one day a more "transaction-oriented" one was designed, then the problem could indeed go away. For instance, if prompts were done by MXP, rather than as text sent down without a cr/lf.

[ Note - in the above cr/lf means "carriage-return/line-feed" which in C is \r\n ].

Here's a few other things I've previously thought about on this matter.

Text sent from mud requires multiple TCP packets due to the large amount of text sent:

• I've noticed, from a single source, that when it's trying to transmit more data that it can fit in a single TCP packet, the maximum size of the packet is always a consistant size.
• This could possible be used to cause MushClient to 'learn' when there is a big likelyhood of more text coming from the mud.
• If you give a limit of 1 second(the mud should send both packets with little to no delay) for additional data, then you can remove the chance of a packet just happening to be the right size but still having a valid prompt at the end.(with minimal delay)

This is a bad option, I believe, as it uses a bit of intelligent guessing, but still has small chances of delay in processing with a specific packet length.

Prompts don't supply a carriage return, so MushClient won't attempt to compare a trigger to it.

Well, how about giving an option for specific triggers that don't require a carriage return.

• Insert an option into your trigger input GUI to 'Match on prompt.'
• Internally, if the final line of data you've received from the server doesn't end in a carriage return, then try to match it only against triggers that use that option.
• Allow for gagging/altering partial lines if this option is selected - if you find any lines with this prompt, just delete the data that would appear on the screen.(leaving all/final color changes?) Data inserted into 'output to world' should not have an extra carriage return if this option is on, and I believe world.tell "" may work appropriately to cause a prompt-like behaviour if you wanted to insert data through scripting.
• Potentially, another string of data may be added when processing each line of data.(internally) If a verifiable prompt is found, store it in it's own section to note it as a prompt. Then when you process your next 'true' line, it can process the entire 'true' line without having to worry about the prompt in your triggers. ('true' line in this case refers to any data received without the prompt prepended to it) When you get a final carriage return, join the two strings correctly for the display and storage into history buffer.
• Insert a global/world option 'Match trigger prompts on all lines.' This could cause MushClient to attempt to match any trigger marked 'Match on prompt' at the beginning of every line that comes from the mud. If this global/world option is checked, then MushClient can check every line for a prompt, if it is found, store it internally as a prompt(after performing necessary actions to it as noted in the trigger setup), the remainder of the line is then processed through standard triggers. (If this is used, any prompt that ends on * or (.*) or (.*)? etc. would cause problems with other triggers, as MushClient would think the whole line is a prompt, even if it is not. This would only really work for prompts that had a specific character that ended the prompt and still didnt' supply a carriage return.)

I prefer this option. Although this seems very possible in theory, not knowing the internal workings of MushClient, I don't know how plausible it is to be added. I believe only the new global/world option would cause much additional processing overhead, depending on how many different prompt triggers you have(why more than 1 active at a time anyways?) I would almost say put this in it's own minisection under world options, since you should only need 1, but since the triggers section has a lot of other things that it could use, it seems appropriate to insert it into that section.


Okay, there's my 3 cents. ...hmm, anyone got change for a nickel?

>Well, how about giving an option for specific triggers that don't require a carriage return.

In theory any trigger that has * somthing * or the like should do so, since there is no implication that it is expected to arrive on its own line. As for detecting prompts.. My mud has at least 3 types that I can think of immediately, no make that 4, or is it five... Basically you can't detect them, since there is no sepecific character or sequence at the end or any certainty that you will get the same one each time. As with a discussion earlier about the current behavior of the mannper, you have to base your program logic on something independant of the things that are currently messing it up. In this case, no cr/lf, no detection.

This is why I suggest parallel processing of the data for triggers. True you have to deal with color data, etc. but the main question is is you had a small buffer that 'built' the input in the same fashion as the output buffer, but ignored user commands and window size while building it, then the problem could be fixed fairly easy, since the only thing the triggers will see is the actually input text. 'Omit from output' and color triggers are the only thing that can't be fixed in such a way, but as I said previously, if a simple solution does not exist to fix them then they can be excluded from the new matching method or an appropriate warning given in the docs to the effect that while they always match for the purpose of calling scripts and sending text to the mud, they may under certain circumstances fail to color or remove the matching text. As well as an explaination why of course.

Put simply it is a case of whether we as users would be more satisfied with something that doesn't color or remove a few lines that do produce a match, but correctly triggers on them, or a client that fails to trigger on any lines that get broken. Imho the coloring and removal problem while it may be a bit annoying is cosmetic, while the failure of triggers to work when they should is a much bigger issue.

As for the idea of a transactional mud... I suppose it could be possible to take some otherwise unprinted characters like 002 - STX and 003 - ETX and use them to 'inform' the client as to whether it has recieved everything within a paragraph, but since muds don't and likely never will support that... any solution has to work within the existing limitations. But a solution of some sort would be appreciated.

In my case, my prompt DOES have a CRLF appended (the MUD I use allows me to set this), so the only problem I was having with broken triggers was due to lag and/or a lot of data being received.

I'm happy with the output to look 'broken', as long as the triggers WORK.