发信人: fenking()
整理人: nhyjq(2003-01-05 15:48:38), 站内信件
|
现在讲解制作mudlibSYS的制作原理：
Service: who
The originator will deliver the following packet over
the in-band network (to its router):
({
(string) "who-req",
(int) 5,
(string) originator_mudname,
(string) originator_username,
(string) target_mudname,
(string) 0
})
The router will route the packet to another router or
to the target mud. The target mud returns:
({
(string) "who-reply",
(int) 5,
(string) originator_mudname,
(string) 0,
(string) target_mudname,
(string) target_username,
(mixed *) who_data
})
where who_data is an array containing an array of the
following format for each user on the mud:
({
(string) user_visname,
(int) idle_time,
(string) xtra_info
})
Each user_visname should specify the user's visual na
me. idle_time should be measured in seconds
and xtra_info should be a string.
If the router fails to deliver the packet for some re
ason, it will return an error packet.
Service: finger
Finger operates similarly to who but returns informat
ion about a specific user rather than all
users logged into the mud. This service uses the in-b
and network; the packet has the following
format:
({
(string) "finger-req",
(int) 5,
(string) originator_mudname,
(string) originator_username,
(string) target_mudname,
(string) 0,
(string) username
})
Note: technically, we could use the target_username f
ield to hold the name of the person to
finger, but we do not wish to imply that the packet i
s destined for that user. The packet is only
querying information about the user.
The target mud will return:
({
(string) "finger-reply",
(int) 5,
(string) originator_mudname,
(string) 0,
(string) target_mudname,
(string) target_username,
(string) visname,
(string) title,
(string) real_name,
(string) e_mail,
(string) loginout_time,
(int) idle_time,
(string) ip_name,
(string) level,
(string) extra // eg, a .plan file, or other info
})
A mud may return 0 for any item if they wish to keep
the information private. In particular, it
is suggested that information about players (as oppos
ed to wizards) be kept confidential.
The returned visname should contain the user's visual
name. loginout_time specifies the (local)
time the user logged in (if they are currently on) or
the time the user logged out. The value
should be expressed as a string. It should be 0 to in
dicate no information. The idle_time is
expressed as an integer number of seconds of idle tim
e. If this value is -1, then the user is not
logged onto the mud at the moment.
If extra is given, then it should be terminated with
a carriage return.
Service: locate
This service locates a particular user on the Intermu
d system. The following packet is delivered
over the in-band network (to the mud's router), which
then delivers it to all muds
(target_mudname == 0):
({
(string) "locate-req",
(int) 5,
(string) originator_mudname,
(string) originator_username,
(string) 0,
(string) 0,
(string) username
})
If the requested user is logged into the receiving mu
d, then the following reply is returned:
({
(string) "locate-reply",
(int) 5,
(string) originator_mudname,
(string) 0,
(string) target_mudname,
(string) target_username,
(string) located_mudname,
(string) located_visname,
(int) idle_time,
(string) status,
})
located_visname should contain the correct visual nam
e of the user. idle_time will have the idle
time (in seconds) of the located user.
status specifies any special status of the user. This
will typically be zero to indicate that the
user has no special status. The values for this strin
g are arbitrary, but certain statuses have
predefined values that can be used:
"link-dead"
"editing"
"inactive"
"invisible"
"hidden"
These predefined values are intended to cover those s
tatuses that might modify a user's reception
of Intermud transmissions; they are not intended to b
e all-inclusive (and the string is arbitrary
in any case). The predefined way to specify multiple
attributes is with a comma-space-separated
list such as: "editing, hidden". The located mud shou
ld not attempt to apply special formatting
or other characters, instead leaving that to the rece
iving mud.
Other examples for the status string might be "afk fo
r dinner" or "taking a test".
Service: channel
There are two types of channels in the Intermud syste
m: selective admission and selective
banning. All channels are owned by a particular mud a
nd are adminstrated by that mud only. The
owner of a channel may also choose to filter the chan
nel, although this may subject that mud to
an increased load for processing the channel contents
and the channel will become unavailable
when the host mud is down.
The routers maintain three channel lists - one list f
or each type of channel (selective admission
vs banning) where the channel is unfiltered, and one
list for selective admission, filtered
channels. Selectively banned, filtered channels are n
ot allowed. For each channel, the router
will store which type it is (what list it is on), the
owning mud of the channel, and a list of
muds that are admitted/banned.
When a mud sends a startup-req-2 packet, it includes
its chanlist-id in the packet. The router
will potentially respond with a chanlist-reply messag
e to update the mud's channel list.
The router will respond to channel list changes with
the chanlist-reply packet.
({
(string) "chanlist-reply",
(int) 5,
(string) originator_mudname, // the router
(string) 0,
(string) target_mudname,
(string) 0,
(int) chanlist_id,
(mapping) channel_list
})
channel_list is mapping with channel names as keys, a
nd an array of two elements as the values.
If the value is 0, then the channel has been deleted.
The array contains the host mud, and the
type of the channel:
0 selectively banned
1 selectively admitted
2 filtered (selectively admitted)
All channel messages are delivered to the router. It
will then pass the message to the
appropriate set of muds. If the channel is filtered,
then the packet will be delivered to the
host mud for filtering; it will then return to the ro
uter network for distribution. It is assumed
that a channel packet for a filtered channel that com
es from the channel host has been filtered.
Channel messages come in three flavors: standard mess
ages, emotes, and targetted emotes. These
use packets channel-m, channel-e, and channel-t, resp
ectively. They are:
({
(string) "channel-m",
(int) 5,
(string) originator_mudname,
(string) originator_username,
(string) 0,
(string) 0,
(string) channel_name,
(string) visname,
(string) message
})
({
(string) "channel-e",
(int) 5,
(string) originator_mudname,
(string) originator_username,
(string) 0,
(string) 0,
(string) channel_name,
(string) visname,
(string) message
})
({
(string) "channel-t",
(int) 5,
(string) originator_mudname,
(string) originator_username,
(string) 0,
(string) 0,
(string) channel_name,
(string) targetted_mudname,
(string) targetted_username,
(string) message_others,
(string) message_target,
(string) originator_visname,
(string) target_visname
})
When a mud receives a channel-m packet, it should del
iver it locally to all listeners. The actual
message delivered to users should be a composition of
the originator_mudname, visname,
channel_name, and message. The message should not be
preformatted with this information before
delivery so that individual muds can define the displ
ay semantics. A suggested format is:
[gwiz] John@Doe Mud: help me! help me! I am a cluebie
newless!
This was composed with:
sprintf("[%s] %s@%s: %s", channel_name, visname, orig
inator_mudname, message);
channel-e packets are similar to channel-m packets, b
ut the message has a token in it to
represent where the originator's name should be. This
token is $N. An example is "$N smiles."
### need more info here ###
When a mud receives a channel-t packet, it should del
iver the message locally to all listeners.
The actual message delivered should be a composition
of the channel_name and one of
message_others or message_target. The messages will i
nclude $N and $O for the name of the
originator and the object/target of their emote. The
appropriate message is selected based on the
listener - if the listener matches the targetted mud/
user, then the message_target should be
used. A suggested format is:
[gwiz] With a flying leap, John@Doe Mud falls into th
e pit.
[gwiz] Jane@BlandMud waves to Goober@PutzMud.
[gwiz] Jane@BlandMud waves to you.
These were composed with:
sprintf("[%s] %s", channel_name, one_of_the_messages)
;
### need a bit more on channel-t ###
All messages should not be terminated with a newline
- that will be applied on the receiving mud
if necessary. The target_username should be in lower-
case if provided.
A channel may be added with the following packet:
({
(string) "channel-add",
(int) 5,
(string) originator_mudname,
(string) originator_username,
(string) target_mudname, // the router
(string) 0,
(string) channel_name,
(int) channel_type
})
The for channel_type field accepts the same values th
at the name server returns for channels.
Sending thi
--
()()()()()()()()()()()()()()()()()(()()()()()()()()()()()()
+ 我的最爱 +
+ 欢迎来到游戏开发者天堂 +
+ 好的意见，好的方法，好的论题 +
+ 在这里解决 +
============================================================
※ 来源:．月光软件站 http://www.moon-soft.com．[FROM: 202.101.177.97]
|
|