27 Jul, 2011, triskaledia wrote in the 1st comment:
Votes: 0
Wanted to simplify Xrakisis' display for the Consecrate menu into one line - I went with a strcat. However, it displays the info properly once, then because buf2&buf3 doesn't get cleared, it copies itself multiple times - depending on how many times you type consecrate ITEM.
if (!IS_WEAPON_STAT (obj, WEAPON_POISON))
strcat(buf3, "Poison:5 ");
if (!IS_WEAPON_STAT (obj, WEAPON_VAMPIRIC))
strcat(buf3, "Vampiric:5 ");
if (!IS_WEAPON_STAT (obj, WEAPON_FLAMING))
strcat(buf3, "Flaming:5 \n\r");
if (!IS_WEAPON_STAT (obj, WEAPON_FROST))
strcat(buf3, "Frost:5 ");
if (!IS_WEAPON_STAT (obj, WEAPON_SHOCKING))
strcat(buf3, "Shocking:5 ");
if (!IS_WEAPON_STAT (obj, WEAPON_SHARP))
strcat(buf3, "Sharp:5 ");
stc(buf3, ch);
buf3 = '\0'; <— I found this on another website when I searched how to clear strcat, but it errors out. Also tried setting it to NULL.

and this is what happened after viewing the item via consecrate twice:
Poisoned Vampiric Flaming Frosted Electric Sharp Poisoned Vampiric Flaming Frosted Electric Sharp
[**********[Consecrate Menu]**********].
It gets uglier the more you go…
Any help as to how to clear my variable would be nice.
27 Jul, 2011, Rarva.Riendf wrote in the 2nd comment:
Votes: 0
buf3[0] = '\0' to put your variable to empty string at the beginning of your method.
27 Jul, 2011, quixadhal wrote in the 3rd comment:
Votes: 0
Also, just to be nitpicky, "\n\r" is backwards. I know, you don't believe it because everyone does that, but it really is.
27 Jul, 2011, Twisol wrote in the 4th comment:
Votes: 0
It really is. :sad:
27 Jul, 2011, Runter wrote in the 5th comment:
Votes: 0
These guys don't know what they're talking about. What you really want is <br>. You just don't know it yet.
27 Jul, 2011, Vigud wrote in the 6th comment:
Votes: 0
quixadhal said:
Also, just to be nitpicky, "\n\r" is backwards. I know, you don't believe it because everyone does that, but it really is.
Could you please provide reasoning?
27 Jul, 2011, Kaz wrote in the 7th comment:
Votes: 0
Vigud said:
quixadhal said:
Also, just to be nitpicky, "\n\r" is backwards. I know, you don't believe it because everyone does that, but it really is.
Could you please provide reasoning?


Because The Telnet Protocol Specification says so. ;)
27 Jul, 2011, Vigud wrote in the 8th comment:
Votes: 0
That's the answer I was expecting to get. I still hope to hear a real reason for following the Telnet standard, though.
27 Jul, 2011, David Haley wrote in the 9th comment:
Votes: 0
I agree with Vigud – why should we bother following standards? It's such a pain, frankly.
27 Jul, 2011, Vigud wrote in the 10th comment:
Votes: 0
Why should you twist my words? It's so counter-productive.
27 Jul, 2011, Runter wrote in the 11th comment:
Votes: 0
I think most clients support \r\n. At least, I haven't found one that didn't. I have found clients that didn't support other configurations correctly. If all clients supported something else I'd be more included to go that route.
27 Jul, 2011, Rarva.Riendf wrote in the 12th comment:
Votes: 0
And the real question …wtf everyone use \n\r then ? when a simple search/replace could 'fix' most of the code ?
27 Jul, 2011, David Haley wrote in the 13th comment:
Votes: 0
What words did I twist? You just said you see no real reason to follow the standard. Either you're asking useless rhetorical questions and already know a reason, or you see no reason.

And yes, clients do tend to support the wrong one simply because so many MUDs make the mistake. That's no reason to perpetuate the mistake further.

Of course this isn't a big issue, it might not be worth eradicating every last instance of it, but there's no sense making the same mistake in new code.
27 Jul, 2011, Vigud wrote in the 14th comment:
Votes: 0
I've never said we shouldn't follow standards in general, and that's what you said ("why should we bother following standards"). My concern is, should we follow the technical standard, or the de facto standard, which is accepting both LF CR and CR LF? And why?
27 Jul, 2011, Runter wrote in the 15th comment:
Votes: 0
I prefer following the robustness principle.

http://en.wikipedia.org/wiki/Robustness_...

Quote
Be conservative in what you send; be liberal in what you accept.


I believe Tyche has said as much in the past as well. If I recall.
27 Jul, 2011, David Haley wrote in the 16th comment:
Votes: 0
Yes. You should always follow the standard when generating data. You should deal with other people's screw-ups when you have to. But don't add to the pile of screw-ups.
27 Jul, 2011, Vigud wrote in the 17th comment:
Votes: 0
The main reason to follow the Robustness Principle is to improve interoperability. But how do I know that fixing this issue in my MUD, in the name of the Robustness Principle, wouldn't actually harm the interoperability?

Besides, it's nothing new that non-standard but popular practices become part of the technical standard. C accepted // comments and other stuff like that. I'm afraid nobody would be willing to "update" the Telnet Protocol standard to accept both CR LF and LF CR, but shouldn't we, the MUD community, do this in this case?
27 Jul, 2011, Runter wrote in the 18th comment:
Votes: 0
Vigud said:
The main reason to follow the Robustness Principle is to improve interoperability. But how do I know that fixing this issue in my MUD, in the name of the Robustness Principle, wouldn't actually harm the interoperability?

Besides, it's nothing new that non-standard but popular practices become part of the technical standard. C accepted // comments and other stuff like that. I'm afraid nobody would be willing to "update" the Telnet Protocol standard to accept both CR LF and LF CR, but shouldn't we, the MUD community, do this in this case?


In other words you don't believe that the robustness principle applies because there's enough robust clients out there to accept whatever trash your server sends to them. Sounds like you're taking advantage of the fact that other people follow it.
27 Jul, 2011, David Haley wrote in the 19th comment:
Votes: 0
Vigud said:
I'm afraid nobody would be willing to "update" the Telnet Protocol standard to accept both CR LF and LF CR, but shouldn't we, the MUD community, do this in this case?

No.
27 Jul, 2011, Twisol wrote in the 20th comment:
Votes: 0
Ohhh wow. Nothing on MudBytes has ever made me laugh this hard. :lol:

The reason Telnet settled on "\r\n" as the standard end-of-line indicator is that in the past, actual terminals connected to systems using the protocol, and it was primarily designed with that in mind. This is why we have all of the other IAC commands like AYT and EC - they're directives to the terminal displaying the data. "\r\n" is treated similarly, as a single command whose meaning is "line break".

RFC 854 said:
The sequence "CR LF", as defined, will cause the NVT to be
positioned at the left margin of the next print line (as would,
for example, the sequence "LF CR"). However, many systems and
terminals do not treat CR and LF independently, and will have to
go to some effort to simulate their effect. (For example, some
terminals do not have a CR independent of the LF, but on such
terminals it may be possible to simulate a CR by backspacing.)


By joining CR LF as a single printer command, it avoids these problems and allows newline to be implemented in a cross-platform manner. Today we don't have that problem - in fact, it seems that CR is ignored everywhere it matters, and LF is treated as the de facto line delimiter. I'm fine with either CR LF or just LF, but LF CR only makes sense if you expect the commands to be interpreted "by the book". That is to say, if a client sees CR it must move to the left margin, and LF must cause it to go down a row. Sticking to CR LF means maximum interoperability, and it's easier to deal with line-based data if the delimiter is consistent.
0.0/101