
Introduction and some fast hints on the CD mudlib for LPmud 3.0
===============================================================

Welcome to the CDmudlib. This mudlib was developed for Genesis mainly by the
following people:

	Johan Andersson		(Commander)
	Carl Hallen		(Fatty)
	Jacob Hallen		(Tintin)
	Ronny Wikh		(Mrpr)
and
	Tony Elmroth		(Banzai)

There were also a lot of others that contributed in the design, among others,
Styles, Mort, Ultimate.

This mudlib was designed from scratch, with a specific intention not to care
about backwards compatibility. It is a break with the old so:

	DO NOT EXPECT YOUR OLD LPC OBJECTS TO WORK WITHOUT CHANGE

Here is a quick reference to what needs to be changed, it turns out that many
objects can be made to work with only minor adjustments.

General
-------

- All objects MUST inherit "/std/object". They will be unusable if they do not.
- All standard stuff, when cloned, should be configured with 'set_' functions.
- Errors are logged in the file 'log/errors' in your home directory.
- The long() lfun now returns a string it does not do a write.
- move_object() will only move this_object(), if you want to move an object
  you do: ob->move(destination);
- command() does not take a second argument, you do: player->command(cmd);
- You need to look through all your say() and tell_room() to make them use
  'reciever dependant messages', see "/doc/man/general/meet_people" and the set
  of usefull macros in "/sys/macros.h"
- The 'reset(0|1)' has been changed into create() and reset()
- first_inventory() and next_inventory() has been replaced with
  all_inventory() and inventory(ob,num)

- The directory structure has changed. All Wizard files are under /d,
  the mudlib standard source are under /std, /cmd, /sys and /secure
  For more docs, see /DIR_DOCS
- All paths given and returned to efuns should have a leading '/'
- Home directories are under /d, nothing is under /players anymore.
- You can not use objects under /open and /ftp. You can create your own subdir
  "open" in your homedirectory. This will be readable by all.

- All your commands is displayed with the 'allcmd' command.
- Use the commands: 'info', 'help' and 'man' for more documentation.


Reset / Create
--------------

There is two important changes to reset. When objects are loaded/cloned it
is NOT reset, but create, that gets called and without argument. So instead of
calling reset(0) for construct and reset(1) for resetting, create() is called
for construct and reset() is called for resetting.

The reset/create scheme in CDmudlib is somewhat complex, but fairly straight
forward. Basically, if you inherit something under /std you should not have two
functions called 'create' and 'reset', they should be called 'create_something'
and 'reset_something', where something is what you inherit, examples:

	inherit "/std/room";     create_room() { ....
	inherit "/std/object";   create_object() { ....
	inherit "/std/weapon";   create_weapon() { ....
			..... etc ....

And likewise with reset_(). You need not worry about any ::create() this is
all taken care of. You do only what YOU need to do.

NOTE again, you will probably use only 'create_something' in 90% of
your objects.

Rooms
-----

- Rooms should inherit "/std/room". The create is called 'create_room'
- Common functions:  set_short("short desc"), set_long("long desc") and
  add_exit("/roompath","dir",0); Do: 'man add_exit' for docs on 3 param.
- Instead of affect_environment there is now: add_my_desc() which can be
  called without having an object in the room doing the call. The description
  will remain as long as the object is not destructed, wherever the object
  is located.


Objects
-------

- You MUST inherit "/std/object", the create is called 'create_object'
- You need to change your 'create' routine as above
- There is no special lfuns like 'get', 'drop', 'can_put_and_get' instead
  properties are used, see "/sys/stdproperties.h", among these are
  OBJ_M_NO_DROP and OBJ_M_NO_GET.
- There is a lot of features in /std/object that you CAN use. You do not
  have to though. You can define your own short(), id(), long() etc and
  they will work fairly well. Player commands like 'get all the blue ones' will
  however not work well with your object in this case.


Weapons
-------

- Weapons will not work in combat unless they inherit "/std/weapon"
  For more docs see 'weapon'

Armour
------

- Armours will not work in combat unless they inherit "/std/armour"
  For more docs see 'armour'

Features
--------

- There is a VERY powerful feature called 'value by function call'. Almost
  all the set_ functions in the standard objects can take a special value on
  the form "@@functionname". Examples:

	set_long("@@my_longfunc");
	add_exit("@@current_room_north","north",0);

  What happens is that everytime the value is used, for set_long() this is 
  when you call long(), instead of returning the value directly, the value
  is interpreted as a function name and that function is called. What the
  function returns will be the actual return value from, in this example, 
  long(). This is a general method to let things 'change on the fly'.

  You can have functions called in other objects too, do 'man check_call'

- Messages given by say() and tell_room() are receiver dependant. This means
  that a function 'catch_msg' is called for each living that is to receive
  the message.

  This is used to implement 'nonmet' players. This feature combined with
  'value by function call' gives you the possibility to let different
  players get different messages depending on their status.

  One example of use is to implement languages for the races. You could make
  a player only understand what a player of the same race says.

- There is a security system. This means that your objects now have the
  exact same rights that you yourself have. If you have write access somewhere
  then all your objects do to, whether you are logged in or not.

  There are some special considerations concerning the security system if you
  intend to make wiztools usable, and clonable, by other wizards. What it
  comes down to is that they have to use the command 'trust object' on your
  tool after they cloned it, unless they make a small object of their own that
  inherits your object.
