Adding a new API system to Evennia. This centralizes all access of the evennia driver through a single module "ev". Importing ev one should be able to access (and also importantly, easily explore) Evennia's API much easier. This API goes a long way to "flatten" the structure so that one doesn't need to remember how to find some method in a deeply nested subdirectory.

As part of this work, I have also written full listings of all available properties on Typeclassed objects (including those inherited in various ways). Should hopefully make things easier to find.
One can of course still import things directly from src/ as before. But this is a first step towards removing the "base" objects in game/gamesrc and instead making those accessible through the core API.
This commit is contained in:
Griatch 2012-03-24 23:02:45 +01:00
parent 7a2cdd3842
commit 0d01462077
24 changed files with 519 additions and 93 deletions

View file

@ -181,20 +181,60 @@ class Player(BasePlayer):
Can be set using BASE_PLAYER_TYPECLASS.
The following hooks are called by the engine. Note that all of the following
are called on the character object too, and mostly at the same time.
at_player_creation() - This is called once, the very first time
the player is created (i.e. first time they
register with the game). It's a good place
to store attributes all players should have,
like configuration values etc.
at_pre_login() - called every time the user connects, after they have
identified, just before the system actually logs them in.
at_post_login() - called at the end of login, just before setting the
player loose in the world.
at_disconnect() - called just before the use is disconnected (this is also
called if the system determines the player lost their link)
* available properties
key (string) - name of player
name (string)- wrapper for user.username
aliases (list of strings) - aliases to the object. Will be saved to database as AliasDB entries but returned as strings.
dbref (int, read-only) - unique #id-number. Also "id" can be used.
dbobj (Player, read-only) - link to database model. dbobj.typeclass points back to this class
typeclass (Player, read-only) - this links back to this class as an identified only. Use self.swap_typeclass() to switch.
date_created (string) - time stamp of object creation
permissions (list of strings) - list of permission strings
user (User, read-only) - django User authorization object
obj (Object) - game object controlled by player. 'character' can also be used.
sessions (list of Sessions) - sessions connected to this player
is_superuser (bool, read-only) - if the connected user is a superuser
* Handlers
locks - lock-handler: use locks.add() to add new lock strings
db - attribute-handler: store/retrieve database attributes on this self.db.myattr=val, val=self.db.myattr
ndb - non-persistent attribute handler: same as db but does not create a database entry when storing data
scripts - script-handler. Add new scripts to object with scripts.add()
cmdset - cmdset-handler. Use cmdset.add() to add new cmdsets to object
nicks - nick-handler. New nicks with nicks.add().
* Helper methods
msg(outgoing_string, from_obj=None, data=None)
swap_character(new_character, delete_old_character=False)
execute_cmd(raw_string)
search(ostring, global_search=False, attribute_name=None, use_nicks=False, location=None, ignore_errors=False, player=False)
is_typeclass(typeclass, exact=False)
swap_typeclass(new_typeclass, clean_attributes=False, no_default=True)
access(accessing_obj, access_type='read', default=False)
check_permstring(permstring)
* Hook methods (when re-implementation, remember methods need to have self as first arg)
basetype_setup()
at_player_creation()
- note that the following hooks are also found on Objects and are
usually handled on the character level:
at_init()
at_cmdset_get()
at_first_login()
at_post_login()
at_disconnect()
at_message_receive()
at_message_send()
at_server_reload()
at_server_shutdown()
"""
pass