|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?