10 Oct, 2007, jjack wrote in the 1st comment:
Votes: 0
So whenever I use the buffer editor to do OLC description edits (for rooms, deities, etc.) everything is goofy.
My text looks like this:

So here is a line of text. I'm getting to the end of the line so I'll
Hit enter…oh wait why
didn't the text go back to the beginning? There it goes, well
let me try this again.
See what I mean? The thing is pretty screwed
up and I don't really get it.


Do I need to put in a manual return symbol or something?

Edit: I guess I should specify, when I do a /l in the buffer editor it looks OK, but in the game, when I do a "look" or something, it's all messed up.
10 Oct, 2007, Davion wrote in the 2nd comment:
Votes: 0
This really doesn't look like a problem with building or something you're doing, ask your programmer if the formatting looks right (I'm assuming that /l just word wraps a descritpion) because it looks like to me, that the new lines you're tossing in there aren't getting completely removed.
10 Oct, 2007, jjack wrote in the 3rd comment:
Votes: 0
To be more clear…I'm hitting "enter" at the end of each line. So at the end of "I'll" I hit enter. When i do a /l it looks like this (the <enter>'s are just me specifying where I pressed the key):

Quote
So here is a line of text. I'm getting to the end of the line so I'll <enter>
Hit enter…oh wait why didn't the text go back to the beginning? There it goes, well <enter>
let me try this again. See what I mean, the thing is pretty screwed <enter>
up and I don't really get it.<enter>


So you see…everywhere I hit enter it begins a new line. But it DOESN'T return to the left side of the screen and begin entering text there. It reminds me of the old days on a typewriter…

So I pull up the file in nano and it looks fine, exactly like I want it to appear, exactly like the quote above in this post. If I erase the whole thing and re-write it in nano, writeout the file and reboot the server, viola it works…even though there is apparently no difference between the two paragraphs.

I hope maybe this can shed some more light onto what's going on. I'm running Smaug FUSS by the way.
10 Oct, 2007, David Haley wrote in the 4th comment:
Votes: 0
Chances are that your client is sending just \n, which will indeed go to a new line, but not to the beginning of the line. \n is however the convention used on Unix systems to mean "end of line, go to beginning of line" in text files. That is why your text editor shows the file correctly.

Try adjusting your client to send \n\r, if you can. This issue comes up occasionally on Nick Gammon's forums, so you can try searching there for more information.
10 Oct, 2007, jjack wrote in the 5th comment:
Votes: 0
Strange, I was telnetting in with both windows telnet (from school) and PuTTY (home) and it does the same thing, but I'll look it up. I searched on Nick Gammon's forums and didn't find anything but it's kind of an awkward thing to search for so I'm not surprised…I'll give that a try, thanks.
10 Oct, 2007, David Haley wrote in the 6th comment:
Votes: 0
I think this is a "known issue" of sorts with telnet. This thread discusses the issue. It took us a while to figure out what was going on; it seems that partway through page 2 is where it becomes relevant to you.

Basically the same issue was coming up, except that it wasn't a display issue, it was confusing the mudprog system.
11 Oct, 2007, Tyche wrote in the 7th comment:
Votes: 0
DavidHaley said:
Chances are that your client is sending just \n, which will indeed go to a new line, but not to the beginning of the line. \n is however the convention used on Unix systems to mean "end of line, go to beginning of line" in text files. That is why your text editor shows the file correctly.

Try adjusting your client to send \n\r, if you can. This issue comes up occasionally on Nick Gammon's forums, so you can try searching there for more information.


Both PuTTY and Windows Telnet send \r\n by default. The problem is the mud is not sending the correct newline Telnet sequence back, which is \r\n. It is sending instead \n\r, or in this case just maybe just dumping the entire description with only \n's in the stream. If you send \n\r from the mud the \n will be treated as a linefeed, and the \r will be ignored because it isn't followed by the required \0. If you just send a string with \n's then the client will only do linefeeds. The solution for it to work properly on all Telnet clients is to fix the mud so it sends \r\n at EVERY place a newline is desired in the output.
11 Oct, 2007, Zeno wrote in the 8th comment:
Votes: 0
Are you using stock SmaugFUSS?
11 Oct, 2007, Kjwah wrote in the 9th comment:
Votes: 0
jjack said:
Strange, I was telnetting in with both windows telnet (from school) and PuTTY (home) and it does the same thing, but I'll look it up. I searched on Nick Gammon's forums and didn't find anything but it's kind of an awkward thing to search for so I'm not surprised…I'll give that a try, thanks.


In PuTTY you need to check off the "Implicit CR in every LF" box in the configuration menu. For telnet.. No clue, I can hardly work windows anymore.. it's too much of a piece of shit. lol

Zeno said:
Are you using stock SmaugFUSS?


I think it's more of a problem with most Merc based MUDs.. I've seen formating happen like this on a lot of different stock MUDs…….(Not saying that the editor isn't also at fault. Though, I've seen these formating problems on more than one stock MUD when using PuTTY or some other not really such a MUD client terminal program).
11 Oct, 2007, Conner wrote in the 10th comment:
Votes: 0
Tyche said:
Both PuTTY and Windows Telnet send \r\n by default. The problem is the mud is not sending the correct newline Telnet sequence back, which is \r\n. It is sending instead \n\r, or in this case just maybe just dumping the entire description with only \n's in the stream. If you send \n\r from the mud the \n will be treated as a linefeed, and the \r will be ignored because it isn't followed by the required \0. If you just send a string with \n's then the client will only do linefeeds. The solution for it to work properly on all Telnet clients is to fix the mud so it sends \r\n at EVERY place a newline is desired in the output.


This was fixed in SmaugFUSS quite awhile back.
11 Oct, 2007, jjack wrote in the 11th comment:
Votes: 0
Yeah I'm using (mostly) stock SmaugFUSS. I solved the problem by downloading AL Client to work in. It's just kind of a pain because I like to build from school when I'm between classes, so I'm stuck on windows Telnet. (Unless I could put a small client on my thumb drive).

Also I was under the impression that the "Solution" of sending the \n\r was REMOVED from SmaugFUSS because it caused more problems that it created.
11 Oct, 2007, Tyche wrote in the 12th comment:
Votes: 0
This is fread_string() from SmaugFUSS 1.7

case '\n':
plast++;
ln++;
*plast++ = '\r';
ln++;
break;


See how it converts the \n's in the strings to \n\r?
Apparently it's still broken.

Should be…
case '\n':
*plast++ = '\r';
ln++;
*plast++ = '\n';
ln++;
break;


One might want to also review the buffer edit code to make sure it handles \r\n
0.0/12