Proposal : File to string vs. Long string

From: Tony Robbins [Kupek] (tonyr@NWPACLINK.COM)
Date: 09/04/98

I got to thinking about some of the little weird things in CircleMUD
(there are a couple things), and started to wonder.  If MOTD is read from
a file, IMOTD is read from a file, credits, and most other "long strings",
why does constants.c contain char *GREETINGS and char *MENU?  The obvious
answer is these would look awkward when loaded from disk with

      Welcome to SphereMUD
  A new dimension of CircleMUD.

By what name do you wish to be known?
<login sequence>

The main logic behind my look for a change is that both the main screen
and the menu are generally changed semi-frequently (which is why the
others can be reloaded from disk while the MUD is running, etc).  The main
detriment that I can see is a CRLF (or LF as appropriate) on the end.
This looks kind of odd at the menu, but at the main screen, it's

1.  Helps to prevent autologon trigger (e.g., zMUD checks for the last
line of text before what it guesses are a name and password to trigger its
logon event).
2.  It looks kinda purdy.
3.  TEDIT is become fairly to extremely common in new MUDs, because it
allows modification of certain files.  This change would make an expansion
to TEDIT simpler, because it makes the startup and menu similar to the

The main detriment would be the CRLF/LF on the end of the string.  Of
course, the last string could be appended at the time of sending to the
user, as to prevent both the line feed and a distracted implementor from
never telling their users to type their names.
And if you're particularly finicky, I suppose you could call an extra
couple of function calls a detriment.

I did this in my MUD, and I don't see why it shouldn't be somewhat
standardized.  Maybe even TEDIT for inclusion (why not?  aliases and
autoeq are going in, TEDIT is just as tried and true) in the stock

These are just my thoughts, anybody else?


     | Ensure that you have read the CircleMUD Mailing List FAQ:  |
     | |

This archive was generated by hypermail 2b30 : 12/15/00 PST