Quirks

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 players.

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 changes.

Web admin to create new Player

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 MULTIPLAYER_MODE you are in. If you are in MULTIPLAYER_MODE 0 or 1, the login system expects each Player to also have a Character object named the same as the Player - 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 Player. From the web interface you must do this manually.

So, when creating the Player, make sure to also create the Character from the same form as you create the Player from. This should set everything up for you. Otherwise you need to manually set the “player” property on the Character and the “character” property on the Player to point to each other. You must also set the lockstring of the Character to allow the Player 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 PackedDict that 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 alist and object.db.mylist are now [1,2,3,4]

If you don’t want this, convert the mutable object to its normal Python form.

blist = list(object.db.mylist)
blist.append(4)

The property blist is now [1,2,3,4] whereas object.db.mylist 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 more details.

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 DefaultObject

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 2016) a bug in the zope.interface installer 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.interface is not found even though pip list shows it’s installed. The reason is a missing empty __init__.py file 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:

touch pyenv/local/lib/python2.7/site-packages/zope/__init__.py

This will create the missing file and things should henceforth work correctly.