Register forum user name Search FAQ

Gammon Forum

Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the password reset link.

Due to spam on this forum, all posts now need moderator approval.

 Entire forum ➜ MUSHclient ➜ Suggestions ➜ PROPER handling of prompts
PROPER handling of prompts

It is now over 60 days since the last post. This thread is closed.     Refresh page

Posted by Worstje   Netherlands  (899 posts)  Bio
Date Sat 03 Oct 2009 02:09 PM (UTC)

Amended on Sat 03 Oct 2009 02:24 PM (UTC) by Worstje

Message
As I mentioned while replying in another thread, I've been toying with my own codebase lately. And it just makes me cringe to see how some 'clients' butcher standards. MS Telnet is particularly horrible in how it claims to do its own echoing, while completely denying to do so. :(

Anyway, this is the MUSHclient forum so on to my 'beef' here.

First problem is the 'Keep commands behind prompt' option. It should by default be ON, since the entire point in nearly all muds I have played is to have a 'status line' of sorts and behind it you can type what you want. Linux telnet and other clients also treat it as such. New players, or new people, will rarely find that option. Hell, I used MUSH for 5 years now, coded it into extremes I suspect most other people haven't, and I found out about it today.

But my biggest and foremost problem is with the 'Convert IAC EOR/GA to newline' option, which is a complete hack as it is now (sorry). I used to be able to put up with it, since the muds I played had prompts but I didn't really care where my typed text ended up, or I even had the echos turned off.

But now that I am playing with my own codebase, I feel it is of bigger importance to have such behaviour correctly. Testing other clients made me realize how much I enjoy having the commands behind my prompt. Yet, there is NO way to do this while still be able to trigger the prompt while it comes in (as opposed to when you finally finish the line by typing something). So right now, people have two choices:

1) Commands on the same line, or
2) Triggering the prompt.

In many muds, especially PK related ones, spam is heavy, so you want to have such commands on the same line, while you still want to see them ('oh, I made a mistake here by doing X, should have done Y instead'). For people looking for this, there is no proper alternative. To boot, triggering on the prompt always has had this annoying behaviour of spawning extra newlines into existence.

However, I hate making complains without offering fixes. So, my (codish) suggestions to fix this behaviour are as follows:
1) Display the current line the moment IAC EOR/GA comes in. I assume that internally, MUSH needs the newline, so that can stay.
2) Add a prompt flag to this line so you can tell it apart.
3) When typing stuff yourself (+echoing it), append to the end of the previous line IF it has the prompt flag, or a new line if it does not.
4) When mud output comes in right after the prompt without us sending/echoing data on the prompt, show it on the same line as the prompt flag. This new content will have a \r\n somewhere due to the mud believing it needs to finish the prompt (although I am sure there are muds who will first add some stuff to the prompt, and THEN add a newline). Thus avoiding the extra newlines the old 'fix' kept giving. Unless you want to implement the optional change to triggers way at the bottom of this post, I suggest the second time this line is 'completed' (by \r\n this time) you do not test it against triggers or you'd get prompts that get triggered twice.

Now, this might/will give some complications with existing scripts, but I have a suggestion for those too:

5) Any and all user commands will ends up on a new line (Tell, Note, etc) if a prompt was the last thing there was. This would probably be no change in behaviour assuming MUSH added the newline it wanted behind the prompt (see point 1)
6) Add the following commands:
AtPrompt() returns boolean if we are currently on a prompt (check the flag we set)
ContinuePrompt() removes the newline MUSHclient added to the end of the prompt line before it, allowing other echoing commands to append to the end of the prompt. It will also remove the prompt flag (for simplicity). This would FAIL if AtPrompt() returned false.
CompletePrompt() will finish the current line and add a newline like Note() would. However, it will also SET the prompt flag for the line you finished, effectively simulating the IAC GA or IAC EOR commands.

This way, we are keeping the current behaviour while also adding functionality. As MUSHclient is now, you can't adjust the prompt while keeping the 'keep commands after prompt' working, unless you dig through the packet. And that can only change basic text (no full RGB color, no hyperlinks unless the server supports MXP, etc). So with this change, you could:
1) keep your commands after your prompt,
2) trigger on your prompt, and
3) replace your prompt
ALL at the SAME time.

Another optional improvement that could be made would be to add a three-way prompt flag to triggers like the textstyle flags. That way, you could trigger on prompts ONLY, non-prompts and both. It isn't really necessary, but I think it might be nice to add.

Even more efficient a solution would be, rather than to set the flag on the line of the prompt, to keep the 'prompt flag' in your connection-state-machine of sorts.

Could both these suggestions (default setting / changed prompt behaviour) be implemented? Pretty please?
Top
Posted by Nick Gammon   Australia  (23,133 posts)  Bio   Forum Administrator
Date Reply #1 on Sat 03 Oct 2009 10:24 PM (UTC)
Message
Quote:

'oh, I made a mistake here by doing X, should have done Y instead'


What is the big problem exactly? If you echo prompts, you still see what you did, and you can see if you made a mistake. It just happens to be on the next line.

Quote:

... triggering on the prompt always has had this annoying behaviour of spawning extra newlines into existence.


I just use a plugin that suppresses blank lines - that tends to work pretty well for situations where the MUD thinks it needs to chuck out a newline.

Quote:

ContinuePrompt() removes the newline MUSHclient added to the end of the prompt line before it ...


MUSHclient doesn't exactly add newlines, it simply starts a line with a new line type.

Quote:

Add a prompt flag to this line so you can tell it apart.


Already each line is flagged as one of:


  • MUD output
  • User input
  • Note (or ColourNote etc.)


I suppose there could be another type: (MUD output ending in IAC/GA)

To be honest Worstje, if I was making a new codebase (which I am thinking of) I would be moving right away from the prompt/response model. This is kinda 1960's technology.

The big problem with the current model is, if you want smart clients that show status line, room exits, mobs in room, what your health is, etc. they currently have to use triggers to try to hopefully parse MUD output, allowing for things being broken between lines, prompts appearing in the middle, etc.

I would be moving to a "transaction" model where the MUD sends something like this:


{
transaction="status",
hp=2343,
mana=432,
move=32,
}


(Note the resemblance to Lua).

The client then definitely knows this is an update to the player's status, and updates its status bars. Similar things could be done for room descriptions, chat, etc.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Worstje   Netherlands  (899 posts)  Bio
Date Reply #2 on Sat 03 Oct 2009 11:21 PM (UTC)
Message
The point is, simply put, to allow MUSHclient to do a basic thing properly. If you don't care -where- your echoed output goes in the log, it is a non-issue. But just like how working in a terminal makes it logical to have your commands behind a prompt (be it #, $, /home/worstje@, etc), so does it make sense to have these two besides eachother. Prompts and commands go side-by-side, and while I can very much live with people who don't want to show commands or prompts, or don't want them on the same line, I feel that for an old and tried medium like muds that is a feature we can expect to be supported.

If we started fresh, I completely agree, I'd do things differently myself as well. It is an old protocol and many things can be done better nowadays. But right now, one of the (many) charms that mudding still has going for it is that everyone can log on, be it with a fullfledged client, with a webclient written in java/flash/silverlight or even AJAX technology. But in the worst case, there is always telnet, something all operating systems still have (although MS telnet.. doesn't deserve the name). Any drastic changes you might be thinking of would need either graceful degradation, or a popular mud to promote it.

I like your Lua suggestion. How about we think of a telnet option LUA so we can go 'IAC WILL LUA', 'IAC DO LUA', followed by an extactic 'IAC SB LUA LUA!! IAC SE' ? =)

Either way, back to the original subject... does my implementation suggestion have any flaws? I don't really have the time to try and get MUSH to work/compile on my own pc after all I've read about it from others, but from what I know of its inner workings I think it would be easy to implement: add a line here, add a line there, done.
Top
Posted by WillFa   USA  (525 posts)  Bio
Date Reply #3 on Sun 04 Oct 2009 12:23 AM (UTC)
Message
On the mud I play, I get a prompt after input and an hpbar every round of combat.

I will get a prompt after I type 'kill critter', go several rounds of combat and then I may have to type something again...

If handled "properly" where would the prompt be echoed? When the mud sends it, or when I send the next command? Would it be echoed twice? omitted from log the first time and duplicated when another command is sent?

Mudclients don't emulate VT terminals exactly. They have 2 windows, one for input and one for output and while doing that it would be highly problematic to have cursor position emulation.

A potential work around could be to have a plugin that triggers off the prompt, remembers the line number when a prompt is received, deletes the previous prompt, and then echo's the current prompt as the last line of the output. When sending a command to the mud, the plugin would log the prompt and your command. Your logs would then read like a logged dos prompt and you'd have your prompt sitting at the bottom of the screen. I have no idea how well this would perform in practice though.
Top
Posted by Nick Gammon   Australia  (23,133 posts)  Bio   Forum Administrator
Date Reply #4 on Sun 04 Oct 2009 12:48 AM (UTC)
Message
Worstje said:

The point is, simply put, to allow MUSHclient to do a basic thing properly.


I think I would prefer to substitute the word "differently" to "properly", as "properly" is a value-laden word that may conceivably get people's backs up.

As Willfa points out, you can easily have this situation:


<24hp 145m 110mv> <#21036> 
Rain falls heavily down on the ground.
Thunder and lightning shake the ground and light up the sky.


Now if you type something (eg. "inventory") are you expecting the word "inventory" to be backdated up to the prompt line, which is now not the last line?

A basic design of the client was that there were three types of lines, as I enumerated earlier:


  • MUD output
  • Your typing
  • Scripted notes


Your suggestion of combining output with typing breaks this concept, for a start.

Willfa said:

Mudclients don't emulate VT terminals exactly. They have 2 windows, one for input and one for output and while doing that it would be highly problematic to have cursor position emulation.


Exactly. The client doesn't pretend to emulate a telnet terminal - we still periodically get requests for cursor positioning for people that want to whip the cursor around the screen and draw fancy graphics.

I'm not saying something along of the lines of what you want can't be done, maybe as an option. I'm just saying that it isn't "improper" in its behaviour, it is by design, and the design had some reasons behind it (one being to get triggers to fire properly).
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Worstje   Netherlands  (899 posts)  Bio
Date Reply #5 on Sun 04 Oct 2009 09:42 AM (UTC)
Message
My experience with muds having prompts is such that they always (well, apparently not always I guess) throw up a new prompt after echoing something. E.g.

<24hp 145m 110mv> <#21036>

Data comes in, and a prompt is appended to the end:
<24hp 145m 110mv> <#21036> 
Rain falls heavily down on the ground.
Thunder and lightning shake the ground and light up the sky.
<24hp 145m 110mv> <#21036>


My suggestion would only affect those clients which 'end' their data with a new prompt, hence my saying that the flag didn't necessarily needed to be put on a prompt line, but could also be part of the state machine.

In other words, it would only have an effect if the prompt was the last thing received. If the prompt was NOT the last thing received, it would simply show it on a new line. My original proposal says this in the number 3) point. The point is not to backtrack through the input and find the last prompt - that would make no sense chronologically - and the invariant 'typed commands end up at the end of the buffer' still remains. It would just be moved onto the end of the last prompt displayed, if the prompt was the last thing received.

To re-iterate the most important points of the proposal:
- Prompt 'echoing' isn't changed. It still always appears when originally sent by the mud.
- The only thing that changes is the location of a newly typed command, which is added to the end of the last line IF it is a prompt.
- Scripts are given access to the ability to add to the end of the prompt, and for that matter, substitute it for their own without breaking 'keep commands behind prompt' line.


Yes, I am aware all lines are either mud output, notes, or my typing. And you say my suggestion breaks this concept, which I will concede. However, this would also by definition mean 'Keep commands after prompt' is a broken concept already, since that too combines something: mud output and user input.

The suggestion as it is doesn't change any of that. The only place where this form of 'mixed' line would exist would still only be the prompt. The change is that it will allow users to make their own prompts to replace it with their own, without side-effects as extra newlines, while still being able to have the 'keep commands after prompt' line work.

WillFa, your suggestion for the prompt plugin to emulate this behavior does not work. For one, it can't be scripted due to limitations in the API, for second, it would need to hold its own settings and NEED to have certain world settings configured, and third, any plugin to implement this would be a lot more complex and errorprone than the implementation I have suggested in my initial post.

That said, I see a lot of things being brought up about how a client is -designed-. That's great. But what I was hoping for, and haven't seen so far, were reasons why my pseudo-code suggestion can't be implemented. I have given it a lot of thought as to how it could best be implemented in MUSHclient without breaking any existing behaviour, and to my knowledge is breaks none and only adds possibilities.

I'll offer to actually implement it if someone can set me up with the latest version that compiles properly in Visual C++ 2008 Express - going through 6000 warnings&errors to convert a project myself is something I simply don't have the time for.
Top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

19,747 views.

It is now over 60 days since the last post. This thread is closed.     Refresh page

Go to topic:           Search the forum

[Go to top] top

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.

Home