nightmare3_fluffos_v2/
nightmare3_fluffos_v2/bin/
nightmare3_fluffos_v2/fluffos-2.9-ds2.08/
nightmare3_fluffos_v2/fluffos-2.9-ds2.08/ChangeLog.old/
nightmare3_fluffos_v2/fluffos-2.9-ds2.08/Win32/
nightmare3_fluffos_v2/fluffos-2.9-ds2.08/compat/
nightmare3_fluffos_v2/fluffos-2.9-ds2.08/compat/simuls/
nightmare3_fluffos_v2/fluffos-2.9-ds2.08/include/
nightmare3_fluffos_v2/fluffos-2.9-ds2.08/testsuite/
nightmare3_fluffos_v2/fluffos-2.9-ds2.08/testsuite/clone/
nightmare3_fluffos_v2/fluffos-2.9-ds2.08/testsuite/command/
nightmare3_fluffos_v2/fluffos-2.9-ds2.08/testsuite/data/
nightmare3_fluffos_v2/fluffos-2.9-ds2.08/testsuite/etc/
nightmare3_fluffos_v2/fluffos-2.9-ds2.08/testsuite/include/
nightmare3_fluffos_v2/fluffos-2.9-ds2.08/testsuite/inherit/
nightmare3_fluffos_v2/fluffos-2.9-ds2.08/testsuite/inherit/master/
nightmare3_fluffos_v2/fluffos-2.9-ds2.08/testsuite/log/
nightmare3_fluffos_v2/fluffos-2.9-ds2.08/testsuite/single/
nightmare3_fluffos_v2/fluffos-2.9-ds2.08/testsuite/single/tests/compiler/
nightmare3_fluffos_v2/fluffos-2.9-ds2.08/testsuite/single/tests/efuns/
nightmare3_fluffos_v2/fluffos-2.9-ds2.08/testsuite/single/tests/operators/
nightmare3_fluffos_v2/fluffos-2.9-ds2.08/testsuite/u/
nightmare3_fluffos_v2/fluffos-2.9-ds2.08/tmp/
nightmare3_fluffos_v2/fluffos-2.9-ds2.08/windows/
nightmare3_fluffos_v2/lib/cmds/ambassador/
nightmare3_fluffos_v2/lib/cmds/database/
nightmare3_fluffos_v2/lib/cmds/hm/
nightmare3_fluffos_v2/lib/cmds/soul/
nightmare3_fluffos_v2/lib/daemon/cfg/
nightmare3_fluffos_v2/lib/daemon/cfg/mon_races/
nightmare3_fluffos_v2/lib/daemon/cfg/races/
nightmare3_fluffos_v2/lib/daemon/include/
nightmare3_fluffos_v2/lib/daemon/save/
nightmare3_fluffos_v2/lib/daemon/services/
nightmare3_fluffos_v2/lib/daemon/soul/
nightmare3_fluffos_v2/lib/doc/
nightmare3_fluffos_v2/lib/doc/TestPlans/
nightmare3_fluffos_v2/lib/doc/approval/
nightmare3_fluffos_v2/lib/doc/approval/QC/
nightmare3_fluffos_v2/lib/doc/approval/balance/
nightmare3_fluffos_v2/lib/doc/build/
nightmare3_fluffos_v2/lib/doc/build/armours/
nightmare3_fluffos_v2/lib/doc/build/economy/
nightmare3_fluffos_v2/lib/doc/build/etc/
nightmare3_fluffos_v2/lib/doc/build/monster/
nightmare3_fluffos_v2/lib/doc/build/room/
nightmare3_fluffos_v2/lib/doc/build/virtual/
nightmare3_fluffos_v2/lib/doc/build/weapon/
nightmare3_fluffos_v2/lib/doc/classes/
nightmare3_fluffos_v2/lib/doc/efun/
nightmare3_fluffos_v2/lib/doc/etc/
nightmare3_fluffos_v2/lib/doc/help/creator/
nightmare3_fluffos_v2/lib/doc/help/hm/
nightmare3_fluffos_v2/lib/doc/law/
nightmare3_fluffos_v2/lib/doc/lpc/basic/
nightmare3_fluffos_v2/lib/doc/lpc/data_types/
nightmare3_fluffos_v2/lib/doc/lpc/etc/
nightmare3_fluffos_v2/lib/doc/lpc/intermediate/
nightmare3_fluffos_v2/lib/doc/lpc/types/
nightmare3_fluffos_v2/lib/doc/mudlib/
nightmare3_fluffos_v2/lib/doc/mudlib/features/
nightmare3_fluffos_v2/lib/domains/Examples/etc/
nightmare3_fluffos_v2/lib/domains/Examples/room/
nightmare3_fluffos_v2/lib/domains/Examples/virtual/
nightmare3_fluffos_v2/lib/domains/Examples/virtual/exaA/
nightmare3_fluffos_v2/lib/domains/Examples/virtual/exaB/
nightmare3_fluffos_v2/lib/domains/Examples/weapon/
nightmare3_fluffos_v2/lib/domains/Praxis/
nightmare3_fluffos_v2/lib/domains/Praxis/adm/
nightmare3_fluffos_v2/lib/domains/Praxis/attic/
nightmare3_fluffos_v2/lib/domains/Praxis/cemetary/
nightmare3_fluffos_v2/lib/domains/Praxis/cemetary/mon/
nightmare3_fluffos_v2/lib/domains/Praxis/data/
nightmare3_fluffos_v2/lib/domains/Praxis/death/
nightmare3_fluffos_v2/lib/domains/Praxis/mountains/
nightmare3_fluffos_v2/lib/domains/Praxis/obj/armour/
nightmare3_fluffos_v2/lib/domains/Praxis/obj/magic/
nightmare3_fluffos_v2/lib/domains/Praxis/obj/weapon/
nightmare3_fluffos_v2/lib/domains/Praxis/orc_valley/
nightmare3_fluffos_v2/lib/domains/Praxis/quests/
nightmare3_fluffos_v2/lib/domains/Praxis/standardOld/
nightmare3_fluffos_v2/lib/include/
nightmare3_fluffos_v2/lib/log/
nightmare3_fluffos_v2/lib/log/errors/
nightmare3_fluffos_v2/lib/log/reports/
nightmare3_fluffos_v2/lib/log/watch/
nightmare3_fluffos_v2/lib/news/
nightmare3_fluffos_v2/lib/secure/cfg/
nightmare3_fluffos_v2/lib/secure/cmds/ambassador/
nightmare3_fluffos_v2/lib/secure/cmds/mortal/
nightmare3_fluffos_v2/lib/secure/save/users/d/
nightmare3_fluffos_v2/lib/secure/std/
nightmare3_fluffos_v2/lib/std/hm/
nightmare3_fluffos_v2/lib/std/living/
nightmare3_fluffos_v2/lib/std/room/
nightmare3_fluffos_v2/lib/std/user/
nightmare3_fluffos_v2/lib/std/virtual/
nightmare3_fluffos_v2/lib/www/
nightmare3_fluffos_v2/lib/www/errors/
nightmare3_fluffos_v2/lib/www/gateways/
nightmare3_fluffos_v2/win32/
Guilds at Nightmare are specializations in certain areas, where as
a Nightmare class represents a player's general areas of
concentration.  In short, the guild is to a class as a job is to a
profession.  Guilds should be highly restrictive and very different
from each other.

In most cases, immortals should have the position of creator before work
is seriously begun on a guild.  The reason for this is that although
you may be very creative and/or a great coder, as an immortal you
do not have the experience coding on Nightmare LPMud that is necessary
to add a meaningful guild.  Plus, good ideas for a guild generally
take a while to develop.  So remember the following guidelines when
putting any guild idea into concrete code:

1) Make sure you have a *small* group of people you are targeting
for membership.  Some people should be *specifically* excluded for
the guild.  And the guild should only benefit highly a VERY small
percentage of players.  For instance an assassin's guild would only
benefit rogues with extremely high stealth, and would explicitly
exclude monks and clerics.  Other people may or may not want to join
based on their individual situations and playing styles.

2) The idea should be narrow in scope, and very unique.  Don't
code another class.  Any guild should just have about 3/4 core powers
and a lot of funky emotes.  Anything beyond that is expanding into
a class.  Of course as many unique features, things which are not
powers but just atmosphere or benefits of the guild, are what
truly make a guild fun.  For instance, one guild might have the power
to brew beer given certaon conditions and sell it.  That is not truly
a power since it is a process (assuming you do not have a single
brew beer command).

Nightmare has an inheritable guild object that contains all the 
functionality needed in any possible guild object.  Those 
functions include allowing a leader to add and remove players
as well as port members to the leader.  The other functions
include some custom set_*() functions (which will be explained in
detail below).  This leaves you free to define the other things which
will make your guild unique, since all the fucntions required by
the mud have been precoded for you.

Guild commands are coded like other mudlib commands.  Each command
is contained in its own file.  A typical command looks like:

-----
#include <std.h>

inherit DAEMON;

int cmd_womble(string str) {
   womble code here
    return 1;
}
----

What happens is that in the user object there is an add_action() that
has every command a player types go through it.  If it is a command
that is in a file a player has access to (in a /bin file specified
for that player), then the cmd_whatever() function is executed.
In other words, the cmd_whatever() function is just like a function
called by an add_action().  It returns 1 for success and 0 for
failure.

But you do not need to know the nitty gritty of how commands are executed
to code a guild.  You just need to know how to add commands.
To add a command a player may execute:
There must be a directory /bin/guild/<guildname>
In that directory you will place a file called: _<commandname>.c
And the function: cmd_<commandname> will be executed.

Of course, you do not have access to that directory to start.  So to
test new powers, add them to /wizards/<yourname>/bin/_<commandname>.c
They will execute properly in that directory.  When your guild is approved,
Approval will create the /bin/guild directory for you and place
approved commands in that directory.  That is all there is to making commands.
See other commands all throughout /bin to see exactly what other 
commands look like.  DO NOT ADD ANY COMMANDS TO THE GUILD OBJECT.

*************************************

How to setup a guild object:

Naturally, you must set_name(), id, long, short and all like with any other
object.  In addition to those generic object sets, the guild object
REQUIRES that the following special functions be set:

set_guild_name(string)
Example: set_guild_name("witch")
Sets the unique name which identifies the guild.

set_guild_test(function)
Example: set_guild_test( (: this_object(), "witch_ok" :) )
Sets the function which will be called to test if a player may be added
to the guild.  The player being tested is passed to the function.  So
you might have witch_ok() defined in your guild object in the following
way:

int witch_ok(object ob) {
    if((string)ob->query_gender() != "female") return 0;
    else return 1;
}

You probably would want to put in information explaining to the leader
of the guild (this_player()) and the person being tested (ob) why
the thing failed.

set_leader(string)
Example: set_leader("dawn")
Sets the name of the leader of the guild.  This person has the ability
to add new members, to remove old members, and to teleport members
to their current position at a cost of mp.

set_guild_home(string)
Example: set_guild_home("/realms/descartes/witch/room/lounge")
Specifies the home base of the guild where player's start out each
time they login.

That is the minimum you must do.  Of course, there are many other
functions which are optional which add flavour:

set_new_member(string|function)
Examples: set_new_member("Welcome new witch! Type <worship Lasher> for help.")
          set_new_member( (: this_object(), "newbie" :) );
If you pass a string, this is the string a newly added member will
see when the person is added to the guild.  If, instead, you specify
a function, that function will be called, passing the new member as
an argument to your function.  

set_welcome(string|function)
Examples: set_welcome("Welcome back to Nightmare Great Witch!");
          set_welcome( (: this_object(), "welcome" :) );
If a string, the string gets printed to the player's screen when they
login.  Otherwise, if it is a function, then the function would be
called when the player logs in.  If you are familiar with the
init_arg() function, the argument which is passed to that will be
passed to your welcome function.  If you do not know, then it is
irrelevant, cause you would know what is passed to init_arg() if you
need it.  Type "man query_auto_load" for more details.

set_guild_description(string|function)
Examples: set_guild_description("is a witch!");
          set_guild_description( (: this_object(), "guild_desc" :) );
If a string, the string will appear in the player's description
after their name.  So: "Descartes is a witch!" would appear for the string
example.  If it is a function, the string returned by your function
will appear in the description.

void set_guild_object(string)
Example: set_guild_object("/realms/descartes/witch/obj/new_necklace")
You will almost never use this function, unless you are making severe
changes to your object and need the players currently getting the object
to get it in from another file.  Generally, players get cloned
the file name of the object as it was when they quit.  If you want that
to change for their next login, specify a different file.

****************************************************************

That's it!  The rest is up to you.  You should have a guild home
where players can go to get away from the rest of the world.  Perhaps
a guild bulletin board and other special things.  The bottom line though,
is be imaginative!

    -Descartes of Borg 931025