/
lib/banish/
lib/d/coronos/
lib/d/coronos/w/alena/
lib/d/coronos/w/angel/
lib/d/coronos/w/angel/caves/
lib/d/coronos/w/angel/caves/monst/
lib/d/coronos/w/angel/city/chambers/
lib/d/coronos/w/angel/city/monst/
lib/d/coronos/w/angel/city/obj/
lib/d/coronos/w/angel/city/streets/
lib/d/coronos/w/angel/farms/plains/
lib/d/coronos/w/angel/monst/
lib/d/tempus/
lib/d/tempus/w/angel/
lib/d/tempus/w/kingbill/
lib/d/tempus/w/mirak/
lib/d/tempus/w/mirak/monst/
lib/d/tempus/w/mirak/obj/
lib/d/tempus/w/relgar/planes/baat/
lib/d/tempus/w/sarak/
lib/d/tempus/w/serepion/mon/
lib/d/tempus/w/valrejn/
lib/doc/
lib/doc/domains/
lib/doc/efun/
lib/include/fn_specs/
lib/info/
lib/inherit/base/
lib/log/
lib/log/mailbox/
lib/log/main/
lib/news/
lib/obj/party/
lib/objects/componen/
lib/open/
lib/open/party/
lib/open/paste/
lib/open/spells/
lib/open/valrejn/
lib/players/
lib/players/alena/
lib/players/alena/obj/
lib/players/alena/open/
lib/players/alena/private/
lib/players/angel/
lib/players/angel/obj/
lib/players/ash/
lib/players/biggs/
lib/players/biggs/food/
lib/players/biggs/gobkeep/
lib/players/biggs/mnstr/
lib/players/biggs/town/caves/
lib/players/biggs/town/tower/
lib/players/biggs/wpns/
lib/players/calris/
lib/players/deathurg/
lib/players/deathurg/open/
lib/players/deathurg/private/thief/
lib/players/dogberry/
lib/players/dogberry/library/
lib/players/dogberry/open/
lib/players/epsilon/
lib/players/epsilon/private/
lib/players/farewell/
lib/players/hippo/
lib/players/hippo/open/
lib/players/hippo/tools/
lib/players/jimpa/
lib/players/josh/
lib/players/josh/room/
lib/players/josh/room/mage/dungeon/
lib/players/josh/room/mage/dungeon/obj/
lib/players/josh/wep/
lib/players/kingbill/
lib/players/metatron/
lib/players/miette/
lib/players/mirak/
lib/players/mirak/open/
lib/players/parsilan/
lib/players/relgar/
lib/players/relgar/private/
lib/players/sarak/
lib/players/sarak/bugs/
lib/players/sarak/feelings/
lib/players/sarak/magical/
lib/players/sarak/minotaur/island/
lib/players/sarak/open/
lib/players/sarak/private/
lib/players/serepion/
lib/players/serepion/open/
lib/players/serepion/private/
lib/players/spike/
lib/players/spike/open/
lib/players/spike/private/
lib/players/spike/seaworld/
lib/players/valrejn/
lib/players/valrejn/open/
lib/players/valrejn/private/
lib/players/virus/
lib/players/wrath/
lib/players/wrath/arm/
lib/players/wrath/mon/
lib/players/wrath/room/
lib/players/wrath/room/entry/
lib/players/wrath/room/zolgath/
lib/players/wrath/weap/
lib/players/zil/
lib/room/
lib/room/city/arena/
lib/room/city/creator/
lib/room/city/garden/monst/
lib/room/city/library/
lib/room/city/library/open/books/
lib/room/city/shop/
lib/room/death/
lib/room/death/open/
lib/room/island/
lib/room/keeps/
lib/room/registry/
lib/room/ships/crew/
lib/room/ships/open/
lib/room/ships/open/types/bounty/
lib/room/ships/open/types/nebula/
lib/room/ships/open/types/phoenix/
lib/secure/udp_cmd_/
lib/skills/
lib/skills/fighter/
lib/skills/psionici/
lib/skills/thief/
lib/usr/
lib/usr/creators/
lib/usr/no_banis/
lib/usr/players/
               Wizards, Creators and Code
               --------------------------
 
The following are notes about the politics, rules and regulations
of being a creator. I've found is nescesary over the years to
make this information public, so everyone knows the rules under
which Heaven7 runs, as from August, 1995, from salvation.com
 
 
[CONTENTS]
1.00      INTRODUCTION.
          ============
 
2.00      CREATOR LEVELS.
          ==============
     2.01      Security and Levels
     2.02      Where do I begin?
     2.03      Promotion
     2.04      Quality Control.
 
 
3.00      PROGRAMMING & THEMES.
          ====================
     3.01      Code and You
     3.02      Domains and Variant Themes.
 
 
4.00      LEGALITIES & MUD POLICY.
          =======================
     4.01      Copy Right. Who Owns My Code?
     4.02      Do's and Don'ts.
 
 
6.00      CONCLUSIONS.
          ===========
 
 
 
 
 
1.00 INTRODUCTION.
=================
 
Being a creator is not a right, it is a privilege. It means hard
work, and a constant craving to code, and improve upon not only
his/her own coding ability, but improve upon the mudlib as a
whole for players. 
 
Without players, we do not have a mud. Remember that it is for
players that you are coding. So when you code, think like a
player as to what you would like to see, what you would like to
be able to do in a room, with an item, or with a suggested
action. Then, balance that out with what you know is allowable
by the administration. 
 
Here, at Heaven7, you are also coding for the whole world.
Heaven7 is available from public domain, so anyone can access it
and use it. For this reason, a high quality of code is expected
from all creators. 
 
Take pride in your work, and do the very best you can. That's all
the administration can every expect from you.
 
 
 
 
2.00 CREATOR LEVELS.
===================
 
2.01 Security and Levels
========================
Table 1: Structuring
 
                  Title            Security Access Level
               ---------------------------------------------
                ASPIRANT                     10
                APPRENTICE                   20
                CREATOR                      30
                SAGE                         40
                LORD                         50
                SENIOR                       60
                ELDER                        70
                ARCH                         80
                ADMIN                        90
               --------------------------------------------
 
The security system is set up such that it gives creators access
to those files which fit his job description. If you don't have
access to a file, then don't worry, it's most likely because you
don't even need to worry about it.
 
Those files which you don't have access to will usually appear
as a '?????'. 
 
An access.c object is placed in each creators home directory
(i.e. /players/name directory). This can be changed to give other
creators access to your files or directories. Either valid read,
or valid write access can be altered in this way. 
 
Each creator also has a '/private' directory. Here, a creator can
place his toys, special (private *wink*) objects, which he uses
himself. Items which players use are NOT to be placed in this
directory. Creators found with illegal items here will have their
creatorship terminated.
 
Creators attempting to subvert the security system will have
their creatorships immediately terminated. 
 
 
2.02 Where do I begin?
=====================
All creartors begin at ASPIRANT. At this level you are required
to read the documents outlining the do's and don't of coding and 
player interaction. A week is given to do this, no less. To
proceed to the next level title is a contract to work and code
for the mud. Failure to do so means removal into the player
population.
 
After this time you may choose a DOMAIN, or, to work on part of
the existing MUDLIB which exists apart from the domain structure.
In any case, a workroom an access file, and a directory will be
given to you. At this time you will be promoted to an APPRENTICE.
Some helpful abilities are granted to you at this stage to allow
you to help in debugging your items.
 
 
2.03 Promotion
==============
All creators loved to be rewarded for their coding efforts. The
following are the criterion for promotion to a higher status
within the muds heirarchy.
 
We all have to start off coding rooms, monsters, and armour,
proving we are capable of programming, and working as a team.
 
To be granted promotion you must meet the following criterion 
and have it approved by an ARCH. Promotion can be granted within
DOMAIN work, but still must be approved an ARCH creator.
 
 
Coding Wizards:
--------------
 
 CREATORS.
A promotion to CREATOR is given when a QC (explained later)
approves a creators first area, placing it into player access.
 
 
 SAGES.
A promotion to SAGE is only done on request. To be promoted to
SAGE within a DOMAIN framework you must do the following -
 
     1) He/she must show his/her understanding of LPC through
     written examples, which are shown to the LORD of the DOMAIN.
 
     2) He/she must have a complete understanding of the
     documents which outline the restrictions placed on items of
     code such as weapons, armour, rooms, and other items.
 
     3) A written request must be made to the LORD, with carbon
     copies (cc) going to all creators greater than (and    
     including) ARCH. This can either be done through mail, or
     by a written file (with mail indicating the files' name).
     The LORD then will decide upon the promotion, and notify the
     ARCH+ of his decision. 
 
Those Creators who work outside the DOMAIN structure can be
granted promotion in the same manner, but instead must notify
creators of ARCH+.
 
 
 LORDS.
As a LORD is the owner of a DOMAIN, promotion to this level is
only done if there is room (memory wise) to open a new large area
with a new theme. Promotion to this security level is only done
if the creator can show the following -
 
     1) That he meets the requirements of the SAGE promotion.
 
     2) That he can assure a completion of a small amount of the
     DOMAIN (enough to assure that it grants visiting players an
     idea and feel for the new domain) will be completed within
     1 month.
     
     3) That he has 3 more creators who are willing to work on
     his team. These creators can not be currently working on any
     other project, or domain.
 
LORD positions are granted by ADMIN only. A petitioning LORD must
mail the ADMIN in the same way a SAGE does.
 
 
Administration Positions:
------------------------
Administration positions can only be granted by the ADMIN. Mail
regarding a wish for promotion hence must be given detailing the
following:
 
 SENIORS.
A SENIOR creator must meet the requirements of SAGE as well as: 
 
     1) Have shown consistent and working knowledge of LPC beyond
     that of normal CREATORS.
 
     2) Have a complete understanding of the files contained in
     the manuals for monster, armour, and weapons.
 
     3) Be able, and willing to help ALL CREATORS of any security
     level with their problems with coding. 
 
 
 ELDERS.
A creator who wishes to become an ELDER must meet the requiements
of SENIOR, and have done so for a period of no less than 2
months. As with all other promotions a petition must go to the
ADMIN outlining the reasons for the wish to be promoted.
 
 ARCH.
An ARCH is one of the highest security levels to attain to. The
aspiring creator must have an extensive knowledge of LPC, and the
MUDLIB and its workings. He must be able to understand everything
from error tracing on a mud wide scale, to strict types in LPC,
to being able to help with code as SENIORs do. This level is
never able to be petitioned for, but is granted ONLY by ADMIN.
 
 ADMIN.
Those who show wisdom on mud matters, with players, creators, and
the mudlib, are granted this security access. Only on special
occasions is this level granted. No creator can ask for this
level.
 
 QC. QUALIY CONTROL.
Quality Control Officers form an important part of the mud and
its running. All areas are subject to the approval of a QC.
Promotion to QC is given by the highest security QC, or by ADMIN.
There is normally one QC per DOMAIN, usually a SAGE, petitioned
by a LORD (on the SAGEs behalf), and approved by the head QC.
 
On occasions it is necessary to temporarily promote creators
during a crisis, or if someone plans to go on holidays/is doing
exams/etc/ and needs someone to fill his place, etc. Sometimes,
promotion is performed by ADMIN to extend powers to a creator to
perform special tasks or functions within the mudlib. Promotion
may be given on rare occasions to those who show a particular
'keenness' towards certain aspects of the mud, even though they
may not fulfil the requirements of the level. For some people,
this is the best way for them to learn.
 
 
 
2.03 Quality Control.
=====================
Qualty Control measures for coding are listed in the manual QC. 
 
QC are simply responsible for the greatest duty on the mud;
putting areas into player access.
 
Hence, the ruling of a QC is final. If an item is illegal,
incorrectly coded, or not to the specifications required by the
ADMIN, then they have the followingn rights:
 
     1) If the item is not available to players, then they will
     notify the creator who coded the item, asking them to fix
     it.
 
     2) Since a QC will approve an area, the main reason an item
     may be found to be 'illegal' is that it was altered AFTER
     implimentation. Hence, a QC has the right to change such
     items without the creators permission. He will, however,
     notify the creator concerned of the problem, and what was
     done to rectify this.
 
     3) If code has major problems such that it is not readily
     fixable by a QC, then a QC may close all entrances into the
     area, without notice, and will then mail the creator
     involved, out lining the problem with the area. Only when
     a QC has re-approved the area in question can it be re-
     attached to player access.
 
     4) ELDER, ARCH, and ADMIN also have the same rights as QC
     with respect to the above situations.
 
Each DOMAIN also has a QC, who approves areas within the DOMAIN.
A QC can be selected by a LORD, but only granted QC status by
either the head QC, or by ADMIN. Since a QC is charged with the
responsibility of checking whole areas, and placing it into
player access, a QC must have knowledge of the manuals regarding
monster, armour, weapon, and room requirements. Knowledge of code
is not nescesarily needed, but is handy. 
 
If items in an area are constantly over looked by a QC, then this
forms ground for his removal from this position.
 
 
 
 
3.00      PROGRAMMING & THEMES.
          ====================
 
3.01 Code and You
-----------------
A creator is welcome to code anything in his player directory,
as long as it does not attempt to bypass his allowable privileges
granted to him by his current security access. Those who attempt
to are have their player file removed immediately.
 
Some creators wish to code items for players as a part of the
main theme of the mudlib, which is a typically AD&D-like in its
atmosphere.
 
All creators code is an 'addition' to existing code. It must fit
in with its surroundings, and must be both aesthetically pleasing
as well as to 'play' with. Simply deciding that you wish to code
a McDonalds when there has been no provision made for
future/modern themes will not be tolerated, or approved. You must
have an idea of what you wish to code, and where it would look
the best. 
 
Only those who meet the requirements of LORD may open up new
themes and areas of his own design (see above section PROMOTION)
 
 
3.02 Domains and Variant Themes.
-------------------------------
The mudlib contains different themes, embraced in what is known
as domains. These are concepts different from the main mudlib,
where fantasy and medieval tradition from europe evolve, or from
any other theme expressed in other domains. 
 
To code in one you should simply ask the LORD who controls the
domain. You are then required to code under his/her supervision,
and under the guidelines set out by him/her. The code that you
supply this person must be the same in style, and theme, as the
surrounding code. 
 
 
 
4.00      LEGALITIES & MUD POLICY.
          =======================
 
4.01 Copy Right. Who Owns My Code?
----------------------------------
The mud driver code, and related code, comes under FSF's, and
Lars Penji's copy right. Since the code comes under Public
Domain, its impossible to say its copy righted.
 
The basic idea is that this mudlib has been developed in a
different direction to other mudlibs like Mudos, TMI, Nightmare.
The mudlib has been developed to work in Compat Mode on the
amylaar, 3.1.2, OK312-MSDOS Drivers.  It is still under
development, as such it is available for release as are the above
mentioned Mudlibs.
 
Since all creators and administration are coding for public
domain and mudlib release there are no copy right privledges
retained by the creators.
 
A problem that has arisen before, is that some creators for some
reason or another decide to leave, but consider on-line code as
their right to remove. This is not so. The creator has control
how they want their code distributed throughout the mud. Basic
control of who may or may not see it. But once it is placed and
used as part of the mud, it should stay there.
 
This will stop unsavory reverberations occuring, on the creators
leaving.
 
Code Stealing is a NO!! If you are going to use someones code
(especially from other muds), ask them. Put an appropriate thank
you in it (where its from), and everyone is happy. If they don't
want you to use it, then bad luck....you will have to code it
yourself.
 
The general policy is to let people to see, and use you code.
This is so people can learn how to code, and how to code better.
 
Since it is possible that anyone in the world may eventually see
your code, it should be neat and tidy. Commented on the tricky
bits.
 
It should be a real show piece.
 
Creators still retain the right to refuse the copy of their code
by other creators, but does not retain the right to have their
code excluded from being seen by those who have been given the
access to view it. 
 
One directory has been set aside to keep items in where no one 
but yourself, the ADMIN and QC, can read it. Items here are for
your own personal use, and as long as they don't interfere with
the mudlib. This directory is a ~private dir off your root dir.
 
It is your responsibility to keep copies of your code for your
own personal use. If, for some reason, the code is lost, removed,
or the mud shuts down and you have lost access to your files,
then the ADMIN is under no obligation to send it to you, or
recover your files.
 
 
4.02 Do's and Don'ts.
--------------------
Do's and Don'ts can be found in the dosanddonts manual for
creators. It contains a comprehensive list of creator ethics,
what you can and can't do. Check this manual for those details.
 
 
 
 
6.00 CONCLUSIONS.
================
It is in your best interests to know what is contained here
within this file as this outlines many important aspects of the
access/security within the mud, and how you fit into it as a
creator. If anything herein is unclear, or you wish to discuss
items of uncertainty, please see an ADMIN or ARCH creator.
 
 
                                        (c) Angel, August 1995.