28 Jul, 2011, Rarva.Riendf wrote in the 41st 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.

When you have a fight with lot of texts, in group fighting as an example you still prefer trigger to highlight some stuff the mud does not per default as it cannot decide for you what do you want to highlight.
(by highlight I mean put a specific color on the result of a specific spell in the middle of 15 people attacking physically as an example (meaning like 20 lines of physical attacks at once)
28 Jul, 2011, Runter wrote in the 42nd 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.


It won't stop people from using triggers, it'll stop newbies from being able to use triggers and the real offenders will lawl at the fact you're giving them an even wider edge over the newbies.
28 Jul, 2011, Vigud wrote in the 43rd comment:
Votes: 0
triskaledia said:
Why should we \r\n besides its telnet friendly?
Because the standard says we should use the standard. If you question the necessity of using the standard, please refer to the standard. That's at least what I understand from what Twisol says.
28 Jul, 2011, Runter wrote in the 44th comment:
Votes: 0
Vigud said:
triskaledia said:
Why should we \r\n besides its telnet friendly?
Because the standard says we should use the standard. If you question the necessity of using the standard, please refer to the standard. That's at least what I understand from what Twisol says.


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

I guess your interoperability argument has been shot down. What else do you got? Just punt and say it's too much work to write the one liner to switch all the \n\r to \r\n.
28 Jul, 2011, Rarva.Riendf wrote in the 45th comment:
Votes: 0
Quote
Just punt and say it's too much work to write the one liner to switch all the \n\r to \r\n.

Actually a little more (as the problem is all areas/mobprogs desc are saved this way also and even reverted back to this way in fread_string…) :p
28 Jul, 2011, Vigud wrote in the 46th comment:
Votes: 0
That's how it looks to me, Runter: I ask why should we follow the Telnet protocol standard in every bit of it, and Twisol keeps telling me what the standards says about this and that. His answer is ridiculous in the context of this discussion, probably because of my poor English.

But this miscommunication, or whatever you want to call it, has nothing to do with my interoperability argument. It's either wrong or right, but that's regardless of what I say afterwards. Fixing my MUD to comply with the standard may or may not break interoperability with some clients my current or future players might use.
28 Jul, 2011, David Haley wrote in the 47th comment:
Votes: 0
Do you not see the silliness of saying that respecting the standard that clients are built to follow will break those clients' support for your game?
28 Jul, 2011, Runter wrote in the 48th comment:
Votes: 0
This isn't a question that is unknowable. There's a finite number of clients out there, and some people in this community have done the work to test which clients support what. Quix gave a great example of how \n\r may appear to work correctly, but in reality is not. Future clients are not compelled to support \n\r. They may. They may support <br> and they may support \b. But I still can't make the argument that it's unknowable and just maybe \b is going to result in more interoperability. I can't make that argument because the number of clients is, again, finite. And ultimately the question can be answered by simply looking at what clients actually support. You aren't going to find a mud client today that doesn't support \r\n correctly. You will find mud clients that do not support \n\r correctly. Maybe tomorrow that won't be the case, maybe tomorrow people will give up on the telnet specification and start using <br>. However, we're dealing with reality of today. And you're wrong about the defacto standard being \n\r. The defacto standard has been for a long time telnet specification, and the liberal nature of what clients may accept is in addition to that standard.
28 Jul, 2011, Vigud wrote in the 49th comment:
Votes: 0
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.
28 Jul, 2011, Oliver wrote in the 50th comment:
Votes: 0
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.


… what? But. Wait, what?

This is like saying that you'll let your players decide whether or not they prefer to have the word 'definitely' misspelled as 'definately.' Seriously, dude. How many repeated explanations does it take for you to comprehend the fact that using \r\n in code is a mistake and can actually break the interoperability of your MUD and some clients.

You keep going on about interoperability, but you don't seem to understand the fact that standardization is the method by which programmers achieve interoperability. You say that They Are Standards is not a reason to follow the standards, but you seem to be laboring under the impression that interoperability is a good thing also– which are two opinions that are patently silly in juxtaposition.
28 Jul, 2011, Twisol wrote in the 51st comment:
Votes: 0
Oliver said:
using \r\n in code is a mistake

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



Vigud said:
That's how it looks to me, Runter: I ask why should we follow the Telnet protocol standard in every bit of it

I explained how \n\r actually undermines the standard and causes compliant clients to do things you didn't want. I also explained how deviating from compliance causes you to trade functionality for nothing. If you want to create your own MUD protocol that's fine - I know a few of us would like that - but don't call it Telnet.

Vigud said:
Fixing my MUD to comply with the standard may or may not break interoperability with some clients my current or future players might use.

No client today handles \r\n incorrectly. That is clear if you consider that many popular MUDs send \r\n, and \r\n was here from the beginning. \n\r only works on clients with specific behavior, and breaks on clients with standard behavior under hard-to-diagnose conditions, while \r\n relies on the assertions of the protocol itself.
28 Jul, 2011, Vigud wrote in the 52nd comment:
Votes: 0
Quote
You keep going on about interoperability, but you don't seem to understand the fact that standardization is the method by which programmers achieve interoperability.
In theory. In practice, there are Zmud, Gmud, CUTCP, Tinkeri View/Savitar, Windows telnet… Yeah. If I were to make my server strictly compliant to the standard, those clients would be problematic for players at the very least. That's what I see as breaking interoperability.

I didn't understand the rest.
28 Jul, 2011, Twisol wrote in the 53rd comment:
Votes: 0
Vigud said:
If I were to make my server strictly compliant to the standard, those clients would be problematic for players at the very least. That's what I see as breaking interoperability.

Do explain. What about these clients would cause trouble with \r\n? I find it hard to believe that any client would explicitly not support either of the two common EOL delimiters, even if one is plainly wrong. That would just limit the client's audience.
28 Jul, 2011, David Haley wrote in the 54th comment:
Votes: 0
Far more effort is being spent arguing about why we should follow standards to get interoperability than it would actually take to just follow them and get interoperability. This is just a little weird.
28 Jul, 2011, Vigud wrote in the 55th comment:
Votes: 0
Twisol said:
Vigud said:
That's how it looks to me, Runter: I ask why should we follow the Telnet protocol standard in every bit of it

I explained how \n\r actually undermines the standard and causes compliant clients to do things you didn't want. I also explained how deviating from compliance causes you to trade functionality for nothing. If you want to create your own MUD protocol that's fine - I know a few of us would like that - but don't call it Telnet.
This actually sounds good to me. Quite close to what I've been trying to suggest in this topic, just with the addition of not calling the derived standard Telnet. I'd be OK with implementing pure, strict Telnet and said MUD protocol - if it were real.

Twisol said:
Vigud said:
If I were to make my server strictly compliant to the standard, those clients would be problematic for players at the very least. That's what I see as breaking interoperability.

Do explain. What about these clients would cause trouble with \r\n? I find it hard to believe that any client would explicitly not support either of the two common EOL delimiters, even if one is plainly wrong. That would just limit the client's audience.
Excuse me, I was trying to say that those clients violate the Telnet protocol standard here and there, not that they specifically send and expect to receive LF CR.
28 Jul, 2011, Twisol wrote in the 56th comment:
Votes: 0
Vigud said:
Excuse me, I was trying to say that those clients violate the Telnet protocol standard here and there, not that they specifically send and expect to receive LF CR.

Well… there really isn't anything you can do about that. It's not an excuse to behave badly yourself, though. :sad: These clients harm usability by behaving poorly; just look at how much trouble Windows Telnet causes.
28 Jul, 2011, KaVir wrote in the 57th comment:
Votes: 0
Twisol said:
I explained how \n\r actually undermines the standard and causes compliant clients to do things you didn't want. I also explained how deviating from compliance causes you to trade functionality for nothing. If you want to create your own MUD protocol that's fine - I know a few of us would like that - but don't call it Telnet.

How about calling it…Nettel!

Twisol said:
No client today handles \r\n incorrectly.

That's been my experience as well, having tested \r\n on a range of clients.

But to be fair, I didn't encounter any problems back when I was sending \n\r, either. Not that that's an acceptable excuse for doing it wrong of course, particularly when it's so easy to fix, but many people tend to leave stuff alone as long as it appears to work.

I guess you could draw parallels between this and the MXP situation. Server implementation is broken, clients don't want to exclude them so they add a workaround, servers never bother to fix their implementation because it appears to work. Along comes a more correctly implemented client, and the server developers think the client is broken, because their solution no longer works.
28 Jul, 2011, Rarva.Riendf wrote in the 58th comment:
Votes: 0
'switch ( *plast = getc(fp) )
{
default:
plast++;
break;

case EOF:
/* temp fix */
bug( "Fread_string: EOF", 0 );
return NULL;
/* exit( 1 ); */
break;

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

case '\r':
break;'

Is in fread_string in db.c (even in the cleaned g++ version). Means that you need more work than a simple search and replace unfortunately. Because all your areas saved the wrong order, and even if you fix them they will be reverted to bad order at load !
If any of you can think of an easy solution you are welcome. (by easy I mean the fewer step to fix both areas and code in the fewer possible steps)
I tried a simple string replace of \n\r by \r\n before returning the string but it broke mprogs somehow.
28 Jul, 2011, Tyche wrote in the 59th comment:
Votes: 0
Rarva.Riendf said:
Is in fread_string in db.c (even in the cleaned g++ version). Means that you need more work than a simple search and replace unfortunately. Because all your areas saved the wrong order, and even if you fix them they will be reverted to bad order at load !
If any of you can think of an easy solution you are welcome. (by easy I mean the fewer step to fix both areas and code in the fewer possible steps)
I tried a simple string replace of \n\r by \r\n before returning the string but it broke mprogs somehow.

Would you like someone to hold your hand and talk you through it?
28 Jul, 2011, Rarva.Riendf wrote in the 60th comment:
Votes: 0
Tyche said:
Rarva.Riendf said:
Is in fread_string in db.c (even in the cleaned g++ version). Means that you need more work than a simple search and replace unfortunately. Because all your areas saved the wrong order, and even if you fix them they will be reverted to bad order at load !
If any of you can think of an easy solution you are welcome. (by easy I mean the fewer step to fix both areas and code in the fewer possible steps)
I tried a simple string replace of \n\r by \r\n before returning the string but it broke mprogs somehow.

Would you like someone to hold your hand and talk you through it?

I am looking for a solution, considering a lot of people are so anal about it and obvioulsy fixed it already in all their code (some of them diku deritative probably) you probably already solved the problem. Off course I can solve the problem myself but reinventing the weel never been the point of IT…
People like to bickers more than giving actual solution….
40.0/101