Someone raised this question on a forum I read and while I don't actively work on MUDs any more it piqued my curiosity enough to give it a try...

Working on a stock ROM 2.4b6 base.

Basically, someone suggested a clear command, so that you could clear your input buffer. Useful if you've spammed a bunch of directions but get attacked, or are in a fight and have spammed a bunch of skills in but suddenly get double-teamed.

The command itself is easy, but having little experience with the input/output handlers I am having trouble getting the command put forward to the top of the input list. A quick example:

Bash
Bash
Bash
Clear

I type the first three bashes quickly, but after the first one I want to cancel the other two so I type clear. The command would have to be moved to the top of the list, ahead of the two other bashes, so it would be the next executed.

Maybe this is simple stuff to some of you but it's giving me a headache. I guess that's what I get for trying to code after a year/18 months of not really doing any.

Any solutions greatly appreciated!

It depends on how the input is handled initially. If the input is simply left in the streambuffer until the program is ready to accept another command from the user, then the first step is to make sure that that buffer is cleaned as soon as new input is sent.

This information should then be placed in a queue, statement by statement (the command statement ending with a \n\r). This queue would then be manipulatable enough to perform functions such as "clear" on. (A clear would probably consist of simply going through and freeing the memory currently in the buffer, and nulling out the pointers to those char strings).

It's important to have it in this form before you implement the clear however, since in order for the "clear" command to work, it can't be implemented as an actual command. Instead, as the data arrives, the new "statement" would have to be checked. If it says clear, immediately clear your buffer. If not, then add the contents to the buffer. When the client is ready to accept a new command, simply pop the next command off the queue.
More simply, you're just adding another level to your command interpretation.
Where-as before you had (probably):

Input from TCP protocol --> Application streambuffer --> command recognition --> command execution/error message

You now have:

Input from TCP protocol --> Application streambuffer (dumped upon arrival of full statement) --> pre-processing to check for "clear" --> entry command queue (or clear of queue) --> command recognition --> command execution/error message


We perform a similar process on user input, only we implement more layers between the buffer and command execution then even this model. Thus we've separated commands into "realtime" commands and "gametime" commands: those commands that need to be executed immediately (such as command-queue processing commands), and those that  need to wait until character is ready to execute a new command (following the completion of the last action usually).