***** A General Guide *****

As you may have guessed (or not) from the title OGHAM is designed around
a medieval fighting fantasy themed mud. To adapt it to a science fiction
theme would not be hard but would be time consuming.

Remember this mud is written in C not forgiving LPC. If you make a mistake
in LPC code the driver will just give an error when it tries to run the code.
If you make an error with this and it compiles you're on the way to some
interesting bugs or even a crash.

I have tried to build some rules into the mud eg strength, weapon skill etc
goes from 0 to 100, weight limits on users and objects. It is trivial to
break these rules however. For instance - users weight limits are enforced by
the get() functions but npcs have no equivilant function so it has to 
be written into their own code if they wish to get. Because of this they
could pick up anything no matter how heavy since its a simple matter of
changing a few variables. Other breaking of rules could be a monster which kills
a users as soon as he enters a room. Anything is possible but remember - if
you piss your players off by building an unfair mud you soon won't have any
players.

Omissions
---------

I have not encluded a "give" command in the mud basically because I couldn't
be bothered to write it and also because it has many problems eg If you give
to a monster or user how does he refuse? How does a monster know when he's 
been given something unless he does an active check all the time or unless 
I include yet another flag into his structure? What if the monster and the item
are incompatible? eg an evil monster and a weapon of good intent etc etc...

Another feature not built in is invisibility for users. I did not do this for
2 main reasons:
   A: Because only wizes & gods usually can use it so it adds nothing to the 
      gameplay.
   B: Checks would have to be built in to most of the user functions. eg If 
      an invisible user called Fred picked something up, the mud could not
      write "Fred gets ...." since this would blow his cover but it would 
      have to write something appropriate. This would require enormous coding
      effort for very little reward.

Snooping is not built in to main.c but this can be coded as a skill function
to be learned or given.

Following or partying is not built it. Monsters can follow users or other
monsters by coding it into their functions (see npcs/dog.c). Making users
follow other users or monsters would require a major hack of main.c but I
may add this in a future version. Ditto for partying.

The last thing not supported is corpses. When a player dies he becomes a ghost
and all his belongings are dropped in the room he is in. The reason for not 
including corpses is that they prove a problem when they decompose if someone
is carrying them but not an insurmoutable one and I may include them in a future
version. Of course you could always try it yourself...

Armour
------

I have defined 5 types of armour which can be seen in the globals.h file.
It was not strictly necessary for me to do this but it makes the game more
realistic. User store whether they are wearing certain types of armour in
ustr[].arm[NUM_ARM_TYPES]. If a user is already wearing one sort of armour
eg BODY armour then the "wear" command will not let him put on any more. 
Eg he could wear chaimail and a helmet at the same time but not chainmail
and ringmail. Npc's do not have this restriction simply because it is
impossible to enforce as npc functions can be written as you please and if
you want an npc to wear chaimail & ringmail at the same there is nothing
to stop you do the following...

obj1=clone("chainmail",WITH_OBJ);
obj2=clone("ringmail",WITH_OBJ);
check for null
obj1->obj_with=npc;  obj2->obj_with=npc;
obj1->worn_wield=1;  obj2->worn_wield=1;
npc->arm+=obj1->arm;  npc->arm+=obj2->arm; 

When a user is in a fight his total ustr[].arm[NUM_ARM_TYPES] is added up
and used as his defence. Npc's simply use the npc->arm variable.


Weapons
-------

An item can be wielded if it has damage > 0. The user must have a weapon
skill equal or greater to that of the weapon to be able to wield it.
This rule does not apply to npc's for the same reason the armour rule doesn't -
its impossible to enforce.
	The users damage in a fight is that of the weapon he is wielding else it 
is zero. The only reason that structure element exists in the user structure
is to avoid searching through all the users belongings every time the mud
wishes to find the wielded weapons damage. It is set when the user wields the
weapon and unset when he unwields it.


Passwords & clients
-------------------

My knowledge of telnet control and configure codes is limited. I have got
password blanking working but it only seems to work properly when the client
is unix client - VMS telnet buggers up (so I've been told). Unless you can 
fix this problem I suggest you set the PASSWORD_ECHO macro in globals.h to 1 
if you wish to have any VMS users and this will cause passwords to be echoed.
But lets be honest - how many people use VMS these days?
	Also any client that runs on a machine that requires carraige return
and line feed as opposed to unix's single character newline and doesn't do
any conversion (NCSA telnet on the mac for example) will produce a messy
screen. There are probably telnet configure codes to overcome this but again I
don't know what they are. 
	Networking is a black art where the wizards know everything but I am a 
mere apprentice.
