Annikka/evennia
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

API fix; the default_commands ended up in the wrong layer

Browse source
This commit is contained in:
Griatch 2012-03-24 23:19:44 +01:00
parent 0d01462077
commit cdbdbe6928
1 changed files with 21 additions and 14 deletions
Download patch file Download diff file Expand all files Collapse all files

35
ev.py
View file

@ -2,24 +2,31 @@
Central API for Evennia MUD/MUX/MU* system. Central API for Evennia MUD/MUX/MU* system.
A simple way to explore Evennia's capabilities is to Import this from ./manage.py shell or set DJANGO_SETTINGS_MODULE manually for proper
import it in a python interpreter where all environment functionality.
variables have been set. Easiest is to do the following:
game/manage.py shell This module tries to group the most commonly useful modules in a flat(ter) structure.
>>> import ev Some notes:
Using ipython is recommended since you will then have tab-completion 1) db_* are shortcuts to initiated versions of Evennia's django database managers (e.g.
and the ability to view docstrings much easier than with the regular db_objects is an alias for ObjectDB.objects). These allows for exploring the database in
python interpreter. various ways. Please note that
the evennia-specific methods in the managers return typeclasses (or lists of
typeclasses), whereas the default django ones (filter etc) return database objects.
You can convert between the two easily via dbobj.typeclass and typeclass.dbobj, but
it's worth to remember.
2) You -have- to use the methods of the "create" module to create new Typeclassed game
entities (Objects, Scripts or Players). Just initializing e.g. the Player class will
-not- set up Typeclasses correctly and will lead to errors. Other types of database objects
can be created normally, but the "create" module offers convenient methods for those too.
3) The API accesses all relevant methods/classes, but might not always include all helper-methods
referenced from each such entity. To get to those, access the modules in src/ directly. You
can always do this anyway, if you do not want to go through this API.
In code, just import via ev.<item> Philosophy is to keep the API as flat as possible, so as to not have to remember which nested
packages to traverse. Most of the important stuff should be made visible from this module.
Philosophy is to keep the API as flat as possible, so as to not have As said, one can of course still import from src/ directly should one prefer!
to remember which nested packages to traverse. Most of the important
stuff should be made visible from this module.
One can of course still import from src/ directly should one prefer!
""" """