The Merentha MUDlib
Documentation and reference material for the Merentha MUDlib, the base library of objects, daemons, and systems that the game is built on. The full MUDlib archive is available as LIB.TGZ.
About the Merentha MUDlib
The Merentha MUDlib was developed for many reasons. In the end it became an academic exercise for myself. As time went on the reasons for creating the lib and what became the Merentha II MUD changed, as did the theme. The Merentha MUDlib, and Merentha II has many unique features which, at the time of this writing, are not available to my knowledge in other MUDlibs. Starting with v0.9.3 special combat and magic rounds were added. By using these combat rounds instead of creating all the special combat skills in commands you allow the possibility of targets to see an attack coming and the chance for them to dodge it. Starting with v1.2.0 the class system was changed. It is now possible to configure your MUD in such a way as to allow classes, no classes, or multi-classing. In fact by default the MUDlib is set up to supply all these options.
License Agreement
Merentha Lib (v1.2.0-A)
Copyright (c) 2002 Peter Sadlon
The following agreement applies to the Merentha Mudlib version 1.2.0 only.
Other versions of the lib will not be bound by this agreement, but by
their own agreement.
All code in the Merentha Lib is intellectual property of Peter Sadlon.
Use of the code is acceptance of the following licensing agreement.
Terms of the Agreement:
1) The Merentha Lib can not be used for profit. You can however request
from players donations to keep the costs of your game in check.
You can not require payment of any type if any of the code included
with this agreement is used in your MUD or application.
2) The Merentha Lib and version numbers must be displayed as one of the
following: Merentha Lib v1.2.0, Merentha Lib, Merentha Mudlib,
Merentha v1.2.0, or other similar form depending on it use and
intention and version number.
Change of the mudlib name is governed as follows:
You may never change the name of the Mudlib by removing the name
Merentha from the name. You may alter the name to reflect your
changes, for example 'Merentha/Foo Lib' or 'Foo/Merentha Mudlib
1.0/1.2.0' or other such change, but the word 'Merentha' must be
used.
3) You are free to re-release this lib under the conditions that this file
be included and unedited. If you wish to add your own AGREEMENT to
this one include it as a separate file. All derived works, even if
a lib name change is warranted from section (2) above, must still
carry this agreement.
4) Not withstanding any of the above issues, the Merentha Lib remains
intellectual property of Peter Sadlon and he retains all copyrights.
Class System
The Merentha MUDlib allows you to customize how you wish to handle classes, if at all. There have been many discussions on how to impliment classes. Do you force a player to join a class (or profession) like mage or fighter, or do you allow them to gain and grow their own skills? And if you allow classes, what about multi-classing? The Merentha MUDlib offers all these possibilities, and it even offers the ability to use all of them at the same time. By default a player does not 'join' a class, but instead they practice and train skills. Once their skills are high enough they may become a member of a class for which their skills are good enough. For example, once you have learnt enough about the ways of magic they may be able to join as a member of the 'mage' class, but you do not need to join it. This system also allows multi-classing, since a player could in theory become members of all classes by gaining all the skills needed. Once a player is considered a member of a class they gain skill bonuses based on the skill and how many classes they are a member of. With some minor changes to the lib you could force players to choose a class at character creation, or limit the number of classes a player could join.
Combat System
This file is intended to describe the special magic and combat rounds
which exit in the Merentha Lib.
In most MUDs you will have a command for fighters called 'whirl'. This
command will have a fighter whirl and hit his enemy, usually in the same
round they typed the command. This, although it works, does not leave the
defendant any chance to escape.
The special magic and combat rounds are a way to give the target a
fighting chance. Both the special magic and combat rounds work the same
and so I will only describe how the combat rounds work, since the same is
true for magic.
First the functions:
Magic Combat
set_casting() set_special()
set_casting_damage() set_special_damage()
set_magic_casting() set_combat_special()
Now a description of how it all works. You will create a command in
/cmds/abilities/ and I've it a name, for example whirl.c. This file will
then check if the caster is able to use this command and so forth, and
from inside this file the functions set_special(), set_special_damage()
and set_combat_special() are called.
Notice that there is no set_target() function. So if you set your combat
special to hit in 3 rounds time and by that time the target has changed
you will hit your new target. Fortunalty the way the code is this
shouldn't happen, but it could. This may be upgraded in the next system
to include a set_target().
Also note that there is no set for defense or anything like that. The
reason being is that I have intentionally left this for the whirl.c
command. Though there are general formulas used for normal combat rounds
to determin hits/misses and damage it is logical to assume that these
formulas would not be used to judge hits from special combat rounds.
So now.....
Lets say in your whirl.c command you have determined that the whirl will
take 1 round to hit, do 25 points of damage. You will then add something
similar to:
message("skill", "You whirl at your target.", this_player());
this_player()->set_special(1);
this_player()->set_special_damage(25);
this_player()->set_combat_special( ({
"You hit your target.",
"You get hit with a whirl.",
this_player()->query_cap_name()+" hits his target."
}) );
Then 1 round later your 25 hp hit will occure on your target and the
messages will be displayed. You will of course want to display messages
to the target and others in the room initally like the one you displayed
before the set_special() call.
If you decide your whirl misses I would suggest still using these calls,
just set the damage to 0 instead of 25 and a default miss message will be
displayed.
I hope this helps. Magic is done the exact same way. I have placed some
examples in /cmds/abilities/ and /cmds/spells/ to show in greater detail
some ways to use these calls.
Skills System
This file describes how the skill systems works in the Merentha MUDlib. There are four (4) values associated with skills. They are your skill level, skill points, skill adjustment and skill adjustment points. Your skill level is simply the level at which your skill exists. So if your sword skill level is 25 and your knife skill level is 20 then you are better at swords then knives. Your skill points is a count of points until your skill improves to the next level. The skill daemon located at /daemon/skills.c has a function called formula() which will return the required number of points to raise a skill from its current level. Points are added via the add_skill_points() function in the living.c inheritable. However, there is also a use_skill() function. This is the function which should be used, the reason is described below. Now your skill adjustment is an adjustment on how many points are needed to raise your skill level. It is recorded as a percent. So for example if your skill adjustment is 10 for sword then however many points are needed to raise your sword skill 1 level is increased by 10%. If it is -10 then it is lowered by 10%. Skill adjustment is set for different skills based on your gender, race and class if you so chose to play a class. It is also set in character creation when you answer the profile questions. The skill adjustment points works similar to the skill points. The idea is the more a skill is used, not only the better do you get at the skill, but the easier it is for you to later learn more of that skill. This is why the use_skill() function should be used when a skill is in use. the use_skill() function will train both the skill and the adjustment value. By using this one call to the living (or player) object you can very easilly rebalance training of skills for your MUD by only editing the use_skill() function in living.c and the skills daemon instead of editing possibly hundreds of skills and commands. Like the skill points calculation, the skill adjusment point calculation is done in the skills daemon. By default the player's level is taken into effect when calculating the adjustment value of a skill. This is done so that as you advance in the game you must continually use a skill to keep current in its approvement value. By doing it this way skills which are used often not only increase quickly in level, but the adjustment value lowers, making future learning easier. Skills not used become harder to learn as time goes on, just like in reality. The reason I mention this is that if you wish to turn the Merentha Lib into a levelless MUD this calculation will need to change. By default levels in the Merentha Lib exist to give a standing amongst players. Players will advance automaticlly through levels and they do not cost money or experience points. I would recommend you not try to remove the levels from the game, but rather hide this information from players if your wish is a levelless MUD.
Miscellaneous Notes
Merentha InterMUD System (MIS) v1.2.0-A By default the MIS is turned off. You can turn it on by copying /save/daemons/network.old to /save/daemons/network.o and rebooting your MUD. MIS is designed to connect all Merentha MudLib MUDs together. It uses UDP datagram sockets, extreamly similar to I2 (InterMUD2). In fact with minor modifications the new network daemon can be converted to use with I2 instead of MIS. There are several reasons why I chose to create MIS instead of just connecting the Merentha Lib to I2 (or I3). o I have no experience with I3 o There is lots of spam on I2 already o This is a learning project for myself above all else o MIS is designed to promote and further develop the Mer Lib All things considered I learn't more by attempting to create my own InterMUD System then just hooking up to an existing one. By default the UDP port is your MUDport +6 (I2 uses +8). Since encoding of information on I2 is different then on MIS I have used a seperate port, this also enables people to incorperate both InterMUDs if they wish. I do not know what I3 uses. It should be noted that in reality both I2 and MIS could interact on port +8 together and have your daemons decode which is which, but I didn't want that. Compatibility MIS should work with all versions of the Mer Lib. It should also work with just about any other LPC lib out there, however, you will need to write your own commands to access the network daemon and MIS.
Known Bugs
An oversight prevents proper use of the MIS. You will need to edit 2
lines in /daemon/network.c as follows:
varargs void read_callback(int s, mixed message) {
change to
varargs void read_callback(int s, mixed message, string host) {
AND
if(junk=="0.0.0.0") junk=="127.0.0.1";
change to
if(junk=="0.0.0.0") sscanf(host, "%s %s", junk, args);
Once you do this replace /save/daemons/network.o with network.old and then
update /daemon/network.c
You ust also make sure that the port your MIS is assigned to is not used
by another serivce on your machine. The port number is defined in
/include/network.h as +6 (your MUD's port number, +6, so if your mud is on
port 4444 your MIS will be on port 4450)
TODO List
This file includes a few lists of things I plan to do in the future releases and will give some of you an idea of where development still needs to be done, or where I plan on taking future releases of the lib. For those using the current release you will see where there are some holes you may wish to plug. ---------------------------------------------------------------------- TODO - create smell and listen commands - create banks - move get_living_contents() and get_nonliving_contents() from container.c to room.c - create similar get_living_contents() and get_nonliving_contents() for storage containers in the case they will be used. - create a bag.c inheritable - create autoload system - update death - currently: death moves user to setter - TODO: make death penalties, etc - remember combat... currently, leave and reenter room stops combat - create day/night and put eyesight into use
Version History
You should always download the latest version of the MUDlib. Older
versions exist here really for no real reason unless you like to punish
yourself. Version0.1 exists for anyone wishing to create a MUD from
scratch. It has the basics to get started and a few other little odds and
ends.
So unless you really want to do everything youself I'd suggest getting the
newest version since it will contain bug fixes of previous versions and
usually more features/improvements.
_Petrarch
===========================================================================
The last version of the MUDliv to be released under the original agreement
was 0.9.3. The next version was 1.2.0-A. This new version came with a
new user agreement so be sure to read it and follow it.
===========================================================================
Merentha Lib - Current Version - 1.2.0-A
Additions
- Added ability to go linkdead, and return and override interactive chars
- Added history command and ! history abilities
- Added brief and verbose movement commands (via setenv)
- Include files:
- math.h, skills.h
- Added inheritables:
- daemon.c
- Added sefuns:
- numbers.c: ordinal(), formal_number()
- math.c: min(), max()
- Added admin commands:
- call, inheritlist, dumpallobj, functionprofile
- getconfig, memoryinfo, mudstatus, usage, cachestats, callouts
- events
- gauge
- Added player commands:
- emote
- Added daemons
- events.c
- Added new skills, new skill categories
- Added lots of help files
Bug Fixes
- Fixed a formatting bug in the man daemon
- Fixed a bug in identify() sefun
Upgrades
- cleanup.c
- plural() sefun
Changes
- reboot daemon
- skills have been renamed abilities (not the command but the actions)
- Inheritables now have a "file.h" file included in the
/std/inheritables/ directory. This was done for the sole purpose of now
having a file which contains pretty much every lfun in an object so new
coders could more easilly see what is available.
- I changed the structure of the /doc/ directory to clean it up a bit
more. Concequently the /daemon/man.c file was updated.
- The max string length causes some problems with really large directory
listings. I have hence divided up a directory listing into may output
lines, but now it will not be possible to 'more' though it. It would need
to be recoded.
- A new direcotry for commands /cmds/actions/ has been created and
non-admin actions put in there, and all commands (help/man etc) updated
- I got rid of the skill maxes and added skill adjustment values. This
allows you to set the rate at which the cost of a skill changes as the
game progresses for a single individual. The skills daemon and the new
setter login sequence makes use of this setting those values based on
choices you make.
- race, gender, class and character history all effect the adjustment
value of skills
===========================================================================
Merentha Lib - Old Version Docs - 0.9.3
Driver Upgraded to MudOS 22.2b12
- modified some files to be compatable (variable names)
- /daemons/skills.c
- /std/inheritables/monster.c
Bug Fixes
- MIS should now work out of the box
- fixed the commandHook() functions in living/user/monster inheritables
- a few minor bugs in the special combat and magic round code
- fixed a bug in determining query_current_attacker()
- fixed a bug in border() sefun
- fixed a few bugs in money
- fixed the way non_living items are displayed in the room
- update the plural() and consolidate() sefuns
Additions
- Lfun documentation is finally done
- Enter/exit messages for moving players
- Gave monsters a modified version of move_player()
- Updated the special and magical combat round features
- Added a few more lfuns mostly to identify objects
- Added a few lfuns in living.c for his/her him/her his/hers he/she
- Added __BORDER_LINE__ to the border() sefun.
- Added the exp for killing code in ADVANCE_D
- Added the death code
- Added money objects
- Added right_align() sefun
- Added Admin command: eval
- Added sample skill and spell commands
- Added commands: drop, get, give
Notes
Though there is some support for multiple currencies the mudlib is still
really based around a single currency being used, gold coins.
I added a spell and a skill in this release so you can see how to use the
special magic and combat rounds in battle. They allow you to incorperate
damage into normal damage rounds instead of having the damage happen right
away (like on most MUDS), thus allowing the other combatant a chance to
dodge the attack.
If your host machine is not hooked up to the Internet the network demon
may cause your MUD to crash. To fix delete the /save/daemons/network.o
file and it should run fine.
Read the TODO file for info on what I still feel needs work, its a good
place to start.
===========================================================================
Merentha Lib - Old Version Docs - 0.9.1
Bug Fixes
- fixed help/more bug
- fixed man with respect to the same bug
Additions
- network daemon for Merentha InterMUD System
- finger daemon for finger command
- chat daemon for global channels
- new commands : finger, finger @, users @, muds,
tell, intermer, setenv
Updates
- updated most player commands for fixed screen width
- update /sefun/strings.c for a few wraping features
The lfun documentation is still missing because I haven't writen them yet.
===========================================================================
Merentha Lib - Old Version Docs - 0.9pre(a)
I have released this version without the a stats/skill training daemon,
everything else is here to get a MUD up and working. This is because I am
rather busy at the moment and don't have the time to update the mudlib to
included these features. You will still need a better then novice
understanding of LPC to get this lib up and running since skill/stat/level
and exp advancing and death are still missing.
Features include:
- 6 races with limbs, eyesight, stats (including weight, carring etc)
- 4 classes
- self updating help system
- asci colours
- single currency economy
- supply shops
- food/drink vendors
- self healing
- armour/weapons
- combat
- man system for functions
- socials
Still missing
- quests
- skills/stats/exp/level training
- death
Most things are realitivly basic still to allow the maximum amout of
customizability. This lib can quite easilly be changed to a
classless/leveless system. Further development of this lib will be in
that general direction.
This is the recommended version to download. Newer versions will not
contain much more in the way of basics. As well, changes to further
versions will be of such size that for the most part new libs will not be
compatable with older ones.
The simplicity of this lib allows easy learning and expanding.
===========================================================================
Merentha Lib - Old Version Docs - 0.7a
ADDITIONS - food/drink
- healing
- monsters (NPCs)
- weapons
- armour
- more player commands
- more admin commands
- money (only gold)
- shops/bars/restaurants
STILL LACKING - lfun documentation
- man system similar to help system
- combat
- exp points
- skill/stats training
- quests
- multiple currency money (only gold currently)
BUG FIXES - a bug in the center() sefun fixed
KNOWN BUGS - If upgrading from an older version of this some new variables
may not upgrade properly. It is a good idea to delete all
characters if upgrading.
- more/help still break each other sometimes
- linkdeath leaves active characters
Lib Recommendations:
This is the last version which will be released under the lighter user
agreement (see /doc/AGREEMENT). It includes the basics of a mudlib, minus
any sort of combat system. People new to building a MUD should wait for
the next release which will have more built in features including
combat. Also there are still many 'little lib errors' which need to be
fixed by someone who knows what they are doing so this version isn't good
for beginners. The major additions here over the previous version all
focus around more inheritable objects and functionality with those
objects.
===========================================================================
Merentha Lib - Old Version Docs - 0.5a
ADDITIONS - ansi colours
- 6 player races
- race daemon (for players and monsters)
- limbs, eyesight, stats based on race
- 4 player classes
- player stats / stat daemon
- skill system / skill daemon
- more player commands
- more admin commands
STILL LACKING - armour
- weapons
- combat/healing
- exp points, advancement, skills/stats training
- food/drink
- NPCs (monsters)
- man system similar to the help system
- lfun documentation
BUG FIXES: - the more daemon works better
- some efuns string changed to work with colours
- bugs with movement fixed
KNOWN BUGS: - the more daemon and interactive help/man daemons sometimes
break each other
Lib Recommendations:
Without too much difficulty you can now run a community online. This lib
still lacks combat and anything to do with combat like armour and weapons.
The major additions are races/classes/stats/skills. Anyone basing
development of their own lib off of this one should take note of the limbs
in the race daemon. This lib is not designed for limb specific combat the
way the Nightmare lib was. If you want limb loss and such to occure you
will need to build your own race daemon and code it as such. Likewise
armour will effect your whole body, not just the location it is worn on.
This is a lot less 'realistic', however, it is not the intention to build
a detailed combat-realistic mudlib.
===========================================================================
Merentha Lib - Old Version Docs - 0.1a
People can log in and move around. Administrators are created by changing
their "position". This must be done from outside of the MUD and editing
the player file.
The lib includes:
a login sequence
basic player commands
basic admin commands
basic inheritables
a <more> daemon
a base 8 time system (read the /include/time.h and "help time" files)
basic sefuns
documentation for everything but lfuns
a help system
The lib is lacking:
much in the way of character and monster customizations
a man system similar to the help system for documentation
areas
security/different admin levels
Lib recommendations:
This is a good starting place for people wishing to create their own
lib. It has the basics needed and a few extras. Unless you are
familiar with LPC and lib work you will have a difficult time
customizing things. Specifically the user object inheritable. The lack
of work on the user object is also an advantage since there is not much
to change to create the theme you wish (fantasy, real world, etc)
===========================================================================
Merentha Lib - History
Merentha was a MUD which was based on the Nightmare Mudlib 3.3. Over time
Merentha grew to be one of the most popular Nightmare based MUDs of all
time.
It was the wish of the administrators to create their own lib many times
through the life of Merentha. However, Merentha became so large and
complex that any changes would be superficial, and judged too much work
for such little over all gain.
The Merentha Lib was developed as a technical challenge and not for use
with Merentha itself. Since 95% of the MUDlib knowledge was gained from
use of editions to the Nightmare Lib there are some similarities between
the Merentha Lib and the Nightmare Lib such as names of sefuns, lfuns and
so on, however, all code is original.
Anyone familuar with the Nightmare Lib should not assume things run the
same here as they did there. There are a lot of difference dispite the
simularities.
Local Options Reference
/*
* options.h: defines for the compile-time configuration of the MudOS driver
*/
#ifndef _OPTIONS_H_
#define _OPTIONS_H_
/****************************************************************************
* EVERY time you change ANYTHING in this file, RECOMPILE from scratch. *
* (type "make clean" then "make" on a UNIX system) Failure to do so may *
* cause the driver to behave oddly. *
****************************************************************************/
/* NOTES:
* Many of the configurable options are now set via the configuration file
* that is specified as the first argument to the driver.
* See port.h for those #defines related to portability (compatibility) if
* you have problems compiling on your system.
* Removing an efun from func_spec.c usually removes most, if not all,
* of the code associated with it.
* Note that anything defined in this file is also visible to LPC files
* surrounded by __. So #define FOO in this file defines __FOO__ for
* all LPC files. This allows code like:
*
* #ifdef __SENSIBLE_MODIFIERS__
* ...
*/
/****************************************************************************
* MALLOC *
* -------- *
* For performance reasons, LP drivers have a variety of memory allocation *
* packages. If you don't care, use the default one on your system: *
* #define SYSMALLOC, #undef the others. *
****************************************************************************/
/* You must choose exactly one of these malloc packages:
* ~~~~
* SYSMALLOC:
* * Built-in system malloc.
* * No statistics.
* * SYSMALLOC incurs no additional CPU or memory overhead.
*
* SMALLOC:
* * Satoria's smalloc.
* * Statistics available. (see wrappers and DO_MSTATS)
* * Faster than most system mallocs with modest ammount of memory overhead.
* * Can fall back onto system malloc if sbrk() not ok.
*
* BSDMALLOC:
* * BSD (Berkeley Software Distributions) malloc.
* * Statistics available. (see wrappers and DO_MSTATS)
* * Faster than SMALLOC but more memory overhead.
* * Requires sbrk().
*/
#define SYSMALLOC
#undef SMALLOC
#undef BSDMALLOC
/* You may optionally choose one (or none) of these malloc wrappers. These
* can be used in conjunction with any of the above malloc packages.
*
* WRAPPEDMALLOC:
* * Limited statistics.
* * Limited additional cpu overhead and no additional memory overhead.
*
* DEBUGMALLOC:
* * Statistics on precisely how much memory has been malloc'd (as well
* as the stats provided by WRAPPEDMALLOC).
* * Incurs a fair amount of overhead (both memory and CPU)
*/
#undef WRAPPEDMALLOC
#undef DEBUGMALLOC
/* The following add certain bells and whistles to malloc: */
/*
* SBRK_OK: do not define this unless SMALLOC is chosen above.
* Defining this causes smalloc to use the low level memory allocation
* routines, and to act as a malloc replacement. Conversely, undef'ing
* SBRK_OK causes smalloc to act as a wrapper for the system malloc
* routines.
*
* Note:
* NeXTStep 3.x users should always #undef SBRK_OK.
*/
#undef SBRK_OK
/* DO_MSTATS: do not define this unless BSDMALLOC or SMALLOC is chosen above.
* Defining this causes those replacement mallocs to keep statistics that
* the malloc_status() efun will print out (including total memory
* allocated/used).
*/
#undef DO_MSTATS
/* DEBUGMALLOC_EXTENSIONS: defining this (in addition to DEBUGMALLOC) enables
* the set_malloc_mask(int) and debugmalloc(string,int) efuns. These two
* efuns basically allow you to cause certain malloc's and free's (with tags
* selected by a specified mask) to print debug information (addr, tag,
* description, size) to stdio (in the shell that invoked the driver) or to a
* file. Not defining this does reduce the overhead of DEBUGMALLOC from 16
* bytes per malloc down to 8. This macro has no effect if DEBUGMALLOC isn't
* defined.
*/
#undef DEBUGMALLOC_EXTENSIONS
/* CHECK_MEMORY: defining this (in addition to DEBUGMALLOC and
* DEBUGMALLOC_EXTENSIONS) causes the driver to check for memory
* corruption due to writing before the start or end of a block. This
* also adds the check_memory() efun. Takes a considerable ammount
* more memory. Mainly for debugging.
*/
#undef CHECK_MEMORY
/****************************************************************************
* COMPATIBILITY *
* --------------- *
* The MudOS driver has evolved quite a bit over the years. These defines *
* are mainly to preserve old behavior in case people didn't want to *
* rewrite the relevant portions of their code. *
* *
* In most cases, code which needs these defines should be rewritten when *
* possible. The 'Compat status' field is designed to give an idea how *
* likely it is that support for that option will be removed in the near *
* future. Certain options are fairly easy to work around, and double *
* the size of the associated code, as well as the maintenance workload, *
* and can make the code significantly more complex or harder to read, so *
* supporting them indefinitely is impractical. *
* *
* WARNING: If you are using software designed to run with the MudOS driver *
* it may assume certain settings of these options. Check the *
* instructions for details. *
****************************************************************************/
/* HAS_STATUS_TYPE: old MudOS drivers had a 'status' type which was
* identical to the 'int' type. Define this to bring it back.
*
* Compat status: very archaic, but easy to support.
*/
#undef HAS_STATUS_TYPE
/* explode():
*
* The old behavior (#undef both of the below) strips any number of
* delimiters at the start of the string, and one at the end. So
* explode("..x.y..z..", ".") gives ({ "x", "y", "", "z", "" })
*
* SANE_EXPLODE_STRING strips off at most one leading delimiter, and
* still strips off one at the end, so the example above gives
* ({ "", "x", "y", "", "z", "" }).
*
* REVERSIBLE_EXPLODE_STRING overrides SANE_EXPLODE_STRING, and makes
* it so that implode(explode(x, y), y) is always x; i.e. no delimiters
* are ever stripped. So the example above gives
* ({ "", "", "x", "y", "", "z", "", "" }).
*/
#undef SANE_EXPLODE_STRING
#undef REVERSIBLE_EXPLODE_STRING
/* CAST_CALL_OTHERS: define this if you want to require casting of call_other's;
* this was the default behavior of the driver prior to this addition.
*
* Compat status: code that requires it doesn't break, and it promotes
* sloppy coding with no benefits.
*/
#undef CAST_CALL_OTHERS
/* NONINTERACTIVE_STDERR_WRITE: if defined, all writes/tells/etc to
* noninteractive objects will be written to stderr prefixed with a ']'
* (old behavior).
*
* Compat status: Easy to support, and also on the "It's a bug! No, it's
* a feature!" religious war list.
*/
#undef NONINTERACTIVE_STDERR_WRITE
/* NO_LIGHT: define this to disable the set_light() and driver maintenance
* of light levels in objects. You can simulate it via LPC if you want...
*
* Compat status: Very dated, easy to simulate, and gross.
*/
#define NO_LIGHT
/* NO_ADD_ACTION: define this to remove add_action, commands, livings, etc.
* process_input() then becomes the only way to deal with player input.
*
* Compat status: next to impossible to simulate, hard to replace, and
* very, very widely used.
*/
#undef NO_ADD_ACTION
/* NO_SNOOP: disables the snoop() efun and all related functionality.
*/
#define NO_SNOOP
/* NO_ENVIRONMENT: define this to remove the handling of object containment
* relationships by the driver
*
* Compat status: hard to simulate efficiently, and very widely used.
*/
#undef NO_ENVIRONMENT
/* NO_WIZARDS: for historical reasons, MudOS used to keep track of who
* is and isn't a wizard. Defining this removes that completely.
* If this is defined, the wizardp() and related efuns don't exist.
*
* Also note that if it is not defined, then non-wizards are always put
* in restricted mode when ed() is used, regardless of the setting of
* the restrict parameter.
*
* Compat status: easy to simulate and dated.
*/
#define NO_WIZARDS
/* OLD_TYPE_BEHAVIOR: reintroduces a bug in type-checking that effectively
* renders compile time type checking useless. For backwards compatibility.
*
* Compat status: dealing with all the resulting compile errors can be
* a huge pain even if they are correct, and the impact on the code is
* small.
*/
#define OLD_TYPE_BEHAVIOR
/* OLD_RANGE_BEHAVIOR: define this if you want negative indexes in string
* or buffer range values (not lvalue, i.e. x[-2..-1]; for e.g. not
* x[-2..-1] = foo, the latter is always illegal) to mean counting from the
* end
*
* Compat status: Not horribly difficult to replace reliance on this, but not
* trivial, and cannot be simulated.
*/
#undef OLD_RANGE_BEHAVIOR
/* OLD_ED: ed() efun backwards compatible with the old version. The new
* version requires/allows a mudlib front end.
*
* Compat status: Easily simulated.
*/
#define OLD_ED
/* SENSIBLE_MODIFIERS:
* Turning this on changes a few things, which may break old code:
*
* (1) 'static' is not recognized; either 'nosave' or 'protected' must
* be used instead.
* (2) The old meaning of 'public' is no longer allowed. Explicit
* functions must be defined at each level to allow access to
* privately inherited functions.
* (3) 'public' now means the default visibility. Previously there was
* no keyword that meant this (before you ask, 'public' meant something
* else, and if you don't know that, you probably don't have any reason
* to care about the old meaning).
*/
#undef SENSIBLE_MODIFIERS
/****************************************************************************
* MISCELLANEOUS *
* --------------- *
* Various options that affect the way the driver behaves. *
* *
* WARNING: If you are using software designed to run with the MudOS driver *
* it may assume certain settings of these options. Check the *
* instructions for details. *
****************************************************************************/
/*
* Define this in order to use Fermat@Equilibria's MD5 based crypt() instead
* of the operating system's. It has the advantage of giving the same value
* on all architectures, and being stronger than the standard UNIX crypt().
*/
#undef CUSTOM_CRYPT
/*
* Some minor tweaks that make it a bit easier to run code designed to run
* on LPmud 3.2/3.2.1. Currently has the following effects:
*
* . m_indices() and m_values() are synonyms for keys() and values(),
* respectively
* . map_delete() returns it's first argument
* . inherit_list() means deep_inherit_list(), not shallow_inherit_list()
* . heart_beat_info() is a synonym for heart_beats()
*/
#undef COMPAT_32
/*
* Keep statistics about allocated strings, etc. Which can be viewed with
* the mud_status() efun. If this is off, mud_status() and memory_info()
* ignore allocated strings, but string operations run faster.
*/
#define STRING_STATS
/*
* Similarly for arrays ...
*/
#define ARRAY_STATS
/* LOG_CATCHES: define this to cause errors that are catch()'d to be
* sent to the debug log anyway.
*
* On by default, because newer libs use catch() a lot, and it's confusing
* if the errors don't show up in the logs.
*/
#define LOG_CATCHES
/* ARGUMENTS_IN_TRACEBACK: prints out function call arguments in error
* tracebacks, to aid in debugging. Note: it prints the values of
* the arguments at the time of the error, not when the function
* was called. It looks like this:
*
* Failed to load file: read_buffer
* program: command/update.c, object: command/update line 15
* ' commandHook' in ' clone/user.c' (' clone/user#1')line 72
* arguments were ("/read_buffer.c")
* ' main' in ' command/update.c' (' command/update')line 15
* arguments were ("/read_buffer.c")
*
* The only down side is some people like their logs shorter
*/
#define ARGUMENTS_IN_TRACEBACK
/* LOCALS_IN_TRACEBACK: similar to ARGUMENTS_IN_TRACEBACK, but for local
* variables. The output looks more or less like:
*
* locals: 1, "local_value"
*
* Same as above. Tends to produce even longer logs, but very useful for
* tracking errors.
*/
#define LOCALS_IN_TRACEBACK
/* MUDLIB_ERROR_HANDLER: If you define this, the driver doesn't do any
* handling of runtime errors, other than to turn the heartbeats of
* objects off. Information about the error is passed in a mapping
* to the error_handler() function in the master object. Whatever is
* returned is put in the debug.log.
*
* A good mudlib error handler is one of the best tools for tracking down
* errors. Unfortunately, you need to have one. Check the testsuite or
* other libs for an example.
*/
#define MUDLIB_ERROR_HANDLER
/* CONFIG_FILE_DIR specifies a directory in which the driver will search for
* config files by default. If you don't wish to use this define, you may
* always specify a full path to the config file when starting the driver.
*/
#ifndef LATTICE
#define CONFIG_FILE_DIR "/u/tim/COMP/bin"
#else
#define CONFIG_FILE_DIR "etc:"
#endif
/* DEFAULT_PRAGMAS: This should be a sum of pragmas you want to always
* be on, i.e.
*
* #define DEFAULT_PRAGMAS PRAGMA_STRICT_TYPES + PRAGMA_SAVE_TYPES
*
* will make every LPC file behave as if it had the lines:
* #pragma strict_types
* #pragma save_types
*
* for no default pragmas:
* #define DEFAULT_PRAGMAS 0
*
* If you don't know what these are, 0 is a good choice.
*
* Supported pragmas:
* PRAGMA_STRICT_TYPES: enforces strict type checking
* PRAGMA_WARNINGS: issues warnings about various dangerous things in
* your code
* PRAGMA_SAVE_TYPES: save the types of function arguments for checking
* calls to functions in this object by objects that
* inherit it.
* PRAGMA_SAVE_BINARY: save a compiled binary version of this file for
* faster loading next time it is needed.
* PRAGMA_OPTIMIZE: make a second pass over the generated code to
* optimize it further. Currently does jump threading.
* PRAGMA_ERROR_CONTEXT:include some text telling where on the line a
* compilation error occured.
*/
#define DEFAULT_PRAGMAS 0
/* supress warnings about unused arguments; only warn about unused local
* variables. Makes older code (where argument names were required) compile
* more quietly.
*/
#define SUPPRESS_ARGUMENT_WARNINGS
/* NO_RESETS: completely disable the periodic calling of reset() */
#undef NO_RESETS
/* LAZY_RESETS: if this is defined, an object will only have reset()
* called in it when it is touched via call_other() or move_object()
* (assuming enough time has passed since the last reset). If LAZY_RESETS
* is #undef'd, then reset() will be called as always (which guaranteed that
* reset would always be called at least once). The advantage of lazy
* resets is that reset doesn't get called in an object that is touched
* once and never again (which can save memory since some objects won't get
* reloaded that otherwise would).
*/
#define LAZY_RESETS
/* SAVE_EXTENSION: defines the file extension used by save_object().
* and restore_object(). Some sysadmins run scripts that periodically
* scan for and remove files ending in .o (but many mudlibs are already
* set up to use .o thus we leave .o as the default).
*/
#define SAVE_EXTENSION ".o"
/* NO_ANSI: define if you wish to disallow users from typing in commands that
* contain ANSI escape sequences. Defining NO_ANSI causes all escapes
* (ASCII 27) to be replaced with a space ' ' before the string is passed
* to the action routines added with add_action.
*
* STRIP_BEFORE_PROCESS_INPUT allows the location where the stripping is
* done to be controlled. If it is defined, then process_input() doesn't
* see ANSI characters either; if it is undefined ESC chars can be processed
* by process_input(), but are stripped before add_actions are called.
* Note that if NO_ADD_ACTION is defined, then #define NO_ANSI without
* #define STRIP_BEFORE_PROCESS_INPUT is the same as #undef NO_ANSI.
*
* If you anticipate problems with users intentionally typing in ANSI codes
* to make your terminal flash, etc define this.
*/
#define NO_ANSI
#define STRIP_BEFORE_PROCESS_INPUT
/* OPCPROF: define this if you wish to enable OPC profiling. Allows a dump
* of the # of times each efun is invoked (via the opcprof() efun).
*/
#define OPCPROF
/* OPCPROF_2D: define this if you wish to enable 2-D OPC profiling. Allows a
* dump of the # of times each *pair* of eoperators is invoked.
*
* You can't use this and OPCPROF at the same time.
*/
#undef OPCPROF_2D
/* TRAP_CRASHES: define this if you want MudOS to call crash() in master.c
* and then shutdown when signals are received that would normally crash the
* driver.
*/
#define TRAP_CRASHES
/* THIS_PLAYER_IN_CALL_OUT: define this if you wish this_player() to be
* usable from within call_out() callbacks.
*/
#undef THIS_PLAYER_IN_CALL_OUT
/* CALLOUT_HANDLES: If this is defined, call_out() returns an integer, which
* can be passed to remove_call_out() or find_call_out(). Removing call_outs
* by name is still allowed, but is significantly less efficient, and also
* doesn't work for function pointers. This option adds 4 bytes overhead
* per callout to keep track of the handle.
*/
#undef CALLOUT_HANDLES
/* FLUSH_OUTPUT_IMMEDIATELY: Causes output to be written to sockets
* immediately after being generated. Useful for debugging.
*/
#undef FLUSH_OUTPUT_IMMEDIATELY
/* PRIVS: define this if you want object privileges. Your mudlib must
* explicitly make use of this functionality to be useful. Defining this
* this will increase the size of the object structure by 4 bytes (8 bytes
* on the DEC Alpha) and will add a new master apply during object creation
* to "privs_file". In general, privileges can be used to increase the
* granularity of security beyond the current root uid mechanism.
*
* [NOTE: for those who'd rather do such things at the mudlib level, look at
* the inherits() efun and the 'valid_object' apply to master.]
*/
#undef PRIVS
/* INTERACTIVE_CATCH_TELL: define this if you want catch_tell called on
* interactives as well as NPCs. If this is defined, user.c will need a
* catch_tell(msg) method that calls receive(msg);
*/
#define INTERACTIVE_CATCH_TELL
/* RESTRICTED_ED: define this if you want restricted ed mode enabled.
*/
#define RESTRICTED_ED
/* NO_SHADOWS: define this if you want to disable shadows in your driver.
*/
#define NO_SHADOWS
/* SNOOP_SHADOWED: define this if you want snoop to report what is
* sent to the player even in the event that the player's catch_tell() is
* shadowed and the player may not be seeing what is being sent. Messages
* of this sort will be prefixed with $$.
*/
#undef SNOOP_SHADOWED
/* RECEIVE_SNOOP: define this if you want snoop text to be sent to
* the receive_snoop() function in the snooper object (instead of being
* sent directly via add_message()). This is useful if you want to
* build a smart client that does something different with snoop messages.
*/
#undef RECEIVE_SNOOP
/* PROFILE_FUNCTIONS: define this to be able to measure the CPU time used by
* all of the user-defined functions in each LPC object. Note: defining
* this adds three long ints (12 bytes on 32-bit machines) to the function
* header structs. Also note that the resolution of the getrusage() timer
* may not be high enough on some machines to give non-zero execution
* times to very small (fast) functions. In particular if the clock
* resolution is 1/60 of a second, then any time less than approxmately 15k
* microseconds will resolve to zero (0).
*/
#define PROFILE_FUNCTIONS
/* NO_BUFFER_TYPE: if this is #define'd then LPC code using the 'buffer'
* type won't be allowed to compile (since the 'buffer' type won't be
* recognized by the lexer).
*/
#undef NO_BUFFER_TYPE
/* BINARIES: define this to enable the 'save_binary' pragma.
* This pragma, when set in a program, will cause it to save a
* binary image when loaded, so that subsequent loadings will
* be much faster. The binaries are saved in the directory
* specified in the configuration file. The binaries will not
* load if the LPC source or any of the inherited or included
* files are out of date, in which case the file is compiled
* normally (and may save a new binary).
*
* In order to save the binary, valid_save_binary() is called
* in master.c, and is passed the name of the source file. If
* this returns a non-zero value, the binary is allowed to be
* saved. Allowing any file by any wizard to be saved as a
* binary is convenient, but may take up a lot of disk space.
*/
#define BINARIES
/* ARRAY_RESERVED_WORD: If this is defined then the word 'array' can
* be used to define arrays, as in:
*
* int array x = ({ .... });
*
* A side effect is that 'array' cannot be a variable or function name.
*/
#undef ARRAY_RESERVED_WORD
/* REF_RESERVED_WORD: If this is defined then the word 'ref' can be
* used to pass arguments to functions by value. Example:
*
* void inc(int ref x) {
* x++;
* }
*
* ... y = 1; inc(ref y); ...
*
* A side effect is that 'ref' cannot be a variable or function name.
*
* Note: ref must be used in *both* places; this is intentional. It protects
* against passing references to routines which don't intend to return values
* through their arguments, and against forgetting to pass a reference
* to a function which wants one (or accidentally having a variable modified!)
*/
#undef REF_RESERVED_WORD
/****************************************************************************
* PACKAGES *
* -------- *
* Defining some/all of the following add certain efuns, and sometimes *
* add/remove code from the driver. *
* *
* if PACKAGE_XYZZY is defined here, then the code in packages/xyzzy.c *
* and the efuns in packages/xyzzy_spec.c will be added to the driver. *
****************************************************************************/
/* various miscellaneous efuns */
#define PACKAGE_CONTRIB
/* efuns that are only of use to those that know something about driver
internals */
#define PACKAGE_DEVELOP
/* PACKAGE_MATH: determines whether or not the math efuns (for floats) are
included.
*/
#define PACKAGE_MATH
/* PACKAGE_MATRIX: determines whether or not the 3d graphics efuns (for floats)
* are included - see packages/matrix.spec for a list.
*/
#undef PACKAGE_MATRIX
/* PACKAGE_MUDLIB_STATS: define this to enable domain and author stats
* maintenance by the driver. These mudlib stats are more domain
* based than user based, and replaces the traditional wiz_list stats.
*/
#undef PACKAGE_MUDLIB_STATS
/* PACKAGE_SOCKETS: define this to enable the socket efunctions. This
* causes HAS_SOCKETS to be defined for all LPC objects.
*/
#define PACKAGE_SOCKETS
/* PACKAGE_PARSER: Natural language parsing efuns for interactive fiction
* type applications
*/
#define PACKAGE_PARSER
/* PACKAGE_EXTERNAL: Allows the driver to exec() commands specified in the
* config file.
*/
#undef PACKAGE_EXTERNAL
/* NUM_EXTERNAL_CMDS: the number of external commands supported */
#ifdef PACKAGE_EXTERNAL
#define NUM_EXTERNAL_CMDS
#endif
/* PACKAGE_DB: efuns for external database access using msql */
#undef PACKAGE_DB
/* If PACKAGE_DB is defined above, you must pick ONE of the following supported
* databases
*/
#ifdef PACKAGE_DB
#define USE_MSQL 1 /* MiniSQL, it's small; it's free */
#undef USE_MYSQL 2 /* MySQL, bigger; it's free */
#define DEFAULT_DB USE_MSQL /* default database */
#endif
/****************************************************************************
* UID PACKAGE *
* ----------- *
* UIDS are the basis for some mudlib security systems. Basically, they're *
* preserved for backwards compatibility, as several ways of breaking *
* almost any system which relies on them are known. (No, it's not a flaw *
* of uids; only that b/c of the ease with which LPC objects can call *
* each other, it's far too easy to leave holes) *
* *
* If you don't care about security, the first option is probably what you *
* want. *
****************************************************************************/
/*
* PACKAGE_UIDS: define this if you want a driver that does use uids.
*
*/
#undef PACKAGE_UIDS
/* AUTO_SETEUID: when an object is created it's euid is automatically set to
* the equivalent of seteuid(getuid(this_object())). undef AUTO_SETEUID
* if you would rather have the euid of the created object be set to 0.
*/
#undef AUTO_SETEUID
/* AUTO_TRUST_BACKBONE: define this if you want objects with the backbone
* uid to automatically be trusted and to have their euid set to the uid of
* the object that forced the object's creation.
*/
#define AUTO_TRUST_BACKBONE
/*************************************************************************
* FOR EXPERIENCED USERS *
* ----------------------- *
* Most of these options will probably be of no interest to many users. *
*************************************************************************/
/* USE_32BIT_ADDRESSES: Use 32 bits for addresses of function, instead of
* the usual 16 bits. This increases the maximum program size from 64k
* of LPC bytecode (NOT source) to 4 GB. Branches are still 16 bits,
* imposing a 64k limit on catch(), if(), switch(), loops, and most other
* control structures. It would take an extremely large function to hit
* those limits, though.
*
* Overhead: 2 bytes/function with LPC->C off. Having LPC->C on forces
* this option, since it needs 4 bytes to store the function pointers
* anyway, and this setting is ignored.
*/
#define USE_32BIT_ADDRESSES
/* HEARTBEAT_INTERVAL: define heartbeat interval in microseconds (us).
* 1,000,000 us = 1 second. The value of this macro specifies
* the frequency with which the heart_beat method will be called in
* those LPC objects which have called set_heart_beat(1).
*
* [NOTE: if ualarm() isn't available, alarm() is used instead. Since
* alarm() requires its argument in units of a second, we map 1 - 1,000,000 us
* to an actual interval of one (1) second and 1,000,001 - 2,000,000 maps to
* an actual interval of two (2) seconds, etc.]
*/
#define HEARTBEAT_INTERVAL 2500000
/*
* CALLOUT_CYCLE_SIZE: This is the number of slots in the call_out list.
* It should be approximately the average number of active call_outs, or
* a few times smaller. It should also be a power of 2, and also be relatively
* prime to any common call_out lengths. If all this is too confusing, 32
* isn't a bad number :-)
*/
#define CALLOUT_CYCLE_SIZE 32
/* LARGEST_PRINTABLE_STRING: defines the size of the vsprintf() buffer in
* comm.c's add_message(). Instead of blindly making this value larger,
* your mudlib should be coded to not send huge strings to users.
*/
#define LARGEST_PRINTABLE_STRING 8192
/* MESSAGE_BUFFER_SIZE: determines the size of the buffer for output that
* is sent to users.
*/
#define MESSAGE_BUFFER_SIZE 4096
/* APPLY_CACHE_BITS: defines the number of bits to use in the call_other cache
* (in interpret.c).
*
* Memory overhead is (1 << APPLY_CACHE_BITS)*16.
* [assuming 32 bit pointers and 16 bit shorts]
*
* ACB: entries: overhead:
* 6 64 1k
* 8 256 4k
* 10 1024 16k
* 12 4096 64k
* 14 16384 256k
* 16 65536 1M
*/
#define APPLY_CACHE_BITS 12
/* CACHE_STATS: define this if you want call_other (apply_low) cache
* statistics. Causes HAS_CACHE_STATS to be defined in all LPC objects.
*/
#define CACHE_STATS
/* TRACE: define this to enable the trace() and traceprefix() efuns.
* (keeping this undefined will cause the driver to run faster).
*/
#undef TRACE
/* LPC_TO_C: define this to enable LPC->C compilation.
*
* [NOTE: BINARIES must also be defined for LPC->C to work. Actually
* using binaries is not required, though.]
*/
#define LPC_TO_C
/* RUNTIME_LOADING: On systems which support it, it allows LPC->C compilation
* 'on the fly' without having to recompile the driver.
*
* Note: This currently only works on machines that have the dlopen() system
* call. SunOS and IRIX do, as do a number of others. AIX and Ultrix don't.
* Linux does if you are using ELF. Versions of FreeBSD prior to 3.0 don't.
*/
#undef RUNTIME_LOADING
/* TRACE_CODE: define this to enable code tracing (the driver will print
* out the previous lines of code to an error) eval_instruction() runs about
* twice as fast when this is not defined (for the most common eoperators).
*/
#undef TRACE_CODE
/* HEART_BEAT_CHUNK: The number of heart_beat chunks allocated at a time.
* A large number wastes memory as some will be sitting around unused, while
* a small one wastes more CPU reallocating when it needs to grow. Default
* to a medium value.
*/
#define HEART_BEAT_CHUNK 32
/* GET_CHAR_IS_BUFFERED: Normally get_char() is unbuffered. That is, once
* a character is received for get_char(), anything else is in the input
* stream is immediately thrown away. This can be very undesirable, especially
* if you're calling get_char() again from the handler from the previous call.
* Define this if you want get_char() to be buffered. In this case, the buffer
* will only get flushed if get_char() is not called from the first get_char()'s
* LPC callback handler.
*/
#undef GET_CHAR_IS_BUFFERED
/* Some maximum string sizes
*/
#define SMALL_STRING_SIZE 100
#define LARGE_STRING_SIZE 1000
/* Number of levels of nested datastructures allowed -- this limit prevents
* crashes from occuring when saving objects containing variables containing
* recursive datastructures (with circular references).
*/
#define MAX_SAVE_SVALUE_DEPTH 25
/* Miscellaneous config options that should probably be in the runtime
* config file.
*/
/* MAX_LOCAL: maximum number of local variables allowed per LPC function */
#define CFG_MAX_LOCAL_VARIABLES 25
#define CFG_EVALUATOR_STACK_SIZE 1000
#define CFG_MAX_CALL_DEPTH 50
/* This must be one of 4, 16, 64, 256, 1024, 4096 */
#define CFG_LIVING_HASH_SIZE 256
/* NEXT_MALLOC_DEBUG: define this if using a NeXT and you want to enable
* the malloc_check() and/or malloc_debug() efuns. Run the 'man malloc_debug'
* command on the NeXT to find out what the arguments to malloc_debug(int)
* mean. The malloc_check() efun calls the NeXT NXMallocCheck() system
* call which does a consistency check on malloc's data structures (this
* consistency check is done at each malloc() and free() for certain
* malloc_debug() levels). A non-zero return value indicates there was
* a consistency problem. For those NeXT users wanting a bit more
* performance out of malloc, try defining NEXT_MALLOC_DEBUG and calling the
* malloc_debug(-1) efun (with an arg of -1). This will turn all
* malloc debugging off and call malloc_singlethreaded() which the NeXT
* malloc man page claims can make NeXT system malloc 10% to 15% faster.
*
* [NOTE: This #define has no affect on the driver if not using the
* NeXTSTEP OS.]
*
* Warning: if you use a NeXT and define NEXT_MALLOC_DEBUG, be sure to
* protect the use of the malloc_check() and malloc_debug() efuns
* since setting certain debug levels can cause malloc() and free()
* to become _very_ slow (protect efuns by using simul_efuns and
* valid_override).
*
* [NOTE: malloc_debug(6) is a good compromise between efficiency and
* completeness of malloc debugging (malloc/free will be about half as fast).]
*/
#define NEXT_MALLOC_DEBUG
#endif