Updated rst files to latest wiki.

docs/sphinx/source/wiki/AdminDocs.rst

@@ -1,24 +1,30 @@
 Administrative Documentation
 ============================
 
-The following pages are aimed at game administrators. These are defined
-as the higher-ups that possess shell access and/or are responsible for
-the game.
+The following pages are aimed at game administrators -- the higher-ups
+that possess shell access and/or are responsible for the game.
 
 Installation and Early Life
 ---------------------------
 
 -  `Choosing an SQL Server <ChoosingAnSQLServer.html>`_
 -  `Getting Started - Installing Evennia <GettingStarted.html>`_
--  `Starting, stopping, restarting and resetting
+-  `Starting, stopping, reloading and resetting
    Evennia <StartStopReload.html>`_
 -  `Keeping your game up to date <UpdatingYourGame.html>`_
+
+Customizing the server
+----------------------
+
 -  `Change Evennia's language <Internationalization.html>`_
--  `Collaborate with others using version
-   control <StaffVersionControl.html>`_ (not updated)
--  `Apache Configuration <ApacheConfig.html>`_ (optional)
--  `Text encodings <TextEncodings.html>`_ used when connecting to
-   Evennia
+-  `Apache webserver configuration <ApacheConfig.html>`_ (optional)
+-  `Changing text encodings used by the server <TextEncodings.html>`_
 -  `How to connect Evennia to IRC channels <IRC.html>`_
 -  `How to connect Evennia to an IMC2 network <IMC2.html>`_
 
+Working with Evennia
+--------------------
+
+-  `Setting up your work environment with version
+   control <VersionControl.html>`_
+

docs/sphinx/source/wiki/Attributes.rst

@@ -87,11 +87,12 @@ situations though.
 -  You are worried about database performance. Maybe you are
    reading/storing data many times a second (for whatever reason) or you
    have many players doing things at the same time. Hitting the database
-   over an over might not be ideal in that case. Non-persistent data
-   simply writes to memory, it doesn't hit the database at all. With the
-   speed and quality of hardware these days, this point is probably less
-   likely to be of any big concern except for the most extreme of
-   situations.
+   over and over might not be ideal in that case. Non-persistent data
+   simply writes to memory, it doesn't hit the database at all. It
+   should be said that with the speed and quality of hardware these
+   days, this point is less likely to be of any big concern except for
+   the most extreme of situations. The default database even runs in RAM
+   if possible, alleviating the need to write to disk.
 -  You *want* to loose your state when logging off. Maybe you are
    testing a buggy `Script <Scripts.html>`_ that does potentially
    harmful stuff to your character object. With non-persistent storage
@@ -124,7 +125,8 @@ explicitly to get the result you want. This means writing a little bit
 more, but has the advantage of clarity and portability: If you plan to
 distribute your code to others, it's recommended you use explicit
 assignment. This avoids weird errors when your users don't happen to use
-the save persistence setting as you.
+the save persistence setting as you. The Evennia server distribution
+always use explicit assignment everywhere.
 
 What types of data can I save?
 ------------------------------
@@ -135,22 +137,22 @@ you can practically store any Python object that can be
 the ``pickle`` module to serialize data into the database.
 
 There is one notable type of object that cannot be pickled - and that is
-a Django database object. These will instead be stored as wrapper object
-containing the ID and its database model. It will be read back to a new
-instantiated `typeclass <Typeclasses.html>`_ when the Attribute is
+a Django database object. These will instead be stored as a wrapper
+object containing the ID and its database model. It will be read back to
+a new instantiated `typeclass <Typeclasses.html>`_ when the Attribute is
 accessed. Since erroneously trying to save database objects in an
 Attribute will lead to errors, Evennia will try to detect database
 objects by analyzing the data being stored. This means that Evennia must
 recursively traverse all iterables to make sure all database objects in
-them are stored safely. So for efficiently, it can be a good idea is to
+them are stored safely. So for efficiency, it can be a good idea is to
 avoid deeply nested lists with objects if you can.
 
-To store several objects, you may only use python *lists* or
-*dictionaries* to store them. If you try to save any other form of
-iterable (like a ``set`` or a home-made class), the Attribute will
-convert, store and retrieve it as a list instead. Since you can nest
-dictionaries and lists together in any combination, this is usually not
-a limitation you need to worry about.
+To store several objects, you may only use python *lists*,
+*dictionaries* or *tuples* to store them. If you try to save any other
+form of iterable (like a ``set`` or a home-made class), the Attribute
+will convert, store and retrieve it as a list instead. Since you can
+nest dictionaries, lists and tuples together in any combination, this is
+usually not a limitation you need to worry about.
 
 *Note that you could fool the safety check if you for example created
 custom, non-iterable classes and stored database objects in them. So to
@@ -172,8 +174,23 @@ Examples of valid attribute data:
     # a dictionary
     obj.db.test4 = 'str':34, 'dex':56, 'agi':22, 'int':77
     # a mixed dictionary/list
-    obj.db.test5 = 'members': [obj1,obj2,obj3], 'enemies':[obj4,obj5]# a tuple will stored and returned as a list [1,2,3,4,5]!
-    obj.db.test6 = (1,2,3,4,5)
+    obj.db.test5 = 'members': [obj1,obj2,obj3], 'enemies':[obj4,obj5]
+    # a tuple with a list in it
+    obj.db.test6 = (1,3,4,8, ["test", "test2"], 9)# a set will still be stored and returned as a list [1,2,3,4,5]!
+    obj.db.test7 = set([1,2,3,4,5])
+
+Example of non-supported save:
+
+::
+
+    # this will fool the dbobj-check since myobj (a database object) is "hidden"
+    # inside a custom object. This is unsupported and will lead to unexpected
+    # results! 
+    class BadStorage(object):
+        pass
+    bad = BadStorage()
+    bad.dbobj = myobj
+    obj.db.test8 = bad # this will likely lead to a traceback
 
 Notes
 -----

docs/sphinx/source/wiki/ChoosingAnSQLServer.rst

@@ -12,17 +12,13 @@ page.
 SQLite
 ------
 
-This is the default database used, and for the vast majority of sites
-out there, will probably be more than adequate. No server process is
+This is the default database used, and for the vast majority of Evennia
+installs it will probably be more than adequate. No server process is
 needed, the administrative overhead is tiny (as is resource
 consumption). The database will appear as a simple file
-(``game/evennia.db`` by default). Purging your database is just a matter
-of deleting this file and re-running the database creation commands in
-GettingStarted.
-
-It is not tested how well Evennia performs with SQLite under a heavier
-load, but it should probably be fine given the relative simplicity of
-our applications.
+(``game/evennia.db3``). It is not tested how well Evennia performs with
+SQLite under a heavier load, but it should probably be fine for most
+normal mud-related usage.
 
 **Note:** If you run Windows and for some reason need to use a
 third-party web server like Apache rather than Evennia's internal web
@@ -33,23 +29,19 @@ Windows.
 Postgres
 --------
 
-This is Django's recommended DB engine, and the one that we recommend
-for all sites aspiring to grow to a larger size. While not as fast as
-SQLite for simple purposes, it will scale infinitely better than SQLite,
-especially if your game has an extensive web presence.
+This is Django's recommended database engine, usable for all sites
+aspiring to grow to a larger size. While not as fast as SQLite for
+simple purposes, it will scale infinitely better than SQLite, especially
+if your game has an extensive web presence.
 
 MySQL
 -----
 
-While perfectly reasonable to deploy under, the MySQL driver for Django
-has some very slight oddities (at the time of this document's writing)
-that probably don't affect our usage case that much (if at all). Make
-sure you look at the aforementioned `Notes about supported
-Databases <http://docs.djangoproject.com/en/dev/ref/databases/#ref-databases>`_
-page for the latest on this.
-
 MySQL **may** be slightly faster than Postgres depending on your setup
-and software versions involved.
+and software versions involved. Older versions had some peculiarities
+though, so check out Django's `Notes about supported
+Databases <http://docs.djangoproject.com/en/dev/ref/databases/#ref-databases>`_
+to make sure you use the correct version.
 
 Others
 ------

docs/sphinx/source/wiki/Contributing.rst

@@ -8,7 +8,9 @@ Contributing with Documentation
 
 Evennia depends heavily on good documentation and we are always looking
 for extra eyes and hands to improve it. Even small things such as fixing
-typos is a great help.
+typos is a great help. To edit the wiki yourself you need contributor
+access. Otherwise, it goes a long way just pointing out wiki errors so
+devs can fix them.
 
 Contributing with Code through a clone repository
 -------------------------------------------------

docs/sphinx/source/wiki/DeveloperCentral.rst

@@ -19,8 +19,8 @@ General Evennia development information
    Guide <http://evennia.googlecode.com/svn/trunk/CODING_STYLE>`_
    (Important!)
 -  `Policy for 'MUX-like' default commands <UsingMUXAsAStandard.html>`_
--  `Setting up a Bazaar environment for coding <BazaarDevel.html>`_ (not
-   updated)
+-  `Setting up a Mercurial environment for
+   coding <VersionControl.html>`_
 
 Evennia Component Documentation
 -------------------------------

docs/sphinx/source/wiki/HowToGetAndGiveHelp.rst

@@ -28,8 +28,8 @@ documentation <Index.html>`_, here's what to do:
 How to *give* Help
 ==================
 
-Evennia is a completely non-funded project. It relies on the time
-donated by its users and developers in order to progress.
+Evennia is a completely un-funded project. It relies on the time donated
+by its users and developers in order to progress.
 
 The first and easiest way you as a user can help us out is by taking
 part in `community
@@ -57,5 +57,5 @@ to get going:
 -  Check out the `Contributing <Contributing.html>`_ page on how to
    contribute with code in practice.
 
-In either case, you may find documentation useful to developers in the
-`Developer Central <DeveloperCentral.html>`_.
+See `Contributing to Evennia <Contributing.html>`_ for more detailed
+information.

docs/sphinx/source/wiki/Internationalization.rst

@@ -5,14 +5,14 @@ Internationalization
 characters between the first "i" and the last "n" in that word) allows
 Evennia's core server to return texts in other languages than English -
 without anyone having to go in and add it manually. Take a look at the
-``locale`` directory of the Evennia installation. there you will find
+``locale`` directory of the Evennia installation, there you will find
 which languages are currently supported.
 
 Note, what is translated in this way are hard-coded strings from the
 server, things like "Connection closed" or "Server restarted".
 Basically, the things users are not supposed to change on their own.
 This means that the default command set is *not* translated. The reason
-for this is that commands are *intended* to be modified by users. .
+for this is that commands are *intended* to be modified by users.
 
 Changing server language
 ------------------------
@@ -33,7 +33,7 @@ Translating Evennia
 -------------------
 
 If you cannot find your language in ``locale/`` it's because noone has
-translated it yet. Alternatively you might find the language but find
+translated it yet. Alternatively you might have the language but find
 the translation bad ... You are welcome to help improve the situation!
 
 To start a new translation, place yourself in Evennia's root directory
@@ -43,7 +43,7 @@ and run
 
     django-admin makemessages -l <language-code>
 
-where ``<language-code`` is the two-letter locale code for the language
+where ``<language-code>`` is the two-letter locale code for the language
 you want, like 'sv' for Swedish or 'es' for Spanish.
 
 Next head to ``locale/<language-code>/LC_MESSAGES`` and edit the
@@ -53,9 +53,7 @@ normal text editor -- best is to use a po-file editor from the web
 
 The concept of translating is simple, it's just a matter of taking the
 english strings you find in the ``*.po`` file and add your language's
-translation best you can. When you are done, send the ``*.po`` file to
-the Evennia developer list so we can integrate your translation it into
-Evennia!
+translation best you can.
 
 Finally, you need to compile your translation into a more efficient
 form.
@@ -67,3 +65,7 @@ form.
 This will go through all languages and create/update compiled files
 (``*.mo``) for them. This needs to be done whenever a ``*.po`` file is
 updated.
+
+When you are done, send the ``*.po`` and \*.mo file to the Evennia
+developer list (or push it into your own repository clone) so we can
+integrate your translation into Evennia!

src/server/serversession.py

@@ -50,7 +50,7 @@ class ServerSession(Session):
         if not self.logged_in:
             return 
 
-        player = self.get_player()
+        player = self.get_player(1)
         character = self.get_character()
         if player:
             #print "sync: at_init() - player"