1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
|
Note: This document is derived from the `help getting-started' text in the core. It may be out of date.
GETTING STARTED WITH YOUR NEW MOO
=================================
This document is intended to help you get started running a new MOO with a JHCore database. It doesn't cover everything, but it should be enough to keep you occupied for a while.
Note that this document assumes you have some knowledge of MOO use and programming, or at least setting properties. Without it, you will lose horribly.
BEFORE YOU START
----------------
For a JHCore database to work well, you'll need a higher tick limit than the default. If you're still running a server version earlier than 1.7.7, you'll need to set this in options.h before compiling; in newer versions you can just set properties on $server_options in the database. The values we use at JHM are:
Max ticks (foreground): 50000
Max ticks (background): 30000
We also recommend compiling with OUTBOUND_NETWORK if you can; besides enabling mail sending (which allows autoregistration), it allows for access to various other network services we think are cool. In addition, we should eventually provide server patches to allow listening on multiple ports, and database code to use it.
STARTING THE DATABASE
---------------------
Once you have a MOO compiled and a JHCore database, you can start it up. You probably want to fetch JHCore.db and rename it to something else; we'll call it `MyMOO.db' for now. Assuming you have the MOO executable (moo) and your database file (MyMOO.db) in your current directory, you can type `./restart MyMOO 1234' to start it up on port 1234. For more detail, see the `README' file in the LambdaMOO source distribution.
Once it's finished loading the database (you can watch `tail -f MyMOO.log' if you're anxious), you should telnet or otherwise connect to your host and port, and `connect Wizard' to log in.
Since the database doesn't initially require a password to log in as Wizard, you should set your password immediately; just type `@password <new-password>'. Then you may want to @rename and @describe yourself.
LETTING PEOPLE LOG IN
---------------------
It takes a surprising amount of setup before other people can log in, but most of it is just setting values for properties.
First, you almost certainly want to change the message people see when logging in. Just `@edit $login.welcome_message'. (If your client supports local editing, you probably want to do `@editoption +local' first.)
You have four options for letting people log in:
o (semi-)anonymous guest characters (can be used with any of the others)
o autocreation at login
o registration (requires guests)
o manual player creation by wizards
Each of them requires a separate piece of setup.
Guests
======
If you want people to be able to log in as guests, you need to create at least one:
>@make-guest guest
Created the guest (#415).
(Before doing that, you may want to set $guest.default_gender; we use "spivak", but "neuter" is a popular choice.)
Once you have a guest, you can make additional guests with specific adjectives--for example,
>@make-guest example
Created an example guest (#416). Now don't forget to @describe em as
something.
There are two more things you may well want to change about guests. First, by default, guests' sites will be shown to anyone who looks at them. To turn this off, set $guest.show_site to 0.
Second, again by default, when people log in as "guest", the connection system will try to match their connect domain using $country_db, and for example connect ".uk" users to "the British guest". (Guests of this type are created automatically.) To turn this off, just set $login.sitematch_guests to 0. For more information about customizing this, see `help $country_db'[1].
Autocreation
============
If you set $login.create_enabled to 1, people will be able to create new characters from the login screen, with no registration address. We don't recommend this at all, but if you're bent on anonymity, this is your option.
AutoRegistration
================
If you have guest characters and outbound network connections, you can allow people logged in as guests to register automatically for characters. If you want to allow this, you need to set up $network for outgoing mail (see below), and set $guest.registration_ok to 1. If not, you may want to set the @noregister message on $guest to something more specific than the default.
If you use autoregistration, you may want to maintain a list of sites from which automatic registration is not allowed. (For example, some schools provide their students with one account for each computer science class they take.) Use the `@spooflist' command to add a domain to this list, which is stored in $login.spooflist.
@Make-player
============
If you have no registration and no autocreation, the only way to make new characters will be the @make-player command (on $wiz and $feature->community group). Setting up $network for outgoing mail (see below) will make this easier, as mail can be sent automatically to the new user.
In addition, you'll probably want to change $login.registration_string so it doesn't make false claims. If you want to include an address to send to for characters, set $login.registration_address to that address, and use "%e" in the registration string to refer to that address. For example:
>;$login.registration_address = "mymoo-registration@mymoo.mydomain.net"
>;$login.registration_string = "Automatic registration is not allowed.
Send mail to %e explaining why you want a character."
THE NETWORK
-----------
The $network object provides various facilities related to networking; most importantly for your initial setup, it handles outgoing mail (through $network:sendmail). Here are some properties you should set before going much of anywhere:
.MOO_name
-- your moo's name--for example, "MyMOO"
.site
-- your moo's site--for example, "mymoo.mydomain.net"
.port
-- your moo's port--for example, 1234
.postmaster
-- someone who will handle bounced mail and such
.mail_domain
-- a mail domain to give for reply addresses (used in
$network:reply_address, which see). If yail domain to give for reply addresses (used in
$network:reply_address, which see). If you don't have incoming
mail (we don't either), you might as well leave this as is.
And finally:
.active
-- signals that $network is set up and (hopefully) usable for mail
ADMINISTRATION
--------------
The JHCore admin system is a way to make certain tasks/responsibilities/privileges available to groups of people without requiring that those people be wizards. The philosophy is that there are several roles that wizards have traditionally been required to play, and that those people who are best suited to some of the roles are not interested in performing all of them. Allocating permissions to administrative groups by their functions provides a way to specify the role(s) people hold.
Our administration system divides into three main groups:
o The Steering Committee, which makes decisions about broad goals and such;
o The Community Group, which tries to avoid or resolve social conflicts;
o The Tech Group, composed of three subgroups that handle technical issues.
This is a gross oversimplification; you can look at each of them (@kids $admin) to get more description.
You'll probably want to customize this. Simple customizations include changing the descriptions and the names (don't forget to describe the associated mailing lists!); you might go on to moving commands around (between $wiz and $feature->community, most likely); or you might just want to get rid of this complex system. It should be fairly simple to reduce the administration system to a simple wizard-rule system a la LambdaCore, by recycling admin groups, changing $admin, and probably hacking some code.
PORTING
-------
There's a lot in JHM and elsewhere that you might want but that JHCore doesn't provide. For general information about porting, you should check the MOO-Cows "Newbie Arch-Wizard FAQ". However, the site from which you retrieved JHCore should also have a set of code modules that are easily ported into a JHCore database; be sure to check these out.
MISCELLANEOUS
-------------
You probably want to change the name of the newspaper. Just `@edit $news.description'. If you like, you can `@edit $help.news', too.
By default, JHCore allows only a small set of "genders" (which actually cover person, number, and gender) for players. The set of defined genders is in $gender_utils.genders; $gender_utils.player_genders holds the list allowed for players. You may want to expand (or contract!) this list.
IN CLOSING
----------
If you're using JHCore, we'd like to hear from you. JHM is at jhm.ccs.neu.edu, port 1709; you can log in as a guest and request a character if you don't have one already. Please feel free to send mail to the *jhcore list--report bugs, provide fixes, ask for help, or just tell us about your MOO.
|
