arthmoor / afkmud

AFKMud is an advanced C++ derivative of the Smaug MUD codebase. Over the years it has grown to become one of the most advanced MERC derivatives in existence. There are several major enhancements to gameplay as well as administrative functions which set it apart.

AFKMud: Alsherok Game Code Release - Version 2.0: January 2007

Space. The final frontier.... no wait. That was someone else's 5 year mission.

Sine our initial public release back in 2002, we've spent five long years developing this codebase into what you see today. Sure, it's not the prettiest code out there. But it does work, and we'd like to think it's better than most. The last 2-3 years were devoted to a C++ conversion which never seemed to get close to "finished". There was always something new to try. Something old to convert. Then there just wasn't enough time. We'd still like to think we did good though. Pushed things past expectations. Did things nobody else has. Hopefully we've left you with a nice, clean, stable, and reliable foundation for you to build your world upon.

This document should help explain some of the mundane details such as how much memory it eats. How much drive space does it need. What features can be compiled out during initial setup.

Either way, have fun. Enjoy yourself and the new world you're about to create.

--- Samson, Implementor of Alsherok. Home site for the AFKMud codebase.

Homepage: https://smaugmuds.afkmods.com/

Licensing

See the file 'license.txt' in your afkmud/doc directory. Read, obey. Downloading and installing this code implies your agreement to the terms.

Installation Notes

There are some things that you need to be aware of prior to installing the game. Please read this stuff BEFORE you try and run the game. You'll avoid alot of hassle, and we'll be asking if you checked this stuff anyway.

Release Frequency

Codebase releases will not be following any kind of set schedule. This is usually done on the fly based on the number of bug reports received between releases. If there are a lot of them, then it could be a relatively short period. If there are none, then it will depend on how confident we feel about new features which might be added. If you absolutely cannot wait, there's always the Subversion repository linked from the main nav menu.

Documentation

Documentation on various features of AFKMud can be found in the areadocs directory. For information on area construction, see Area.txt. Adding races and classes are covered by Addrace.txt and Addclass.txt respectively. Overland editing is covered by Newcontinent.txt and RGB.txt.

We know the existing documentation is sparse. Hopefully it won't stay that way forever, but it's been given very low priority. User submitted docs are always welcome though.

Older SMAUG and Merc documentation can be found in the /doc directory. Most of these older docs have been superseded by newer AFK docs, but there may still be useful elements in them. One that you should most likely read anyway is hacker.txt - it offers some basic thoughts on how to be a mud admin.

If anything seems lacking or there is a feature you want to know about that isn't documented here, please let us know.

Cygwin Support

Cygwin support is largely touch and go. The C++ conversion leaves it somewhat up in the air as to whether it will decide to work properly or not. It has not been heavily tested, so don't be too surprised if after it's compiled it just refuses to behave.

SQL, Multiport, and interport channels are not available in Cygwin. It simply lacks the proper tools to handle it. You also need to make sure the NEED_DL line in the Makefile is commented out.

FreeBSD Support

There should be no real reason why AFKMud 2.0 should not work in FreeBSD. It might require some tweaking of the Makefile, and you'll need to be sure to use the gmake compiler, but aside from that the code itself should compile hassle free.

Comment out the NEED_DL define in the Makefile to compile.

OpenBSD Support

OpenBSD support has not been verified with 2.0. It was shaky at best in 1.x. If you have any luck getting it to work, let us know. If it needed special attention, let us know what changes to include and we'll try and see to it they show up in a future maintenance release.

Comment out the NEED_DL define, and the EXPORT_SYMBOLS define in the Makefile to compile.

CPU, Memory, and Hard Drive Requirements

AFKMud is on the large side due to the sheer number of features included. You will need to take this into consideration first, before ever even thinking about where to host it. Count on somewhere around 30MB in drive space usage once the code is compiled. Preliminary results for 64bit systems suggests you'll need almost twice that. Don't ask us why because we don't know. It's probably one of those weird gcc things only GNU knows about.

RAM usage should expect to hover around 30MB on a moderately sized world. This is assuming approximately 9,000 rooms and 3 1000x1000 overland maps.

CPU usage should hover at or near 0.0% during idle, and around 0.5% during moderate load. We don't have any high stress usage figures to offer, but it shouldn't cause you any grief.

First Immortal

A pfile named "Admin" is included, with password "admin". Use this to get your first immortal advanced. Then promptly delete him!

The Makefile

The Makefile has some suggestions on what to comment out if you get certain errors during your compile. If you encounter any, refer there to see if there's a fix for it. The usual 'make clean' command will do its usual thing, then proceed to recompile the code. Don't panic, this is normal. If all you want to do is remove the *.o files, use the 'make purge' option instead.

Stock Areas

First of all: No. There are no stock areas included, other than our rendition of the Astral Plane. The purpose of releasing AFKMud was not to provide people with cookie-cutter ready made worlds. It was to provide people the tools to create their own unique worlds for people to enjoy. Sure, this means we don't have 500 muds using the code, but those who do use it end up creating some great stuff with it.

Not satisfied with that? All is not lost. Though the AFKMud area file format has been significantly altered from Smaug, we included a conversion routine to allow loading of stock Smaug material. It's not perfect, but if you want your ready made stuff, you've got to work for it. This can be accomplished one of two ways:

1. Leave your areas and area.lst file alone and try to boot the mud with them as is. Your logs will look like a train wreck, but if you're lucky they'll load and you can then execute a "fold all" command once you've logged in. This would be advisable ASAP after an event of this magnitude. If any of the zones crash the mud, you'll need to take them out of the area.lst file and hold them over for method 2 below.

2. If you come across a stock zone that won't convert and you need to try it again later, or if you decide to load one you've downloaded at some point, drop it into your area directory and type "areaconvert filename.are". If it fails to load, your mud has probably crashed. Examine the logs, core dumps, etc to find out why, correct it, and try again.

This functionality allows you to load Smaug 1.02a, 1.4a, SmaugWiz, ResortMUD, CalareyMUD, Chronicles, Dark Rifts, DOTDII, and SWR areas. Other formats are considered non-standard and will not be supported.

Keep in mind that you may also need to do some fine tuning once the area is converted - subtle differences in each version may produce unpredictable stats on the areas.

Adding Commands, Skills, and spec_funs

When you find yourself wanting to add a new command to the code, either from a snippet you've downloaded and decided to use, or from something you've written yourself, if you've been working with Smaug for long you know all about the tables.c file and the places you need to insert things to make it work.

With AFKMud, you no longer need to worry about that. The code used the dlsym functionality to handle the required lookups. It isn't even necessary to have DECLARE_DO_FUN statements anywhere. Just insert, compile, and create the command online. It's that easy now.

In the unlikely event your system does not have the right library support, you'll need to have that fixed by your sysadmin. Most linux installs have this natively.

Overland, and libgd-devel

AFKMud comes with a wilderness ANSI map system we've dubbed "The overland". Basically it is an ANSI color representation of the surrounding terrain around your character when he's out in the wilderness, away from normal areas. This is meant to be used as a filler for what are ordinarily boring connector zones, like large forests, hills, mountains, etc. It lets your builders concentrate more on the interesting places like castles, cities, troll dens, etc. The maps are stored statically in memory after being loaded from png graphic files. Because of this, you will need to be sure your host has the GD development library installed. The compiler will alert you to this in the form of errors trying to compile overland.cpp if the library is not installed.

IMC2

The code comes with IMC2 support installed. IMC2 is an intermud chat protocol which allows you to communicate with other people on other muds. The AFKMud team highly recommends connecting to the network as it is a valuable resource for new and old admins alike. Information is available at: http://lpmuds.net/intermud.html

If your host does not allow outbound connections from your mud you can't use it.

An option in the Makefile allows you to disable it from compiling.

Multiple Port Support

The code now has ways to check which port the mud is running on. This allows for things to behave differently based on which port the game is running on. This requires that some defines be set prior to startup or things will not behave properly. The defines are located in mud.h and are called MAINPORT, BUILDPORT, and CODEPORT. These values MUST be different from each other or the mud will not compile. Change them to fit your hosting situation. These should only be used for additional testing ports and will require an additional password for newly created characters to enter. This password can be set using cset, and ships with the default password of "blocked". Change this ASAP if you intend to use it.

This feature is disabled by default in the Makefile.

Shell Code

The mud has an internal shell processor that will allow some limited functions to make life easier. It is not recommended that these commands be given to anyone but administrators. Also, some mud hosts may not allow this kind of access, check with them first if you have any doubts.

This feature will not be available if Multiport support has been disabled in the Makefile. Command entries will need to be created for this code if the support is activated. Help for this will not be given. Expect to be ignored if you ask, this is dangerous code in the wrong hands and we refuse to be responsible for any damage that could be done.

MSP - Mud Sound Protocol

AFKMud includes support for the MUD Sound Protocol, a system which allows the mud to generate sound for players with clients that support it. For now this seems largely restricted to Zmud users.

Further information on the protocol can be found at: http://www.zuggsoft.com/zmud/mspzmud.htm

MXP - Mud eXtension Protocol

MXP is one of those things that sounds good on paper, looks good when the specs are written, but end up being badly implemented by the people who cooked it up. Still, we have basic support included. It probably doesn't work 100% right, and definitely won't work right in Zmud, ironically enough. But when the spec author disobeys his own standards, that happens.

This feature is being considered for removal. If you want to save it, there's a poll pinned to the forum. Go vote. If you want to guarantee that we don't remove it anyway, despite the poll, then send us a patch to fix it.

afkmud's Issues

Player titles are corrupting after being set during chargen.

   Rogue        [-----] Arielles the Title

Master Felon

^ That more or less says it all. It appears as though titles are either being loaded wrong or are being corrupted in the process of setting one on a new player.

Line endings for text sent through mudprogs are getting stripped.

Somehow, the text responses from mudprogs (echos, says, etc) are getting their line endings stripped off. The resulting chaos is rather unpleasant to try and decipher.

Pager output has several issues to fix.

The pager_output() code in descriptor.cpp has several issues:

• It bleeds color after the prompt.
• It repeats the last line it just showed you before resuming.
• The "N" prompt does not work.
• Using the "R" prompt refreshes but loses one line each time this is done.
• Using the "B" prompt goes back 1 less line than it showed.

Implement regions for assignment to the overland.

The overland could use some kind of new region system, similar to how Oblivion and Skyrim handle it. For AFKMud's purposes, the following is probably adequate:

• Weather type assignments (after the new code is in)
• Regional bounties for criminal activity.
• Large scale regions for the continent tags we're using now.
• Tie in to the mob generation system so that mobs can be set to spawn in certain region types.

Implement Kayle's weather system from SmaugFUSS 1.9

Title says it all really. Kayle's weather system that replaced the original Smaug system is a much better way to do weather.

Asking the user for input after connection state is CON_PLAYING not working with added function

Hello all,
I'm either doing this wrong or something else weird is happening. I've added the CON_INPUT and CON_INPUTPWD connection states to mud.h to act as general input handling states. They set ch->readtxt to the argument descripter_data::nanny () gets whenever a state is set to something else other than CON_PLAYING. (I tried moving this stuff around and this keeps happening.) Then I edited character.h and added the following functions to it ('it' being the character_data class):

// from character.h:
   string read (const string &);
   string readln (const string &);
   string readf( const char *, ... ) __attribute__ ( ( format( printf, 2, 3 ) ) );
      string readlnf( const char *, ... ) __attribute__ ( ( format( printf, 2, 3 ) ) );
   string readpwd (const string &);
   string readpwdln (const string &);
   string readpwdf( const char *, ... ) __attribute__ ( ( format( printf, 2, 3 ) ) );
      string readpwdlnf( const char *, ... ) __attribute__ ( ( format( printf, 2, 3 ) ) );   
// I added the readtxt variable at the end of the class as to not cause class discord:
      string readtxt; // Used with ch->readln () and related functions.
// The implementation of the above functions is below, in character.cpp, starting at line 5400 for my copy:
string char_data::read (const string &txt)
{
this->print (txt);
this->desc->connected = CON_INPUT;
return this->readtxt;
}

string char_data::readln (const string &txt)
{
this->printf ("%s\r\n", txt.c_str());
this->desc->connected = CON_INPUT;
return this->readtxt;
}

string char_data::readf ( const char *fmt, ... )
{
   char buf[MSL * 2];
   va_list args;

   va_start( args, fmt );
   vsnprintf( buf, MSL * 2, fmt, args );
   va_end( args );

   this->print( buf);
this->desc->connected = CON_INPUT;
return this->readtxt;   
}

string char_data::readlnf( const char *fmt, ... )
{
   char buf[MSL * 2];
   va_list args;

   va_start( args, fmt );
   vsnprintf( buf, MSL * 2, fmt, args );
   va_end( args );

   this->printf ("%s\r\n", buf);
   this->desc->connected = CON_INPUT;
return this->readtxt;
}

string char_data::readpwd (const string &txt)
{
this->print (txt);
this->desc->connected = CON_INPUTPWD;
return this->readtxt;
}

string char_data::readpwdln (const string &txt)
{
this->println (txt);
this->desc->connected = CON_INPUTPWD;
return this->readtxt;
}

string char_data::readpwdf ( const char *fmt, ... )
{
   char buf[MSL * 2];
   va_list args;

   va_start( args, fmt );
   vsnprintf( buf, MSL * 2, fmt, args );
   va_end( args );

   this->printf ("%s", buf);
this->desc->connected = CON_INPUTPWD;
return this->readtxt;   
}

string char_data::readpwdlnf( const char *fmt, ... )
{
   char buf[MSL * 2];
   va_list args;

   va_start( args, fmt );
   vsnprintf( buf, MSL * 2, fmt, args );
   va_end( args );

   this->printf ("%s\r\n", buf);
   this->desc->connected = CON_INPUTPWD;
return this->readtxt;
}

Then I implemented the two connection states like so:

// Ln. 3536 for my copy:
         case CON_INPUT:
         {
         ch->readtxt = argument;
         connected = CON_PLAYING;
         }
         break;
         case CON_INPUTPWD:
         {
         write_to_buffer( (const char*)echo_off_str );
         ch->readtxt = argument;
                  write_to_buffer( (const char*)echo_on_str );
         connected = CON_PLAYING;
}
break;

Can any of you tell me what I'm doing wrong? It's hard to determine what's wrong -- the function or the connection state. Even accepting the return value and then doing something like ch->printf ("You entered '%s'\r\n", result.c_str()); doesn't fix it. So right now I'm just confused. The reason I implemented these functions is so that I don't have to implement a hundred thousand connection states for every single form of input I want.
P.s. I used some functions you might not recognize (i.e. println, printlnf, ...); I implemented these and they do work fine.

Tells list "someone" when on overland map

There is a bug that when a player is sending a tell to someone that is on the overland map it will list the sender as "someone". From in code comments it appears this was a bug with channels as well at some point and was fixed differently. I was not able to apply the same fix but instead changed the act functions to printf's instead and this seems to work.

This code replaces the portion between MOBtrigger = false; and MOBtrigger = true; in CMDF( do_tell )

// Changed "act" functions to printf's to avoid "someone" bug on overland maps -Khonsu 12-APR-2024
   // act( AT_TELL, "You tell $N '$t'", ch, argument.c_str(  ), victim, TO_CHAR );
   ch->printf("%sYou tell %s '%s'&d\r\n", ch->color_str(AT_TELL), victim->name, argument.c_str(  ));
   update_tellhistory( victim, ch, argument, true );
   position = victim->position;
   victim->position = POS_STANDING;
   if( speaking != -1 && ( !ch->isnpc(  ) || ch->speaking ) )
   {
      int speakswell = UMIN( knows_language( victim, ch->speaking, ch ), knows_language( ch, ch->speaking, victim ) );

      if( speakswell < 85 )
      {
         victim->printf("%s%s tells you '%s'&d\r\n", ch->color_str(AT_TELL), ch->name, translate( speakswell, argument, lang_names[speaking] ).c_str(  ));
         update_tellhistory( victim, ch, translate( speakswell, argument, lang_names[speaking] ), false );
      }
      else
      {
         victim->printf("%s%s tells you '%s'&d\r\n", ch->color_str(AT_TELL), ch->name, argument.c_str(  ));
         update_tellhistory( victim, ch, argument, false );
      }
   }
   else
   {
      victim->printf("%s%s tells you '%s'&d\r\n", ch->color_str(AT_TELL), ch->name, argument.c_str(  ));
      update_tellhistory( victim, ch, argument, false );
   }

Add area conversion support for Smaug 1.8b (and FUSS too)

The area conversion tool could use being able to convert a Smaug 1.8b area. There are slight differences in the format, but they exist.

SmaugFUSS 1.9 format would be nice too and shouldn't be too much trouble considering it's the same KEY based format we use.

Rework channel historys as vectors of strings.

Channel historys are a mess of crazy dispose and str_dup calls and it just looks hideous, and quite possibly crash prone.

Rework channel history as a vector of strings.

Push to back until max history size is reached. Once it has, erase the beginning element, then push onto the back. Ought to eliminate a whole slew of nasty code.

Finish implementing Guild Inns

Guild inns were planned to allow clans/guilds to run an inn of their own that would draw rent paid by players into the guild's coffers. This was never implemented beyond the room flag for it though and no support exists within the rare items code to pass the money along to the guild who owns the inn.

Councils should be reimplemented

While going through and merging old Smaug 1.8b stuff into SmaugFUSS, it suddenly hit me, "Councils" are just like the realms we're using on Alsherok. So... why the hell did we rip them out?

Stick em back in, but do it in a separate set of code files for easier management.

Reimplement the say and sayto commands as dynamic room channels.

Say and SayTo are effectively nothing more than glorified room channels. There is no logical reason for why they should be treated any differently from the others since channels can be restricted easily enough.

Plus this way it won't be necessary to duplicate the new channel history methods just for the sake of these two special cases.

Overland random mobs need a better method for selection.

The Overland random mobs are currently being set in a static table of ugliness that's not very flexible. There really should be some way to just use mob flags or something to allow for any mob from anywhere in the game to spawn in certain sector types.

The code should then check the available vnums in installed areas to see what it can choose from based on those flags that are set. This way it will be possible to not only supply a small stock set of a few in void.are but also for future areas written to add to this as needed.

Could be even more useful if it's possible to have regional mobs that will only spawn near certain areas on the map, like cities or forts or dragon dens etc.

Mudlet casues hotboot to hang / fail.

hotboot_recover seems to fail on line ~810 due to fscanf not reading the client type provided properly. This causes the mud to hang indefinitely it seems, not just the connected player.

This seems to be caused by Mudlet providing the client name and version number, Mudlet 4.17.1, instead of just a name like 'mushclient' does.

I solved this by modifying how the hotboot file is written slightly.

#include <sstream> // For std::istringstream

// Add this function before do_hotboot

std::string firstWord(const std::string& str) {
    std::istringstream iss(str);
    std::string word;
    iss >> word; // This captures the first word up to the first whitespace
    return word;
}

// And then modifying do_hotboot slightly around line 708

// When writing to the file:
      fprintf(fp, "%d %d %d %d %d %d %d %s %s %s\n",
            d->descriptor, d->can_compress, d->is_compressing, d->msp_detected,
            och->in_room->vnum, d->client_port, d->idle, och->name, d->hostname.c_str(), firstWord(d->client).c_str());

This is the backtrace provided by gdb before the above fix:

Program received signal SIGINT, Interrupt.
0x00007ffff7a369ea in __vfscanf_internal (s=0x55555597de20, format=0x555555798e1f "%d %d %d %d %d %d %d %s %s %s\n", argptr=argptr@entry=0x7fffffffa100, mode_flags=mode_flags@entry=2) at ./stdio-common/vfscanf-internal.c:278
278     ./stdio-common/vfscanf-internal.c: No such file or directory.
(gdb) bt
#0  0x00007ffff7a369ea in __vfscanf_internal (s=0x55555597de20, format=0x555555798e1f "%d %d %d %d %d %d %d %s %s %s\n", argptr=argptr@entry=0x7fffffffa100,
    mode_flags=mode_flags@entry=2) at ./stdio-common/vfscanf-internal.c:278
#1  0x00007ffff7a3621d in __isoc99_fscanf (stream=stream@entry=0x55555597de20, format=format@entry=0x555555798e1f "%d %d %d %d %d %d %d %s %s %s\n")
    at ./stdio-common/isoc99_fscanf.c:30
#2  0x0000555555697ed5 in hotboot_recover () at hotboot.cpp:798
#3  0x0000555555656791 in init_mud (fCopyOver=fCopyOver@entry=true, gameport=<optimized out>, wsocket=wsocket@entry=-1, imcsocket=imcsocket@entry=-1) at comm.cpp:460
#4  0x00005555555a7ea8 in main (argc=<optimized out>, argv=0x7fffffffe488) at comm.cpp:1335

Write a text dumper to dump help files from the SQL data

There needs to be a method available in the SQL version of the help.cpp file to dump the contents of the database out into the current supported file format for helps.

Error Compiling on macOS Sierra: invalid operands to binary expression

Compiling on macOS Sierra version 10.12.2 gives me the output:

Building AFKMud....
/Applications/Xcode.app/Contents/Developer/usr/bin/make -j2 -s afkmud
  Compiling o/comm.o....
  Compiling o/comments.o....
clang: clang: warning: argument unused during compilation: '-rdynamic'
clang: warning: argument unused during compilation: '-e xport-dynamic'
warning: argument unused during compilation: '-rdynamic'
clang: warning: argument unused during compilation: '-e xport-dynamic'
warning: warning: unknown warning option '-Wuseless-cast' [-Wunknown-warning-option]unknown
 warning option '-Wuseless-cast' [-Wunknown-warning-option]
warning: unknown warning option '-Wstrict-null-sentinel' warning[-Wunknown-warning-option]:
unknown warning option '-Wstrict-null-sentinel' [-Wunknown-warning-option]
comm.cpp:377:59: error: invalid operands to binary expression ('__bind<int &, sockaddr *, unsigned long>' and 'int')
   if( bind( fd, ( struct sockaddr * )&sa, sizeof( sa ) ) == -1 )
       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^  ~~
2 warnings and 1 error generated.
make[1]: *** [o/comm.o] Error 1
make[1]: *** Waiting for unfinished jobs....
2 warnings generated.
make: *** [all] Error 2

Using "listen none" to turn off all channels throws a string exception.

When trying to turn off all mutable channels via "listen none" the MUD dumps the following log:

Bugs: [****] BUG: Command exception: 'basic_string::erase' on command: listen none
Bugs: Obtained 7 stack frames.
Bugs: interpret(char_data, std::string)
Bugs: process_input()
Bugs: game_loop()
Bugs: ../src/afkmud(main+0x202)
Bugs: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)
Bugs: ../src/afkmud()
Log: [*****] LAG: Samson: listen none (R:1203 S:1416690772.610337)

All channels remain flagged as on once this happens.

The code in channels.cpp calls the following:

   if( !str_cmp( argument, "none" ) )
   {
      for( chan = chanlist.begin(  ); chan != chanlist.end(  ); ++chan )
      {
         channel = *chan;

         if( channel->flags.test( CHAN_ALWAYSON ) )
            continue;

         if( hasname( ch->pcdata->chan_listen, channel->name ) )
            removename( ch->pcdata->chan_listen, channel->name );
      }
      ch->print( "&YYou no longer listen to any available muteable channels.\r\n" );
      return;
   }

Which in turn calls this in editor.cpp:

/* Remove a member from a list, provided it's there. */
void removename( string & list, const string & member )
{
   if( !hasname( list, member ) )
      return;

   // Implies the list has more than just this name.
   if( list.length(  ) > member.length(  ) )
   {
      string die = " " + member;
      string::size_type pos = list.find( die );

      list.erase( pos, die.length(  ) );
   }
   else
      list.clear(  );
   strip_lspace( list );
}

It's the erase call being made in removename() that's actually breaking.

Shopkeeper inventories are not present.

Title says it all. Shopkeepers are not resetting their inventories despite being configured correctly to be shopkeepers.

Fix bans. They aren't currently implemented.

From descriptor.cpp:

/* FIXME: Write a new ban module so this code has meaning again.
if( dnew->check_total_bans( ) )
{
dnew->write( "Your site has been banned from this Mud.\r\n" );
deleteptr( dnew );
set_alarm( 0 );
return;
}
*/
Maybe it's about time this gets done?