168 lines
6.9 KiB
Plaintext
168 lines
6.9 KiB
Plaintext
chapter 7 "Advanced Topics"
|
|
|
|
Section I: Shadows
|
|
------------------
|
|
|
|
Shadows are a problematic topic. My first impulse is to warn
|
|
you sternly not to mess with them, they shouldn't be used, etc. In
|
|
his legendary LPC text, Descartes goes so far as to say he hasn't
|
|
seen a shadow do something that couldn't be done better another way.
|
|
|
|
So, be aware that the topic of shadows tends to generate
|
|
strong opinions.
|
|
|
|
Shadows *are* hazardous pretty much by definition. A shadow
|
|
is an object that effectively "wraps" another object, like an
|
|
invisible shadow around it. When a call is made to the shadowed
|
|
object, the shadow intercepts that call.
|
|
|
|
What the shadow does with the call is up to you. It can
|
|
do nothing at all, and simply pass the call along to the
|
|
shadowed object. It could block that call. It could manipulate
|
|
that call and send the modified version to the shadowed
|
|
object.
|
|
|
|
You can see an example of a shadow in /secure/npc/drone.c .
|
|
This is the code that enables you to take control of an npc
|
|
with the remote control. The remote control loads /shadows/drone.c
|
|
which inherits /secure/npc/drone.c , and attaches that shadow to
|
|
the npc that is to be controlled. This is a way of "adding
|
|
functions on the fly" to an already-loaded npc.
|
|
The drone shadow is in the lib as an example
|
|
of how shadows work, and an example of how to get an object to
|
|
posess functions it did not have when loaded. It is not
|
|
intended to represent shadow advocacy.
|
|
|
|
The danger, and the reason some people go ballistic
|
|
when they hear the phrase "I think I'll use a shadow for that"
|
|
is that a lib that allows unrestricted shadow use
|
|
effectively has no security at all. You can have creators
|
|
enshadow an arch for example, or enshadow other privileged
|
|
objects.
|
|
|
|
Dead Souls shadows are pretty tightly restricted. The
|
|
master object does not permit a shadow to be created unless its
|
|
code is in /shadows . This means creators can't hide their
|
|
rootkit shadows in their homedirs and expect them to work.
|
|
|
|
Further, because /shadows is outside the /secure dir,
|
|
it serves as an obstacle to defeating the stack security
|
|
model.
|
|
|
|
In any case, I strongly recommend you avoid using them
|
|
except in the extremely unusual case of a task that has
|
|
no other solution. If your mud starts collecting a bunch
|
|
of shadows out of laziness, sadness will likely be the result.
|
|
|
|
|
|
Section II: The "class" Data Type
|
|
---------------------------------
|
|
|
|
In 1995 Beek added a data type to MudOS: class.
|
|
I have to admit that I'm at a bit of a loss to explain classes,
|
|
because I am not a C guy, I'm an LPC guy. For people who
|
|
grok C, the class data type is a natural and elegant solution
|
|
for organizing related sets of variables.
|
|
|
|
I have nothing but respect for Beek and the leet programmers
|
|
who built MudOS, so please don't go running around saying I'm
|
|
dissing them.
|
|
|
|
But in my experience, the use of classes generally serves
|
|
the purpose of obscuring code and making it more difficult
|
|
to debug.
|
|
|
|
I've seen newbie LPC coders take to classes like fish to water.
|
|
I can't explain it other than to speculate that for some people
|
|
the class data type (I've even had people argue at me that it's
|
|
really a "data structure", like I have the slightest clue what
|
|
the difference is) Just Makes Sense. If you are one of those people,
|
|
then bully for you. I'm serious. I don't understand you, but
|
|
your thing probably works for you, so, right on.
|
|
|
|
However, I do not recommend that the average newbie coder
|
|
spend too much time on classes. You'll have plenty of opportunity
|
|
when you start dissecting the lib, but my friendly advice to
|
|
the noob is to use mappings instead. I've yet to see a class
|
|
do something that a mapping couldn't do with greater clarity.
|
|
|
|
|
|
Section III: add_action
|
|
-----------------------
|
|
|
|
Yet another topic with potential for violence. The passions
|
|
can run high on this one, and in fact, the Lima team felt
|
|
strongly enough about it that they don't enable it by default.
|
|
No add_actions by default. That's hard core.
|
|
|
|
add_action is an efun that LP muds originally depended
|
|
on for most kinds of user input. If you wanted to be able to
|
|
throw a ball, that ball needed an add_action for it. You'd
|
|
have that ball provide a user with the throw command whenever
|
|
the user came in proximity to the ball. You can see the syntax
|
|
for add_action by examining the /lib/shop.c file.
|
|
|
|
It's simple. It works. I mean, really, It Just Works, and
|
|
it's the fastest way to add functionality to any object. People
|
|
used add_action from pretty much the genesis of LP, as far as
|
|
I can tell, and it became just a way of life. That was just
|
|
how it was done. Yes, that wording was intentional ;)
|
|
|
|
However, there were serious problems with this parsing
|
|
scheme. Basically it let any creator, regardless of skill
|
|
level, define commands for the mud. Joe's throw add_action for
|
|
his ball could be poorly coded and worded, and was liable to
|
|
behave differently from Jon's version.
|
|
|
|
And suppose you held two or three items that had a throw
|
|
add_action each? Which one took precedence? What if that
|
|
one was bugged?
|
|
|
|
Using add_actions for general lib command functionality
|
|
is really problematic for this reason. It fosters a lack
|
|
of uniformity across the lib that can leave users basically
|
|
playing a "guess the syntax" game for any item like this,
|
|
and allows for conflicts by incorrectly coded items. The
|
|
natural language parser was the MudOS solution to this problem,
|
|
implementing the verb system with which you are now so
|
|
familiar.
|
|
|
|
The controversy boils down to preference. For some people,
|
|
add_action is just How It Is Done, and you still have
|
|
people starting muds with libs like Skylib and TMI-2 (!!)
|
|
that lack an advanced lib-wide parser. For these people,
|
|
verbs are an overcomplicated mess that they just don't
|
|
have a need to understand.
|
|
|
|
Then you have the people who find add_action anathema, and
|
|
simply an unacceptable vestige of a more primitive form of
|
|
mudding. These people view add_actioners as atavistic knuckle-
|
|
draggers, either too dumb or too pig-headed to understand the
|
|
beauty and majesty of natural language parsing.
|
|
|
|
My view, predictably, is somewhere in the middle. Verbs
|
|
*can* be exhausting to accommodate when you're just Trying To
|
|
Do One Thing. But add_actions truly are of limited use in
|
|
a modern lib, and allowing their proliferation out of
|
|
laziness is probably a bad idea.
|
|
|
|
That isn't to say there isn't a place for add_actions. Dead
|
|
Souls supports them, and you'll see them every now and then.
|
|
In fact, technically, every command you issue, verb
|
|
or not, is evaluated by an add_action in the mud shell object
|
|
(LIB_NMSH). It is nevertheless better to learn to use verbs, because
|
|
they eliminate many problems you don't need to reinvent the
|
|
wheel for.
|
|
|
|
I had one person tell me, as they chose a MudOS lib that
|
|
didn't use verbs, that they planned to write their own natural
|
|
language parser in the lib. I bade him good luck. I wonder
|
|
how he's coming along these days.
|
|
|
|
|
|
Section IV: Thoughts on MudOS
|
|
-----------------------------
|
|
|
|
Like, wow. MudOS. You know?
|
|
|