Accounts

┌──────┐ │   ┌───────┐    ┌───────┐   ┌──────┐
│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 exit, who and chat-channel commands are in the Account cmdset.

> ooc

The default 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.

> ic

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 Builder, 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 DefaultAccount).

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

… 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:

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_TYPECLASS to 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 User Django object, representing the logged-in user.

  • obj - an alias for character.

  • name - an alias for user.username

  • 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 sessid on each Session instance.

  • is_superuser (bool: True/False) - if this account is a superuser.

Special handlers:

  • cmdset - This holds all the current Commands of this Account. By default these are the commands found in the cmdset defined by settings.CMDSET_ACCOUNT.

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