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);
>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.
References:
Home |
Subject Index |
Thread Index