This is feature available from evennia 0.9 and onward.
There are multiple ways for you to plug in your own functionality into Evennia. The most common way to do so is through hooks - methods on typeclasses that gets called at particular events. Hooks are great when you want a game entity to behave a certain way when something happens to it. Signals complements hooks for cases when you want to easily attach new functionality without overriding things on the typeclass.
When certain events happen in Evennia, a Signal is fired. The idea is that you can “attach” any number of event-handlers to these signals. You can attach any number of handlers and they’ll all fire whenever any entity triggers the signal.
Evennia uses the Django Signal system.
Attaching a handler to a signal¶
First you create your handler
1 2 3
def myhandler(sender, **kwargs): # do stuff
**kwargs is mandatory. Then you attach it to the signal of your choice:
1 2 3
from evennia.server import signals signals.SIGNAL_OBJECT_POST_CREATE.connect(myhandler)
This particular signal fires after (post) an Account has connected to the game.
When that happens,
myhandler will fire with the
sender being the Account that just connected.
If you want to respond only to the effects of a specific entity you can do so like this:
1 2 3 4 5
from evennia import search_account from evennia import signals account = search_account("foo") signals.SIGNAL_ACCOUNT_POST_CONNECT.connect(myhandler, account)
All signals (including some django-specific defaults) are available in the module
(with a shortcut
evennia.signals). Signals are named by the sender type. So
Account instances as senders,
Objects etc. Extra keywords (kwargs)
be extracted from the
**kwargs dict in the signal handler.
SIGNAL_ACCOUNT_POST_CREATE- this is triggered at the very end of
Account.create(). Note that calling
evennia.create.create_account(which is called internally by
Account.create) will not trigger this signal. This is because using
Account.create()is expected to be the most commonly used way for users to themselves create accounts during login. It passes and extra kwarg
ipwith the client IP of the connecting account.
SIGNAL_ACCOUNT_POST_LOGIN- this will always fire when the account has authenticated. Sends extra kwarg
sessionwith the new Session object involved.
SIGNAL_ACCCOUNT_POST_FIRST_LOGIN- this fires just before
SIGNAL_ACCOUNT_POST_LOGINbut only if this is the first connection done (that is, if there are no previous sessions connected). Also passes the
sessionalong as a kwarg.
SIGNAL_ACCOUNT_POST_LOGIN_FAIL- sent when someone tried to log into an account by failed. Passes the
sessionas an extra kwarg.
SIGNAL_ACCOUNT_POST_LOGOUT- always fires when an account logs off, no matter if other sessions remain or not. Passes the disconnecting
sessionalong as a kwarg.
SIGNAL_ACCOUNT_POST_LAST_LOGOUT- fires before
SIGNAL_ACCOUNT_POST_LOGOUT, but only if this is the last Session to disconnect for that account. Passes the
sessionas a kwarg.
SIGNAL_OBJECT_POST_PUPPET- fires when an account puppets this object. Extra kwargs
accountrepresent the puppeting entities.
SIGNAL_OBJECT_POST_UNPUPPET- fires when the sending object is unpuppeted. Extra kwargs are
SIGNAL_ACCOUNT_POST_RENAME- triggered by the setting of
Account.username. Passes extra kwargs
SIGNAL_TYPED_OBJECT_POST_RENAME- triggered when any Typeclassed entity’s
keyis changed. Extra kwargs passed are
SIGNAL_SCRIPT_POST_CREATE- fires when a script is first created, after any hooks.
SIGNAL_CHANNEL_POST_CREATE- fires when a Channel is first created, after any hooks.
SIGNAL_HELPENTRY_POST_CREATE- fires when a help entry is first created.
evennia.signals module also gives you conveneient access to the default Django signals (these
different naming convention).
pre_save- fired when any database entitiy’s
.savemethod fires, before any saving has happened.
post_save- fires after saving a database entity.
pre_delete- fires just before a database entity is deleted.
post_delete- fires after a database entity was deleted.
pre_init- fires before a typeclass’
__init__method (which in turn happens before the
post_init- triggers at the end of
__init__(still before the
These are highly specialized Django signals that are unlikely to be useful to most users. But they are included here for completeness.
m2m_changed- fires after a Many-to-Many field (like
pre_migrate- fires before database migration starts with
post_migrate- fires after database migration finished.
request_started- sent when HTTP request begins.
request_finished- sent when HTTP request ends.
settings_changed- sent when changing settings due to
@override_settingsdecorator (only relevant for unit testing)
template_rendered- sent when test system renders http template (only useful for unit tests).
connection_creation- sent when making initial connection to database.