This is a list of various quirks or common stumbling blocks that people often ask about or report when using (or trying to use) Evennia. They are not bugs.
Forgetting to use @reload to see changes to your typeclasses¶
Firstly: Reloading the server is a safe and usually quick operation which will not disconnect any accounts.
New users tend to forget this step. When editing source code (such as
when tweaking typeclasses and commands or adding new commands to command
sets) you need to either use the in-game
@reload command or, from
the command line do
python evennia.py reload before you see your
Web admin to create new Account¶
If you use the default login system and are trying to use the Web admin
to create a new Player account, you need to consider which
MULTIACCOUNT_MODE you are in. If you are in
1, the login system expects each Account to also have a
Character object named the same as the Account - there is no character
creation screen by default. If using the normal mud login screen, a
Character with the same name is automatically created and connected to
your Account. From the web interface you must do this manually.
So, when creating the Account, make sure to also create the Character from the same form as you create the Account from. This should set everything up for you. Otherwise you need to manually set the “account” property on the Character and the “character” property on the Account to point to each other. You must also set the lockstring of the Character to allow the Account to “puppet” this particular character.
Mutable attributes and their connection to the database¶
When storing a mutable object (usually a list or a dictionary) in an Attribute
object.db.mylist = [1,2,3]
you should know that the connection to the database is retained also if
you later extract that Attribute into another variable (what is stored
and retrieved is actually a
PackedList or a
works just like their namesakes except they save themselves to the
database when changed). So if you do
alist = object.db.mylist alist.append(4)
this updates the database behind the scenes, so both
object.db.mylist are now
If you don’t want this, convert the mutable object to its normal Python form.
blist = list(object.db.mylist) blist.append(4)
blist is now
remains unchanged. You’d need to explicitly re-assign it to the
mylist Attribute in order to update the database. If you store
nested mutables you only need to convert the “outermost” one in order to
“break” the connection to the database like this. See Attributes for
Commands are matched by name or alias¶
When merging command sets it’s important to remember that command
objects are identified both by key or alias. So if you have a
command with a key
look and an alias
ls, introducing another
command with a key
ls will be assumed by the system to be
identical to the first one. This usually means merging cmdsets will
overload one of them depending on priority. Whereas this is logical once
you know how command objects are handled, it may be confusing if you are
just looking at the command strings thinking they are parsed as-is.
Objects turning to
A common confusing error for new developers is finding that one or more
objects in-game are suddenly of the type
DefaultObject rather than
the typeclass you wanted it to be. This happens when you introduce a
critical Syntax error to the module holding your custom class. Since
such a module is not valid Python, Evennia can’t load it at all to get
to the typeclasses within. To keep on running, Evennia will solve this
by printing the full traceback to the terminal/console and temporarily
fall back to the safe
DefaultObject until you fix the problem and
reload. Most errors of this kind will be caught by any good text
editors. Keep an eye on the terminal/console during a reload to catch
such errors - you may have to scroll up if your window is small.
Known upstream bugs¶
There is currently (Autumn 2017) a bug in the
zope.interfaceinstaller on some Linux Ubuntu distributions (notably Ubuntu 16.04 LTS). Zope is a dependency of Twisted. The error manifests in the server not starting with an error that
zope.interfaceis not found even though
pip listshows it’s installed. The reason is a missing empty
__init__.pyfile at the root of the zope package. If the virtualenv is named “pyenv” as suggested in the Getting Started instructions, use the following command to fix it:
This will create the missing file and things should henceforth work correctly.
There is an issue with Python3-style syntax and older Python2 versions. If you run into errors like
SyntaxError: unqualified exec is not allowed in function 'call' it contains a nested function with free variables (scripts.py, line 448)when running e.g. the In-Game-Python contrib, you need to update to the latest Python version (
2.7.13at the time of writing).