MOO-cows Mailing List Archive
> At 02:19 PM 22/02/96 PST, you wrote:
> >Hey, was talking to a few people (Kipp, and a few others) about setting
> >up a prompt similar to those on MUDs. Kipp tells me that a while back
> >Pavel wrote about how to set this up, and I'm wondering if anyone could
> >either a) point me to a FAQ file with this in it, or b) tell me how to do
> >it. Kipp gave me the verb code for a verb named Prompt, but I'm not sure
> >how it functions and where it goes.
> The MUD type prompt will not be solved entirely by 1.8.0, as over and
> above the ability of sending a non CR/LF terminated line, you will need
> the ability to send a prompt under all circumstances.
> What has been proposed in the other followups will require you to call
> something like player:do_prompt() at the end of every non 'this none this'
> verb. A task sure to daunt even the most fearless programmer.
> The solution is to have the server call a verb after decoding and
> processing every input from the player, even a blank line (such as when
> the player presses ENTER or RETURN only). I wrote a patch for this, and
> can dig it up if nobody else still has a copy of it for you.
> Unfortunately, you will have to patch it for 1.7.9 as I wrote it for
> 1.7.8p4. However, there is the distinct possibility that you can
> insert the patch without modification.
> All it really does is, inside server.c, in the main program loop, after
> decoding AND executing the line of text typed by the player, it calls
> the verb #0:do_prompt() IF the verb exists. I found the best thing to
> do inside there is to just call player:do_prompt() which handled things
> like prompt enabling, disabling, customizing, etc.
> The nice part about it is that the prompt will display even if the verb
> you are calling suspends for any reason, as well as when the player
> just presses ENTER, something no in-db verb can do.
I wrote a patch for this for 1.7.8p4. I ported it to 1.8.0alphas, but not
for 1.8.0betas for yet. I first wrote it like Ian's, then modified it to
track down suspend()ed or read()ing commands, and call #0:do_prompt()
after the task completely ended. Then I added a built-in and $server_option
to control its action. (the server may or may not call #0:do_prompt() when
a *command* task suspends, and don't call #0:do_prompt() while read()ing)
It doesn't call #0:do_prompt() for fork()ed tasks. (seems natural to me)
However, it had some subtle bugs, and I couldn't wipe them out. I
modified the code heavily (200+ lines added) and thinks it needs some
refining, but I haven't got enough time for it. I'm planning to finish it
after final 1.8.0 release. Unfortunately, there may be little time to
concentrate on this until summer......
If anyone interested, I could send the patch or make it available by
Ahn, Jin-su email: firstname.lastname@example.org
School of Electrical Engineering LambdaMOO: Deedlit(#103811)
Seoul National University, Korea
Subject Index |