| |
|
-
What happens if I shut down my MUSH? Will MudNet automatically
come back up, or do I have to email you to get it working?
Ordinarily, yes, it will retry at randomly increasing multiples of
5 minutes. If your IP address happens to have changed, it may still
try the old one several times, due to DNS caching. If you bring your
mush back up and the bot doesn't reconnect in a time period roughly
equal to the downtime, it might be time to send email. If your world
is marked as DISABLED, that means the MudNet player doesn't exist or
the password is different; please fix it and let us know, since the
bot doesn't bother trying to connect to such a mush.
If it isn't disabled and you've waited a long enough time, there
are several possibilities: network lag, misconfiguration, network
outage, etc., some of which we can do something about and some of
which we can't. If there's nothing we can do to connect to your mush
in a two-week period we'll just have to delete it, but in the meantime
we will make some effort to connect. There is no warning of two-week
timeout, only notification after the fact, since it's easy enough to
just resubmit the mush (and this often fixes errors anyway).
-
I'm running my MUSH at home and I don't have a static IP. Is
there some way for me to give my new IP to MudNet each time it
changes?
The bot does do DNS lookups, so if you were to get a hostname, you
could change the DNS entry when you reconnect. I think pennmush.org
offers free hostnames, but I'm not sure what kind of turnaround they'd
have on processing changes (plus there's the issue of DNS cache
timeout). One person who asked this question got a 2y.net hostname.
We've generally just tried to discourage temporary addresses. For
permanent or infrequent moves, you're welcome to email us the new
address. In the future we might provide a way for you to update your
address thru the web interface, but I don't think it'll happen very
soon.
-
I've just switched from PennMUSH to TinyMUX (or other combination).
Why are strange things happening and what do I do about it?
MudNet refers to a configuration file to determine what kind of
server you have, and tries to send commands appropriate to that
server. If you change servers, the bot will not notice all by itself.
You need to inform us by email so we can update the configuration.
You should also be sure to install the softcode appropriate for the
new server instead of depending on importing everything from your old
database.
-
Can I have a copy of the server source code? Can I run my own
mudnet?
The short answers are no and sort of; you're welcome to use
MushLink
or write your own code. There is only one MudNet; we're not interested
in fragmentation of the linked MU* community. If you can demonstrate to
our satisfaction that some other system is sufficiently better than the
current implementation of MudNet, we might consider switching, but don't
hold your breath. If you're not satisfied with the existing MudNet, try
giving us specific and constructive feedback before you do anything
rash; we may already have an answer that isn't listed here.
-
How can I join the team?
Um, we don't know exactly. We're just a group of friends who happen
to hack bots together. Convince us you're useful, and we'll listen, but
there isn't any formal structure here that would provide a specific way
to join, or for that matter a way for us to make decisions :)
-
Why doesn't MudNet have any MUDs on it?
Compared to softcoding on a MUSH, it's a lot more difficult to
provide instructions on getting a MUD to support all the right features.
We did have a couple of ColdCore MUDs at one point, when Rodregis
made an attempt at emulating enough PennMUSH features to fake the MudNet
softcode. Unfortunately he never wrote up his work for others to use,
and has since deleted it by accident. If you're interested in porting
the softcode to an unusual MU* server, we can make some adjustments in
the mudnet server and provide necessary information about the interface.
Stuff should eventually end up on the website under help-porting.
-
Why are you using @trigger instead of $-commands?
In previous versions of MudNet, we did use $-commands, but we ended
up providing two versions of the softcode: one for mushes that allowed
$-commands on players, and one for mushes that didn't. At some point
we added an installer that would try to autodetect and use commands on
the MudNet player if possible, because in most cases the $-commands on
players would run faster than $-commands on a nearby object.
We've avoided these installation and maintenance problems by just
using triggers, which are always allowed on players. Thus, on
platforms where there would be a queueing penalty for invoking a
$-command or trigger on a non-player object, we've avoided the delay
by placing all the triggers on a player. We found that @trigger parses
its arguments more sanely than $-commands do; with @trigger it's easy
to escape a comma and have it included in the argument. @trigger is
one of the least-modified commands shared among the various MU*
flavors.
|