Can anyone help with this problem?

Posted by Vector on Tue 02 Sep 2003 11:27 AM — 9 posts, 31,504 views.

USA #0
I'm editing a file on an LPMUD, and MUSHclient does this...

1034. *

What is that character on line 1034? The editor has a * to prompt you for adding lines of code.

I have tried this in GMUD, and don't have any strange symbols.
Canada #1
I just copied your little block into windows clipboard, then went to MUSHclient and typed /world.note asc("") and got back 8, which is the ascii value for that symbol.

Some ascii symbols represent special things, like 10 is a return (or maybe it's a line feed, I forget). Knowing which ascii character it is may help track down the purpose for it's being echoed.

If you have any doubts about the display of the character, you can turn on MUSHclient packet debug, and examine the actual communication packet to clarify matters. (EDIT | Debug Packets).
USA #2
It is line feed Magnum. 13 is a charage return.

However, in this case, 8 is a backspace. This is supposed to trigger a client that knows what to do with it to delete the character just prior to the arriving character 8. Apparently Mushclient is ignoring this character and trying to display it instead. Of course, this makes no real sense for the mud to be sending this anyway, since it would erase the * from the display as well. I can't see why Mushclient would be showing it...
Australia Forum Administrator #3
If you don't mind my saying it, a server sending a "backspace" to a client is rather bizarre. I mean, backspace might be used from the client ot the server, to indicate you made a typing mistake. But why would the server send one? Did the server software make a typing mistake?

I suggest that the backspace character should not be being sent by the MUD in the first place, and MUSHclient is just trying to display what it receives.
USA #4
I have not eliminated this problem yet. After more testing on different muds, I have come to this conclusion... This only happens on LP muds, with the built-in editor. MUSHclient is sending a backspace character, when it should be an asterisk.

This is the output I get again:

1. *[]

Can anyone think of a way to fix this? I want to be certain that this is something the server is doing, and not MUSHclient.
Amended on Thu 18 Sep 2003 10:17 AM by Vector
Australia Forum Administrator #5
Sending a backspace? You mean displaying an asterisk?

To be sure, turn on Packet Debug under the Edit menu and see what appears, in hex, for the line in question.
USA #6
I turned Debug Packets on, and this is what appeared:

*... 2a 08 ff f9

How do you interpret this? Does every char represent a new hex value? If this is a server related problem, can I do anything about it?
USA #7
Hmm...

I was on another LP mud, and one of the Imms said that MUSHclient has been doing this for a year now. Well, this is only happening on certain muds. Can I write a trigger to fix this? Do I need to wait for Nick to take care of the problem?

And I only get the *[] on MUDs (LP) that have the ed (built-in editor). I don't know if there is anything I can do on my side. However, I have tested this on GMUD, and the square does not show.

Any thoughts?

Australia Forum Administrator #8
Quote:

I turned Debug Packets on, and this is what appeared:

*... 2a 08 ff f9

How do you interpret this?


Each 2-character hex code is one byte. Thus you have four bytes. They are:

  • 2a - asterisk
  • 08 - backspace to remove the asterisk
  • ff - IAC (start of telnet negotiation)
  • f9 - TELNET_GO_AHEAD - go ahead and do something


It is a mystery to me why the server sends 2a and then 08. If they don't want you to see the asterisk, surely it is easier not to send it?

Backspacing is for when a human makes a mistake. I would think that if the server "makes a mistake" it is easier to correct the server code, not have it send backspaces to the client.

Quote:

I want to be certain that this is something the server is doing, and not MUSHclient.


The server is doing it, and I suppose you could argue that MUSHclient should honour the backspace. But what if this happens?

blah blah \n \x08 blah blah

Where \n represents a new line. Now when MUSHclient gets a \n it does trigger processing, logs the line if applicable, starts a new line in the output window, and so on. Would you expect in this situation that MUSHclient then notices the backspace and then undoes all that?

Or what about this:

blah blah (some colour change here) \x08 blah blah

Would you expect the backspace to undo the colour change?

I really thing it is weird for servers to send backspaces and am in no big rush to change MUSHclient.