On Sat, 1 Jan 2000, Del wrote:
> Any company that produces a product, makes that product for the
> consumer. As it stands now, if CircleMUD produces an annoyance to the
> players, the coder will change his code to please the players. (Even
> if it is non-standard) How many times have all coders (including
> George) made a work-around to get things working?
And how many times have those work-arounds had negative effects or caused
problems because they pandered to buggy client software? Ignoring the
real problem is NOT the answer here -- having it fixed is what we need to
do. It might take a concerted effort, with everyone sending bug reports
in it to Zugg, the authors of Rapscallion, CRT, and other broken clients.
A workaround is one thing -- breaking compliance for the sake of someone
else's broken software is entirely another. This is the same reason you
don't see \n\r in CircleMUD at all, even though many clients worked with
it and even expected it. I'm not against catering to the needs of people
who have broken clients -- but we're already doing so much by trying to
get their clients fixed by taking our time out to appeal to the
developers, and that's my catering quota.
> Being both coder and player. If I start on a new mud and see multiple
> lines where they should not be, I would think the coder doesn't know
> what he is doing.
I wouldn't, and I don't think most anyone else would, either. More likely
is that they'd think there was some network garbage -- maybe they held
down [ENTER] too long or something. At the most, I'd think it was an
aesthetic quirk and not at all disconcerting. If you make it clear why
that occurs in the MOTD and tell them to take it up with the authors of
their clients (or, even, tell them to e-mail dkoepke@circlemud.org about
it), your problem's solved and then its up to the developers (or me). If
people are leaving in the middle of the character creation process because
of some extra lines, then your MUD failed to intrigue them to begin with.
If they get to the MOTD and see your "IMPORTANT NOTICE:" in big bold
colors about why its broken, then they'll know it's not your fault.
> My client currently works on 99.9% of the muds, and I would think it
> was the mud that is messed up vice my client.
Only because those other Muds are broken and/or not trying to do more
fancy things with the TELNET protocol. Sure, going off the paper is the
easiest thing to do here, but I will hold that it's detrimental to the
entire Mud community and future authors of Mud servers and clients. If we
change here, and we don't try to get the rest of the world fixed, then
every so often, Joe Schmoe, who has wrote a new client or server based
upon the standards will discover his stuff doesn't work as expected with
CircleMUD. And then what? We're back where we started because we chose
to hide the problem, rather than fix the problem. No, thank you, as I
said before, I won't be a part of that.
> The option for an #if seems to be the best solution until the clients
> conform to standards.
Which they won't ever if everyone chooses to hide the fact that they're
broken. Put it upfront, make it visible to everyone, make the explanation
widely available and easily understandable, and either force the
developers to fix their clients or force those clients into extinction. I
don't think anyone loses ANYTHING from having the extra lines showing in
broken clients.
> Having the old and new code in so the coders do not have to hunt down
> an older version to satisfy thier customers.
Nope. We nip it in the bud here before we compound the problem, since we
sure as hell aren't going to get the RFCs to change and break
compatability with all the properly functioning clients and programs based
upon those RFCs (which, believe it or not, far out number and outweigh our
little niche).
-dak
+------------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
| http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
+------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 04/10/01 PDT