And they said one to another, Behold, this dreamer cometh. Come now therefore, and let us slay him, and cast him into some pit, and we will say, Some evil beast hath devoured him: and we shall see what will become of his dreams.
A client object is created when a player logs in and gets destroyed when that player logs out. Whereas a mob being used by a player and an NPC mob are treated identically by the computer, the client datum contains properties which are applicable only to players.
You may define verbs under the client data object. These are treated just like private verbs attached to the player's mob: they are accessible only to the player and the source is implicit. In addition to verbs, you may also define client variables and procs. The pre-defined ones will be described in the sections that follow.
The client variables contain information about the player and the state of the player's display. They are described in the following list:
Using the client.mob variable, we can make a better who
command
which only lists players who are currently logged in.
mob/verb/who() var/mob/M usr << "Active players:" for(M) if(M.client) usr << M.name
Mobs without a client (i.e. NPCs) are excluded from the output list.
There are a number of pre-defined procs which handle various forms of input from the user. These and other client procs are described in the following sections.
When the player clicks an arrow key, this calls a corresponding client proc. There are procedures for each of the keys: North(), South(), East(), West(), Northeast(), Northwest(), Southeast(), Southwest(), and Center().
It would be more precise to call these verbs, because that is in fact what they are. They just happen to be verbs with names starting with a dot, which means they don't show up in any expansion lists until you type the dot. So you could type ".north" instead of clicking the up arrow if you really wanted. That is all the up arrow does for you.
By default, the directional procs call the client's Move proc, which in turn calls the mob's own Move proc. It is simply there to redefine if you want.
|
The Center proc also exists primarily for you to redefine. The only default action is to stop any automated movement of the player's mob. That topic will be discussed in section 14.2.
In some games, you might want to disallow diagonal movements. You could do that by simply redefining the relevant procs to do nothing.
client //disable diagonals Northeast() Northwest() Southeast() Southwest()
The Click proc is called when the player clicks an object on the map or in the stat panels. There is an identical proc DblClick which is activated by double-clicking. The default action simply calls the object's own Click or DblClick proc. These object procedures were described in section 7.4.
|
The following example tells you what you clicked.
client/Click(O) usr << "You clicked [O]."
Note that the default (parent) proc was not called in this example. That means the object's own Click procedure will not be called. You must remember to call ..() if you wish this to still take place.
The client's Click procedure is convenient to use when you want to perform an action that is the same for all types of objects. When the action depends on the type of object, the object's own Click procedure is usually the better choice.
The Stat proc is called periodically by the client to refresh the stat panels. By default, this merely calls statobj.Stat(). You could generate stat output directly from this proc, but when the contents reflect the status of another object (like the player's mob), this is normally done in the object's own Stat proc. Generation of stat output was discussed in section 7.3.
The Topic proc is activated by the player clicking on a topic link embedded in the text output somewhere. You could use it to give the player more information on the indicated subject (hence the name topic). However, there is no restriction on what action you may perform. Some of the possibilities will be explored in chapter 11.
|
The Obj
and SubTopic
parameters are only supplied if Topic
begins with an object reference (embedded with \ref
). By default,
the object's own Topic proc is called with SubTopic
as the
argument. You saw the result of that in section 7.6 when we
created a link to a game object.
Since all topic links go through the client first, you have a chance to control which objects a player may access. You may also have topics which do not really belong to any particular object. In that case, you can just handle them in the client object.
Topic hyperlinks are created in an HTML tag. The syntax was already introduced in connection with object links, but for client topics, you do not necessarily have to insert an object reference. It is also possible to use this tag for other types of links. The general syntax will be described in section 11.2.8.
|
As an example of a client topic link, you could give some advice to new players.
client/Topic(T) if(T == "help") usr << "The motto here is: you are what you eat." else ..() mob/Login() ..() usr << "When in doubt, click here."
The Import and Export procs are used to read and write to a save file stored in the player's key file. This is useful if the same information about a player will be used in multiple worlds. In that case, rather than each world saving information about the player separately, it can be attached to the player's key and carried from world to world that way.
Since we haven't covered save files yet, further discussion of these procs will be postponed until that time. See chapter 12.
The New and Del procs are called at creation and destruction of the client, as they are for all objects. The default behavior of New is to connect the player to the mob with the same key as the player. If none is found, one will be created. If there is a mob defined to have the same key, that type of mob will be used; otherwise world.mob is used.
|
Normally an initial topic is not specified when a player connects. However, it may be useful in some situations. By default, once a mob has been selected, the Topic proc is called to handle it.
You could override the New proc to ban certain keys from connecting.
client/New() if(key == "Real Jerk") return //sorry pal! return ..()