I''m trying to create a simple MUD telnet server with Async Sockets, and I want to prevent the user from receiving input while they are typing. Now, I am unsure whether this is a TELNET feature (using Go aheads maybe?) to block incoming traffic until the user finishes putting in their command or is that something you have to code into the server? It''s just a common feature I noticed while playing MUDS over the years that I don''t know how to impliment (and I can''t really find anything about programming telnet besides the RFC''s) Any kind of help or direction would be appreciated, thanks in advance!

How about:

char nextch = GetCharacterFromNetwork();

if( UserIsTyping() )
{
StoreInBuffer( nextch );
}
else
{
PrintAndClearBuffer();
PrintChar( nextch );
}


If I had my way, I''d have all of you shot!

codeka.com - Just click it.

Yeah... this should really be handled client-side because you don''t have any reliable way to do it server-side. Most MUD clients will ignore things like GA sequences so it''s pointless you wasting your time on them. In fact, RFC596 states that "GA will not, in general, work" and "GA is impossible for most hosts to implement correctly in all cases." So I suggest you give up now.

Remember that Telnet is not limited to sending new-line delimited commands, and that single characters are legitimate too. Therefore whether the user is ''still typing'' or not is going to vary depending on the client implementation, the server specification, and the user''s expectation

Personally I''ve never seen a MUD that didn''t send you input while you were typing, although if it had a custom client it could work the way Dean has shown above.

Also take a look at http://www.circlemud.org/maillist/1998-04/0320.html.

[ MSVC Fixes | STL | SDL | Game AI | Sockets | C++ Faq Lite | Boost | Asking Questions | Organising code files | My stuff ]

Thanks both of you, I checked out the source for MERC and played around on an old BBS mud (majormud) just to see how they handled it, and it is indeed handled by the server. Just set a flag and let all their output build up in a buffer until they finish entering their command.

Kylotan, most muds do block input while you are entering text. Say you are typing out a really long ''send'' or ''say'', you wouldn''t want to get interrupted and lose your place everytime someone walks in the room, or says something, (etc.) right?

The only problem I was thinking of was what to do if a user sits there with a command partially entered without hitting enter and allows their buffer to fill up? Drop them at some point if it gets too full i''m guessing?

quote:Original post by pyroGX
Thanks both of you, I checked out the source for MERC [...]

Kylotan, most muds do block input while you are entering text. Say you are typing out a really long ''send'' or ''say'', you wouldn''t want to get interrupted and lose your place everytime someone walks in the room, or says something, (etc.) right?

Wrong. Trust me, I''ve been programming MERC muds for 5 years now. Yes, the text is all buffered, but that has zero effect on what happens client side. Try it. Log onto Realms of Despair with the basic Windows telnet client and sit in that first room. Type out half of a long ''say''. Watch as your message scrolls up the screen as all the other newbies log in.

quote:The only problem I was thinking of was what to do if a user sits there with a command partially entered without hitting enter and allows their buffer to fill up? Drop them at some point if it gets too full i''m guessing?

It would do, if it did the buffering you''re talking about, which it does not. The output buffer is flushed once per pulse, which is every 1/4 second on MERC derivatives by default, not only when you send in input to the server.

[ MSVC Fixes | STL | SDL | Game AI | Sockets | C++ Faq Lite | Boost | Asking Questions | Organising code files | My stuff ]

This is definitely something that should be left up to the design of the client telnet software. Like a seperate input area for typing, or simply the client buffering the input while they type. Going to be very uncoordinated and troublesome done serverside. Sorry can''t be of any help

Years back I wrote a mud client. You want to allow receiving input on both the socket and the standard input simultaneously. Simply multiplex stdin with select, and do the same (nonblocking/multiplexed) with your connected socket. The server side doesn''t know and doesn''t care what you''re doing, as long as you are sending your commands in the manner that the server expects them (new-line delimited for diku if I recall).