#HELPFILEDATA
colourcode `
security 7
END

#HELPENTRIES
keyword CRANK-IMM CLANRANKS-IMM~
level 92
helpflags wordwrapped~
category command:immortal~
see_also CRANK~
immsee_also CLANLIST~
text `=lSyntax:`=?     crank <clan name>  Lists the ranks within your clan.  If you 
are an immortal crank will take an argument, that being a clan name, so you 
can view the ranks of any clan.  Use the clans short name as listed in help 
clan-list. 
~
END

keyword CLANLIST CLIST~
level 92
helpflags wordwrapped~
category command:immortal~
immsee_also CRANK-IMM~
text `=lSyntax: `=?clanlist`+
`+
This command lists all clans within the game and specific info relating to 
them, including Top Rank, Whoname, and Recall point.`+

~
END

keyword PREFIX~
level 92
helpflags wordwrapped~
category command:immortal~
text `=? `=lSyntax:`=? prefix <argument> `=lSyntax:`=? prefix The PREFIX command will take 
an argument of any legal command and place that argument at your prompt and 
await for addition or execution.  Typing PREFIX without an argument will 
clear your prefix. 
~
END

keyword BREAKTELL~
level 92
helpflags wordwrapped~
category command:immortal~
text `#`=lSyntax:`^  breaktell <playername> `+
    `#`BOr:`^  breaktell all `+
`+
This command enables you to disconnect the reply and retell connections any 
player may have on you.  The all option disconnects this reply and retell 
link for all those that can not see you on the wholist. 
~
END

keyword CASTATLEVEL~
level 92
helpflags wordwrapped~
category command:immortal~
text `=lSyntax:`=? castatlevel <lvl#> <spellname> <target>`+
`+
This command enables immortals to cast a spell at a level many times higher 
or lower than their natural level.  Your level is unchanged when using this 
command, so there is no chance of being killed if you cast an aggresive 
spell at a low level.`+
`+
The level range is from 1 to about three times your level.`+

~
END

keyword AMAP FULLMAP MAPNUM~
level 92
helpflags wordwrapped~
category command:immortal~
see_also SCALEMAP SCALEMXP AREAMAP~
text `=lSyntax:`=? amap`+
`=lSyntax:`=? fullmap`+
`=lSyntax:`=? mapnum`+
`+
These commands made up the original mapping system which was not line of 
sight based and breaks horribly on non grid perfect areas.  The commands 
were never removed because one day they may be useful for something.`+
`+
Since the development of these commands, scalemap, scalemxp and areamap have 
been written which produce much more attractive results.`+
 
~
END

keyword LASTONSTATS MUDCLIENTSTATS~
level 92
helpflags wordwrapped~
category command:immortal~
see_also RACESTATS CLASSSTATS ALIGNSTAT~
text `=lSyntax:`=? lastonstats`+
`+
Lastonstats displays a number of statistics about the playerbase.  This 
information is generated entirely based on the active players recorded in 
laston.  Active players are players which are over level 5 who have logged 
on in the last week.`+
`+
Subsets of the information displayed in lastonstats are available to the 
players using the racestats, classtats and alignstat commands.`+
`+
`=lSyntax:`=? mudclientstats`+
`+
Mudclientstats displays information about the mud clients used to connect to 
the mud which is also recorded in laston.  This information is obtained by 
clients which identify themselves to dawn using the MXP version facility or 
the telnet suboption terminal type system.`+
 
~
END

keyword ATELL KTELL~
title Immortal Only Tell Commands~
level 92
helpflags wordwrapped~
category command:immortal~
see_also TELL~
immsee_also BREAKTELL~
text `=lSyntax:`=? atell <player> <message>`+
`+
atell is short for annoymous tell.  It is used to send a tell to a player 
even while whovisible.  The player when receiving your tell will see it as 
though it came from 'someone'.  If they reply to the tell and you use retell 
the entire conversation will remain annoymous.  The equivilent of an atell 
can be achieved using the normal tell command if you were to go whoinvis, 
send a single tell, then go whovis.  There is no real in using atell over 
tell if you are already whoinvis.`+
`+
You can use breaktell straight after sending a player an atell to prevent 
them replying to you. `+
`+
`+
`=lSyntax:`=? ktell <player> <message>`+
`+
ktell is short for known tell.  It is effectively the opposite of atell.  It 
can be used to send a tell to a player while whoinvis in such a way that 
your name is known to that player.  The player when receiving your tell will 
see it as though it came from you even though they wont be able to see you 
on the who list.  The equivilent of an ktell can be achieved using the 
normal tell command if you were to go whovis, send a single tell, then go 
whoinvis.  There is no benefit in using ktell over tell if you are already 
whovis.`+
  
~
END

keyword CHECKCOMMANDS CHECKBUG CHECKCLANBANK CHECKCODE CHECKMULTILOG CHECKMOBLOG CHECKNTALK CHECKNEWBIE CHECKNSUP CHECKOOC CHECKTYPOS CHECKLOG CHECKDEAD CHECKIRC~
title Immortal Check Commands~
level 92
helpflags wordwrapped~
category command:immortal~
see_also WIZHELP MOBLOG~
text There are a number of immortal commands starting with the word 'check'.  You 
can see the complete list by typing `=Cwizhelp check`=?.  The general rule for 
these commands is they display the most recent output of a logged file or 
the contents of a directory on the disk.`+
`+
An example of a command which displays the most recently logged information 
from a logfile is `=Ccheckntalk`=?.  This command displays the logged use of the 
ntalk command.  Typing checkntalk by itself will display the last 10 lines 
of text transmitted over the ntalk channel.  You can also specify the number 
of lines back into a log you want to see.  E.g. 'checkntalk 30' would 
display the last 30 said on ntalk.  Obviously this could become overloading, 
as a result, the check commands limit the output to upto 40 lines.  What 
this means is if you attempt to look more than 40 lines back into a log, you 
will see upto 40 lines starting back how far you specify... e.g. if you type 
checkntalk 70... the mud will display lines 70 thru 30 from the end of the 
log file.  Generally you are unable to look back beyond line 20000 in a log 
file (assuming that many lines are logged). `+
`+
`=U  Check commands supporting the number of lines argument:`=?`+
`=lSyntax:`=? checkbug      - look into the bugs log.`+
`=lSyntax:`=? checkclanbank - look at the clanbanking records.`+
`=lSyntax:`=? checkcode     - look into the coding log.`+
`=lSyntax:`=? checkmultilog - look at recorded multilogging events`+
`=lSyntax:`=? checkmoblog   - look at the `=_moblog output`+
`=lSyntax:`=? checkntalk    - look into the ntalk log.`+
`=lSyntax:`=? checknewbie   - look into the newbie channel log.`+
`=lSyntax:`=? checknsup     - look into the newbie support tell log.`+
`=lSyntax:`=? checkooc      - look into the ooc channel log.`+
`=lSyntax:`=? checktypos    - look into the typos log.`+
`+
`=lSyntax:`=? checklog  [player] - look at a logged players logfile.  If you 
don't specify the name checklog lists all player logfiles in date order.`+
`+
`=U  Check commands looking at files on the disk:`=?`+
`=lSyntax:`=? checkdead - list all pfiles stored in the dead directory.`+
`=lSyntax:`=? checkirc - used to read irc logs... not active by default.`+
`+
`=U  Other check commands documented elsewhere:`=?`+
`=_checkbalance, `=_checkban, `=_checkexits`+
`+
Note: Not all checkcommands listed in this help will be available to lower 
level immortals.`+
 
~
END

keyword CWHERE~
level 92
helpflags wordwrapped~
category command:immortal~
see_also MWHERE IWHERE OWHERE~
text `=lSyntax:`=? cwhere`+
`+
Cwhere is short for 'corpse where'... its output displays all player corpses 
in the game.  Depending on the colour of the corpse listed determines its 
status.`+
`gGreen`=? pc corpses are empty.`+
`RRed`=? pc corpses contain objects and is not being carried by anyone.`+
`BBlue`=? pc corpses are being carried by someone (and contain objects).`+
`+
If are corpse is being carried by a player, cwhere will tell you who is 
carrying it.`+
 
~
END

keyword MPDUMP MPSTAT~
level 92
helpflags wordwrapped~
category command:immortal~
see_also MPSHOW MSHOW~
text `=lSyntax:`=? mpdump <mobprog vnum>`+
`=lSyntax:`=? mpstat <mob with mobprog>`+
`+
mpdump is an old command originally used to display a mobprog of a 
particular vnum.  The command has actually been superceeded by the olc 
mpshow command which displays more information.`+
`+
mpstat displays the mobprog status on a given mob.  Most of the information 
shown here can be seen using the olc mshow command.`+

~
END

keyword INOTE PENALTY ANOTE~
level 92
helpflags wordwrapped~
category command:immortal~
see_also NOTES~
text Inote, anote and penalty are immortal/admin only note spools.  The use of 
these commands is exactly like the standard note spools other than the fact 
that they are imm/admin only. 
~
END

keyword TJUNK~
level 92
helpflags wordwrapped~
category command:immortal~
see_also TOKENS MOBHELP~
text `=?Syntax:`=? tjunk <tokennumber> <person>`+
`=?Syntax:`=? tjunk all.<tokennumber> <person>`+
`+
These are immortal versions of the mobprog token junk commands.  They are 
used to purge tokens on players/mobs.`+
`+
Type `=Cmobhelp tjunk`=? for futher information.`+
 
~
END

keyword NPCINFO~
level 92
helpflags wordwrapped~
category command:immortal~
text `=lSyntax:`=? npcinfo`+
`+
Npcinfo displays statistics on all mobs in the game.  Giving a breakdown of 
the total different races in use and how they are distributed thru the areas 
in the realm.`+

~
END

keyword SEDIT SSHOW SPSKLIST~
level 92
helpflags wordwrapped~
category command:immortal~
see_also -CLASS~
text `=lSyntax:`=? spsklist`+
`+
Displays a list of spells and skills grouped into categories.`+
`+
`=lSyntax:`=? sedit <spell/skill>`+
`=lSyntax:`=? sedit create <spell>`+
`+
sedit is the olc editor used to edit a number of properties stored with 
spells and skills.  Sedit can modify the mana, damage type, lag (4 beats per 
second), realms, spheres, elements & seasons and spell function orientated 
with a spell.   Sedit configures global properties of a spell/skill.  The 
class command can be used to configure the level at which a class can get a 
spell/skill.  See help `=_-class for more on that.`+
`+
Sedit can also be used to create spells which are aliased versions of 
existing c++ spell functions.  This involves using sedit create, then 
setting the spell function accordingly. `+
`+
`=lSyntax:`=? sedit <spell/skill>`+
`+
sshow displays the 'show' screen of the sedit olc editor.`+
 
~
END

keyword TESTYELL~
level 92
helpflags wordwrapped~
category command:immortal~
text `#`=lSyntax:`^ testyell`1This command shows how far a yell will go.`+
`+
Example:  Room vnum = 3000`+
          Yellindex=455`+
          Yell_enteredindir=0`+
          Yell_amplitude=24.116692`+
`+
This command was used during the initial development of the yelling system.`+
`+
For lack of a place to put other testing information, testyell also includes 
testing code relating to MSP, DawnFTP and the colour system.`+
 
~
END

keyword REVERSE~
level 92
helpflags wordwrapped~
category command:immortal~
text `=lSyntax:`=? reverse <text to say backwards>`+
`+
Reverse was just a language created for fun, it reverses the order of what 
ever you say, making each word spelt backwards.`+

~
END

keyword SEEVNUM~
level 92
helpflags wordwrapped~
category command:immortal~
see_also HOLYVNUM~
text `=lSyntax:`=? seevnum <command>`+
`+
Seevnum has the affect of turning on `=_holyvnum for the duration of the 
command.  Most people prefer to have `=_holyvnum on all the time.  But for the 
few that don't they are able to turn it on temporarily... e.g. `=Cseevnum 
look`=?`+

~
END

keyword SETRACE~
level 92
helpflags wordwrapped~
category command:immortal~
text `=lSyntax:`=? setrace <racename>`+
`+
The setrace command is used to change your own race quickly in order to test 
mobprogs etc.  You can not change the race of others with this command.`+

~
END

keyword ADDSCRIPT LISTSCRIPT RUNSCRIPT~
level 92
helpflags wordwrapped~
category command:immortal~
text `=lSyntax:`=? addscript <script> [immortal name]`+
`=lSyntax:`=? listscript`+
`=lSyntax:`=? runscript <script to run>`+
`+
The runscript command is used to execute scripts stored on the file system 
in the scripts directory.  The scripts have to be setup using the addscript 
command.  You can list all scripts that have been setup using the listscript 
command.`+
`+
Example uses of scripts include triggering a script which emails a backup of 
the area files to the head builder without giving them site access.  Another 
script could email a backup of the player files to the imp without requiring 
the imp to go into the shell etc.`+
 
~
END

keyword TELNETGA~
level 92
helpflags wordwrapped~
category command:immortal~
text `=lSyntax:`=? telnetga`+
`+
TelnetGA is short for telnet Go Ahead.  Telnet Go Ahead is a telnet option 
which is used to instruct a supporting telnet client where the prompt ends.  
The system can be used with telnet clients that remove the prompt and 
display it on a status bar.`+
 
~
END

keyword SCALEMAP SCALEMXP AREAMAP~
level 92
helpflags wordwrapped~
category command:immortal~
text `=lSyntax:`=? scalemap [range]`+
`=lSyntax:`=? scalemxp [range]`+
`=lSyntax:`=? areamap [range]`+
`+
Scalemap scans the rooms surrounding you to generate an ascii art type map 
which represents the land surrounding you.  It is based on an extended form 
of the automapper with extended range.  The mapper does not cross into areas 
where the map scale changes.`+
`+
Scalemxp is an mxp enabled version of the scalemap with a few extra 
features.  Firstly rooms a clickable, right clicking them will display 
information about a selected room.  Secondly if the map is not grid perfect, 
the scalemxp will show rooms which overlap in red.`+
`+
Areamap displays a map containing only rooms in the same area as you are 
in... this command is very useful for determining the boundaries between 
areas.`+
     
~
END

keyword CHECKBALANCE~
level 92
helpflags wordwrapped~
category command:immortal~
see_also CHECKCOMMANDS~
text `=lSyntax:`=? checkbalance obj`+
`+
Checkbalance was written to help test the balance of items created within 
the OLC interfaces of the dawn codebase.  Unfortunately it is uncompleted 
and only currently checks objects.  The rules which it uses to check objects 
are also dated and are generally not appropriate to every muds balance 
guidelines. 
~
END

keyword CHECKBAN BAN-EMAIL-EXAMPLE EMAIL-VERIFICATION~
level 96
helpflags wordwrapped~
category command:immortal~
see_also CHECKCOMMANDS~
text `=lSyntax:`=? checkban <ip/host address of player as shown in sockets/laston>`+
`+
The checkban command is used to show you which if any of the ban matching 
rules will match for a particular host.`+
`+
For example if you had a ban forcing email verification for all players 
coming from aol.com.  If you typed `Ycheckban AC9HCFA4.ipt.aol.com`=? you would 
expect to see something like the following:`+
`+
`S-===========================================================================--
`=?`+
==- CHECK BAN ON: 'AC9HCFA4.ipt.aol.com'`=?`+
- Newbies: `Gallowed`x`+
- Permit/Letgained check: `Gallowed`x`+
- Email check: `Rdenied`x`+
Ban #1`+
`=t-========================== `=TBANEDIT SHOW `=t==========================-`+
`x`=rSitemask:    '`=R*aol.com`+
*msn.com`+
*uunet.com`+
`=r'`+
IntendedPeople: `=R`N Email Verification System`+
`=rEnabled: `=RTrue`+
`=rPermanent: `=RTrue`+
`=rType: `=Remail`+
`=rban created on: `SSat May 25 12:05:00 2002`+
`=rby: `SKalahn`x`+
`=rReason: `=RTo require email verification for users from particular ISPs.`+
`=rCustom disconnect message: `Snone`+
`=rExpire date: `=Rnone`+
`=ralways_allowed_email_masks: `=R`+
exception1@hotmail.com`+
goodplayer@hotmail.com`+
anothergoodplayer@hotmail.com`+
friend@yahoomail.com`+
`=rallowed_email_masks: `=R`+
*@aol.com`+
*@msn.com`+
*@uunet.com`+
`=rdisallowed_email_masks: `=R`+
badperson@aol.com`+
idiot@msn.com`+
`=rnote: disallowed_email_masks have a higher priority than allowed masks, if 
a particular email addy matches the disallowed email mask, it will be denied 
even if it matches the allowed mask also.  The only exception to this is if 
the email address is on the always_allowed_email_masks list for this ban... 
note the always allowed only applies to this particular ban... if the host 
and email match a disallowed on another ban, it will be declined.`x`+
`+
`=rdisallowed_email_masks_message: `=R`+
Access to this site has been denied!  Please contact the MUD Administration 
for inquiries on why access is denied.`+
`x- All: `Gallowed`x`+
`S-===========================================================================--
`=?`+
 
~
END

keyword CHARNOTES EDITCHARNOTE~
level 94
helpflags wordwrapped~
category command:immortal~
see_also PINFO~
text `=lSyntax:`=? charnotes <playername>`+
`=lSyntax:`=? editcharnote <playername>`+
`+
The mud has the ability to store notes on each player that are saved with 
their pfile.  These notes can be viewed by any immortal at any time using 
the charnotes command.  Players with charnotes attached to them have a 
yellow `Y-`=? beside their name in `=_pinfo`+
`+
Charnotes can be edited using the editcharnotes command.  
~
END

keyword CHECKEXITS~
level 94
helpflags wordwrapped~
category command:immortal~
see_also CHECKCOMMANDS OLC-EXITS~
text `=lSyntax:`=? checkexits area`+
`=lSyntax:`=? checkexits all`+
`+
The checkexits command is used to check the linking of room exits with an 
area and over the entire realm.  There are two types of linking errors 
checkexits will detect.`+
`+
The first type of linking error is in the format:`+
 8200:S  ->  8201 has no  N exit, set 1way on  8200:S  or relink.`+
`+
In this particular example, this indicates that walking south from room 8200 
will put you into room 8201.  But upon arriving in room 8201, you are unable 
to walk north to get back to room 8200 since there is no north exit in room 
8200.  If this unusual room linking is intentional (say in a maze area), you 
should set the oneway flag on the exit to remove the error report in 
checkexits.  The oneway flag in the above example would be set by typing 
`=Credit 8200`=? followed by `=Csouth oneway`=? followed by `=Cdone`=?.`+
`+
The second type of linking error checkexits tests for is in the format:`+
 8205:N  ->  8200:S  -> 8201.`+
`+
This example shows that walking north from room 8205 would put you in room 
8200.  Then walking south from there would put you in room 8201 (when you 
would expect to be back in the starting room 8205).`+
`+
For any of the linking errors, they can be fixed by removing the incorrect 
exits then recreating them... see help `=_olc-exits for more on this.`+
 
~
END

keyword IMM-LASTON~
level 92
helpflags wordwrapped~
category command:immortal~
see_also LASTON~
text `=lSyntax:`=? laston [options]`+
`=lSyntax:`=? laston -?`+
`+
The immortal version of laston supports a lot of filtering options.  A list 
of all these options can be displayed by typing "`=Claston -?`=?".`+
`+
The laston filtering options can be stacked, for example:`+
`=Claston -c -r >5 <10 -x -a -f`=?`+
Could be used to filter the laston database to display full (-f) records on 
all (-a) characters between level 5 (>5) and 10 (<10).  Displaying their 
class (-c) and race (-r) while numbering each match (-x).`+

~
END

keyword GAMEEDIT SAVEGAMESET~
title GameEdit - The Game Engine Parameter Editor~
level 100
helpflags wordwrapped~
category command:immortal~
text `=lSyntax:`=? gameedit confirm`+
`+
The gameedit command is used to access the olc editor for all the game 
settings.`+
`+
There are a lot of settings which can be configured in the game editor, most 
of which affect some aspect of the game engine.`+
  `+
Probably the most important setting in the gameeditor is the gamename.  This 
is the name of your mud, and appears in the top of a number of commands 
(e.g. mudstats, laston).  Once in the game editor, type `=Cgamename <your mud 
name>`=? to set your gamename.`+
`+
A lot of dawn's vnums and parameters are not hard coded.  The values and 
vnums which can be changed within gameedit can be viewed using the 
`=Cshowvalues`=? command.  In addition these values can be modified using the 
`=Cvalue`=? gameedit command.`+
`+
At this stage many options configurable within gameedit are undocumented... 
they will most likely be documented in newer releases of the dawn codebase.`+
`+
Unlike all the other olc editors, changes in performed in gameedit do not 
automatically save... they must be manually saved using the`=C savegameset 
`=?command.  This command saves the gamesettings to gameset.txt located in the 
same directory as the dawn executable binary.`+
   
~
END

keyword HOW-DAWN-WORKS~
title How Dawn Works~
level 92
helpflags wordwrapped~
category undefined~
text This is based on a posted originally from the Dawn forums at 
http://forums.dawnoftime.org/ by Kalahn in April 2003.`+
`+
The Dawn Codebase is written in C/C++, and is modular to a certain degree, 
there is the core engine which drives the game, and various subcomponents 
such as spells/skills which are hooked in in various places.`+
`+
Dawn is a very flexible mud codebase, and supports a significant amount of 
customisation without requiring any programming knowledge (for example in 
the olc editors).  If you are wanting major changes which can't be achieved 
within the existing Dawn framework, you will need to modify the C/C++ source 
code.`+
`+
If you are unfamilar with the C or C++ languages, it is very likely you will 
need to do some background reading on the C language to help you get 
orientated.  `+
In order to understand how to hook your own features in, it helps to 
understand how the core engine works (at least at a high level). `+
`+
======core engine======`+
main() is located within comm.cpp, basically it boots up the mud loads in 
the environment (system files, realm etc) then enters game_loop(). `+
`+
The core of game_loop() runs 4 times per second and does the following: `+
- syncronise to a clock (to prevent it running more than 4 times per second) 
`+
- accept new TCP connections (people connecting) `+
- disconnect connections in an network error state `+
- process one queued command per player (unless speed walking, which does 2 
movement commands - enabling speedwalkers to move 8 rooms per second instead 
of 4 if using manual directions) `+
- run update_handler() (more on this shortly) `+
- send all queued output for all connections `+
`+
update_handler() is responsible for a lot of things including (but not 
limited to): ticks, wandering mobs, combat, affects, weather messages, aggie 
mobs, olc autosave and the mob queue system. `+
====================== `+
`+
======user input====== `+
game_loop() processes user input in various ways depending on the type of 
connection and state the connection is in. When a connections state is 
something other than CON_PLAYING (which is the state for logged in players) 
all input is routed through nanny() in nanny.cpp. This handles creation and 
redirects dawnftp transactions. `+
`+
If a player is fully logged, their connection state will be set to 
CON_PLAYING and all input is directed interpret() - the only exception being 
if they are in an olc editor, which means it is first handled by 
run_olc_editor(). `+
`+
interpret() parses the user input using the cmd_table[] table to determine 
which command a player is trying to use (you can see this table in 
interp.cpp starting about 65 lines down). `+
`+
For example the first command in the cmd_table[] is "north"... so interp 
matchs this with the user input and the player has access to that command, 
the command function will be executed - do_north() in this case. A number of 
attributes for entries in cmd_table[] are dynamically populated in at bootup 
and can be edited using "comedit". `+
`+
Nearly all commands run via interpret() are prefixed with "do_"... this is 
part of the coding style, not something that is enforced by a compiler. `+
`+
The "do_" functions are then stored in various files in the source, 
depending on the type of commands... for example the act_*.cpp files, store 
a number of do_ functions, act_obj.cpp typically stores do_ functions that 
manipulate objects. act_wiz*.cpp are generally immortal commands. `+
`+
magic.cpp, contains do_cast() (and its variants) redirect to do_newcast()... 
which is the core of the magic system. do_newcast looks up spells from 
within skill_table[] and runs the spell function a simular was that commands 
are located in cmd_table[]. skill_table[] is dynamically created at bootup 
and can be edited using sedit. `+
`+
An example may make things clearer.. `+
`+
Lets take what is involved to cast the spell acid blast...(contained in the 
function spell_acid_blast(). `+
`+
Lets assume a player is already connected, and logged in and has the spell 
etc. `+
The player types "cast 'acid blast' target", game_loop() recognises that 
there is input waiting from the player connection, it redirects the input to 
interpret() which finds there is a cast command... it then executes the 
function for this command - do_cast(). do_cast() redirects to do_newcast() 
which searchs skill_table[] for a spell called "acid blast", after finding 
it and confirming it has a spell function set, it then executes the spell 
function (Which is called spell_acid_blast() in this case), and that 
function does what it is supposed to do. `+
====================== `+
`+
Some other files in the source, some a pretty obvious: `+
include.h - the main include file for the entire game. `+
macros.h - a LOT of compiler macros used to save time. `+
params.h - a LOT of hard coded limits and parameters are defined in here - 
have a look. `+
structs.h - almost all of the data structures used in the game. `+
prototyp.h - function prototypes `+
chardata.h - the definition of the char_data class. `+
chardata.cpp - the implementation of the char_data class. `+
act_move.cpp - functions to move players around (e.g. do_north()). `+
*edit.cpp - olc editors e.g. aedit.cpp, comedit.cpp. `+
colour.* - the colour system `+
dynamics.* and dyntable.* - the core of code enabling classes and skills to 
stored in text files. `+
fight.cpp, duel.cpp - combat system and related code. `+
ftp.cpp - dawnftp/mudftp implementation `+
gio.cpp - the generic IO system - this is the heart of most of the muds 
input and output. `+
magic*.* contains all the spells `+
global.h - global variables are defined in here using the "EXTERN" macro... 
this macro is rewritten into "extern" in every file within the source code 
other than global.cpp. In global.cpp it is renamed to "" so therefore the 
variable is defined to be 'physically' stored in global.cpp. `+
gsn.h - global skill/spell numbers `+
handler.cpp - a heap of utility functions `+
hreboot.* - the hotreboot system `+
intro.* - the introduction system `+
language.* - the language system `+
mob_*.* - the mobprog engine and systems. `+
msp.* - core msp libraries `+
websvr.cpp - the integrated webserver implementation `+
mud2web.cpp - support functions bridging websvr.cpp into the mud `+
mob_q.cpp - the mobprog queuing system. `+
mount.cpp - horse riding anyone? `+
mxp.*- mxp library functions `+
namegen.* the name generated accessed in creation `+
nanny.cpp - handles non playing connections `+
network.cpp - operating system specific low level network code `+
noble.cpp - the noble system `+
note.cpp - the notes system `+
offmoot.cpp - offline mooting `+
pipe.cpp - popen() and system() based commands. e.g. checklog, pipe. `+
mem.cpp and recycle.cpp - memory management system `+
resolve.* - dns resolver and ident related code `+
save.cpp - this file saves pfiles `+
socials.cpp - the socials system `+
special.* - mob specials `+
support.* - commands originally used by the dawn support council `+
tables.* - a LOT of lookup tables - have a look. `+
textsrch.* - the text search system `+
tokens.* - the token system used by mobprogs `+
track.* - the tracking system `+
trap.* - traps perhaps? `+
update.cpp - update_handler() and many functions it calls `+
who.cpp - the core of the who engine `+
whofmt.cpp - various display formats for different muds. `+
wizlist.cpp - dynamic wizlist. `+
`+
In terms of starting out, I suggest adding a spell or two... that is 
probably the easiest thing to start with. Work with little things, get them 
reliable, then get more involved. `+
`+
- Kal, April 2003`+
 
~
END

EOF~
#$