21 Aug, 2012, Alathon wrote in the 1st comment:
Votes: 0
Since I'm writing JABB from the ground up, I've suddenly started to doubt how I'd like to handle when to display prompts
and how to deal with it internally.

Are these assumptions generally correct, for what most people will expect on a MUD?
- A prompt is displayed at the end of a command that you issue.
- A prompt is displayed if an event occurs, which influences the state of your character (Such as being the target of attack/defense/whatever, but not f.ex receiving a tell, since it doesn't influence the character).

What I have now looks like this (And this looks wrong):

<Prompt here>say Test
You say, 'Test'

<Prompt here>Alathon says, 'Test2'

<Prompt here>say test
You say, 'test'

<Prompt here>say test
You say, 'test'

<Prompt here>Alathon leaves the game.


The says (And the leaving announcement) from others should, at minimum be on their own line. But to avoid having to prefix with newline on most stuff, I'll probably go with displaying less prompts overall. I'm curious whether I'm correct or not, as I'd like to figure this out now to avoid some serious redesign later in the messages sent.
21 Aug, 2012, KaVir wrote in the 2nd comment:
Votes: 0
Alathon said:
What I have now looks like this (And this looks wrong):

<Prompt here>say Test
You say, 'Test'

<Prompt here>Alathon says, 'Test2'

<Prompt here>say test
You say, 'test'

<Prompt here>say test
You say, 'test'

<Prompt here>Alathon leaves the game.

It would usually be displayed as follows:

<Prompt here>say Test
You say, 'Test'

<Prompt here>
Alathon says, 'Test2'

<Prompt here>say test
You say, 'test'

<Prompt here>say test
You say, 'test'

<Prompt here>
Alathon leaves the game.


Most muds also offer options for configuring blank lines.
21 Aug, 2012, Alathon wrote in the 3rd comment:
Votes: 0
KaVir said:
It would usually be displayed as follows:

<Prompt here>say Test
You say, 'Test'

<Prompt here>
Alathon says, 'Test2'

<Prompt here>say test
You say, 'test'

<Prompt here>say test
You say, 'test'

<Prompt here>
Alathon leaves the game.


Ah, I see - Thats quite a lot of prompts. I guess I can provide the player with the option of always seeing a prompt on things, or only seeing one on own actions / actions affecting the character.

KaVir said:
Most muds also offer options for configuring blank lines.


As in, whether to insert a blank line before a prompt?
21 Aug, 2012, Alathon wrote in the 4th comment:
Votes: 0
Seems I've got the behavior I want now, based on the following:

- When a client is sent a prompt, a flag is set on the client. If the flag is set, the client will receive a newline before subsequent text.
- This prevents the "<Prompt here>Alathon leaves the game." situation

- Clients can choose to receive a newline after being sent text, but before a prompt, for more separated output.
21 Aug, 2012, KaVir wrote in the 5th comment:
Votes: 0
Alathon said:
Ah, I see - Thats quite a lot of prompts. I guess I can provide the player with the option of always seeing a prompt on things, or only seeing one on own actions / actions affecting the character.

The purpose of a prompt is to "indicate readiness to accept commands. Its intent is to literally prompt the user to take action".

If you're not always sending a new prompt after other text, then I'd argue it's not really a prompt any more (it could also end up giving the same "feel" you sometimes get when a mud is very laggy). In that case you might be better off removing the prompt entirely and using a status bar instead.
21 Aug, 2012, Alathon wrote in the 6th comment:
Votes: 0
KaVir said:
The purpose of a prompt is to "indicate readiness to accept commands. Its intent is to literally prompt the user to take action".

If you're not always sending a new prompt after other text, then I'd argue it's not really a prompt any more (it could also end up giving the same "feel" you sometimes get when a mud is very laggy). In that case you might be better off removing the prompt entirely and using a status bar instead.


Hmm, quite. I suppose you're correct that I'm using a prompt more as a status update to the player. However, I'm not really sure on where to start if I wanted to go with a status bar instead, unless I end up doing something like a MUSHclient / MUDlet plugin. My problem with the prompt being sent every time, is that player prompts tend to take up a decent amount of space - And things like regular communication between players (Players sitting in a room, talking) tends to be short message -> large prompt -> short message -> large prompt. Which looks pretty bad to me.
21 Aug, 2012, Runter wrote in the 7th comment:
Votes: 0
I separated prompt from prompt with status update. You could just use "$ " or some such as a prompt, and have it display following the correct rules of a prompt (Which is after every block of text that wasn't a prompt.) every time. Then some of the time you can have it display the full status with the prompt: "[status bar]$ " etc.

I'd argue that no matter what you decide to do, you need a consistant prompt like KaVir explained if you have a traditional mud. Its purpose is just like in a shell. To tell you when you're in a wait state, or when its ready to accept input. If you make it arbitrary when it's displayed, most users will assume they're under a lag either generated by internet connection or the server.
21 Aug, 2012, Idealiad wrote in the 8th comment:
Votes: 0
IMO a prompt should automatically be turned off, but turned on if the player connects with a non-mud client (i.e. they're in a shell without a separate command window). Then the 'prompt' should be renamed to 'status' and configurable by the player.
21 Aug, 2012, Hades_Kane wrote in the 9th comment:
Votes: 0
I'm of the mind to give them the option. I haven't gotten around to it myself, but I think having prompt on, prompt off, and prompt <other options> would be good, in which case they would be able to either configure what events create a new prompt, or at the very least, have a prompt refresh/display only when one of the prompt values that are displayed changes (such as increase/decrease in hp, money, exp, etc).

That way, the whole "lag effect" thing is moot, because if the player has opted for that, then they are aware they aren't lagging, just not showing the prompt unless necessary.

Another idea might be to simply show: > instead of a prompt until new information is presented (as probably another option).

Particularly for players with screen readers, I think letting them set what degree of prompt spam they have to endure would be a good thing.

I'm planning on eventually going through and adding in an optional setting that will greatly reduce non crucial information, particularly during combat, as to give players an option to greatly reduce spam, and some prompt modifications / options will be a big part of that.
21 Aug, 2012, Alathon wrote in the 10th comment:
Votes: 0
It honestly surprises me that someone would think they were experiencing lag, upon not seeing a prompt. At least under the context of a game, where you'd very sparingly receive prompts/status updates
and only due to certain events. I'm not sure thats how it'll be in practice.

However, I don't particularly see any harm in spending the hour or two it takes to support the following:

- Player can turn a prompt on/off, with a customizable symbol (> by default). The prompt will display at the very end of any text block sent to the client, and can optionally be prefixed by a newline.
- Occasionally, the prompt will be replaced by a status-bar prompt which is more detailed (and whose display is customizable), when combat-related things occur, f.ex.
- The player can opt to always have the status-bar prompt displayed, no matter the reason.

That should suffice to support both those who want no prompt, those who want a minimal prompt, and those who want a full-blown MUD-like status prompt every time something happens.
21 Aug, 2012, Nathan wrote in the 11th comment:
Votes: 0
I personally find the prompt to be very annoying, and a bit spammy. Admittably its better than typing something like 'stats' repeatedly. I agree that a means to turn it off would be nice. I would suggest perhaps a way to enable it only in combat if it's treated mostly as a status update (unless you are designing in movement limitations).
21 Aug, 2012, KaVir wrote in the 12th comment:
Votes: 0
Alathon said:
It honestly surprises me that someone would think they were experiencing lag, upon not seeing a prompt.

I occasionally get this strange sort of one-way lag, where I'm still receiving text from the mud, but the commands I'm typing aren't going through. I'll hit enter over and over, then eventually it catches up and I receive a load of prompts. Other times I don't receive data either, and once again I keep hitting enter until I eventually get a prompt.

Alathon said:
At least under the context of a game, where you'd very sparingly receive prompts/status updates and only due to certain events.

Well once I know how it works then it's just a matter of getting used to it. But from a newbie perspective, if I'm not getting a prompt then my instinctive reaction is to keep hitting enter while getting increasingly frustrated. It might not be fair on your mud, but it's a pretty ingrained reaction.

Even when I'm using a GUI with energy bars, icons, graphical maps, etc, I still like to have a simple ">" prompt.
21 Aug, 2012, Hades_Kane wrote in the 13th comment:
Votes: 0
For those reasons, it would probably be best to default newbies to the "regular" prompt, and then later on show/teach them the customizing options.
22 Aug, 2012, Runter wrote in the 14th comment:
Votes: 0
As has already been said, if you're talking about a "prompt" you're talking about something that semantically is that the server is ready for input. If you're not meeting that goal, don't call it a prompt. Cause anything else is just debating if you need a prompt in a mud at all. Prompt != stat bar.

It's not just muds that this behavior. It's any CLI interfaces in general.
22 Aug, 2012, Alathon wrote in the 15th comment:
Votes: 0
Thanks for the input so far :) Its good to know that there are both those who consider the usual MUD 'prompt' (Which is usually a full status-bar as well) essential and those who consider it annoying, and those who like an in-between solution.

These are the 3 different modes I ended up with so far (With MUSHclient set to keep command input on same line as prompt):

Prompt off (Inserts a blank line, after ...
Prompt on (with newline-before-prompt on...
Prompt status (Replaces the prompt symbo...
22 Aug, 2012, Hades_Kane wrote in the 16th comment:
Votes: 0
Alathon said:
Thanks for the input so far :) Its good to know that there are both those who consider the usual MUD 'prompt' (Which is usually a full status-bar as well) essential and those who consider it annoying, and those who like an in-between solution.

These are the 3 different modes I ended up with so far (With MUSHclient set to keep command input on same line as prompt):

Prompt off (Inserts a blank line, after ...
Prompt on (with newline-before-prompt on...
Prompt status (Replaces the prompt symbo...


*thumbs up* I think that covers everything :p

Only other suggestion I might have would be to maybe have a seperate option for combat altogether, so that someone could choose to have their status display at all times, only when status changes, or not at all. I could see many people opting for the ">" prompt when not in combat and wanting to see it every round regardless during.
22 Aug, 2012, Alathon wrote in the 17th comment:
Votes: 0
Hades_Kane said:
Only other suggestion I might have would be to maybe have a seperate option for combat altogether, so that someone could choose to have their status display at all times, only when status changes, or not at all. I could see many people opting for the ">" prompt when not in combat and wanting to see it every round regardless during.


Yeah, that makes sense. The way it works now, theres an overridable procedure that helps determine if a statusbar should be sent instead of a prompt. So the programmer is free to decide whether combat should force a statusbar, or talking, swimming or whatever
else they have in mind.
22 Aug, 2012, Hades_Kane wrote in the 18th comment:
Votes: 0
I fully intend on having all the same possibilities on End of Time, I just gotta figure out how I want to go about checking whether or not any information in the status bar has changed since last time it's been displayed.
31 Aug, 2012, quixadhal wrote in the 19th comment:
Votes: 0
If you're using TELNET, you can always send the TELNET GA sequence after the prompt text. If the client supports it, it can use that to know the thing it just got really is a prompt. If not, it won't visually display junk… although it may break regular expression triggers the same way DikuMUD does by having LFCR as their broken line endings. :)
0.0/19