MOO-cows Mailing List Archive

[Subject Prev][Subject Next][Thread Prev][Thread Next][Subject Index][Thread Index]

Re: read() and force_input()

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);

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. :) 


Home | Subject Index | Thread Index