New Topic : Wizard Capabilities
Ross Williamson
with the Diku I'm running the wizards can most commands from simple
things like echo / stat all the way up to shutdown etc. Should
we as admins have a lot of little but mostly useless commands to
give out to the wizards.... also along these lines is building (
one of my pet subjects at the moment ) how much building and/or building
commands to we let the wiz's have? Do we let them alter the current world
or only add to the world.
Ross ( Belarion ).
'Da Wiggs
That depends on YOUR personal prefrence. I am running (in the
test stages) a Muck. I find that given the two levels of power
(GOD/WIZARD) isnt enough. I would like to be able to, in the near
future, hack in one more flag (ie apprentice). For me, I trust my Wizards
And the gods, Usually, not always have access to the account that it
it running on. Giving the wizzes the power to run the place isnt a bad
idea, it take away from some of the menial tasks that I would have
to end up doing.... but thats just for a MUCK, for a Diku or MUD, dont know.
Santiago Zorzopulos
>Ross ( Belarion ).
Well, here's Armageddon's wizhelp file, in its entirety. The system we
have seems to work quite well...
G E N E R A L C O M M A N D S
-------------------------------------------------------------------------------
GOTO (21) - "goto <room>|<object>|<char>"
AT (21) - "at <room>|<object>|<char> <command>"
STAT (22) - "stat room|<object>|<char>"
SHOW (21) - "show rooms|objects|npcs|zone <zone>"
ZASSIGN (25) - "zassign <char> <zone>"
LOG (21) - "log <msg>"
LOAD (22) - "load char|object <virtual number>"
PURGE (22) - "purge <char>|<object>"
FORCE (23) - "force <char> <command>"
ECHO (21) - "echo <msg>"
TRANSFER (21) - "transfer <char>"
ADVANCE (24) - "advance <char> <level>"
TITLE (21) - "title <title>"
SHUTDOWN (25) - "shutdown"
SNOOP (24) - "snoop <char>"
RESTORE (23) - "restore <char>"
REROLL (23) - "reroll <char>"
SWITCH (23) - "switch <char>"
USERS (21) - "users"
NOSHOUT (21) - "noshout <char>"
CRIMINAL (23) - "criminal <char>"
FREEZE (24) - "freeze <char>"
PLIST (24) - "plist"
RACES (22) - "races"
BAN (24) - "ban <site name>"
UNBAN (24) - "unban <site name>"
BSAVE (24) - "bsave"
W O R L D B U I L D I N G
-------------------------------------------------------------------------------
RNAME (22) - "rname <room name>"
RLINK (22) - "rlink <dir> <room number>"
RLINKRM (22) - "rlinkrm <dir>"
REXIT (22) - "rexit <dir> <room number>"
REXITRM (22) - "rexitrm <dir>"
RFLAGS (22) - "rflags <flag>"
RSECTOR (22) - "rsector <sector>"
RCREATE (22) - "rcreate <room number>"
RDESC (22) - "rdesc"
REDESC (22) - "redesc <keywords>"
RDDESC (22) - "rddesc <dir> <direction desc>"
RDKEY (22) - "rdkey <dir> <key>"
RDOOR (22) - "rdoor <dir> <keywords>"
WSAVE (22) - "wsave"
ZSAVE (22) - "zsave <zone>"
ZCLEAR (22) - "zclear <zone>"
ZRESET (22) - "zreset <zone>"
ZNAME (22) - "zname <zone name>"
ZSET (22) - "zset <zone> time|mode <value>"
O B J E C T C R E A T I O N
-------------------------------------------------------------------------------
ONAME (22) - "oname <obj> <object name>"
OSDESC (22) - "osdesc <obj> <object short desc>"
OLDESC (22) - "oldesc <obj> <object long desc>"
ODESC (22) - "odesc <obj>"
OEDESC (22) - "oedesc <obj> <keywords>"
OEDESCRM (22) - "oedescrm <obj> <keywords>"
OCREATE (22) - "ocreate <object number>"
OSET (22) - "oset <obj> <field> <value>"
OTYPE (22) - "otype <obj> <type>"
OAFFECT (22) - "oaffect# <obj> <value> <mod>"
OVAL (22) - "oval# <obj> <value>"
OSAVE (22) - "osave <obj>"
OCOPY (22) - "ocopy <obj> <obj>"
OEFLAGS (22) - "oeflags <obj> <extra flag>"
OWFLAGS (22) - "owflags <obj> <wear flag>"
N P C C R E A T I O N
--------------------------------------------------------------------------------
MNAME (22) - "mname <mob> <mobile name>"
MSDESC (22) - "msdesc <mob> <mobile short desc>"
MLDESC (22) - "mldesc <mob> <mobile long desc>"
MDESC (22) - "mdesc <mob>"
MCREATE (22) - "mcreate <mobile number>"
MSET (22) - "mset <mob> <field> <value>"
MDUP (22) - "mdup <mob>"
MSAVE (22) - "msave <mob>"
MAFFECT (22) - maffect <mob> <affect>"
Wildfire
>Ross ( Belarion ).
It really depends. Are the wizes always going to be people you trust with
that sort of thing? On Lp's, there are usually many levels of wiz.
The beginning ones can only code in their directory, and other stuff.
The higher they go, (as presumably promotions are given out based on
trust and ability) they gain more power. The highest ones besides the
admins can shut down the mud, snoop other players/lower wizes, build
anywhere (to facilitate fixing bugs) etc. But I sure would not
want to let a newbie wiz have the power to code in the wrong directories
or shut down the mud. ("what? You say I can't do that? Fine." shutdown 1)
But if you're only going to have wizards you know and trust, it shouldn't be
a problem.
-Wildfire-
|| Wildfire || ho...@ux1.cso.uiuc.edu || lmh4...@uxa.cso.uiuc.edu ||
|| "Computers are just the opposite of people. In computers the software ||
|| goes into the hardware. In people the hardware..." Torchsong Trilogy ||
|| disclaimer: "...my love, you, if anyone, should know that my rules ||
|| only apply to other people, not myself" -Friday ||
Patrick Atoon
>[...stuff deleted ...] But I sure would not
>want to let a newbie wiz have the power to code in the wrong directories
>or shut down the mud. ("what? You say I can't do that? Fine." shutdown 1)
Such action is probably followed by "demote <wizard> 0". It's rediculous to
think that newbie wizards should be kept on a short leash by giving them
not all the commands. A lot of newbie wizards aren't real newbies, because
they have already coded on other muds. If a wizard knows how to code, he can
code himself everything he needs.
The more stuff you keep from them, the more they will build themselves.
People will find out soon enough that it is simple to code an "echoall" that
does not log what you said.
I think that letting the wizards know that a misstep is first followed by
a warning, and that there will be no second warning, is effective enough to
keep them in line.
>But if you're only going to have wizards you know and trust, it shouldn't be
>a problem.
Hmmmm. "Wizards you know and trust". As Lord I sometimes get applications to
our domain from wizards that I do not know. Should I not trust them to become
wizard? Is suspect this fenomena is even worse for archwizards or keepers.
In big muds you cannot possibly know all apprentices, so what you do is
trust the people that recommend them to you. Knowing the people comes after
a while if you're lucky. Then you'll know if you made the right decision.
> -Wildfire-
Patrick Atoon
University of Nijmegen
The Netherlands
Jacob Hallen
This is a very important subject, because untrustworthy wizards are
the cause of very much work for the game admins. If we can reduce this
workload we can spend our time on much more productive things.
To start with, we must identify the problem correctly. In my
experience there are two quite different aspects to be considered:
1. When players become wizards they still behave like mortals for some
time. This is quite natural, but has the effect that they will use
all their new tools and powers to affect the course of the game. It
is quite common for new wizzes to be indebted (sp?) to other
players for their new rank, and to have links and ties with the
active high level mortals. It is also quite common for newbie
wizards to feel bewildered in their new environment.
2. There are always a number of wizards who act in a manner that
detracts from other peoples enjoyment of the game, no matter how
long they have been wizards. They can be divided into these main
subcategories:
a) Horseplayers
Use their powers to play practical jokes on mortals and/or other
wizards.
b) Cheaters
Help their friends.
c) Terrorists
Are out to sabotage the mud.
d) Monty-hallers
Have no concern for the balance of the game. Some of them write
stuff as an ego trip, others are just inexperienced or
ignorant.
e) Killers
Write stuff that is too deadly.
f) Smoothtalkers
The wizards who scare off all female players by doing their best
to chat up every female character that ever logs in.
I think the best way to deal with category 1 is to wait for a little
while before giving the new wizard a full set of commands. The length
of time needed is very individual, and if the rest of the wiz system
is set up correctly you never need to think about when to give full
access to commands.
In Genesis you become apprentice wizard with read access to
documentation and mudlib code. You also get commands to set your own
title, appearance etc, teleport and some minor commands to check people and
items in the game. You get writing and cloning capacity when you are
accepted into a domain (see below).
The people in category 2 are much harder to deal with, because they
already have wiz powers, and they engage in such diverse activities.
The biggest problem to start with is that there is no way a few admins
can keep tab of several hundred wizards, so in a large LPMud with
traditional organisation you run the risk of prepetrators remaining
undiscovered for very long times.
The domain system that we use in Genesis was mainly invented to remedy
this situation. An experienced or trustworthy wizard is set to be in
charge of a domain with no more than 8 other wizards as members.
The internal politics of the domain are up to the lord and the
members, but the lord is responsible for the the code produced by the
domain, and it is in his interest that all the domain members are
cooperating in making the domain a popular place. The domain lord has
the power to accept apprentice wizards into the domain, and also the
power to expel any member at any time. An expelled member becomes
apprentice again (with the apprentice command set).
Once in a while you will be in the situation that you have to deal
with perpetrators in some way to make the problem go away. These are
my recommendations:
Category 1: Speak kindly to the person and explain the rules, and why
the rules are there. This is almost always enough.
Category 2a: Start with a warning or two. If that doesn't help, shut
the player out a few days. If that doesn't help demotion
is the next step.
Category 2b: Shut out for a few days. Demotion on next occasion.
Category 2c: Demote on sight. Shut out his site for a while if
necessary. Tell others about it and publish what has
happened. These people are a plague and if admins are
forewarned they are at disadvantage. Never belive that
they will improve, they will prove you wrong sooner or
later.
Category 2d: Make these people show you everything they produce and
check their code regularly. Many wizards in this category
can be taught to produce high quality stuff. If you don't
have the time or patience to deal with with these people
you should probably demote them straight away. Otherwise
they will kill your game or take up all the time you
couldn't spend.
Category 2e: These are uncommon, but they do exist. Closing their area
every time a new deadly trap is implemented is a good way
of dealing with them. You don't have to look for wizards
in this category. You discover them when the players
start hollering: 'UNFAIR!!!'.
Category 2f: These people are more common than you may think, and they
are a problem because many female players stop playing
your mud if you have one or a few of these guys active.
Give them a sharp warning the first time and demote them
next.
I developed these principles on the old Genesis LPMud, where we had a
few cases to deal with every week.
With the new apprentice/domain system that we have now, we have hardly
had any problems at all. Of course this may be due to the fact that we
only have 180 wizards right now, but from the looks of things the
system will work at full scale too.
The drawback of the system is that you don't cater in full for all
types of people. Some people are loners and we won't let them work
alone until we know them and trust them. This is however a price that
we are ready to pay if the system continues to work as it has done up
to now.
Jacob