LPC Concepts

Compiled from: LPC 23.

  • 3.0 Properties

    • ************************************************
    Part 1: Data Types
    ************************************************

    All LPMud drivers have the following data types:

    void, status, int, string, object, int *, string *, object *, mixed *

    Many drivers, but not all have the following important data types which
    are important to discuss:

    float, mapping, float *, mapping *

    And there are a few drivers with the following rarely used data types
    which are not important to discuss:

    function, enum, struct, char

    A note about the data types void and status:
    Void is a trivial data type which points to nothing. It is not used
    with respect to variables, but instead with respect to functions. You
    will come to understand this better later. For now, you need only
    understand that it points to no value.

    The data type status is a boolean data type. That is, it can only have 1 or 0 as a value. This is often referred to as being true or false.

    ************************************************
    Part 2: Functions
    ************************************************

    Like math functions, LPC functions take input and return output. Languages like Pascal distinguish between the concept of procedure and the concept of function. LPC does not, however, it is useful to understand this distinction. What Pascal calls a procedure, LPC calls a function of type void. In other words, a procedure, or function of type void returns no output. What Pascal calls a function differs in that it does return output.

    The declaration of a function called drink_water() which accepts a string as
    input and an int as output would thus look like this:

    int drink_water(string str);

    where str is the name of the input as it will be used inside the function.

    The function definition is the code which describes what the function actually
    does with the input sent to it.
    The call is any place in other functions which invokes the execution of the
    function in question. For two functions write_vals() and add(), you thus
    might have the following bit of code:

    /* First, function declarations.  They usually appear at the beginning
   of object code.
*/
void write_vals();
int add(int x, int y);

/* Next, the definition of the function write_vals().  We assume that
   this function is going to be called from outside the object
*/
void write_vals() {
    int x;

    /*N Now we assign x the value of the output of add() through a call */
    x = add(2, 2);
    write(x+"\n");
}

/* Finally, the definition of add() */
int add(int x, int y) {
    return (x + y);
}

    Remember, it does not matter which function definition appears first in the
    code. This is because functions are not executed consecutively. Instead,
    functions are executed as called. The only requirement is that the
    declaration of a function appear before its definition and before the
    definition of any function which makes a call to it.

    ************************************************
    Part 2.3: Efuns
    ************************************************

    For a complete list if external functions, use the command: 

    efuns

    Efuns are functions pre-defined by the driver. The value of efuns is that they are much faster than LPC functions, since they already exist in the binary form the computer understands. Efun calls are just like calls made to your functions. Still, it is important to know two things of any efun: 1) what return type does it have, and 2) what parameters of what types does it take.

    Information on efuns such as input parameters and return types is often found in a directory called /doc/efun on your mud. I cannot detail efuns here, because efuns vary from driver to driver. However, you can often access this information using the commands “man” or “help” depending on your mudlib. For instance, the command “man write” would give you information on the write efun. But if all else fails, “more /doc/efun/write” should work.

    ************************************************
    Part 3: Property Types
    ************************************************

    The Nightmare IV LPC Library allows creators to set dynamic variables in objects which do not get saved when the object saves. The variables are called properties. A property is an attribute of an object which is considered fleeting. This document serves to list the properties commonly used and their purpose. It is by no means complete, as the point of having properties is to allow creators to build their own on the fly.

    Note: All properties are 0 by default unless otherwise stated.

    Property: light
    Values: integer between -6 and 6
    Light is a value generally between -6 and 6 which, for rooms, determines how much light is naturally available in a room in daytime. For other objects, it determines the degree to which the object is able to modify the amount of light that exists in the room. If the room is indoors, the light does not change based on the time of day.

    Property: no attack
    Values: 1 to prevent attacks, 0 to allow them
    Things cannot begin combat from inside a room with this property.

    Property: no bump
    Values: 1 to prevent bumping, 0 to allow it
    If a room, then nothing can be bumped from this room. If a living thing, then it cannot be bumped.

    Property: no steal
    Values: 1 to prevent stealing, 0 to allow it
    This prevents stealing inside a room with this property.

    Property: no magic
    Values: 1 to prevent magic, 0 to allow it
    This prevents any magic from being used inside the room if set.

    Property: no paralyze
    Values: 1 prevents paralysis from occurring in a room, 0 allows it
    Stops any sort of thing which might cause paralysis from occurring in a room.

    Property: no teleport
    Values: 1 if teleporting is prohibited, 0 if allowed
    Prevents people from teleporting to or from the room.

    Property: no clear
    Values: 1 to prevent clearing, 0 to allow it
    If set this prevents an avatar from clearing a wilderness room in order to build a town. Not relevant to rooms in towns.

    Property: estates
    Values: any non-negative number
    Sets the number of estates which can be built in an area. No estates may be built outside of towns.

    Property: magic item
    Values: an array of strings describing the magic contained in an object
    Allows you to mark specific objects as magic. For example, if a sword has a magical lighting ability, you might do:
    SetProperty(“magic item”, ({ “light” }));

    Property: lockpicking tool
    Values: any integer marking how well lockpicking is enhanced
    When picking a lock, the value of this property is calculated for each object and added to the overall chance to pick the lock.

    Property: keep
    Values: the name of whomever the object is kept for
    While set, this object may only be picked up by the person whose name matches the value of this property. If 0, anyone can pick it up assuming it is normally gettable.

    Property: magic hold
    Value: any integer
    Is subtracted from the chance of success of anyone trying to pick a lock.

    Property: enchantment
    Value: any integer
    Enchants any object to boost (or degrade) its performance of its natural functions.

    Property: login
    Value: a string representing a file name
    Sets which room a player should login to at next login if they quit from the room that has this property. For example, if you have a treasure room that is protected, and therefore you do not want people logging into it, you can call:
    SetProperty(“login”, “/file/name/outside/this/room”);
    to have the players login to the room outside.