# read() and force_input()

Andy Bakun (abakun@scinc.com)
Wed, 30 Jul 1997 10:23:24 -0500

- Messages sorted by:[ date ][ thread ][ subject ][ author ]

    At 12:11 PM 7/30/97 +0200, you wrote:
    >I actually managed to get this working (if I get your intentions right) with
    >the following code:
    >
    >commands = {":1", ":2", ":3"};
    >for command in (commands)
    >  ok = $command_utils:yes_or_no(tostr("Execute ", command, "?"));
    >  ok && force_input(player, command, 1);
    >  suspend(0);
    >endfor

    I was initially surprised that this worked, but it makes sense now that
    I've reread the docs on read()... the specific part is:

        It is possible to call `read()' many times in the same command task, so
        long as the task does not call `suspend()' or an explicit
        argument is given. The best use for `read()' with an explicit argument
        is in conjunction with `open_network_connection()', if it
        is enabled.

    The operative part being 'an explicit argument is given', which is what
    :yes_or_no does, and what I always do.  Essentially, I've been operating
    under this suspend()ing read() problem for the past two years and it never
    was an issue (and I suspect it rarely is).  I'm embarrassed I overlooked
    this.  Ouch

    Perhaps that last sentence should read "the best use for read() with an
    explict argument is in conjunction with open_network_connection, if it is
    enabled, or to just get a line of input at any time from any player".

    >the ,1 makes sure the input is entered at the front of the queue, and the
    >suspend(0) gives the server time to dequeue the command. I tested it and it
    >seemed to work fine for me.

    Yeah, this is important, so the server will create a command task for it on
    the next network i/o handling, and it won't get stuck in the queue.  It
    does make a difference if you are waiting for the above loop to finish
    though. :)

    Andy.