28 Jul, 2011, Tonitrus wrote in the 61st comment:
Votes: 0
If you need a reason to follow standards, consider web browsers.

If, after thinking about that for a while, you can't think of a reason to follow the standard, you may as well just give up on standards altogether and be satisfied at having earned my abject bewilderment.
28 Jul, 2011, Twisol wrote in the 62nd comment:
Votes: 0
It should be noted that web browsers experiment on their own, then standardize the results as adoption increases. It's impressively effective, and it focuses on practical benefit before theoretical concern.
28 Jul, 2011, Oliver wrote in the 63rd comment:
Votes: 0
Twisol said:
Oliver said:
using \r\n in code is a mistake

I think you meant \n\r. :wink:


Ah, yes. Good catch.

I've been writing code correctly for too long, and wrote it correctly out of habit. Correctly. Good habits break hard. Correctly.

Edit: correctly.
28 Jul, 2011, Vigud wrote in the 64th comment:
Votes: 0
Oliver said:
Vigud said:
I have an idea. I'll let players choose between \n\r and \r\n. That will solve at least two problems: my MUD will be standard-compliant, and you won't have to answer my useless crap/trolling/whatever you think I'm trying to achieve in this topic.
This is like saying that you'll let your players decide whether or not they prefer to have the word 'definitely' misspelled as 'definately.'
It's more like allowing people who use readers to choose if they prefer to hear "Ben" or "bean" when the text reads "been".
28 Jul, 2011, Runter wrote in the 65th comment:
Votes: 0
Re Rarva

I'd bet most diku derivs haven't fixed it, and none of the folks speaking up in this thread so far (That I know of) work in diku derivs.

As for that block of code you posted, you just need to rearrange the \n and the \r there *after* running a script with the mud turned off that changes them in the area files.

So I guess instead of
case '\n':
plast++;
*plast++ = '\r';
break;


You could do

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


and

case '\n':
break;'
28 Jul, 2011, Twisol wrote in the 66th comment:
Votes: 0
No. It's more like allowing people to have their choice of a period or a semicolon at the end of a sentence.
28 Jul, 2011, Twisol wrote in the 67th comment:
Votes: 0
Retnur: Personally I would keep the operation in the case '\n', but instead do "if (*(plast-1) != '\r') { *plast++ = '\r'; *plast++ = '\n'; }" Keeps a parallel with the original as it doesn't affect lone \r's. You do have to make sure plast[-1] is valid though - you don't want to go off the start of the buffer.
28 Jul, 2011, Runter wrote in the 68th comment:
Votes: 0
Twisol said:
Retnur: Personally I would keep the operation in the case '\n', but instead do *plast++ = '\r'; *plast++ = '\n'; Keeps a parallel with the original as it doesn't affect lone \r's.


Well, it's just the routine for reading the help files files (i think).
Honestly, I don't know what nasty stuff is going on in diku. Why it isn't just stored in a terminated string is beyond me. Why is it having to process it line by line?
28 Jul, 2011, Twisol wrote in the 69th comment:
Votes: 0
Good question. I just wanted close parity to the original. :P
28 Jul, 2011, Rarva.Riendf wrote in the 70th comment:
Votes: 0
Runter said:
Re Rarva

I'd bet most diku derivs haven't fixed it, and none of the folks speaking up in this thread so far (That I know of) work in diku derivs.

As for that block of code you posted, you just need to rearrange the \n and the \r there *after* running a script with the mud turned off that changes them in the area files.

So I guess instead of
case '\n':
plast++;
*plast++ = '\r';
break;


You could do

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


and

case '\n':
break;'

Yep that fix the code. But you can only do that after you fix the areas. It is what I did first, fixing code and see what happens. Unfortunately it breaks some stuff while loading areas that are saved using the wrong order. So you have to load them first, fix them then modify code to read them correctly. I thought that modifying it in fread_string could do it but there must be a little more than that. Guess in fact no one did it. Another 'dont use ROM if you can avoid it' argument.
Dunno if it worth fixing it as it means you probably break every area you will import from other dikus. Oh well….I will at least fix the messages.
28 Jul, 2011, Runter wrote in the 71st comment:
Votes: 0
You can fix it just by reading the whole string until the delimiter and not doing any funky transformations on it… :P
Then it doesn't matter what is in the string, it'll read it how it was written in the first place. (old format or new)


I think I remember diku delimiting its fields with like ~ or something weird. I'd just read all the way up to hte delimiter, store it in a string, and if I need to modify it do it all at once after the string is loaded.
28 Jul, 2011, Rarva.Riendf wrote in the 72nd comment:
Votes: 0
Yeah Dikus way of parsing/save files is horrible…If i look in the files with an editor I have text with one blank line for every line of text…so 3 blank lines anytime there is one actually shown in game.
It works 'fine' once loaded…( I suspect the \n\nr is the problem because oh miracle, once code is fixed those blank lines suddenly appear….)

And yeah tilde is the used chararcter to end a multiple line string.
29 Jul, 2011, Tyche wrote in the 73rd comment:
Votes: 0
Runter said:
Re Rarva
I'd bet most diku derivs haven't fixed it, and none of the folks speaking up in this thread so far (That I know of) work in diku derivs.

As for that block of code you posted, you just need to rearrange the \n and the \r there *after* running a script with the mud turned off that changes them in the area files.

So I guess instead of


That's very good.
Except you've let go of his hand too soon, because you haven't fixed his mobprog problem yet.
Notice any pattern yet.
29 Jul, 2011, Tyche wrote in the 74th comment:
Votes: 0
Rarva.Riendf said:
Yeah Dikus way of ……… is horrible…


Hehe. It came before I even finished editing my post.
29 Jul, 2011, quixadhal wrote in the 75th comment:
Votes: 0
triskaledia said:
Don't care about triggers. Triggers I believe deplete game play experience. You should learn to expect what is coming and time it yourself, not rely on a program to do your work for you.


Well then, if you believe so strongly that YOUR way is the only way anyone should care about, why don't you code yourself a custom client and REQUIRE that your players use it? Problem solved. Your "standard" is whatever you say it is, and nobody can do anything you don't want them to do, since without your custom client, they can't connect.

On the other hand, if you are NOT willing to go down that path, and do actually intend to be part of the TELNET MUD community, why do you insist on making *EXTRA* work for all the client authors out there, who have to jury rig blocks of code to check for YOUR lazy broken-ass crap code that refuses to follow a clear and definitive standard that is older than many of your players? Do you hate everyone else that much?

I have no issues with folks running "stock" codebases that do it wrong, because they simply don't realize they're doing it wrong. But when someone is told it's wrong, told the right way to do it, and the fix is stupidly simple… and they STILL argue that there's no point to changing it. *sigh* Why do you even bother? Surely logging into your own game is too much effort for you.
29 Jul, 2011, Tyche wrote in the 76th comment:
Votes: 0
Rarva.Riendf said:
Another 'dont use ROM if you can avoid it' argument.

Ahh… more sage advice from someone who cannot even code in the language ROM was written in.
29 Jul, 2011, kiasyn wrote in the 77th comment:
Votes: 0
quixadhal said:
On the other hand, if you are NOT willing to go down that path, and do actually intend to be part of the TELNET MUD community, why do you insist on making *EXTRA* work for all the client authors out there, who have to jury rig blocks of code to check for YOUR lazy broken-ass crap code that refuses to follow a clear and definitive standard that is older than many of your players? Do you hate everyone else that much?

I think this is going in my signature.
29 Jul, 2011, triskaledia wrote in the 78th comment:
Votes: 0
quixadhal said:
triskaledia said:
Don't care about triggers. Triggers I believe deplete game play experience. You should learn to expect what is coming and time it yourself, not rely on a program to do your work for you.


Well then, if you believe so strongly that YOUR way is the only way anyone should care about, why don't you code yourself a custom client and REQUIRE that your players use it? Problem solved. Your "standard" is whatever you say it is, and nobody can do anything you don't want them to do, since without your custom client, they can't connect.

On the other hand, if you are NOT willing to go down that path, and do actually intend to be part of the TELNET MUD community, why do you insist on making *EXTRA* work for all the client authors out there, who have to jury rig blocks of code to check for YOUR lazy broken-ass crap code that refuses to follow a clear and definitive standard that is older than many of your players? Do you hate everyone else that much?

I have no issues with folks running "stock" codebases that do it wrong, because they simply don't realize they're doing it wrong. But when someone is told it's wrong, told the right way to do it, and the fix is stupidly simple… and they STILL argue that there's no point to changing it. *sigh* Why do you even bother? Surely logging into your own game is too much effort for you.
29 Jul, 2011, Rarva.Riendf wrote in the 79th comment:
Votes: 0
Tyche said:
Rarva.Riendf said:
Another 'dont use ROM if you can avoid it' argument.

Ahh… more sage advice from someone who cannot even code in the language ROM was written in.

Ah more sarcasm from someone who does not code a ROM one anymore but think 'a simple stupid fix' cannot break anything anywhere….
If IT was as simple, why are software so ridden with bugs, even written by people way smarter than I or you are…
29 Jul, 2011, triskaledia wrote in the 80th comment:
Votes: 0
quixadhal said:
triskaledia said:
Don't care about triggers. Triggers I believe deplete game play experience. You should learn to expect what is coming and time it yourself, not rely on a program to do your work for you.


Well then, if you believe so strongly that YOUR way is the only way anyone should care about, why don't you code yourself a custom client and REQUIRE that your players use it? Problem solved. Your "standard" is whatever you say it is, and nobody can do anything you don't want them to do, since without your custom client, they can't connect.

On the other hand, if you are NOT willing to go down that path, and do actually intend to be part of the TELNET MUD community, why do you insist on making *EXTRA* work for all the client authors out there, who have to jury rig blocks of code to check for YOUR lazy broken-ass crap code that refuses to follow a clear and definitive standard that is older than many of your players? Do you hate everyone else that much?

I have no issues with folks running "stock" codebases that do it wrong, because they simply don't realize they're doing it wrong. But when someone is told it's wrong, told the right way to do it, and the fix is stupidly simple… and they STILL argue that there's no point to changing it. *sigh* Why do you even bother? Surely logging into your own game is too much effort for you.



…Sorry for double…
I believe you got the wrong impression as to what I was saying about triggers. I realize people DO and people WILL use them no matter what. I can also recall a time when I ran triggers to do stuff around MUD's that I played on, but found in time that the MUD's were becoming less entertaining because I had a program running stuff for me. The main issue I have with people running triggers is when they begin to BOT.
Also, my coding experience is limited or I would have never asked how to clear a strcat to begin with - so building my own MUD client is out of question.
I'm also not going to create *EXTRA* work for myself to rewrite/replace what the previous coders had screwed up either in their ingenious or ignorant intentions.
I am strictly asking why, I am not arguing that I am not going to change how my code is written from here out.
60.0/101