Room Description Layout Issues

Ok, here's the issue. I have searched many different keywords and didn't see my issue brought up before.

I have a few rooms laid out, no issue. Exits linked, again no issue. I do redit desc and pull up the editor, no problem. I type a few lines in (im in playing mode right now, so I can learn before going completely live aside of friends and others.). I then /s on a new line to save.

This is where the problems start. When I do look (or even l) here is what the description looks like:


Room Name Here
description line one with a few words.
Description line two with a few more words.
Description line three with a few more words again.
Few more lines. You get the point.
EXITS: North, South


It's not centered. It seems each time I hit enter it does a new line (no issue) but it won't align all the lines I put in to the left like the stock zones currently are descripted.

What am I doing wrong? I tried to fill up each line with about 70-75 characters before hitting enter. It still does the same thing. it does it on my MOTD's as well. I have tried to /s after each line and reedit as if to add a line, but it still does the same. I'm confussed. Any advice?

Thanks in advance.

What you're seeing is the expected behavior, although it might not be the desired behavior. The editing code doesn't reformat what you entered; it just stores it exactly as is.

By the way, did you mean "justified", "line-wrapped" or really "centered"?

I mean like all the other stock smaugfuss rooms are. You know like this:




In the redit edit screen, when I hit enter to advance down a line (to avoid the mud from cutting the sentence off) it puts it on a new line at the end of the first line instead of right below the first line. Unfortunately I'm on a friends winblowz machine tonight so the command prompt telnet won't let me cut and paste verbatim, and the posts get edited to show correctly on this forum.

Edited by Nick Gammon to insert the [code] tag.

It's not letting me post correctly.

Uhm... basically each start of the new line is one line down and at the END of the previous line. If that makes sense.

Ignore the dots, lets see if I can portray this right.


Room Name Here

blah blah blah blah this is line one description....... .................................................This would start line two description. ...........................Thiswould start line three description. .............................................. ............This would be line four description. ............ ................................................EXITS: North, West



Hopefully that works. Ignore the dots tho.

Nope forum not formatting it right. Line one formats fine, Line two starts on line two but at the END of line one so there's a big huge space before line two's sentence and so on.

Use the code tag to show us what you mean.

This was recently discussed at The FUSS Project (http://www.fussproject.org/index.php?a=topic&t=1098) basically the problem is with copy_buffer and it only impacts certain clients, like the telnet that comes with windows or putty.

The forum does not show "as is" formatting unless you use the [code] tag. Click on "What are forum codes?" when you edit a post, for a list.

Thanks Conner. That solved the issue.

Appreciated.

Always glad to be able to help instead of just needing help. :)

The problem, and it's a known issue with "raw" telnet clients, is that telnet is interpretting the exact codes sent by the mud. In this case it's being sent "new line" which any actual mu* client will, based on proper standards, interpret as "new line, carriage return". Without the code for carriage return all a raw telnet client will do is move the text down a line and start printing where the previous line ended. The issue is actually in the telnet implementation and isn't really something that can be readily fixed server side.

Conceivably the "low level" output routines could check for linefeeds that are not preceded by a carriage-return, and insert one.

Most serious MUD players will use a proper MUD client, in which case the problem goes away.

However there is potentially a possibility that poorly-formatted MUD output would put off someone who was "putting a toe in the water", so they would lose interest, and never get to the stage of getting themselves a good client.

That's one option but you will be doublespacing everything sent to an actual mu* client unless I'm forgetting a way to determine "raw" telnet clients. You could I suppose add a dummy check to the negotiation phase of connecting but this may well be more trouble than it's worth to fix given the very small number of people willing to use windows telnet for anything they don't absolutely have to.

Why would this double-space everything? If you make sure that you never have \n on its own, and always pair it with a \r, you should be fine (unless clients are breaking lines with \r as well, but I don't think they do).

Of course, you have to be careful with people using the sequence in the wrong order; you'd have to realize that \n\r and \r\n are "basically" the same, and you don't need another \r in front. (Although it shouldn't do any harm, except perhaps to a Mac.)

Nick will have to correct me if I'm wrong about how clients that interpret /n as /n/r work. If the client is reading /n to include /r adding an actual /r would in fact double space everything sent to that client since both the mud and the client are applying /r to the same /n.


The fact that MS can't manage to properly apply a protocol standard isn't something that should inconvenience the rest of the world, despite the fact that it regularly does so.

As far as I can see, some MUDs (SMAUG springs to mind) tend to send a combination of \r or \r\n to mark end of lines. For example, internal code tends to use \r\n (for some reason), however routines that "dump" a file to the client (eg. a help file) tend to send it "as is" which will generally be with only \n at the end of lines, if the file was edited under Unix.

This means that a standard telnet client will "sort of" work, which isn't particularly helpful.

What MUSHclient does, and I imagine others do too, is do this:

• Discard \r totally - to avoid the double-spacing issue
• Start a new line at \n

However MXP tags can modify that behaviour too, making lines wrap around, even after a \n (like HTML does).

This behaviour can sometimes lead to problems, such as MUDs that do things like a "milestone count" by sending something like:


\r 10% \r 20% \r 30% ... and so on


In this case, the \r is supposed to return the cursor to the start of the line, to "wipe out" the previous percentage.

There is an option in MUSHclient for \r to "clear the line" which effectively should make that sort of stuff work. I know it isn't perfect, as \r isn't supposed to actually clear the line, however for the sort of situation described above, that is acceptable.

Ok, so I kinda had the client interpretation backwards, but based on this excerpt from the telnet protocol whitepaper (http://www.faqs.org/rfcs/rfc854.html)



The actual clients are following the standard as written.