Considering using AFKMUD for a pirate MUD (which are very lacking it seems). Scratching my head about a few things that were probably already answered here.

1) How do I link a normal room to the overland? I tried redit excoord etc and it doesn't seem to work.

2) Why is the helpfile system case sensitive?


3) Why is help REDIT the credits?

help REDIT
Help level: -1
/-------------------------------------------------------------------------\
| o         M A N Y    S P E C I A L    T H A N K S    T O :            o |
|           ================================================              |
|                                                                         |
| AFKMud: Samson, Dwip, Whir, Cyberfox, Karangi, Rathian, Cam, Raine,     |

4) We can't take any kind of donations, correct? What if we put ads up on the website for the MUD?

1. The excoord part is only half the battle. You also have to make sure the exit gets the Overland flag as well. redit <dir> flags overland

2. Uh. The helpfile system may be suffering from std::string silliness there which was not an issue on Alsherok because Alsherok used database helps instead. I'd have to look into that.

3. I would assume a glitch and it's offering up "CREDITS" because it botched "REDIT" into it some how. Never saw that happen before.

4. Ads on the website are beyond the scope of the license for the codebase.

Fairly certain I did add the overland flag as well. I'll have to double check.
[EDIT] Ah thanks, that worked. I was trying redit flags map

Any ideas why I get this on startup?


Using

What's the shebang line (the line with 'csh' in it)?
Are you sure that csh is an alias to tcsh on your system?

I would assume it's an alias because of this:

[zeno@vps src]$ csh --version
tcsh 6.14.00 (Astron) 2005-03-25 (i386-intel-linux) options wide,nls,dl,al,kan,rh,color,filec

As for the lines:

[zeno@vps src]$ head startup
#! /bin/csh -f

# Set the port number.
set port = 7500

[EDIT] Found solution:
http://www.gammon.com.au/forum/?id=2322&page=999

I DLed the archive using lynx from this site and extracted. Does that mean the file was packed wrong or was this an issue on my end?

Yup, I agree that it looks like it's aliased. But just to be super-sure, try: /bin/csh --version -- you might have several csh programs in your path (and /bin/csh -- the one the shebang uses -- might be the real csh, not tcsh)

The shebang line looks ok, though. Are there any other occurrences of csh in the startup file?

Is this the same question as in this thread?

Posted while I was editing.

[EDIT] The next problem I'm seeing is that telnet isn't handling newlines correctly.

[30000hp 30836m 30000mv]  [1exp] help SECTORTYPES
Help level: 103
Indoors *     - Represents a room which is sheltered from the weather.
                                                                      City
    - Room is either part of a city, or part of a roadway.
                                                          Field         - Room i
s a farm, or other grassland type area.
                                       Forest        - Room is part of a forest.

Hills         - Room is in the hills, or other rocky terrain.
                                                             Mountains     - Roo
m is in steep mountains, or other equally rugged terrain.
                                                         Water_swim    - Room is
 shallow freshwater. Freezes in winter.

MUSHclient and PuTTy are fine though. Haven't looked at code yet, but it seems like it isn't seeing newlines just the carriage returns.

Actually that is it doing new lines without doing carriage returns. If I remember right that is a problem in the mud editor. Normally saving the area/helps/etc... and hotbooting/rebooting makes it display correctly again. So can fix it or just go the hotbooting/rebooting way (which gets annoying after awhile).

Edit:
Hmm although I figure that might be a stock help file and that means the hotbooting/rebooting won't work for you there and you will have to just fix it lol.

When you say "telnet" is giving you the scrambled output, are you talking about Windows Telnet? Or something else? Windows Telnet is not compliant with the telnet standard and may well generate bogus results like that when encountering a proper \r\n sequence, instead of the \n\r it's clearly expecting. Typical Microsoft.

Yea it's probably windows telnet he is talking about. Had a builder that only used windows telnet and I eventually just fixed that problem in it so she didn't have that problem when she edited stuff.

No, Microsoft telnet does the right thing with line endings. Don't forget that \r\n is in fact the line ending that Windows uses.

EDIT: to elaborate, it's pretty clear that the output only uses \n and not \r, so the cursor isn't going back to the beginning of the line. This can happen if you talk to the MUD using a client that only uses \n to terminate lines, or if your editor code removes line endings to replace them with \n.

Debugging packets:

This displays correctly in telnet (CR):

Help level: 103.   48 65 6c 70 20 6c 65 76 65 6c 3a 20 31 30 33 0d
.                  0a

So 0d 0a for newline and carriage return?

Doesn't display correctly in telnet (no CR):

ather..City        61 74 68 65 72 2e 0a 43 69 74 79 20 20 20 20 20

Just 0a?

Sorry, not sure I see the question here? Yes, you do need the CR for it to display correctly, that's part of the telnet specification.

Sorry, wasn't really a question. Was just trying to show the packets to see if what is received is a proper sequence.

Yes, CR (0xd, or 13 decimal) LF (0xa, or 10 decimal) is the proper sequence. See e.g. this image of the ASCII character chart.

Has anyone figured out how to resolve the helpfile issue?

in editor.cpp find

string char_data::copy_buffer(  )
{
   char buf[MSL], tmp[100];
   short i, len;

   if( !pcdata->editor )
   {
      bug( "%s: null editor", __FUNCTION__ );
      return "";
   }

   buf[0] = '\0';
   for( i = 0; i < pcdata->editor->numlines; ++i )
   {
      mudstrlcpy( tmp, pcdata->editor->line[i], 100 );
      len = strlen( tmp );
      if( tmp && tmp[len - 1] == '~' )
         tmp[len - 1] = '\0';
      else
         mudstrlcat( tmp, "\n", 100 );
      smash_tilde( tmp );
      mudstrlcat( buf, tmp, MSL );
   }
   string newbuf = buf;
   return newbuf;
}

char *char_data::copy_buffer( bool hash )
{
   char buf[MSL], tmp[100];
   short i, len;

   if( !pcdata->editor )
   {
      bug( "%s: null editor", __FUNCTION__ );
      if( hash )
         return STRALLOC( "" );
      return str_dup( "" );
   }

   buf[0] = '\0';
   for( i = 0; i < pcdata->editor->numlines; ++i )
   {
      mudstrlcpy( tmp, pcdata->editor->line[i], 100 );
      len = strlen( tmp );
      if( tmp && tmp[len - 1] == '~' )
         tmp[len - 1] = '\0';
      else
         mudstrlcat( tmp, "\n", 100 );
      smash_tilde( tmp );
      mudstrlcat( buf, tmp, MSL );
   }
   if( hash )
   {
      if( buf && buf[0] != '\0' )
         return STRALLOC( buf );
      return NULL;
   }
   return str_dup( buf );
}

If you notice it is just copying "\n" onto the end of the lines on both of those just make it copy "\r\n" instead and it should be all it takes its been ages though so don't recall right off if that was all it took to fix it or not Will have to toss stuff that is added using these through strip_cr (guess thats still in AFK) when saving to disk so that it doesn't add extra unneeded lines.

Would that fix existing helpfiles or do I need to do that on every helpfile?

Anyone know how to save overland after doing a setexit?

Yea it should fix it on all the ones that have problems.