26 Dec, 2008, Vladaar wrote in the 1st comment:
Votes: 0
Not sure who all uses oasis, but the buildwalk portion of this would
probably benefit any diku type mud.

http://6dragons.org/oasisolcaddon.txt

Vladaar
http://6dragons.org
26 Dec, 2008, Kline wrote in the 2nd comment:
Votes: 0
I added something similar in AckFUSS – really makes life easier when digging a new zone out :)
26 Dec, 2008, Sharmair wrote in the 3rd comment:
Votes: 0
a couple times the snippet said:
… \r\n\n\r"

This was kinda funny. I know there has been quite a few threads on line ends,
and I can understand having some one way and others another if you have more
then one coder (and some don't know the proper way) or you are using one way
with new code but not changing old. But I am not sure I have ever seen both
ways used like this (I guess the coder was confused and thought he would cover
all the bases) - for the record, the proper line end for text sent to players is \r\n.
27 Dec, 2008, Hades_Kane wrote in the 4th comment:
Votes: 0
Sharmair said:
for the record, the proper line end for text sent to players is \r\n.


Wow, then a TON of stock ROM has it wrong…
27 Dec, 2008, Igabod wrote in the 5th comment:
Votes: 0
I myself was under the impression that it was \n\r because of the way I've seen in stock rom and godwars codes. Are you absolutely sure about that sharmair?
27 Dec, 2008, David Haley wrote in the 6th comment:
Votes: 0
Yes, Sharmair is correct. And yes, tons of code is, strictly speaking, wrong. (Not just on MUDs, by the way.) The proper sequence is CR LF (carriage return, line feed). The carriage return returns the carriage to the beginning of the line and the line feed feeds a new line to the printer. (Think typewriters…)
27 Dec, 2008, Tricky wrote in the 7th comment:
Votes: 0
CR LF is the sequence. CR (Carriage Return) being \r and LF (Line Feed) being \n. However these characters are not a 'C' standard as referenced in this wiki article.

Tricky
27 Dec, 2008, David Haley wrote in the 8th comment:
Votes: 0
However, the article also notes that when in binary mode, no translation is performed. Sockets are opened in binary mode, and I imagine that the vast majority of implementations that a MUD developer would see translate \r and \n to the ANSI values, so I think that for all intents and purposes, it's a standard as far as MUD devs should be concerned. (Regardless, it's a telnet standard, so MUD devs should respect it one way or the other…)
27 Dec, 2008, Lobotomy wrote in the 9th comment:
Votes: 0
DavidHaley said:
Yes, Sharmair is correct. And yes, tons of code is, strictly speaking, wrong. (Not just on MUDs, by the way.) The proper sequence is CR LF (carriage return, line feed). The carriage return returns the carriage to the beginning of the line and the line feed feeds a new line to the printer. (Think typewriters…)

While it may be considered the "proper" way by some, I'd be more interested to know if there's any actual tangible differences in the use of either. It's been my experience that text is correctly displayed with both orders of "\r\n" and "\n\r", so if there are some kind of error(s) or othersuch being caused by using "\n\r" instead of "\r\n" I'd like to hear it. Otherwise, I think you guys may be acting needlessly pedantic on the matter.
27 Dec, 2008, Kayle wrote in the 10th comment:
Votes: 0
\r\n is the telnet standard.. isn't that reason enough?
27 Dec, 2008, David Haley wrote in the 11th comment:
Votes: 0
It makes it hard/annoying to figure out line endings on the client side. When people don't follow standards, everybody has to play guessing games when they see strange line endings come in.

Of course, it's such a common mistake that most people have workarounds built into the client for this. But while people should gracefully handle bad input, it's very bad form to actually generate bad output.

Being lax about standards is the first step toward not having useful standards at all…
27 Dec, 2008, Tyche wrote in the 12th comment:
Votes: 0
Aye…
Be conservative in what you send, liberal in what you accept.

Which means for a Telnet client or server…

Send \013\010
Accept \013\010 or \010\013 or \010 or \013\000
27 Dec, 2008, The_Fury wrote in the 13th comment:
Votes: 0
One small thing that i would change is this, it really dont make a lot of difference, but it does make for more compact code.

if ( !IS_NPC( ch ) )
{
if ( IS_IMMORTAL( ch ) && IS_SET( ch->pcdata->flags, PCFLAG_BUILDWALK ) )
{
do_build_walk( ch, "north" );
return;
}

if ( !IS_SET( ch->pcdata->flags, PCFLAG_BUILDWALK ) )
{
move_char( ch, get_exit( ch->in_room, DIR_NORTH ), 0 );
return;
}
}
if ( IS_NPC( ch ) )
{
move_char( ch, get_exit( ch->in_room, DIR_NORTH ), 0 );
return;
}


I would make like this:

void do_north ( CHAR_DATA * ch, char *argument )
{
if ( IS_IMMORTAL( ch ) && IS_SET( ch->pcdata->flags, PCFLAG_BUILDWALK ) )
{
do_build_walk( ch, "north" );
return;
}
else
{
move_char ( ch, get_exit ( ch->in_room, DIR_NORTH ), 0, DIR_NORTH );
return;
}
}



Everything else that is not immortal and is not flagged build walk is going to want to move in the requied direction, so there is no need to if check around the other options. Other than that, it looks nice, i have not installed it yet, but i will let you know when i do.

Thanks for sharing Vladaar.
27 Dec, 2008, Lobotomy wrote in the 14th comment:
Votes: 0
Kayle said:
\r\n is the telnet standard.. isn't that reason enough?

Yes and no. Following official standards is all well and good, but if all clients are providing support for "\n\r" then it becomes a de facto standard reducing the differences between "\r\n" and "\n\r" to a matter of preference. That's all I wanted to know.
27 Dec, 2008, David Haley wrote in the 15th comment:
Votes: 0
No, it is not at all a matter of preference. What you are advocating is the same unacceptable reasoning that brought about the complete mess there is with Javascript. Just because some people provide workarounds for broken implementations does not make it acceptable to perpetuate those broken implementations. In fact, it is all the more unacceptable to perpetuate such a terrifically easy thing to fix when the problem is brought to light.

\n\r is simply wrong – it would be debatable to use just \n on its own because that is at least "a standard", but doing something completely bogus like "\n\r" is not defensible as anything at all, certainly not personal preference.

Sorry if I sound aggressive here. It is just that there is no point whatsoever in having standards if people choose willy-nilly to ignore them due to other people's crappy code!
27 Dec, 2008, Guest wrote in the 16th comment:
Votes: 0
Hades_Kane said:
Sharmair said:
for the record, the proper line end for text sent to players is \r\n.


Wow, then a TON of stock ROM has it wrong…


Stock Smaug had this wrong as well. It's something that was fixed at some point with SmaugFUSS and AFKMud awhile back. I recall even having mentioned it in several places. Perhaps something for the RAM guys to take note of :)
27 Dec, 2008, Lobotomy wrote in the 17th comment:
Votes: 0
DavidHaley said:
No, it is not at all a matter of preference. What you are advocating is the same unacceptable reasoning that brought about the complete mess there is with Javascript. Just because some people provide workarounds for broken implementations does not make it acceptable to perpetuate those broken implementations. In fact, it is all the more unacceptable to perpetuate such a terrifically easy thing to fix when the problem is brought to light.

\n\r is simply wrong – it would be debatable to use just \n on its own because that is at least "a standard", but doing something completely bogus like "\n\r" is not defensible as anything at all, certainly not personal preference.

Sorry if I sound aggressive here. It is just that there is no point whatsoever in having standards if people choose willy-nilly to ignore them due to other people's crappy code!

It seems you're not as pragmatic as I had previously figured. Arguing against non-standard methods only holds weight when there is an actual negative effect of breaking said standard (the ire of pedants doesn't count). If a particular bit of code is broken in terms of the standard, but all clients provide support that renders the result of the code equal to its standardized counterpart, then that code in fact ceases to be broken. The only way to argue to the contrary is to provide instances or cases of where the non-standard code causes problems. Name a client that doesn't support it. Describe some case or othersuch where output will get screwy in one that does. Just give me something to go on other than mere fussing over what is standard de jure versus what is standard de facto.
27 Dec, 2008, Omega wrote in the 18th comment:
Votes: 0
becareful what you wish for Lobotomy.. He may just write a client ;)
27 Dec, 2008, Lobotomy wrote in the 19th comment:
Votes: 0
Darien said:
becareful what you wish for Lobotomy.. He may just write a client ;)

Why should that bother me?
27 Dec, 2008, Omega wrote in the 20th comment:
Votes: 0
sheesh, couldn't sense the sarcasm with the ;)…….

Its what is called a joke, funny comment, a haha.. No need to be commander serious all the time.
0.0/45