[Home] [Downloads] [Search] [Help/forum]

Gammon Software Solutions forum

See www.mushclient.com/spam for dealing with forum spam. Please read the MUSHclient FAQ!

[Folder]  Entire forum
-> [Folder]  MUSHclient
. -> [Folder]  General
. . -> [Subject]  Character \b
Home  |  Users  |  Search  |  FAQ
Username:
Register forum user name
Password:
Forgotten password?
(New message)
Subject: Character \b
Name:
Your forum user name.
Register forum user name
Password:
Your forum password.
Forgotten password?
Message:
Message to be posted (in English, please).
Forum codes:
Check this if your message uses 'forum codes' or templates (auto-detected for new posts).
Forum codes Templates

Save this message ...

Subject review (reverse sequence)

Pages: 1  2 

Posted by David Haley   USA  (3,881 posts)  [Biography] bio   Moderator
Date Sat 08 Jan 2005 07:11 PM (UTC)  [ quote  ]
Message
Hey, don't get me wrong either - I love MC as well (and think it's the best client, hence the recommendation for it on the BMud page!), I was just trying to make a small suggestion that I thought would be kind of neat. I didn't mean to have an argument or anything. :-)
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
[Go to top] top
Posted by Nick Gammon   Australia  (18,770 posts)  [Biography] bio   Forum Administrator
Date Sat 08 Jan 2005 07:04 PM (UTC)  [ quote  ]
Message
Thank you, Greven. :)
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Greven   Canada  (835 posts)  [Biography] bio
Date Sat 08 Jan 2005 07:29 AM (UTC)  [ quote  ]

Amended on Sat 08 Jan 2005 07:32 AM (UTC) by Greven

Message
Quote:
Greven, what you could do to handle this case of the "timer display" is detect the specific sequence, and omit it from the packet altogether, eg. match on:


Processing: |


You would delete that part entirely, and show it on the status line.

Then when you get a second packet:


\b /


You would also delete that, but update the status line, and so on until the sequence ends.
Thanks alot for the suggestion Nick. Never meant this as something large, was just curious about it. Honestly, its not that important to me, and I think I use a very small portion of MUSHclients functionality as I do almost no playing on muds, strictly development, and have the rare occasion for triggers and such. Aliases are useful though :)

I use MUSHclient mostly because it supports almost all things that my mud does, like MCCP and MXP. I also thouroughly like the look, feel, and use of the client. After years and years of gmud the resizable input area was a god send. Plus I thouroughly despise zmud.
Nobody ever expects the spanish inquisition!

darkwarriors.net:4848
http://darkwarriors.net
[Go to top] top
Posted by Shadowfyr   USA  (1,774 posts)  [Biography] bio
Date Sat 08 Jan 2005 05:05 AM (UTC)  [ quote  ]
Message
In my experience, applications treat the first character in a sequence as 'belonging' to the style, so if you had:

<grey>This is <blue>Fred\b\b\b\bWilma.\n

What you finally end up with is:

<grey>This is Wilma.\n

All in grey. You don't erase the style seperately, it is 'attached' to the first character in the line it effects. This, again, would be do to the transition from teletype to eventually Ansi and telnet. In the first terminals that allowed any sort of style or even color, they where literally physically coded into the display memory like:

@4This like is color 4$

Though, the @ and $ would have been unprintable characters. When Ansi emerged, the 'end of style' part got dropped, but the @4 like part remained. The reason being that each individual character was stored as two bytes, one to define the style, the second to define the letter. When you sent '^[[32m' to it, it automatically set each following characters 'style' to that color. So, when you used \b, it erased 'both' the letter and the style that was defined for the last memory address. Since Ansi was specifically developed to be used this way on such terminals, as was VT-52, VT-100, et al, the 'expected' behaviour is for the color/style information to be removed at the same time the letter you erase is. This is also why I am fairly sure backspace can't span lines, the terminals the standard was developed for wouldn't have likely allowed it. \b past the first part of the line and you would end up at the 80th column on the right of the display, not the 'end of line', since no special character was likely used in to designate where that was.

The newline would not likely, if used at all have been treated as a character itself, but merely the end of the 'visible' and thus erasable characters. However, that doesn't mean I am right about it. I am 99.9% sure of the color/style issue, but only about 70% sure of the newline one.
main {
__if (Schrodinger_Cat is Alive or version >= "XP"){
____if version = "Vista" then Performance /= Number_of_Cores;
____call Functional_Code();}
__else
____call Crash_Windows();}
[Go to top] top
Posted by David Haley   USA  (3,881 posts)  [Biography] bio   Moderator
Date Sat 08 Jan 2005 12:47 AM (UTC)  [ quote  ]
Message
Why do we care much about styles? That is, why would the MUD server try to erase a style, especially an MXP one? I think it should be fine to just make it undefined behavior whenever a an attempt to erase a style is made.
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
[Go to top] top
Posted by Flannel   USA  (1,230 posts)  [Biography] bio
Date Sat 08 Jan 2005 12:32 AM (UTC)  [ quote  ]

Amended on Sat 08 Jan 2005 12:33 AM (UTC) by Flannel

Message
I think defining a backspace as only being able to delete things on the same line is fine. Once a line has been finished with a newline, too bad. Your mud server is severely messed up, and you should take it up with your admins.

The question next is styles. Are they entities to be backspaced independantly? I would think not, since they arent characters being displayed. But do you erase it when the former character or with the latter character?
This would be for styles, MXP entities, and everything of that sort.
I would think it'd be when the character infront of it gets erased. A(style)B would cause the style to get erased when A is erased, or more specifically, the space in between the characters, which is where the style is anyway and seems to make more sense with MXP and such.

I would like to see the functionality be passed to plugins, in one form or another. But as to what the function is going to be, I really dont know. There are a couple ways to do it.
~Flannel

Messiah of Rose
Eternity's Trials.

Clones are people two.
[Go to top] top
Posted by Shadowfyr   USA  (1,774 posts)  [Biography] bio
Date Fri 07 Jan 2005 11:42 PM (UTC)  [ quote  ]
Message
As I said, that assumes backspace can even cross between lines in the first place. The only times I have 'ever' seen it do so is when it was actually a bug and incorrectly ignored where the line started. I may be wrong, but I don't think so, since it makes no sense from the standpoint of the original teletype system that telnet was designed to simulate, for that behaviour to happen.
main {
__if (Schrodinger_Cat is Alive or version >= "XP"){
____if version = "Vista" then Performance /= Number_of_Cores;
____call Functional_Code();}
__else
____call Crash_Windows();}
[Go to top] top
Posted by David Haley   USA  (3,881 posts)  [Biography] bio   Moderator
Date Fri 07 Jan 2005 11:33 PM (UTC)  [ quote  ]
Message
Quote:
Yes, but what will happen is that once a feature is added, you may not care if it isn't perfectly implemented, but 6 months later I will get a message (from someone else) saying "Your client claims to support backspace but here is some test data to prove it doesn't. I refer you to RFC xyz which shows your implementation is flawed. I suggest you fix it up straight away".
Sure, I see what you mean. But is there really no way to delegate this to plugins? I don't think MUDs will send random or useless backspaces such as the examples you give, so the average user will never run into problems.

If some bozo makes the claim that you don't fully support backspaces, then just say that indeed you don't and never claimed that you do. It's an "at your own risk, this does not fully work" kind of plugin. It just seems that it would be really nice (and not that hard) to just pop off characters one at a time from the end of the output buffer, and simply leave behavior undefined if the backspaces cross over non-printable characters (or MXP or whatever.)

If you stress that it doesn't work completely, and remind people that it's for very specific purposes - and recall that MUD servers won't just randomly send backspaces - it should all work out.

All this of course assuming that there isn't some technical reason for not being able to simply pop off a character from the output buffer.
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
[Go to top] top
Posted by Shadowfyr   USA  (1,774 posts)  [Biography] bio
Date Fri 07 Jan 2005 11:33 PM (UTC)  [ quote  ]

Amended on Fri 07 Jan 2005 11:35 PM (UTC) by Shadowfyr

Message
Quote:
Say I have something like this:

FOO\n\b\b\b\bBAR\n

If I have a trigger on FOO and one on BAR which one triggers? One? Both?


On BAR. FOO would be on a seperate line. The \b command does not, in any client I have ever seen, treat line breaks as a character that can be reversed over, so the \b\b\b part would simply not do anything at all. You can't delete what is on a line you are not on and such commands deal with 'lines' not the entire range of text sent.
main {
__if (Schrodinger_Cat is Alive or version >= "XP"){
____if version = "Vista" then Performance /= Number_of_Cores;
____call Functional_Code();}
__else
____call Crash_Windows();}
[Go to top] top
Posted by Nick Gammon   Australia  (18,770 posts)  [Biography] bio   Forum Administrator
Date Fri 07 Jan 2005 09:50 PM (UTC)  [ quote  ]
Message
That could possibly be done, but it still isn't as simple as it sounds.

MUSHclient potentially has a 500,000 line buffer. To quickly index into that (eg. when you scroll the window) it also has a "directory" which points to batches of 100 lines.

If it didn't have that, moving from end-of-buffer to line 250,000 would potentially mean scanning the linked list of lines for 250,000 iterations.

Now, if you remove even a single line, the directory would be "out" and have to be rebuilt, or adjusted somehow.

For now I am trying to get a stable release that I can call version 4, so things that might potentially introduce heaps of bugs, like omitting lines, backspacing etc. will have to wait.

Having said that, there is no real reason you can't make a "backspace processor" for the OnPluginPacketReceived which simply scans through, and if it finds a backspace removes the previous character, however I doubt that will work for the case raised in this thread.

Greven wants to use backspace to remove characters like | / - \ in a row, which is presumably shown over a lengthy operation, so each would be in its own packet.

In that case the OnPluginPacketReceived idea wouldn't work, as each packet would be separate.



Greven, what you could do to handle this case of the "timer display" is detect the specific sequence, and omit it from the packet altogether, eg. match on:


Processing: |


You would delete that part entirely, and show it on the status line.

Then when you get a second packet:


\b /


You would also delete that, but update the status line, and so on until the sequence ends.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Flannel   USA  (1,230 posts)  [Biography] bio
Date Fri 07 Jan 2005 09:25 PM (UTC)  [ quote  ]

Amended on Fri 07 Jan 2005 09:27 PM (UTC) by Flannel

Message
(This was an edit to that post, but it got long enough to support it's own post)

Sorry, wasn't thinking. This would require you to be able to get rid of those lines your colortelled. Thought hadn't even crossed my mind. Nick, what about if we could remove a random line from the buffer? Just the display buffer. Whether it was a note, or output, or whatever.
We have the tools to get the amount of lines in the buffer already, so we have everything else to be able to do this.

Although, there are obvious problems with that. Like what about if something else tries to get a line that has changed numbers?
Actually, would anyone be doing that? Since a simple note would throw off their count, they'd have to be checking before getting the information anyway, if they wanted to know it was the right line.

So, maybe that is a feasible command. Obviously, it would only remove it from the buffer, it would still be in the log as it were.
~Flannel

Messiah of Rose
Eternity's Trials.

Clones are people two.
[Go to top] top
Posted by Flannel   USA  (1,230 posts)  [Biography] bio
Date Fri 07 Jan 2005 09:18 PM (UTC)  [ quote  ]

Amended on Fri 07 Jan 2005 09:26 PM (UTC) by Flannel

Message
Couldn't a plugin be made to do this?
Well, if it were all on one line.
I would think backspacing over newlines would be a huge problem.
But write a plugin to handle it, and I would think the best way of doing it would be to treat backspaces as if they meant to erase the character prior. Not pieces of styles, nor styles themselves. abc if backspaced twice, would be a not ab(no-bold). If you only backspaced once you would get either ab(bold) or ab(no-bold) depending on how you felt it should act.

Couldnt this be done with a plugin? Partial lines, and then you colortell the text? And just keep colortelling the full text?

(On receiving a backspace character, the plugin adds a newline, which allows it to be caught (and omitted) via a trigger, you store that in a variable somewhere, which you can manipulate however you like (you can treat styles as you wish) and then colourtell every time you need it to change (another backspace character). If you get to the end of your line... well, you're not going back up a line, so it's blank. And once you get a newline, you finish off your line, and start listening for the initial backspace character again.
~Flannel

Messiah of Rose
Eternity's Trials.

Clones are people two.
[Go to top] top
Posted by Nick Gammon   Australia  (18,770 posts)  [Biography] bio   Forum Administrator
Date Fri 07 Jan 2005 08:58 PM (UTC)  [ quote  ]
Message
These are all part of the same idea:


  • Backspacing

  • Full-screen cursor addressing

  • Clear screen


This is what the telnet protocol supports, however a MUD client is not really a telnet client. If you want a telnet client, go ahead and download one.

But you really want a telnet client which also has:


  • Separate command window

  • Triggers

  • Aliases

  • Timers etc.

  • Logging

  • Long scrollback buffer

  • Word-wrap at edge of buffer

  • MXP with hyperlinks etc.

  • High speed


Some of these are quite tedious to do if you allow the user to willy-nilly move the cursor around (eg. clear screen, backspace, cursor address).

What happens with a triggered line, if the triggering text is changed by backspacing it, or cursor addressing into the middle of it?

Say I have something like this:

FOO\n\b\b\b\bBAR\n

If I have a trigger on FOO and one on BAR which one triggers? One? Both?

Some of these questions are going to come down to the word "compromise" - or maybe "user option" - or maybe "bug", if it doesn't work perfectly.

The point is, that for right or wrong reasons, it isn't easy to change now. For speed and space-saving reasons, internally things are stored in linked lists, style runs, cached MXP actions, and so on.

MXP for instance is parsed on-the-fly, not even at a newline.

So, imagine something like <b> (text is now bold) followed by \b\b\b <i> (text is now italic).

To allow this I have to not only handle the backspaces, but the effect of changing styles from bold to italic.

It just isn't cost effective to tackle things like this. I might spend many, many hours getting something like this coded, debugged, and go through maybe 5 release cycles whilst minor glitches are removed, and then it would only be for maybe a handful of users whose MUDs send backspaces.

Quote:

But if the server uses it incorrectly, MUSHclient makes no guarantees as to what will happen ...


Yes, but what will happen is that once a feature is added, you may not care if it isn't perfectly implemented, but 6 months later I will get a message (from someone else) saying "Your client claims to support backspace but here is some test data to prove it doesn't. I refer you to RFC xyz which shows your implementation is flawed. I suggest you fix it up straight away".
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Shadowfyr   USA  (1,774 posts)  [Biography] bio
Date Fri 07 Jan 2005 05:43 PM (UTC)  [ quote  ]
Message
> Again, this is trying to make a MUD client into a telnet client.

Mud clients are telnet clients. The fact that most muds have never bothered to take advantage of some telnet features is just a design decision. But some do attempt to take advantage of them, so I have never been sure what your point is about this issue Nick. Imho, all that assuming such things are totally unneeded does is limit the client, and thus force the mud developers to limit the muds themselves, even if they don't want to, because of the expectation that no one will have a client that does support such things. Of course, if other clients can do it, then you hang yourself instead. It really doesn't make a lot of sense to support only subsets of features, that someone might have the unmitigated gall to then use anyway. lol
main {
__if (Schrodinger_Cat is Alive or version >= "XP"){
____if version = "Vista" then Performance /= Number_of_Cores;
____call Functional_Code();}
__else
____call Crash_Windows();}
[Go to top] top
Posted by David Haley   USA  (3,881 posts)  [Biography] bio   Moderator
Date Fri 07 Jan 2005 07:19 AM (UTC)  [ quote  ]
Message
Is there any way you could have this as an option, 'enable at your own risk', that worked if and only if the server used it in a well-behaved manner, e.g. only erasing characters that are actually present. But if the server uses it incorrectly, MUSHclient makes no guarantees as to what will happen (most likely a crash.)
Quote:
Again, this is trying to make a MUD client into a telnet client. I can envisage all sort of complications, like backspacing over style run boundaries, or removing a hyperlink that MXP had just put there.
Isn't MXP trying to make a MUD client into something it didn't use to be, though? And isn't a MUD client really a telnet client to begin with? That's how it started, after all. *grin*
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
[Go to top] 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.

4,601 views.

This is page 2, subject is 2 pages long:  [Previous page]  1  2 

[Reply to this subject]  Reply to this subject   [New subject]  Start a new subject   [Refresh] Refresh page

Go to topic:           Search the forum

[Go to top] top

[Home]

Written by Nick Gammon - 5K

Comments to: Gammon Software support
[RH click to get RSS URL] Forum RSS feed ( http://www.gammon.com.au/rss/forum.xml )

[Best viewed with any browser - 2K]    [Internet Contents Rating Association (ICRA) - 2K]    [Web site powered by FutureQuest.Net]