This directory is for topics which are asked about on a regular basis, but have long, complicated answers which are a real pain to explain each time.
The files in this directory are intended to explain why certain things are the way they are in the Lima lib. The purpose is not always to assert that a particular way of doing things is the best or only way of doing things, but to let people know that we are aware that there are other ways of doing these things, but we have chosen to do them the way we have for a reason.
Please be aware that in many (in fact, most) cases, these issues have been discussed to death on here, and in some cases the admins may not be particularly interested in continuing the discussion with everyone who disagrees, unless they have thought of some new angle or insight.
The name of the directory is important; this is the way we *decided* to do certain things. The fact that these things are decisions implies that there are other valid ways of doing these things. Feel free to implement them on your MUD.
add_action
To really do this subject justice would take many, many pages, but for now we will settle for a short overview.
Lima does not use add_action() at all; it uses verbs instead. Absolutely nothing remotely similar to add_action() exists in the lib. It is completely impossible for a room or object to add new commands to the game.
The reason for this is consistency. With the Lima lib, things work the same everywhere, making things much easier to understand. Of course, many things may not do anything interesting; however they should at least give a reasonable error message. For example, if there is anything in the MUD that can be twisted, it makes more sense for EVERYTHING to be able to be twisted, and simply do nothing, instead of each object which can be twisted having to completely reimplementing the concept.
The add_action() way of doing things leads to lots of code duplication, and in many cases poor parsing since the person writing the command is more interested in getting it to work for him than doing any sort of general parsing; in many cases the person in question is an area coder with little mudlib experience anyway. As anyone who has worked extensively with add_action() knows, bringing any two such objects into close proximity often results in complete disasters, and rarely even succeeds in generating the correct error message for most commands.
-Beek
P.S. if you really need it somewhere, there is always:
void create() {
parse_init(); parse_add_rule("foo", "STR");
}
mixed can_foo_str() {
// or something appropriate to objects meant to be carried return environment(this_body()) == this_object();
}
Intelligent readers will note this proves that the LIMA parser is capable of doing anything add_action() was capable of doing. The reverse, however, is not true, nor is it anywhere close to being true.
Default to First Object
When there are two possible valid interpretations for a noun, the Lima Mudlib *always* prints an error stating that there is an ambiguity. This is different from the behavior of many MUDs, although it is similar to most text adventure games (which the developers of this lib believe were, in general, higher quality than the average MUD). Note that an error message is *not* generated in cases where there are two possible objects but only one makes sense.
For example, if someone in the room is holding a sword, and there is a sword on the ground, ‘get sword’ will correctly figure out which sword was probably meant. Why is the sword in the persons hand considered at all? Because in the case where there *isn’t* a sword on the ground, you get a much better error message than the “There is no sword here” which would otherwise be generated.
The case most people complain about is “look at orc” with two orcs in the room. In our opinion, if you really want to look at either orc, but don’t care which, you should say so. There are a number of ways of doing this: “look at first orc”, “look at 1st orc”, “look at any orc”, “look at a orc”, etc.
[Note: support for ‘a’ and ‘any’ was added in v22.1a10, so v22.1 beta
versions and v22.1, as well as all later drivers, support it. Earlierones support 'first' and '1st' but not 'a' and 'any']
In our opinion, warning about ambiguities is a *good* thing. Arbitrarily picking the first object can be very bad, as anyone who has played MUDs extensively knows. For example, most players have accidentally sold the wrong object, due to having both a buckler and a shield in their inventory, and not realizing that the buckler can also be called a shield.
Lastly, on a well written MUD, the number of objects which are simply generic copies of each other with no noticeable differences should be rare anyway.
-Beek
Look Direction
At one point in the past, Lima did in fact have a “look
The problem with this is the output is usually wrong, and often nonsensical:
— You are standing in the middle of a large plain.
> look east You are standing towards the east side of a large plain. There is a small rock here. Sunning itself on the small rock is a pretty little lizard. —
The first sentence is downright wrong; as is the second. The last sentence implies pretty impressive eyesight, especially if the “scale” of the plain is large, like hundreds of feet/room as is typical in an outdoor setting.
Furthermore, exits may twist around, etc, so looking in a particular direction may not even be possible!
After much thought, support for that non-feature was removed. It is our general opinion that the “correct” way to do this sort of thing is to allow exits (or possibly directions) to have long descriptions so people can in fact look in arbitrary directions. That has not been implemented yet, though.
-Beek
Player Age
We don’t think it is particularly useful to keep track of how much time people have spent online :-) We know MUDs traditionally have done this, but there isn’t much point to it.
-Beek
Light Levels
In the Lima mudlib, zero is dark, and anything positive is light. Exactly how bright anything is is completely ignored. As long as there is a light source in the room, you can see; if there isn’t, you can’t.
Much more complex systems are indeed possible. In fact, it is not particularly hard to do something more complex since almost all of the code involved is in /std/object/light (most of the rest is in /std/object/move and /std/container).
The rationale for *not* doing it is that it doing a *good* job of implementing a complex multi-level light system isn’t particularly simple, and in our opinion adds little to the game. For that reason, we’ve gone with something simple, yet functional.
-Beek
Hiding
The Lima Mudlib doesn’t support the notion of “hiding” that is found in many historical mudlibs. Our view is simply that you can never plug all the holes (see wizzes_can_dest_admins). Therefore, we haven’t bunged up the whole mudlib trying to make hiding work.
Second, we simply don’t believe in the concept of hiding. The whole notion of a wizard hiding from players or other wizards, or even worse admins hiding from people is anathema to the types of muds that the Lima team would like to see. Our view is that a wizard should always be available to help a player and that an admin should always be there to help players and wizards. Hiding is simply anti-social which we feel engenders the wrong types of attitudes that a successful mud should embody.
Properties
For a little while, it was popular for mudlibs to use “properties” all over the mudlib. I.e., if you want to set some property “foo” in a player, you would call set(“foo”, value) instead of set_foo(“value”). All the mudlibs that did that either changed their ways, or made no qualms that time proved that design decision to be a poor one.
Lima provides set_perm() and set() functions. However, their use in mudlib code is strictly prohibited. We are wholeheartedly against mudlib coders using these functions for reasons outlined below. The only time we find their use acceptable is when an area coder finds it an essential hack to make up for his lack of mudlib access.
Here’s an outline of the problems with properties:
1) efficiency 2) irregularity 3) design
1) Efficiency: properties aren’t ever going to be faster than using separate accessor functions, because you have to access a variable and then index into a mapping in properties. You always have at *least* the overhead of mapping lookup (which is always a factor of 7 slower than not using mappings). However, if you want to add some sort of general purpose security to properties, then you’re going to add probably *tons* of overhead to every call to set (a la TMI… your security has to be general enough to be useful, which is likely to make it very slow). So there is always something faster than properties.
We’ve never seen a well-designed security system for properties. Even if you could make something secure, the extra overhead would hardly be worth it. It’s far better to provide as little security as is necessary, on a case by case basis.
Also, properties are not memory efficient. Big mappings are usually wasteful, as they always have more memory allocated than they are actually using, proportional to the size of the mapping.
2) Irregularity If you have want to avoid paying the large cost of using properties for some functions, and have some set_xxx() functions in addition to your set() function, you’re making it incredibly hard on your area coders. It was very confusing for novice TMI coders to figure out which one to use where.
Whereas most function calls do some sort of type checking or bounds checking on their input, set() can not do so. It can’t know if set(“gerrable”,1); is an error, or if it is correct.
3) Design One argument We’ve seem people make in favor of properties, is that it is nice to be able to write something as concise as: set_props(([P_INDOORS:1,P_LIGHT:2,P_NLIGHT:-1])
We have several criticisms of this, beyond those already mentioned:
1) This is not good design. A good object oriented design would export an interface to each unit of functionality. You *should* need to call set_indoors() and set_light() separately.
“/domains/config/help/cre/design_decisions/properties” (1-60 68%) [h]:
2) A good OO design would also tend to be more descriptive and readable. What does P_NLIGHT mean? If all the code related to it were all in one module, it would be easy to go to the code to figure out what’s going on, if the name of the function weren’t enough. With properties, who knows WHERE in the lib P_NLIGHT gets used?
3) properties encourage poor implementations. For example, INDOOR ROOMS should not be implemented by a flag. It is far easier to use and extend if it is implemented by subclassing a generic room. light:
– What if you want to make a generic STONE CHAMBER? Are you going to do this with more flags? You’d make things easier on everyone if you just inherited from INDOOR ROOM.
– It’s a lot easier to customize behaviors when you have them separated out into modules. That way, the rooms define their own behavior, instead of relying on the things acting on rooms to remember to test flags.
Another example: You can make an object that subclasses your base sword, let’s say, and does special stuff when set_xxx() is called by overriding that function. You’d need an expensive hook system to do anything close to that with set(), and it’d be ghastly to boot.
– Rust
Wizzes can dest admins
Wizzes are quite capable of desting admins. And we allow it. In fact, there are MANY things that are allowed by the mudlib that might otherwise be viewed as bothersome, annoying, or just plain downright problematic.
Our general view is this: if a wiz is intent on being a pest, then there is no amount of coding and protection that you can put into a mudlib to prevent that situation. Nothing.
Given that, we simply opted not to bulk up the lib with a zillion checks and protections and safeguards when their only end result is to stump some dumb wizards, but slow down the whole lib to the detriment of who you’re really there for: the players.
So what’s the answer to these bothersome wizards? Heh. Grow up and ban them. Quite simple. First time they’re a pest, just tell them “Don’t do that.” Second time, ban them. Our view is that people can be adults and work together.