┌──────┐ │ ┌───────┐ ┌───────┐ ┌──────┐ │Client├─┼──►│Session├───►│Account├──►│Object│ └──────┘ │ └───────┘ └───────┘ └──────┘ ^
An Account represents a unique game account - one player playing the game. Whereas a player can potentially connect to the game from several Clients/Sessions, they will normally have only one Account.
The Account object has no in-game representation. In order to actually get on the game the Account must puppet an Object (normally a Character).
Exactly how many Sessions can interact with an Account and its Puppets at once is determined by Evennia’s MULTISESSION_MODE
Apart from storing login information and other account-specific data, the Account object is what is chatting on Evennia’s default Channels. It is also a good place to store Permissions to be consistent between different in-game characters. It can also hold player-level configuration options.
The Account object has its own default CmdSet, the
AccountCmdSet. The commands in this set are available to the player no matter which character they are puppeting. Most notably the default game’s
who and chat-channel commands are in the Account cmdset.
ooc command causes you to leave your current puppet and go into OOC mode. In this mode you have no location and have only the Account-cmdset available. It acts a staging area for switching characters (if your game supports that) as well as a safety fallback if your character gets accidentally deleted.
This re-puppets the latest character.
Note that the Account object can have, and often does have, a different set of Permissions from the Character they control. Normally you should put your permissions on the Account level - this will overrule permissions set on the Character level. For the permissions of the Character to come into play the default
quell command can be used. This allows for exploring the game using a different permission set (but you can’t escalate your permissions this way - for hierarchical permissions like
Admin etc, the lower of the permissions on the Character/Account will always be used).
Working with Accounts¶
You will usually not want more than one Account typeclass for all new accounts.
An Evennia Account is, per definition, a Python class that includes
evennia.DefaultAccount among its parents. In
mygame/typeclasses/accounts.py there is an empty class ready for you to modify. Evennia defaults to using this (it inherits directly from
Here’s an example of modifying the default Account class in code:
# in mygame/typeclasses/accounts.py from evennia import DefaultAccount class Account(DefaultAccount): # [...] def at_account_creation(self): "this is called only once, when account is first created" self.db.real_name = None # this is set later self.db.real_address = None # " self.db.config_1 = True # default config self.db.config_2 = False # " self.db.config_3 = 1 # " # ... whatever else our game needs to know
Reload the server with
… However, if you use
examine *self (the asterisk makes you examine your Account object rather than your Character), you won’t see your new Attributes yet. This is because
at_account_creation is only called the very first time the Account is called and your Account object already exists (any new Accounts that connect will see them though). To update yourself you need to make sure to re-fire the hook on all the Accounts you have already created. Here is an example of how to do this using
py [account.at_account_creation() for account in evennia.managers.accounts.all()]
You should now see the Attributes on yourself.
If you wanted Evennia to default to a completely different Account class located elsewhere, you > must point Evennia to it. Add
BASE_ACCOUNT_TYPECLASSto your settings file, and give the python path to your custom class as its value. By default this points to
typeclasses.accounts.Account, the empty template we used above.
Properties on Accounts¶
Beyond those properties assigned to all typeclassed objects (see Typeclasses), the Account also has the following custom properties:
user- a unique link to a
UserDjango object, representing the logged-in user.
obj- an alias for
name- an alias for
sessions- an instance of ObjectSessionHandler managing all connected Sessions (physical connections) this object listens to (Note: In older versions of Evennia, this was a list). The so-called
session-id(used in many places) is found as a property
sessidon each Session instance.
is_superuser(bool: True/False) - if this account is a superuser.
cmdset- This holds all the current Commands of this Account. By default these are the commands found in the cmdset defined by
nicks- This stores and handles Nicks, in the same way as nicks it works on Objects. For Accounts, nicks are primarily used to store custom aliases for Channels.
Selection of special methods (see
evennia.DefaultAccount for details):
get_puppet- get a currently puppeted object connected to the Account and a given session id, if any.
puppet_object- connect a session to a puppetable Object.
unpuppet_object- disconnect a session from a puppetable Object.
msg- send text to the Account
execute_cmd- runs a command as if this Account did it.
search- search for Accounts.