MOO-cows Mailing List Archive
[Prev][Next][Index][Thread]

Re: My wish: built-in prompt support

Grady Park wrote:
> 
> On Fri, 9 Aug 1996, Kipp the Kidd wrote:
> 
> > I think it's just fine in the database.
> >
> > The only possible server way, as I see it, is if it has been 1/10th to 1
> > second second since the last notify(), display the prompt.  This would be
> > hard to do in the server, and is easily solved in the Paradigm core with a
> > simple .prompt_ok and a fork()
> >
> 
> What about making it display the prompt not after a notify, but after a
> typed command finishes executing? If the verb forks or suspends, then the
> programmer would have to make sure e called some builtin like
> display_prompt() if e was displaying text..
> 

It's a safe bet that every command typed on a MOO generates some sort of out-
put to the initiating player.  If you can think of a valid reason to have a
command verb generate absolutely no output whatsoever, please tell me.  I 
would find it extremely interesting.

If you can safely assume that any command verb you use on a MOO will generate
output, then it is a simple matter to modify player:notify() to handle
prompting.  Basically, a property named .prompt_task would need to be added
to the generic player.  player:notify() would check that prop every time it
is called.  If set, good.  If zero, it would fork a this:prompt() task and
put its ID in this.prompt_task.  (You could do it as a simple bit but having
some sort of handle on a task could possibly be useful elsewhere.)  The
player:prompt() verb prints the prompt and clears this.prompt_task.  That way,
every time a task calls player:notify(), a prompt will be sent to the player 
soon after the task that used :notify() ended.

Verbs like @dump and @grep can suspend several times during their execution,
and generate output sporadically.  This would result in a prompt each time
these verbs printed, then suspended.  That would throw the output of these
tasks off, so :prompt() would also have to maintain a .last_prompted property.
player:notify would then need to compare idle_seconds(this) to time() -
this.last_prompted, to see if the player has initiated a command since the
last prompt.  If not, then :notify() would need to send a newline before
sending its data, so the new text starts on a fresh line.

Verbs that use notify() directly are probably doing some prompting of their
own.  See $player:@more for a good example.  In these cases it would be
okay that the builtin notify() didn't generate a prompt.

I may have missed something, and I apologize for the rambling.  :)
Follow-Ups: References:
Home | Subject Index | Thread Index