Prompt system

[vincent-lg]

Hi everyone,

In a lot of MUDs we still find lying around the Internet, there is a simple or complex prompt system. This "prompt" is usually a line at the bottom of the output showing your vital statistics and this line is sent on a regular basis (usually, when you do something).

I'm not a huge fan of the prompt system. It usually means one has to move rather quickly, which is not my thing. But the player base has its own idea. So I was wondering how to add such a prompt system? It's not that simple.

First, it ought to send the prompt to the player whenever we send her something else.

You say: "that's helpful"

HP: 50   End:   15

So we send her the message You say: "that's helpful" and the prompt magically appears.

But if several messages are sent "at once", the prompt should only appear once.

So nothing like that:

Output 1.

HP: 50   End:   15

Output 2.

HP: 50   End:   15

... but something like this:

Output 1.
Output 2.

HP: 50   End:   15

Adding a prompt doesn't sound too bad: perhaps one could override the player:notify verb for instance. I'm not a hue fan of the solution (it doesn't sound very safe). However, when adding the additional constraint on grouping, it sounds extremely difficult.

The best option would be to postpone sending when we use things like player:notify and instead queueing messages. At some signals (left to be specified but usually when the command task has ended), ALL queued messages are actually sent and we add, after a blank line, the prompt. If necessary (it sometimes isn't).

I have no idea if it would be simple to add in ToastStunt and how to do it. Any idea would be great!

Thanks to keep MOO alive and well,

Vincent-lg

[tvdijen]

Why not just only output stats whenever they change?

Other than that, there are several enhanced clients that can display your stats in a GUI. The stats would be exchanged between server and client using out-of-band communication using a protocol like MOO Client Protocol (MCP)

[vincent-lg]

Good ideas. Unfortunately, a majority of the community doesn't use a client that supports MCP.

The other option, send the prompt only when the stats are modified, could indeed solve the problem. Of course, the prompt would then appear between messages rather than at the bottom, but I don't think that's such an issue.

What would be my best bet for implementing this? Overriding $player:notify?

[tvdijen]

It's easy to put tons of stuff like this inside $player:notify, but remember that any little bug in that verb can give you a really tough time. Also, you would have to make it check if stats have changed for every single line of output. You must have heard of the KISS principe once in your life.. Keep it stupid, simple. $player:notify should do just that; notify output.

Instead, create $player:notify_stats to output the stats and trigger that verb from the code where you update the stats. The end result will be small and easy to read pieces of code and the least amount of overhead.

[vincent-lg]

Indeed, it seems quite dangerous. Your solution is probably much better. Come to think of it, I could also design a special verb on $root_class, say msg or queue or whatever, that just stores the message but doesn't send it, and then a verb to flush all queued messages to all players. Since I'm planning on writing all commands, this doesn't look like a bad solution. Commands in the original database might not have that, not a big deal and easy to add if need be.

[tvdijen]

That would actually be re-inventing the wheel, because the notify() builtin using it's second parameter provides exactly this functionality. << Forget what I said here, there is no builtin available to control output buffers.

Adding stuff to $root_class can be very handy, but be aware that for each use of $ the MOO will loop through every verb or property on #0 until it finds a match. The more you add on #0, the more overhead you will create.

[NathanTech7713]

Peaked my interest on this one, especially that last comment there.
Surely that's horribly inefficient, especially as modern toast has maps and such?
Would be interested in having a nose at where it does this lookup, could it be converted to an in-mud matcher that could be shunted over to a map?

[tvdijen]

I must admit I was talking about legacy LambdaCore.. I haven't seen the ToastStunt DB in a while.
From the top of my head most of the $ magic is done in #0:do_command, $command_utils:do_huh and $code_utils:corify_object and $string_utils:literal_object, but forgive me if I'm wrong.. Haven't touched MOO since forever :)

[vincent-lg]

@tvdijen : agreed, but I don't think I could edit flush_input() which would definitely be a good fit. I would add a prompt right there and it would do the trick. But it's not possible. So I'll have to do it another way and stop using notify at a high level. It's not the ideal solution but I don't see any other to do what I need to do here. I have nothing against reinventing the wheel (yes, and I call myself a programmer) when it comes to learning, and if the wheel doesn't do what I need, then reinventing it is. But I wasn't sure what I planned was the only approach. And of course, storing messages to send in a MOO list is not just redundant, it will be worse in performance overall.

As a reminder, I would need to insert a line below each output line, but allow some kind of grouping. I don't see another option and I don't really like touching $player:notify, seems error-prone to say the list.