Copy doc tools from develop

docs/source/Locks.md

@@ -1,7 +1,7 @@
 # Locks
 
 
-For most games it is a good idea to restrict what people can do. In Evennia such restrictions are applied and checked by something called *locks*. All Evennia entities ([Commands](Commands), [Objects](Objects), [Scripts](Scripts), [Accounts](Accounts), [Help System](Help-System), [messages](Communications#Msg) and [channels](Communications#Channels)) are accessed through locks. 
+For most games it is a good idea to restrict what people can do. In Evennia such restrictions are applied and checked by something called *locks*. All Evennia entities ([Commands](./Commands), [Objects](./Objects), [Scripts](./Scripts), [Accounts](./Accounts), [Help System](./Help-System), [messages](./Communications#Msg) and [channels](./Communications#Channels)) are accessed through locks. 
 
 A lock can be thought of as an "access rule" restricting a particular use of an Evennia entity.  Whenever another entity wants that kind of access the lock will analyze that entity in different ways to determine if access should be granted or not. Evennia implements a "lockdown" philosophy - all entities are inaccessible unless you explicitly define a lock that allows some or full access. 
 
@@ -65,9 +65,9 @@ If you want to make sure the lock is used however, you should pick `access_type`
 
 Below are the access_types checked by the default commandset.
 
-- [Commands](Commands) 
+- [Commands](./Commands) 
   - `cmd` - this defines who may call this command at all.
-- [Objects](Objects):
+- [Objects](./Objects):
   - `control` - who is the "owner" of the object. Can set locks, delete it etc. Defaults to the creator of the object.
   - `call` - who may call Object-commands stored on this Object except for the Object itself. By default, Objects share their Commands with anyone in the same location (e.g. so you can 'press' a `Button` object in the room). For Characters and Mobs (who likely only use those Commands for themselves and don't want to share them) this should usually be turned off completely, using something like `call:false()`. 
   - `examine` - who may examine this object's properties.
@@ -77,25 +77,25 @@ Below are the access_types checked by the default commandset.
   - `get`- who may pick up the object and carry it around.
   - `puppet` - who may "become" this object and control it as their "character".
   - `attrcreate` - who may create new attributes on the object (default True)
-- [Characters](Objects#Characters): 
+- [Characters](./Objects#Characters): 
   - Same as for Objects
-- [Exits](Objects#Exits): 
+- [Exits](./Objects#Exits): 
   - Same as for Objects 
   - `traverse` - who may pass the exit.
-- [Accounts](Accounts):
+- [Accounts](./Accounts):
   - `examine` - who may examine the account's properties.
   - `delete` - who may delete the account.
   - `edit` - who may edit the account's attributes and properties.
   - `msg` - who may send messages to the account.
   - `boot` - who may boot the account.
-- [Attributes](Attributes): (only checked by `obj.secure_attr`)
+- [Attributes](./Attributes): (only checked by `obj.secure_attr`)
   - `attrread` - see/access attribute
   - `attredit` - change/delete attribute
-- [Channels](Communications#Channels):
+- [Channels](./Communications#Channels):
   - `control` - who is administrating the channel. This means the ability to delete the channel, boot listeners etc.
   - `send` - who may send to the channel.
   - `listen` - who may subscribe and listen to the channel.
-- [HelpEntry](Help-System):
+- [HelpEntry](./Help-System):
   - `examine` - who may view this help entry (usually everyone)
   - `edit` - who may edit this help entry.
 
@@ -160,10 +160,10 @@ Some useful default lockfuncs (see `src/locks/lockfuncs.py` for more):
 
 - `true()/all()` - give access to everyone
 - `false()/none()/superuser()` - give access to none. Superusers bypass the check entirely and are thus the only ones who will pass this check.
-- `perm(perm)` - this tries to match a given `permission` property, on an Account firsthand, on a Character second. See [below](Locks#permissions).
+- `perm(perm)` - this tries to match a given `permission` property, on an Account firsthand, on a Character second. See [below](./Locks#permissions).
 - `perm_above(perm)` - like `perm` but requires a "higher" permission level than the one given.
 - `id(num)/dbref(num)` - checks so the access_object has a certain dbref/id.
-- `attr(attrname)` - checks if a certain [Attribute](Attributes) exists on accessing_object.
+- `attr(attrname)` - checks if a certain [Attribute](./Attributes) exists on accessing_object.
 - `attr(attrname, value)` - checks so an attribute exists on accessing_object *and* has the given value.
 - `attr_gt(attrname, value)` - checks so accessing_object has a value larger (`>`) than the given value.
 - `attr_ge, attr_lt, attr_le, attr_ne` - corresponding for `>=`, `<`, `<=` and `!=`.
@@ -187,11 +187,11 @@ Note here that the `access_type` can be left to a dummy value since this method
 
 ## Default locks
 
-Evennia sets up a few basic locks on all new objects and accounts (if we didn't, noone would have any access to anything from the start).  This is all defined in the root [Typeclasses](Typeclasses) of the respective entity, in the hook method `basetype_setup()` (which you usually don't want to edit unless you want to change how basic stuff like rooms and exits store their internal variables). This is called once, before `at_object_creation`, so just put them in the latter method on your child object to change the default. Also creation commands like `create` changes the locks of objects you create - for example it sets the `control` lock_type so as to allow you, its creator, to control and delete the object.
+Evennia sets up a few basic locks on all new objects and accounts (if we didn't, noone would have any access to anything from the start).  This is all defined in the root [Typeclasses](./Typeclasses) of the respective entity, in the hook method `basetype_setup()` (which you usually don't want to edit unless you want to change how basic stuff like rooms and exits store their internal variables). This is called once, before `at_object_creation`, so just put them in the latter method on your child object to change the default. Also creation commands like `create` changes the locks of objects you create - for example it sets the `control` lock_type so as to allow you, its creator, to control and delete the object.
 
 # Permissions
 
-> This section covers the underlying code use of permissions. If you just want to learn how to practically assign permissions in-game, refer to the [Building Permissions](Building-Permissions) page, which details how you use the `perm` command.
+> This section covers the underlying code use of permissions. If you just want to learn how to practically assign permissions in-game, refer to the [Building Permissions](./Building-Permissions) page, which details how you use the `perm` command.
 
 A *permission* is simply a list of text strings stored  in the handler `permissions` on `Objects` and `Accounts`. Permissions can be used as a convenient way to structure access levels and hierarchies. It is set by the `perm` command. Permissions are especially handled by the `perm()` and `pperm()` lock functions listed above. 
 
@@ -233,16 +233,16 @@ Selected permission strings can be organized in a *permission hierarchy* by edit
 
 The main use of this is that if you use the lock function `perm()` mentioned above, a lock check for a particular permission in the hierarchy will *also* grant access to those with *higher* hierarchy access. So if you have the permission "Admin" you will also pass a lock defined as `perm(Builder)` or any of those levels below "Admin". 
 
-When doing an access check from an [Object](Objects) or Character, the `perm()` lock function will always first use the permissions of any Account connected to that Object before checking for permissions on the Object. In the case of hierarchical permissions (Admins, Builders etc), the Account permission will always be used (this stops an Account from escalating their permission by puppeting a high-level Character).  If the permission looked for is not in the hierarchy, an exact match is required, first on the Account and if not found there (or if no Account is connected), then on the Object itself. 
+When doing an access check from an [Object](./Objects) or Character, the `perm()` lock function will always first use the permissions of any Account connected to that Object before checking for permissions on the Object. In the case of hierarchical permissions (Admins, Builders etc), the Account permission will always be used (this stops an Account from escalating their permission by puppeting a high-level Character).  If the permission looked for is not in the hierarchy, an exact match is required, first on the Account and if not found there (or if no Account is connected), then on the Object itself. 
 
 Here is how you use `perm` to give an account more permissions: 
 
      perm/account Tommy = Builders
      perm/account/del Tommy = Builders # remove it again
 
-Note the use of the `/account` switch. It means you assign the permission to the [Accounts](Accounts) Tommy instead of any [Character](Objects) that also happens to be named "Tommy". 
+Note the use of the `/account` switch. It means you assign the permission to the [Accounts](./Accounts) Tommy instead of any [Character](./Objects) that also happens to be named "Tommy". 
 
-Putting permissions on the *Account* guarantees that they are kept, *regardless* of which Character they are currently puppeting. This is especially important to remember when assigning permissions from the *hierarchy tree* - as mentioned above, an Account's permissions will overrule that of its character. So to be sure to avoid confusion you should generally put hierarchy permissions on the Account, not on their Characters (but see also [quelling](Locks#Quelling)).
+Putting permissions on the *Account* guarantees that they are kept, *regardless* of which Character they are currently puppeting. This is especially important to remember when assigning permissions from the *hierarchy tree* - as mentioned above, an Account's permissions will overrule that of its character. So to be sure to avoid confusion you should generally put hierarchy permissions on the Account, not on their Characters (but see also [quelling](./Locks#Quelling)).
 
 Below is an example of an object without any connected account
 
@@ -300,7 +300,7 @@ This is how the `create` command sets up new objects. In sequence, this permissi
 
 ## A complete example of setting locks on an object
 
-Assume we have two objects - one is ourselves (not superuser) and the other is an [Object](Objects) called `box`. 
+Assume we have two objects - one is ourselves (not superuser) and the other is an [Object](./Objects) called `box`. 
 
      > create/drop box
      > desc box = "This is a very big and heavy box."
@@ -320,7 +320,7 @@ Ok, so for testing we made ourselves strong, but not strong enough.  Now we need
         return
 ```
 
-So the `get` command looks for a lock with the type *get* (not so surprising). It also looks for an [Attribute](Attributes) on the checked object called _get_err_msg_ in order to return a customized error message. Sounds good! Let's start by setting that on the box: 
+So the `get` command looks for a lock with the type *get* (not so surprising). It also looks for an [Attribute](./Attributes) on the checked object called _get_err_msg_ in order to return a customized error message. Sounds good! Let's start by setting that on the box: 
 
      > set box/get_err_msg = You are not strong enough to lift this box.