Andreas/evennia
1
0
Fork 0
mirror of https://github.com/evennia/evennia.git synced 2026-03-31 13:07:16 +02:00
Code Issues Projects Releases Packages Wiki Activity Actions 1

Fixed all errors in doc building

Browse source
This commit is contained in:
Griatch 2020-07-11 00:14:13 +02:00
parent 9fbfc8f8d0
commit 76761825d0
80 changed files with 766 additions and 767 deletions
Download patch file Download diff file Expand all files Collapse all files

24
docs/source/Component/Accounts.md
View file

@ -1,27 +1,27 @@
# Accounts
All *users* (real people) that starts a game [Session](Sessions) on Evennia are doing so through an
All *users* (real people) that starts a game [Session](./Sessions) on Evennia are doing so through an
object called *Account*. The Account object has no in-game representation, it represents a unique
game account. In order to actually get on the game the Account must *puppet* an [Object](Objects)
(normally a [Character](Objects#Character)).
game account. In order to actually get on the game the Account must *puppet* an [Object](./Objects)
(normally a [Character](./Objects#Character)).
Exactly how many Sessions can interact with an Account and its Puppets at once is determined by
Evennia's [MULTISESSION_MODE](Sessions#Multisession-mode) setting.
Evennia's [MULTISESSION_MODE](./Sessions#Multisession-mode) setting.
Apart from storing login information and other account-specific data, the Account object is what is
chatting on [Channels](Communications). It is also a good place to store [Permissions](Locks) to be
chatting on [Channels](./Communications). It is also a good place to store [Permissions](./Locks) to be
consistent between different in-game characters as well as configuration options. The Account
object also has its own [CmdSet](Command-Sets), the `AccountCmdSet`.
object also has its own [CmdSet](./Command-Sets), the `AccountCmdSet`.
Logged into default evennia, you can use the `ooc` command to leave your current
[character](Objects) and go into OOC mode. You are quite limited in this mode, basically it works
[character](./Objects) and go into OOC mode. You are quite limited in this mode, basically it works
like a simple chat program. It acts as a staging area for switching between Characters (if your
game supports that) or as a safety mode if your Character gets deleted. Use `ic` to attempt to
(re)puppet a Character.
Note that the Account object can have, and often does have, a different set of
[Permissions](Locks#Permissions) from the Character they control. Normally you should put your
[Permissions](./Locks#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
@ -76,7 +76,7 @@ You should now see the Attributes on yourself.
## Properties on Accounts
Beyond those properties assigned to all typeclassed objects (see [Typeclasses](Typeclasses)), the
Beyond those properties assigned to all typeclassed objects (see [Typeclasses](./Typeclasses)), the
Account also has the following custom properties:
- `user` - a unique link to a `User` Django object, representing the logged-in user.
@ -91,11 +91,11 @@ as
- `is_superuser` (bool: True/False) - if this account is a superuser.
Special handlers:
- `cmdset` - This holds all the current [Commands](Commands) of this Account. By default these are
- `cmdset` - This holds all the current [Commands](./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](Nicks), in the same way as nicks it works on Objects.
- `nicks` - This stores and handles [Nicks](./Nicks), in the same way as nicks it works on Objects.
For Accounts, nicks are primarily used to store custom aliases for
[Channels](Communications#Channels).
[Channels](./Communications#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

30
docs/source/Component/Attributes.md
View file

@ -7,8 +7,8 @@ can give correct subsequent commands. If you are writing a combat system, you mi
combattant's next roll get easier dependent on if their opponent failed. Your characters will
probably need to store roleplaying-attributes like strength and agility. And so on.
[Typeclassed](Typeclasses) game entities ([Accounts](Accounts), [Objects](Objects),
[Scripts](Scripts) and [Channels](Communications)) always have *Attributes* associated with them.
[Typeclassed](./Typeclasses) game entities ([Accounts](./Accounts), [Objects](./Objects),
[Scripts](./Scripts) and [Channels](./Communications)) always have *Attributes* associated with them.
Attributes are used to store any type of data 'on' such entities. This is different from storing
data in properties already defined on entities (such as `key` or `location`) - these have very
specific names and require very specific types of data (for example you couldn't assign a python
@ -16,12 +16,12 @@ specific names and require very specific types of data (for example you couldn't
want to assign arbitrary data to arbitrary names.
**Attributes are _not_ secure by default and any player may be able to change them unless you
[prevent this behavior](Attributes#locking-and-checking-attributes).**
[prevent this behavior](./Attributes#locking-and-checking-attributes).**
## The .db and .ndb shortcuts
To save persistent data on a Typeclassed object you normally use the `db` (DataBase) operator. Let's
try to save some data to a *Rose* (an [Object](Objects)):
try to save some data to a *Rose* (an [Object](./Objects)):
```python
# saving
@ -87,13 +87,13 @@ The handlers have normal access methods that allow you to manage and retrieve `A
returned, but the method takes keywords for returning the Attribute object itself. By supplying an
`accessing_object` to the call one can also make sure to check permissions before modifying
anything.
- `add(...)` - this adds a new Attribute to the object. An optional [lockstring](Locks) can be
- `add(...)` - this adds a new Attribute to the object. An optional [lockstring](./Locks) can be
supplied here to restrict future access and also the call itself may be checked against locks.
- `remove(...)` - Remove the given Attribute. This can optionally be made to check for permission
before performing the deletion. - `clear(...)` - removes all Attributes from object.
- `all(...)` - returns all Attributes (of the given category) attached to this object.
See [this section](Attributes#locking-and-checking-attributes) for more about locking down Attribute
See [this section](./Attributes#locking-and-checking-attributes) for more about locking down Attribute
access and editing. The `Nattribute` offers no concept of access control.
Some examples:
@ -118,23 +118,23 @@ An Attribute object is stored in the database. It has the following properties:
to `attrname`.
- `value` - this is the value of the Attribute. This value can be anything which can be pickled -
objects, lists, numbers or what have you (see
[this section](Attributes#What_types_of_data_can_I_save_in_an_Attribute) for more info). In the
[this section](./Attributes#What_types_of_data_can_I_save_in_an_Attribute) for more info). In the
example
`obj.db.attrname = value`, the `value` is stored here.
- `category` - this is an optional property that is set to None for most Attributes. Setting this
allows to use Attributes for different functionality. This is usually not needed unless you want
to use Attributes for very different functionality ([Nicks](Nicks) is an example of using
to use Attributes for very different functionality ([Nicks](./Nicks) is an example of using
Attributes
in this way). To modify this property you need to use the [Attribute
Handler](Attributes#The_Attribute_Handler).
- `strvalue` - this is a separate value field that only accepts strings. This severely limits the
data possible to store, but allows for easier database lookups. This property is usually not used
except when re-using Attributes for some other purpose ([Nicks](Nicks) use it). It is only
accessible via the [Attribute Handler](Attributes#The_Attribute_Handler).
except when re-using Attributes for some other purpose ([Nicks](./Nicks) use it). It is only
accessible via the [Attribute Handler](./Attributes#The_Attribute_Handler).
There are also two special properties:
- `attrtype` - this is used internally by Evennia to separate [Nicks](Nicks), from Attributes (Nicks
- `attrtype` - this is used internally by Evennia to separate [Nicks](./Nicks), from Attributes (Nicks
use Attributes behind the scenes).
- `model` - this is a *natural-key* describing the model this Attribute is attached to. This is on
the form *appname.modelclass*, like `objects.objectdb`. It is used by the Attribute and
@ -162,7 +162,7 @@ default
during heavy loads.
- A more valid reason for using non-persistent data is if you *want* to lose your state when logging
off. Maybe you are storing throw-away data that are re-initialized at server startup. Maybe you
are implementing some caching of your own. Or maybe you are testing a buggy [Script](Scripts) that
are implementing some caching of your own. Or maybe you are testing a buggy [Script](./Scripts) that
does potentially harmful stuff to your character object. With non-persistent storage you can be
sure
that whatever is messed up, it's nothing a server reboot can't clear up.
@ -192,7 +192,7 @@ not a big deal. But if you are accessing the Attribute as part of some big loop
amount of reads/writes you should first extract it to a temporary variable, operate on *that* and
then save the result back to the Attribute. If you are storing a more complex structure like a
`dict` or a `list` you should make sure to "disconnect" it from the database before looping over it,
as mentioned in the [Retrieving Mutable Objects](Attributes#retrieving-mutable-objects) section
as mentioned in the [Retrieving Mutable Objects](./Attributes#retrieving-mutable-objects) section
below.
### Storing single objects
@ -248,7 +248,7 @@ containing dicts, etc.
Since you can use any combination of the above iterables, this is generally not much of a
limitation.
Any entity listed in the [Single object](Attributes#Storing-Single-Objects) section above can be
Any entity listed in the [Single object](./Attributes#Storing-Single-Objects) section above can be
stored in the iterable.
> As mentioned in the previous section, database entities (aka typeclasses) are not possible to
@ -355,7 +355,7 @@ already disconnected from the database from the onset.
Attributes are normally not locked down by default, but you can easily change that for individual
Attributes (like those that may be game-sensitive in games with user-level building).
First you need to set a *lock string* on your Attribute. Lock strings are specified [Locks](Locks).
First you need to set a *lock string* on your Attribute. Lock strings are specified [Locks](./Locks).
The relevant lock types are
- `attrread` - limits who may read the value of the Attribute

4
docs/source/Component/Batch-Code-Processor.md
View file

@ -1,7 +1,7 @@
# Batch Code Processor
For an introduction and motivation to using batch processors, see [here](Batch-Processors). This
For an introduction and motivation to using batch processors, see [here](./Batch-Processors). This
page describes the Batch-*code* processor. The Batch-*command* one is covered [here](Batch-Command-
Processor).
@ -192,7 +192,7 @@ connect that room with a room you built in the current block. There are two ways
- Perform a database search for the name of the room you created (since you cannot know in advance
which dbref it got assigned). The problem is that a name may not be unique (you may have a lot of "A
dark forest" rooms). There is an easy way to handle this though - use [Tags](Tags) or *Aliases*. You
dark forest" rooms). There is an easy way to handle this though - use [Tags](./Tags) or *Aliases*. You
can assign any number of tags and/or aliases to any object. Make sure that one of those tags or
aliases is unique to the room (like "room56") and you will henceforth be able to always uniquely
search and find it later.

4
docs/source/Component/Batch-Command-Processor.md
View file

@ -1,7 +1,7 @@
# Batch Command Processor
For an introduction and motivation to using batch processors, see [here](Batch-Processors). This
For an introduction and motivation to using batch processors, see [here](./Batch-Processors). This
page describes the Batch-*command* processor. The Batch-*code* one is covered [here](Batch-Code-
Processor).
@ -152,7 +152,7 @@ when creating the file, so that you can 'walk' (or teleport) to the right places
This also means there are several pitfalls when designing and adding certain types of objects. Here
are some examples:
- *Rooms that change your [Command Set](Command-Sets)*: Imagine that you build a 'dark' room, which
- *Rooms that change your [Command Set](./Command-Sets)*: Imagine that you build a 'dark' room, which
severely limits the cmdsets of those entering it (maybe you have to find the light switch to
proceed). In your batch script you would create this room, then teleport to it - and promptly be
shifted into the dark state where none of your normal build commands work ...

4
docs/source/Component/Batch-Processors.md
View file

@ -35,8 +35,8 @@ just list in-game commands in a text file. The code-processor on the other hand
powerful but also more complex - it lets you use Evennia's API to code your world in full-fledged
Python code.
- The [Batch Command Processor](Batch-Command-Processor)
- The [Batch Code Processor](Batch-Code-Processor)
- The [Batch Command Processor](./Batch-Command-Processor)
- The [Batch Code Processor](./Batch-Code-Processor)
If you plan to use international characters in your batchfiles you are wise to read about *file
encodings* below.

2
docs/source/Component/Channels.md
View file

@ -1,3 +1,3 @@
# Channels
TODO: Channels are covered in [Communications](Communications) right now.
TODO: Channels are covered in [Communications](./Communications) right now.

6
docs/source/Component/Coding-Utils.md
View file

@ -181,13 +181,13 @@ number of seconds. This is a very light wrapper over a Twisted
non-persistently, which means that if the server is `@reload`ed before the delay is over, the
callback will never run (the server forgets it). If setting `persistent` to True, the delay will be
stored in the database and survive a `@reload` - but for this to work it is susceptible to the same
limitations incurred when saving to an [Attribute](Attributes).
limitations incurred when saving to an [Attribute](./Attributes).
The `deferred` return object can usually be ignored, but calling its `.cancel()` method will abort
the delay prematurely.
`utils.delay` is the lightest form of delayed call in Evennia. For other way to create time-bound
tasks, see the [TickerHandler](TickerHandler) and [Scripts](Scripts).
tasks, see the [TickerHandler](./TickerHandler) and [Scripts](./Scripts).
> Note that many delayed effects can be achieved without any need for an active timer. For example
if you have a trait that should recover a point every 5 seconds you might just need its value when
@ -203,7 +203,7 @@ classes, instances or python-paths-to-classes.
Note that Python code should usually work with [duck
typing](http://en.wikipedia.org/wiki/Duck_typing). But in Evennia's case it can sometimes be useful
to check if an object inherits from a given [Typeclass](Typeclasses) as a way of identification. Say
to check if an object inherits from a given [Typeclass](./Typeclasses) as a way of identification. Say
for example that we have a typeclass *Animal*. This has a subclass *Felines* which in turn has a
subclass *HouseCat*. Maybe there are a bunch of other animal types too, like horses and dogs. Using
`inherits_from` will allow you to check for all animals in one go:

18
docs/source/Component/Command-Sets.md
View file

@ -1,7 +1,7 @@
# Command Sets
Command Sets are intimately linked with [Commands](Commands) and you should be familiar with
Command Sets are intimately linked with [Commands](./Commands) and you should be familiar with
Commands before reading this page. The two pages were split for ease of reading.
A *Command Set* (often referred to as a CmdSet or cmdset) is the basic unit for storing one or more
@ -11,7 +11,7 @@ classes in a command set is the way to make commands available to use in your ga
When storing a CmdSet on an object, you will make the commands in that command set available to the
object. An example is the default command set stored on new Characters. This command set contains
all the useful commands, from `look` and `inventory` to `@dig` and `@reload`
([permissions](Locks#Permissions) then limit which players may use them, but that's a separate
([permissions](./Locks#Permissions) then limit which players may use them, but that's a separate
topic).
When an account enters a command, cmdsets from the Account, Character, its location, and elsewhere
@ -116,7 +116,7 @@ adding commands, read the [Step by step tutorial](../Howto/Starting/Part1/Adding
customize which command sets are added to your objects by using `self.cmdset.add()` or
`self.cmdset.add_default()`.
> Important: Commands are identified uniquely by key *or* alias (see [Commands](Commands)). If any
> Important: Commands are identified uniquely by key *or* alias (see [Commands](./Commands)). If any
overlap exists, two commands are considered identical. Adding a Command to a command set that
already has an identical command will *replace* the previous command. This is very important. You
must take this behavior into account when attempting to overload any default Evennia commands with
@ -127,7 +127,7 @@ new one that has a matching alias.
There are several extra flags that you can set on CmdSets in order to modify how they work. All are
optional and will be set to defaults otherwise. Since many of these relate to *merging* cmdsets,
you might want to read the [Adding and Merging Command Sets](Command-Sets#adding-and-merging-
you might want to read the [Adding and Merging Command Sets](./Command-Sets#adding-and-merging-
command-sets) section for some of these to make sense.
- `key` (string) - an identifier for the cmdset. This is optional, but should be unique. It is used
@ -195,15 +195,15 @@ priority determines what is used.
## Command Sets Searched
When a user issues a command, it is matched against the [merged](Command-Sets#adding-and-merging-
When a user issues a command, it is matched against the [merged](./Command-Sets#adding-and-merging-
command-sets) command sets available to the player at the moment. Which those are may change at any
time (such as when the player walks into the room with the `Window` object described earlier).
The currently valid command sets are collected from the following sources:
- The cmdsets stored on the currently active [Session](Sessions). Default is the empty
- The cmdsets stored on the currently active [Session](./Sessions). Default is the empty
`SessionCmdSet` with merge priority `-20`.
- The cmdsets defined on the [Account](Accounts). Default is the AccountCmdSet with merge priority
- The cmdsets defined on the [Account](./Accounts). Default is the AccountCmdSet with merge priority
`-10`.
- All cmdsets on the Character/Object (assuming the Account is currently puppeting such a
Character/Object). Merge priority `0`.
@ -215,14 +215,14 @@ included if `no_objs` option is active in the merge stack.
`no_objs` option is active in the merge stack.
- The cmdsets of Exits in the location. Merge priority `+101`. Will not be included if `no_exits`
*or* `no_objs` option is active in the merge stack.
- The [channel](Communications) cmdset containing commands for posting to all channels the account
- The [channel](./Communications) cmdset containing commands for posting to all channels the account
or character is currently connected to. Merge priority `+101`. Will not be included if `no_channels`
option is active in the merge stack.
Note that an object does not *have* to share its commands with its surroundings. A Character's
cmdsets should not be shared for example, or all other Characters would get multi-match errors just
by being in the same room. The ability of an object to share its cmdsets is managed by its `call`
[lock](Locks). For example, [Character objects](Objects) defaults to `call:false()` so that any
[lock](./Locks). For example, [Character objects](./Objects) defaults to `call:false()` so that any
cmdsets on them can only be accessed by themselves, not by other objects around them. Another
example might be to lock an object with `call:inside()` to only make their commands available to
objects inside them, or `cmd:holds()` to make their commands available only if they are held.

52
docs/source/Component/Commands.md
View file

@ -1,14 +1,14 @@
# Commands
Commands are intimately linked to [Command Sets](Command-Sets) and you need to read that page too to
Commands are intimately linked to [Command Sets](./Command-Sets) and you need to read that page too to
be familiar with how the command system works. The two pages were split for easy reading.
The basic way for users to communicate with the game is through *Commands*. These can be commands
directly related to the game world such as *look*, *get*, *drop* and so on, or administrative
commands such as *examine* or *@dig*.
The [default commands](Default-Command-Help) coming with Evennia are 'MUX-like' in that they use @
The [default commands](./Default-Command-Help) coming with Evennia are 'MUX-like' in that they use @
for admin commands, support things like switches, syntax with the '=' symbol etc, but there is
nothing that prevents you from implementing a completely different command scheme for your game. You
can find the default commands in `evennia/commands/default`. You should not edit these directly -
@ -16,7 +16,7 @@ they will be updated by the Evennia team as new features are added. Rather you s
for inspiration and inherit your own designs from them.
There are two components to having a command running - the *Command* class and the
[Command Set](Command-Sets) (command sets were split into a separate wiki page for ease of reading).
[Command Set](./Command-Sets) (command sets were split into a separate wiki page for ease of reading).
1. A *Command* is a python class containing all the functioning code for what a command does - for
example, a *get* command would contain code for picking up objects.
@ -28,7 +28,7 @@ object in various ways. Consider a "Tree" object with a cmdset defining the comm
*chop down*. Or a "Clock" with a cmdset containing the single command *check time*.
This page goes into full detail about how to use Commands. To fully use them you must also read the
page detailing [Command Sets](Command-Sets). There is also a step-by-step
page detailing [Command Sets](./Command-Sets). There is also a step-by-step
[Adding Command Tutorial](../Howto/Starting/Part1/Adding-Commands) that will get you started quickly without the
extra explanations.
@ -81,15 +81,15 @@ In Evennia there are three types of objects that may call the command. It is im
of this since this will also assign appropriate `caller`, `session`, `sessid` and `account`
properties on the command body at runtime. Most often the calling type is `Session`.
* A [Session](Sessions). This is by far the most common case when a user is entering a command in
* A [Session](./Sessions). This is by far the most common case when a user is entering a command in
their client.
* `caller` - this is set to the puppeted [Object](Objects) if such an object exists. If no
* `caller` - this is set to the puppeted [Object](./Objects) if such an object exists. If no
puppet is found, `caller` is set equal to `account`. Only if an Account is not found either (such as
before being logged in) will this be set to the Session object itself.
* `session` - a reference to the [Session](Sessions) object itself.
* `session` - a reference to the [Session](./Sessions) object itself.
* `sessid` - `sessid.id`, a unique integer identifier of the session.
* `account` - the [Account](Accounts) object connected to this Session. None if not logged in.
* An [Account](Accounts). This only happens if `account.execute_cmd()` was used. No Session
* `account` - the [Account](./Accounts) object connected to this Session. None if not logged in.
* An [Account](./Accounts). This only happens if `account.execute_cmd()` was used. No Session
information can be obtained in this case.
* `caller` - this is set to the puppeted Object if such an object can be determined (without
Session info this can only be determined in `MULTISESSION_MODE=0` or `1`). If no puppet is found,
@ -97,7 +97,7 @@ this is equal to `account`.
* `session` - `None*`
* `sessid` - `None*`
* `account` - Set to the Account object.
* An [Object](Objects). This only happens if `object.execute_cmd()` was used (for example by an
* An [Object](./Objects). This only happens if `object.execute_cmd()` was used (for example by an
NPC).
* `caller` - This is set to the calling Object in question.
* `session` - `None*`
@ -120,10 +120,10 @@ it the following properties:
- `caller` - The character BigGuy, in this example. This is a reference to the object executing the
command. The value of this depends on what type of object is calling the command; see the previous
section.
- `session` - the [Session](Sessions) Bob uses to connect to the game and control BigGuy (see also
- `session` - the [Session](./Sessions) Bob uses to connect to the game and control BigGuy (see also
previous section).
- `sessid` - the unique id of `self.session`, for quick lookup.
- `account` - the [Account](Accounts) Bob (see previous section).
- `account` - the [Account](./Accounts) Bob (see previous section).
- `cmdstring` - the matched key for the command. This would be *look* in our example.
- `args` - this is the rest of the string, except the command name. So if the string entered was
*look at sword*, `args` would be " *at sword*". Note the space kept - Evennia would correctly
@ -131,7 +131,7 @@ interpret `lookat sword` too. This is useful for things like `/switches` that sh
In the `MuxCommand` class used for default commands, this space is stripped. Also see the
`arg_regex` property if you want to enforce a space to make `lookat sword` give a command-not-found
error.
- `obj` - the game [Object](Objects) on which this command is defined. This need not be the caller,
- `obj` - the game [Object](./Objects) on which this command is defined. This need not be the caller,
but since `look` is a common (default) command, this is probably defined directly on *BigGuy* - so
`obj` will point to BigGuy. Otherwise `obj` could be an Account or any interactive object with
commands defined on it, like in the example of the "check time" command defined on a "Clock" object.
@ -169,7 +169,7 @@ key can consist of more than one word, like "press button" or "pull left lever".
either matches. This is important for merging cmdsets described below.
- `aliases` (optional list) - a list of alternate names for the command (`["glance", "see", "l"]`).
Same name rules as for `key` applies.
- `locks` (string) - a [lock definition](Locks), usually on the form `cmd:<lockfuncs>`. Locks is a
- `locks` (string) - a [lock definition](./Locks), usually on the form `cmd:<lockfuncs>`. Locks is a
rather big topic, so until you learn more about locks, stick to giving the lockstring `"cmd:all()"`
to make the command available to everyone (if you don't provide a lock string, this will be assigned
for you).
@ -181,9 +181,9 @@ by the next command by retrieving `self.caller.ndb.last_cmd`. The next run comma
or replace the storage.
- `arg_regex` (optional raw string): Used to force the parser to limit itself and tell it when the
command-name ends and arguments begin (such as requiring this to be a space or a /switch). This is
done with a regular expression. [See the arg_regex section](Commands#on-arg_regex) for the details.
done with a regular expression. [See the arg_regex section](./Commands#on-arg_regex) for the details.
- `auto_help` (optional boolean). Defaults to `True`. This allows for turning off the
[auto-help system](Help-System#command-auto-help-system) on a per-command basis. This could be useful if you
[auto-help system](./Help-System#command-auto-help-system) on a per-command basis. This could be useful if you
either want to write your help entries manually or hide the existence of a command from `help`'s
generated list.
- `is_exit` (bool) - this marks the command as being used for an in-game exit. This is, by default,
@ -219,7 +219,7 @@ from this method will be returned from the execution as a Twisted Deferred.
Finally, you should always make an informative [doc
string](http://www.python.org/dev/peps/pep-0257/#what-is-a-docstring) (`__doc__`) at the top of your
class. This string is dynamically read by the [Help System](Help-System) to create the help entry
class. This string is dynamically read by the [Help System](./Help-System) to create the help entry
for this command. You should decide on a way to format your help and stick to that.
Below is how you define a simple alternative "`smile`" command:
@ -277,7 +277,7 @@ default commands thus need to implement `parse()` at all, but can assume the
incoming string is already split up and parsed in suitable ways by its parent.
Before you can actually use the command in your game, you must now store it
within a *command set*. See the [Command Sets](Command-Sets) page.
within a *command set*. See the [Command Sets](./Command-Sets) page.
### On arg_regex
@ -428,7 +428,7 @@ will show.
> Note again that the `yield` keyword does not store state. If the game reloads while waiting for
the user to answer, the user will have to start over. It is not a good idea to use `yield` for
important or complex choices, a persistent [EvMenu](EvMenu) might be more appropriate in this case.
important or complex choices, a persistent [EvMenu](./EvMenu) might be more appropriate in this case.
## System commands
@ -458,7 +458,7 @@ display the "Huh?" error message.
matches.
- User is not allowed to execute the command (`syscmdkeys.CMD_NOPERM`) - Default is to display the
"Huh?" error message.
- Channel (`syscmdkeys.CMD_CHANNEL`) - This is a [Channel](Communications) name of a channel you are
- Channel (`syscmdkeys.CMD_CHANNEL`) - This is a [Channel](./Communications) name of a channel you are
subscribing to - Default is to relay the command's argument to that channel. Such commands are
created by the Comm system on the fly depending on your subscriptions.
- New session connection (`syscmdkeys.CMD_LOGINSTART`). This command name should be put in the
@ -485,7 +485,7 @@ work.
Normally Commands are created as fixed classes and used without modification. There are however
situations when the exact key, alias or other properties is not possible (or impractical) to pre-
code ([Exits](Commands#Exits) is an example of this).
code ([Exits](./Commands#Exits) is an example of this).
To create a command with a dynamic call signature, first define the command body normally in a class
(set your `key`, `aliases` to default values), then use the following call (assuming the command
@ -509,10 +509,10 @@ make your command completely customized at run-time.
*Note: This is an advanced topic.*
Exits are examples of the use of a [Dynamic Command](Commands#Dynamic_Commands).
Exits are examples of the use of a [Dynamic Command](./Commands#Dynamic_Commands).
The functionality of [Exit](Objects) objects in Evennia is not hard-coded in the engine. Instead
Exits are normal [typeclassed](Typeclasses) objects that auto-create a [CmdSet](Commands#CmdSets) on
The functionality of [Exit](./Objects) objects in Evennia is not hard-coded in the engine. Instead
Exits are normal [typeclassed](./Typeclasses) objects that auto-create a [CmdSet](./Commands#CmdSets) on
themselves when they load. This cmdset has a single dynamically created Command with the same
properties (key, aliases and locks) as the Exit object itself. When entering the name of the exit,
this dynamic exit-command is triggered and (after access checks) moves the Character to the exit's
@ -610,9 +610,9 @@ cmdset, ignore.
- CmdSets defined on the current account, if caller is a puppeted object.
- CmdSets defined on the Session itself.
- The active CmdSets of eventual objects in the same location (if any). This includes commands
on [Exits](Objects#Exits).
on [Exits](./Objects#Exits).
- Sets of dynamically created *System commands* representing available
[Communications](Communications#Channels).
[Communications](./Communications#Channels).
7. All CmdSets *of the same priority* are merged together in groups. Grouping avoids order-
dependent issues of merging multiple same-prio sets onto lower ones.
8. All the grouped CmdSets are *merged* in reverse priority into one combined CmdSet according to

16
docs/source/Component/Communications.md
View file

@ -12,7 +12,7 @@ mimics the API of a `Msg` but has no connection to the database.
## Msg
The `Msg` object is the basic unit of communication in Evennia. A message works a little like an
e-mail; it always has a sender (a [Account](Accounts)) and one or more recipients. The recipients
e-mail; it always has a sender (a [Account](./Accounts)) and one or more recipients. The recipients
may be either other Accounts, or a *Channel* (see below). You can mix recipients to send the message
to both Channels and Accounts if you like.
@ -22,16 +22,16 @@ have 'mailboxes' with the messages they want to keep.
### Properties defined on `Msg`
- `senders` - this is a reference to one or many [Account](Accounts) or [Objects](Objects) (normally
- `senders` - this is a reference to one or many [Account](./Accounts) or [Objects](./Objects) (normally
*Characters*) sending the message. This could also be an *External Connection* such as a message
coming in over IRC/IMC2 (see below). There is usually only one sender, but the types can also be
mixed in any combination.
- `receivers` - a list of target [Accounts](Accounts), [Objects](Objects) (usually *Characters*) or
- `receivers` - a list of target [Accounts](./Accounts), [Objects](./Objects) (usually *Characters*) or
*Channels* to send the message to. The types of receivers can be mixed in any combination.
- `header` - this is a text field for storing a title or header for the message.
- `message` - the actual text being sent.
- `date_sent` - when message was sent (auto-created).
- `locks` - a [lock definition](Locks).
- `locks` - a [lock definition](./Locks).
- `hide_from` - this can optionally hold a list of objects, accounts or channels to hide this `Msg`
from. This relationship is stored in the database primarily for optimization reasons, allowing for
quickly post-filter out messages not intended for a given target. There is no in-game methods for
@ -48,16 +48,16 @@ system expecting a `Msg` but when you don't actually want to save anything.
## Channels
Channels are [Typeclassed](Typeclasses) entities, which mean they can be easily extended and their
Channels are [Typeclassed](./Typeclasses) entities, which mean they can be easily extended and their
functionality modified. To change which channel typeclass Evennia uses, change
settings.BASE_CHANNEL_TYPECLASS.
Channels act as generic distributors of messages. Think of them as "switch boards" redistributing
`Msg` or `TempMsg` objects. Internally they hold a list of "listening" objects and any `Msg` (or
`TempMsg`) sent to the channel will be distributed out to all channel listeners. Channels have
[Locks](Locks) to limit who may listen and/or send messages through them.
[Locks](./Locks) to limit who may listen and/or send messages through them.
The *sending* of text to a channel is handled by a dynamically created [Command](Commands) that
The *sending* of text to a channel is handled by a dynamically created [Command](./Commands) that
always have the same name as the channel. This is created for each channel by the global
`ChannelHandler`. The Channel command is added to the Account's cmdset and normal command locks are
used to determine which channels are possible to write to. When subscribing to a channel, you can
@ -109,5 +109,5 @@ for channel communication (since the default ChannelCommand instead logs to a fi
- `aliases` - alternative native names for channels
- `desc` - optional description of channel (seen in listings)
- `keep_log` (bool) - if the channel should store messages (default)
- `locks` - A [lock definition](Locks). Channels normally use the access_types `send, control` and
- `locks` - A [lock definition](./Locks). Channels normally use the access_types `send, control` and
`listen`.

68
docs/source/Component/Component-Overview.md
View file

@ -5,49 +5,49 @@ than, the doc-strings of each component in the [API](../Evennia-API).
## Database entites
- [Typeclasses](Typeclasses)
- [Sessions](Sessions)
- [Acccounts](Accounts)
- [Typeclasses](./Typeclasses)
- [Sessions](./Sessions)
- [Acccounts](./Accounts)
- [Guests](../Concept/Guest-Logins)
- [Objects](Objects)
- [Scripts](Scripts)
- [Channels and Messages](Communications)
- [Attributes](Attributes)
- [Nicks](Nicks)
- [Tags](Tags)
- [Help system](Help-System)
- [Spawner and prototypes](Spawner-and-Prototypes)
- [Objects](./Objects)
- [Scripts](./Scripts)
- [Channels and Messages](./Communications)
- [Attributes](./Attributes)
- [Nicks](./Nicks)
- [Tags](./Tags)
- [Help system](./Help-System)
- [Spawner and prototypes](./Spawner-and-Prototypes)
## Commands
- [Command-System](Command system)
- [Command-Sets](Command-Sets)
- [Commands](Commands)
- [The Connection Screen](Connection-Screen)
- [Available default Commands](Default-Command-Help)
- [Batch-Processors](Batch-Processors)
- [Batch-Code-Processor](Batch-Code-Processor)
- [Batch-Command-Processor](Batch-Command-Processor)
- [Command-Sets](./Command-Sets)
- [Commands](./Commands)
- [The Connection Screen](./Connection-Screen)
- [Available default Commands](./Default-Command-Help)
- [Batch-Processors](./Batch-Processors)
- [Batch-Code-Processor](./Batch-Code-Processor)
- [Batch-Command-Processor](./Batch-Command-Processor)
## Utils
- [Coding-Utils](Coding-Utils)
- [EvEditor](EvEditor)
- [EvMenu](EvMenu)
- [EvMore](EvMore)
- [MonitorHandler](MonitorHandler)
- [TickerHandler](TickerHandler)
- [Lock system](Locks)
- [Coding-Utils](./Coding-Utils)
- [EvEditor](./EvEditor)
- [EvMenu](./EvMenu)
- [EvMore](./EvMore)
- [MonitorHandler](./MonitorHandler)
- [TickerHandler](./TickerHandler)
- [Lock system](./Locks)
## Server and network
- [Signals](Signals)
- [Portal](Portal-And-Server)
- [Inputfuncs](Inputfuncs)
- [Outputfuncs](Outputfuncs)
- [Signals](./Signals)
- [Portal](./Portal-And-Server)
- [Inputfuncs](./Inputfuncs)
- [Outputfuncs](./Outputfuncs)
- [Protocols](../Concept/Custom-Protocols)
- [Server](Server)
- [Server conf object](Server-Conf)
- [Webserver](Webserver)
- [Webclient](Webclient)
- [Bootstrap](Bootstrap-Components-and-Utilities)
- [Server](./Server)
- [Server conf object](./Server-Conf)
- [Webserver](./Webserver)
- [Webclient](./Webclient)
- [Bootstrap](./Bootstrap-Components-and-Utilities)

4
docs/source/Component/Connection-Screen.md
View file

@ -29,8 +29,8 @@ available.
### Commands available at the Connection Screen
You can also customize the [Commands](Commands) available to use while the connection screen is
You can also customize the [Commands](./Commands) available to use while the connection screen is
shown (`connect`, `create` etc). These commands are a bit special since when the screen is running
the account is not yet logged in. A command is made available at the login screen by adding them to
`UnloggedinCmdSet` in `mygame/commands/default_cmdset.py`. See [Commands](Commands) and the
`UnloggedinCmdSet` in `mygame/commands/default_cmdset.py`. See [Commands](./Commands) and the
tutorial section on how to add new commands to a default command set.

570
docs/source/Component/Default-Command-Help.md
View file

File diff suppressed because it is too large Load diff

28
docs/source/Component/EvMenu.md
View file

@ -33,7 +33,7 @@ said functions, like `{"nodename": <function>, ...}`
## Launching the menu
Initializing the menu is done using a call to the `evennia.utils.evmenu.EvMenu` class. This is the
most common way to do so - from inside a [Command](Commands):
most common way to do so - from inside a [Command](./Commands):
```python
# in, for example gamedir/commands/command.py
@ -70,7 +70,7 @@ EvMenu(caller, menu_data,
```
- `caller` (Object or Account): is a reference to the object using the menu. This object will get a
new [CmdSet](Command-Sets) assigned to it, for handling the menu.
new [CmdSet](./Command-Sets) assigned to it, for handling the menu.
- `menu_data` (str, module or dict): is a module or python path to a module where the global-level
functions will each be considered to be a menu node. Their names in the module will be the names
by which they are referred to in the module. Importantly, function names starting with an
@ -107,7 +107,7 @@ after
- `startnode_input` (str or (str, dict) tuple): Pass an input text or a input text + kwargs to the
start node as if it was entered on a fictional previous node. This can be very useful in order to
start a menu differently depending on the Command's arguments in which it was initialized.
- `session` (Session): Useful when calling the menu from an [Account](Accounts) in
- `session` (Session): Useful when calling the menu from an [Account](./Accounts) in
`MULTISESSION_MODDE` higher than 2, to make sure only the right Session sees the menu output.
- `debug` (bool): If set, the `menudebug` command will be made available in the menu. Use it to
list the current state of the menu and use `menudebug <variable>` to inspect a specific state
@ -428,16 +428,16 @@ See `evennia/utils/evmenu.py` for the details of their default implementations.
## Examples:
- **[Simple branching menu](EvMenu#example-simple-branching-menu)** - choose from options
- **[Dynamic goto](EvMenu#example-dynamic-goto)** - jumping to different nodes based on response
- **[Set caller properties](EvMenu#example-set-caller-properties)** - a menu that changes things
- **[Getting arbitrary input](EvMenu#example-get-arbitrary-input)** - entering text
- **[Storing data between nodes](EvMenu#example-storing-data-between-nodes)** - keeping states and
- **[Simple branching menu](./EvMenu#example-simple-branching-menu)** - choose from options
- **[Dynamic goto](./EvMenu#example-dynamic-goto)** - jumping to different nodes based on response
- **[Set caller properties](./EvMenu#example-set-caller-properties)** - a menu that changes things
- **[Getting arbitrary input](./EvMenu#example-get-arbitrary-input)** - entering text
- **[Storing data between nodes](./EvMenu#example-storing-data-between-nodes)** - keeping states and
information while in the menu
- **[Repeating the same node](EvMenu#example-repeating-the-same-node)** - validating within the node
- **[Repeating the same node](./EvMenu#example-repeating-the-same-node)** - validating within the node
before moving to the next
- **[Full Menu](EvMenu#example-full-menu):** a complete example
- **[Yes/No prompt](EvMenu#example-yesno-prompt)** - entering text with limited possible responses
- **[Full Menu](./EvMenu#example-full-menu):** a complete example
- **[Yes/No prompt](./EvMenu#example-yesno-prompt)** - entering text with limited possible responses
(this is *not* using EvMenu but the conceptually similar yet technically unrelated `get_input`
helper function accessed as `evennia.utils.evmenu.get_input`).
@ -507,7 +507,7 @@ def enter_guild:
This simple callable goto will analyse what happens depending on who the `caller` is. The
`enter_guild` node will give you a choice of what to say to the guard. If you try to enter, you will
end up in different nodes depending on (in this example) if you have the right [Tag](Tags) set on
end up in different nodes depending on (in this example) if you have the right [Tag](./Tags) set on
yourself or not. Note that since we don't include any 'key's in the option dictionary, you will just
get to pick between numbers.
@ -993,8 +993,8 @@ auto-created by the `list_node` decorator.
## Assorted notes
The EvMenu is implemented using [Commands](Commands). When you start a new EvMenu, the user of the
menu will be assigned a [CmdSet](Command-Sets) with the commands they need to navigate the menu.
The EvMenu is implemented using [Commands](./Commands). When you start a new EvMenu, the user of the
menu will be assigned a [CmdSet](./Command-Sets) with the commands they need to navigate the menu.
This means that if you were to, from inside the menu, assign a new command set to the caller, *you
may override the Menu Cmdset and kill the menu*. If you want to assign cmdsets to the caller as part
of the menu, you should store the cmdset on `caller.ndb._menutree` and wait to actually assign it

2
docs/source/Component/EvMore.md
View file

@ -16,7 +16,7 @@ from evennia.utils import evmore
evmore.msg(receiver, long_text)
```
Where receiver is an [Object](Objects) or a [Account](Accounts). If the text is longer than the
Where receiver is an [Object](./Objects) or a [Account](./Accounts). If the text is longer than the
client's screen height (as determined by the NAWS handshake or by `settings.CLIENT_DEFAULT_HEIGHT`)
the pager will show up, something like this:

4
docs/source/Component/Help-System.md
View file

@ -67,7 +67,7 @@ entries together for people to more easily find them. See the `help` command in-
default categories. If you don't specify the category, "General" is assumed.
If you don't want your command to be picked up by the auto-help system at all (like if you want to
write its docs manually using the info in the next section or you use a [cmdset](Command-Sets) that
write its docs manually using the info in the next section or you use a [cmdset](./Command-Sets) that
has its own help functionality) you can explicitly set `auto_help` class property to `False` in your
command definition.
@ -89,7 +89,7 @@ looking for help. The topic can contain spaces and also partial matches will be
- The *help category*. Examples are *Administration*, *Building*, *Comms* or *General*. This is an
overall grouping of similar help topics, used by the engine to give a better overview.
- The *text* - the help text itself, of any length.
- locks - a [lock definition](Locks). This can be used to limit access to this help entry, maybe
- locks - a [lock definition](./Locks). This can be used to limit access to this help entry, maybe
because it's staff-only or otherwise meant to be restricted. Help commands check for `access_type`s
`view` and `edit`. An example of a lock string would be `view:perm(Builders)`.

6
docs/source/Component/Inputfuncs.md
View file

@ -42,7 +42,7 @@ Evennia defines a few default inputfuncs to handle the common cases. These are d
This is the most common of inputcommands, and the only one supported by every traditional mud. The
argument is usually what the user sent from their command line. Since all text input from the user
like this is considered a [Command](Commands), this inputfunc will do things like nick-replacement
like this is considered a [Command](./Commands), this inputfunc will do things like nick-replacement
and then pass on the input to the central Commandhandler.
### echo
@ -134,7 +134,7 @@ to expand. By default the following values can be retrieved:
accepted names if given an unfamiliar callback name.
This will tell evennia to repeatedly call a named function at a given interval. Behind the scenes
this will set up a [Ticker](TickerHandler). Only previously acceptable functions are possible to
this will set up a [Ticker](./TickerHandler). Only previously acceptable functions are possible to
repeat-call in this way, you'll need to overload this inputfunc to add the ones you want to offer.
By default only two example functions are allowed, "test1" and "test2", which will just echo a text
back at the given interval. Stop the repeat by sending `"stop": True` (note that you must include
@ -155,7 +155,7 @@ This is a convenience wrapper for sending "stop" to the `repeat` inputfunc.
This sets up on-object monitoring of Attributes or database fields. Whenever the field or Attribute
changes in any way, the outputcommand will be sent. This is using the
[MonitorHandler](MonitorHandler) behind the scenes. Pass the "stop" key to stop monitoring. Note
[MonitorHandler](./MonitorHandler) behind the scenes. Pass the "stop" key to stop monitoring. Note
that you must supply the name also when stopping to let the system know which monitor should be
cancelled.

38
docs/source/Component/Locks.md
View file

@ -2,9 +2,9 @@
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.
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
@ -92,9 +92,9 @@ the default command set) actually checks for, as in the example of `delete` abov
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
@ -109,26 +109,26 @@ something like `call:false()`.
- `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.
@ -214,10 +214,10 @@ Some useful default lockfuncs (see `src/locks/lockfuncs.py` for more):
- `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).
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
@ -250,7 +250,7 @@ a Lock lookup.
## 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)
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
@ -316,7 +316,7 @@ a particular permission in the hierarchy will *also* grant access to those with
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
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
@ -330,14 +330,14 @@ Here is how you use `perm` to give an account more permissions:
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
[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)).
Account, not on their Characters (but see also [quelling](./Locks#Quelling)).
Below is an example of an object without any connected account
@ -417,7 +417,7 @@ whereas only Admins and the creator may delete it. Everyone can pick it up.
## 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)
Assume we have two objects - one is ourselves (not superuser) and the other is an [Object](./Objects)
called `box`.
> create/drop box
@ -443,7 +443,7 @@ This is defined in `evennia/commands/default/general.py`. In its code we find th
```
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
[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.

6
docs/source/Component/MonitorHandler.md
View file

@ -23,10 +23,10 @@ MONITOR_HANDLER.add(obj, fieldname, callback,
```
- `obj` ([Typeclassed](Typeclasses) entity) - the object to monitor. Since this must be
typeclassed, it means you can't monitor changes on [Sessions](Sessions) with the monitorhandler, for
- `obj` ([Typeclassed](./Typeclasses) entity) - the object to monitor. Since this must be
typeclassed, it means you can't monitor changes on [Sessions](./Sessions) with the monitorhandler, for
example.
- `fieldname` (str) - the name of a field or [Attribute](Attributes) on `obj`. If you want to
- `fieldname` (str) - the name of a field or [Attribute](./Attributes) on `obj`. If you want to
monitor a database field you must specify its full name, including the starting `db_` (like
`db_key`, `db_location` etc). Any names not starting with `db_` are instead assumed to be the names
of Attributes. This difference matters, since the MonitorHandler will automatically know to watch

8
docs/source/Component/Nicks.md
View file

@ -1,7 +1,7 @@
# Nicks
*Nicks*, short for *Nicknames* is a system allowing an object (usually a [Account](Accounts)) to
*Nicks*, short for *Nicknames* is a system allowing an object (usually a [Account](./Accounts)) to
assign custom replacement names for other game entities.
Nicks are not to be confused with *Aliases*. Setting an Alias on a game entity actually changes an
@ -75,7 +75,7 @@ You can also use [shell-type wildcards](http://www.linfo.org/wildcard.html):
## Coding with nicks
Nicks are stored as the `Nick` database model and are referred from the normal Evennia
[object](Objects) through the `nicks` property - this is known as the *NickHandler*. The NickHandler
[object](./Objects) through the `nicks` property - this is known as the *NickHandler*. The NickHandler
offers effective error checking, searches and conversion.
```python
@ -101,12 +101,12 @@ offers effective error checking, searches and conversion.
In a command definition you can reach the nick handler through `self.caller.nicks`. See the `nick`
command in `evennia/commands/default/general.py` for more examples.
As a last note, The Evennia [channel](Communications) alias systems are using nicks with the
As a last note, The Evennia [channel](./Communications) alias systems are using nicks with the
`nick_type="channel"` in order to allow users to create their own custom aliases to channels.
# Advanced note
Internally, nicks are [Attributes](Attributes) saved with the `db_attrype` set to "nick" (normal
Internally, nicks are [Attributes](./Attributes) saved with the `db_attrype` set to "nick" (normal
Attributes has this set to `None`).
The nick stores the replacement data in the Attribute.db_value field as a tuple with four fields

30
docs/source/Component/Objects.md
View file

@ -3,7 +3,7 @@
All in-game objects in Evennia, be it characters, chairs, monsters, rooms or hand grenades are
represented by an Evennia *Object*. Objects form the core of Evennia and is probably what you'll
spend most time working with. Objects are [Typeclassed](Typeclasses) entities.
spend most time working with. Objects are [Typeclassed](./Typeclasses) entities.
## How to create your own object types
@ -48,17 +48,17 @@ thing yourself in code:
call manually you have to give the full path to the class. The `create.create_object` function is
powerful and should be used for all coded object creating (so this is what you use when defining
your own building commands). Check out the `ev.create_*` functions for how to build other entities
like [Scripts](Scripts)).
like [Scripts](./Scripts)).
This particular Rose class doesn't really do much, all it does it make sure the attribute
`desc`(which is what the `look` command looks for) is pre-set, which is pretty pointless since you
will usually want to change this at build time (using the `@desc` command or using the
[Spawner](Spawner-and-Prototypes)). The `Object` typeclass offers many more hooks that is available
[Spawner](./Spawner-and-Prototypes)). The `Object` typeclass offers many more hooks that is available
to use though - see next section.
## Properties and functions on Objects
Beyond the properties assigned to all [typeclassed](Typeclasses) objects (see that page for a list
Beyond the properties assigned to all [typeclassed](./Typeclasses) objects (see that page for a list
of those), the Object also has the following custom properties:
- `aliases` - a handler that allows you to add and remove aliases from this object. Use
@ -67,12 +67,12 @@ of those), the Object also has the following custom properties:
- `home` is a backup location. The main motivation is to have a safe place to move the object to if
its `location` is destroyed. All objects should usually have a home location for safety.
- `destination` - this holds a reference to another object this object links to in some way. Its
main use is for [Exits](Objects#Exits), it's otherwise usually unset.
- `nicks` - as opposed to aliases, a [Nick](Nicks) holds a convenient nickname replacement for a
main use is for [Exits](./Objects#Exits), it's otherwise usually unset.
- `nicks` - as opposed to aliases, a [Nick](./Nicks) holds a convenient nickname replacement for a
real name, word or sequence, only valid for this object. This mainly makes sense if the Object is
used as a game character - it can then store briefer shorts, example so as to quickly reference game
commands or other characters. Use nicks.add(alias, realname) to add a new one.
- `account` - this holds a reference to a connected [Account](Accounts) controlling this object (if
- `account` - this holds a reference to a connected [Account](./Accounts) controlling this object (if
any). Note that this is set also if the controlling account is *not* currently online - to test if
an account is online, use the `has_account` property instead.
- `sessions` - if `account` field is set *and the account is online*, this is a list of all active
@ -87,9 +87,9 @@ object set as their `location`).
The last two properties are special:
- `cmdset` - this is a handler that stores all [command sets](Commands#Command_Sets) defined on the
- `cmdset` - this is a handler that stores all [command sets](./Commands#Command_Sets) defined on the
object (if any).
- `scripts` - this is a handler that manages [Scripts](Scripts) attached to the object (if any).
- `scripts` - this is a handler that manages [Scripts](./Scripts) attached to the object (if any).
The Object also has a host of useful utility functions. See the function headers in
`src/objects/objects.py` for their arguments and more details.
@ -104,7 +104,7 @@ on).
- `execute_cmd()` - Lets the object execute the given string as if it was given on the command line.
- `move_to` - perform a full move of this object to a new location. This is the main move method
and will call all relevant hooks, do all checks etc.
- `clear_exits()` - will delete all [Exits](Objects#Exits) to *and* from this object.
- `clear_exits()` - will delete all [Exits](./Objects#Exits) to *and* from this object.
- `clear_contents()` - this will not delete anything, but rather move all contents (except Exits) to
their designated `Home` locations.
- `delete()` - deletes this object, first calling `clear_exits()` and
@ -126,10 +126,10 @@ practice they are all pretty similar to the base Object.
### Characters
Characters are objects controlled by [Accounts](Accounts). When a new Account
Characters are objects controlled by [Accounts](./Accounts). When a new Account
logs in to Evennia for the first time, a new `Character` object is created and
the Account object is assigned to the `account` attribute. A `Character` object
must have a [Default Commandset](Commands#Command_Sets) set on itself at
must have a [Default Commandset](./Commands#Command_Sets) set on itself at
creation, or the account will not be able to issue any commands! If you just
inherit your own class from `evennia.DefaultCharacter` and make sure to use
`super()` to call the parent methods you should be fine. In
@ -150,21 +150,21 @@ you to modify.
*in* might be an exit, as well as *door*, *portal* or *jump out the window*. An exit has two things
that separate them from other objects. Firstly, their *destination* property is set and points to a
valid object. This fact makes it easy and fast to locate exits in the database. Secondly, exits
define a special [Transit Command](Commands) on themselves when they are created. This command is
define a special [Transit Command](./Commands) on themselves when they are created. This command is
named the same as the exit object and will, when called, handle the practicalities of moving the
character to the Exits's *destination* - this allows you to just enter the name of the exit on its
own to move around, just as you would expect.
The exit functionality is all defined on the Exit typeclass, so you could in principle completely
change how exits work in your game (it's not recommended though, unless you really know what you are
doing). Exits are [locked](Locks) using an access_type called *traverse* and also make use of a few
doing). Exits are [locked](./Locks) using an access_type called *traverse* and also make use of a few
hook methods for giving feedback if the traversal fails. See `evennia.DefaultExit` for more info.
In `mygame/typeclasses/exits.py` there is an empty `Exit` class for you to modify.
The process of traversing an exit is as follows:
1. The traversing `obj` sends a command that matches the Exit-command name on the Exit object. The
[cmdhandler](Commands) detects this and triggers the command defined on the Exit. Traversal always
[cmdhandler](./Commands) detects this and triggers the command defined on the Exit. Traversal always
involves the "source" (the current location) and the `destination` (this is stored on the Exit
object).
1. The Exit command checks the `traverse` lock on the Exit object

16
docs/source/Component/Scripts.md
View file

@ -2,7 +2,7 @@
*Scripts* are the out-of-character siblings to the in-character
[Objects](Objects). Scripts are so flexible that the "Script" is a bit limiting
[Objects](./Objects). Scripts are so flexible that the "Script" is a bit limiting
- we had to pick something to name them after all. Other possible names
(depending on what you'd use them for) would be `OOBObjects`,
`StorageContainers` or `TimerObjects`.
@ -14,7 +14,7 @@ Scripts can be used for many different things in Evennia:
- They can work as timers and tickers - anything that may change with Time. But
they can also have no time dependence at all. Note though that if all you want
is just to have an object method called repeatedly, you should consider using
the [TickerHandler](TickerHandler) which is more limited but is specialized on
the [TickerHandler](./TickerHandler) which is more limited but is specialized on
just this task.
- They can describe State changes. A Script is an excellent platform for
hosting a persistent, but unique system handler. For example, a Script could be
@ -22,11 +22,11 @@ used as the base to track the state of a turn-based combat system. Since
Scripts can also operate on a timer they can also update themselves regularly
to perform various actions.
- They can act as data stores for storing game data persistently in the database
(thanks to its ability to have [Attributes](Attributes)).
(thanks to its ability to have [Attributes](./Attributes)).
- They can be used as OOC stores for sharing data between groups of objects, for
example for tracking the turns in a turn-based combat system or barter exchange.
Scripts are [Typeclassed](Typeclasses) entities and are manipulated in a similar
Scripts are [Typeclassed](./Typeclasses) entities and are manipulated in a similar
way to how it works for other such Evennia entities:
```python
@ -41,7 +41,7 @@ list_of_myscript = evennia.search_script("myscript")
## Defining new Scripts
A Script is defined as a class and is created in the same way as other
[typeclassed](Typeclasses) entities. The class has several properties
[typeclassed](./Typeclasses) entities. The class has several properties
to control the timer-component of the scripts. These are all _optional_ -
leaving them out will just create a Script with no timer components (useful to act as
a database store or to hold a persistent game system, for example).
@ -104,7 +104,7 @@ If we put this script on a room, it will randomly report some weather
to everyone in the room every 5 minutes.
To activate it, just add it to the script handler (`scripts`) on an
[Room](Objects). That object becomes `self.obj` in the example above. Here we
[Room](./Objects). That object becomes `self.obj` in the example above. Here we
put it on a room called `myroom`:
```
@ -144,7 +144,7 @@ command in-game.
## Properties and functions defined on Scripts
A Script has all the properties of a typeclassed object, such as `db` and `ndb`(see
[Typeclasses](Typeclasses)). Setting `key` is useful in order to manage scripts (delete them by name
[Typeclasses](./Typeclasses)). Setting `key` is useful in order to manage scripts (delete them by name
etc). These are usually set up in the Script's typeclass, but can also be assigned on the fly as
keyword arguments to `evennia.create_script`.
@ -164,7 +164,7 @@ after the reload is complete).
There is one special property:
- `obj` - the [Object](Objects) this script is attached to (if any). You should not need to set
- `obj` - the [Object](./Objects) this script is attached to (if any). You should not need to set
this manually. If you add the script to the Object with `myobj.scripts.add(myscriptpath)` or give
`myobj` as an argument to the `utils.create.create_script` function, the `obj` property will be set
to `myobj` for you.

4
docs/source/Component/Server-Conf.md
View file

@ -67,10 +67,10 @@ other things that must run in your game but which has no database persistence.
a greeting screen to show when an Account first connects. If more than one string variable is
present in the module a random one will be picked.
- `inlinefuncs.py` - this is where you can define custom [Inline functions](../Concept/TextTags#inlinefuncs).
- `inputfuncs.py` - this is where you define custom [Input functions](Inputfuncs) to handle data
- `inputfuncs.py` - this is where you define custom [Input functions](./Inputfuncs) to handle data
from the client.
- `lockfuncs.py` - this is one of many possible modules to hold your own "safe" *lock functions* to
make available to Evennia's [Locks](Locks).
make available to Evennia's [Locks](./Locks).
- `mssp.py` - this holds meta information about your game. It is used by MUD search engines (which
you often have to register with) in order to display what kind of game you are running along with
statistics such as number of online accounts and online status.

2
docs/source/Component/Server.md
View file

@ -1,3 +1,3 @@
# Server component
TODO: This is currently in [Portal-and-Server](Portal-And-Server).
TODO: This is currently in [Portal-and-Server](./Portal-And-Server).

18
docs/source/Component/Sessions.md
View file

@ -5,14 +5,14 @@ An Evennia *Session* represents one single established connection to the server.
Evennia session, it is possible for a person to connect multiple times, for example using different
clients in multiple windows. Each such connection is represented by a session object.
A session object has its own [cmdset](Command-Sets), usually the "unloggedin" cmdset. This is what
A session object has its own [cmdset](./Command-Sets), usually the "unloggedin" cmdset. This is what
is used to show the login screen and to handle commands to create a new account (or
[Account](Accounts) in evennia lingo) read initial help and to log into the game with an existing
[Account](./Accounts) in evennia lingo) read initial help and to log into the game with an existing
account. A session object can either be "logged in" or not. Logged in means that the user has
authenticated. When this happens the session is associated with an Account object (which is what
holds account-centric stuff). The account can then in turn puppet any number of objects/characters.
> Warning: A Session is not *persistent* - it is not a [Typeclass](Typeclasses) and has no
> Warning: A Session is not *persistent* - it is not a [Typeclass](./Typeclasses) and has no
connection to the database. The Session will go away when a user disconnects and you will lose any
custom data on it if the server reloads. The `.db` handler on Sessions is there to present a uniform
API (so you can assume `.db` exists even if you don't know if you receive an Object or a Session),
@ -26,13 +26,13 @@ Here are some important properties available on (Server-)Sessions
- `sessid` - The unique session-id. This is an integer starting from 1.
- `address` - The connected client's address. Different protocols give different information here.
- `logged_in` - `True` if the user authenticated to this session.
- `account` - The [Account](Accounts) this Session is attached to. If not logged in yet, this is
- `account` - The [Account](./Accounts) this Session is attached to. If not logged in yet, this is
`None`.
- `puppet` - The [Character/Object](Objects) currently puppeted by this Account/Session combo. If
- `puppet` - The [Character/Object](./Objects) currently puppeted by this Account/Session combo. If
not logged in or in OOC mode, this is `None`.
- `ndb` - The [Non-persistent Attribute](Attributes) handler.
- `ndb` - The [Non-persistent Attribute](./Attributes) handler.
- `db` - As noted above, Sessions don't have regular Attributes. This is an alias to `ndb`.
- `cmdset` - The Session's [CmdSetHandler](Command-Sets)
- `cmdset` - The Session's [CmdSetHandler](./Command-Sets)
Session statistics are mainly used internally by Evennia.
@ -99,7 +99,7 @@ transparently detect which session was triggering the command (if any) and redir
`command.msg()` is often the safest bet.
You can get the `session` in two main ways:
* [Accounts](Accounts) and [Objects](Objects) (including Characters) have a `sessions` property.
* [Accounts](./Accounts) and [Objects](./Objects) (including Characters) have a `sessions` property.
This is a *handler* that tracks all Sessions attached to or puppeting them. Use e.g.
`accounts.sessions.get()` to get a list of Sessions attached to that entity.
* A Command instance has a `session` property that always points back to the Session that triggered
@ -132,7 +132,7 @@ changes carefully.
*Note: This is considered an advanced topic. You don't need to know this on a first read-through.*
Evennia is split into two parts, the [Portal and the Server](Portal-And-Server). Each side tracks
Evennia is split into two parts, the [Portal and the Server](./Portal-And-Server). Each side tracks
its own Sessions, syncing them to each other.
The "Session" we normally refer to is actually the `ServerSession`. Its counter-part on the Portal

2
docs/source/Component/Signals.md
View file

@ -69,7 +69,7 @@ be extracted from the `**kwargs` dict in the signal handler.
used way for users to themselves create accounts during login. It passes and extra kwarg `ip` with
the client IP of the connecting account.
- `SIGNAL_ACCOUNT_POST_LOGIN` - this will always fire when the account has authenticated. Sends
extra kwarg `session` with the new [Session](Sessions) object involved.
extra kwarg `session` with the new [Session](./Sessions) object involved.
- `SIGNAL_ACCCOUNT_POST_FIRST_LOGIN` - this fires just before `SIGNAL_ACCOUNT_POST_LOGIN` but only
if
this is the *first* connection done (that is, if there are no previous sessions connected). Also

16
docs/source/Component/Spawner-and-Prototypes.md
View file

@ -2,10 +2,10 @@
The *spawner* is a system for defining and creating individual objects from a base template called a
*prototype*. It is only designed for use with in-game [Objects](Objects), not any other type of
*prototype*. It is only designed for use with in-game [Objects](./Objects), not any other type of
entity.
The normal way to create a custom object in Evennia is to make a [Typeclass](Typeclasses). If you
The normal way to create a custom object in Evennia is to make a [Typeclass](./Typeclasses). If you
haven't read up on Typeclasses yet, think of them as normal Python classes that save to the database
behind the scenes. Say you wanted to create a "Goblin" enemy. A common way to do this would be to
first create a `Mobile` typeclass that holds everything common to mobiles in the game, like generic
@ -105,12 +105,12 @@ instead.
exist.
- `destination` - a valid `#dbref`. Only used by exits.
- `permissions` - list of permission strings, like `["Accounts", "may_use_red_door"]`
- `locks` - a [lock-string](Locks) like `"edit:all();control:perm(Builder)"`
- `locks` - a [lock-string](./Locks) like `"edit:all();control:perm(Builder)"`
- `aliases` - list of strings for use as aliases
- `tags` - list [Tags](Tags). These are given as tuples `(tag, category, data)`.
- `attrs` - list of [Attributes](Attributes). These are given as tuples `(attrname, value,
- `tags` - list [Tags](./Tags). These are given as tuples `(tag, category, data)`.
- `attrs` - list of [Attributes](./Attributes). These are given as tuples `(attrname, value,
category, lockstring)`
- Any other keywords are interpreted as non-category [Attributes](Attributes) and their values.
- Any other keywords are interpreted as non-category [Attributes](./Attributes) and their values.
This is
convenient for simple Attributes - use `attrs` for full control of Attributes.
@ -119,7 +119,7 @@ Deprecated as of Evennia 0.8:
- `ndb_<name>` - sets the value of a non-persistent attribute (`"ndb_"` is stripped from the name).
This is simply not useful in a prototype and is deprecated.
- `exec` - This accepts a code snippet or a list of code snippets to run. This should not be used -
use callables or [$protfuncs](Spawner-and-Prototypes#protfuncs) instead (see below).
use callables or [$protfuncs](./Spawner-and-Prototypes#protfuncs) instead (see below).
### Prototype values
@ -233,7 +233,7 @@ A prototype can be defined and stored in two ways, either in the database or as
### Database prototypes
Stored as [Scripts](Scripts) in the database. These are sometimes referred to as *database-
Stored as [Scripts](./Scripts) in the database. These are sometimes referred to as *database-
prototypes* This is the only way for in-game builders to modify and add prototypes. They have the
advantage of being easily modifiable and sharable between builders but you need to work with them
using in-game tools.

12
docs/source/Component/Tags.md
View file

@ -10,11 +10,11 @@ currently dead.
*Tags* are short text labels that you attach to objects so as to easily be able to retrieve and
group them. An Evennia entity can be tagged with any number of Tags. On the database side, Tag
entities are *shared* between all objects with that tag. This makes them very efficient but also
fundamentally different from [Attributes](Attributes), each of which always belongs to one *single*
fundamentally different from [Attributes](./Attributes), each of which always belongs to one *single*
object.
In Evennia, Tags are technically also used to implement `Aliases` (alternative names for objects)
and `Permissions` (simple strings for [Locks](Locks) to check for).
and `Permissions` (simple strings for [Locks](./Locks) to check for).
## Properties of Tags (and Aliases and Permissions)
@ -26,7 +26,7 @@ unique key + category combination.
When Tags are assigned to game entities, these entities are actually sharing the same Tag. This
means that Tags are not suitable for storing information about a single object - use an
[Attribute](Attributes) for this instead. Tags are a lot more limited than Attributes but this also
[Attribute](./Attributes) for this instead. Tags are a lot more limited than Attributes but this also
makes them very quick to lookup in the database - this is the whole point.
Tags have the following properties, stored in the database:
@ -52,8 +52,8 @@ free up the *category* property for any use you desire.
## Adding/Removing Tags
You can tag any *typeclassed* object, namely [Objects](Objects), [Accounts](Accounts),
[Scripts](Scripts) and [Channels](Communications). General tags are added by the *Taghandler*. The
You can tag any *typeclassed* object, namely [Objects](./Objects), [Accounts](./Accounts),
[Scripts](./Scripts) and [Channels](./Communications). General tags are added by the *Taghandler*. The
tag handler is accessed as a property `tags` on the relevant entity:
```python
@ -135,7 +135,7 @@ objs = evennia.search_tag(category="bar")
There is also an in-game command that deals with assigning and using ([Object-](Objects)) tags:
There is also an in-game command that deals with assigning and using ([Object-](./Objects)) tags:
@tag/search furniture

4
docs/source/Component/TickerHandler.md
View file

@ -11,7 +11,7 @@ hard-coded to rely on the concept of the global 'tick'. Evennia has no such noti
use tickers is very much up to the need of your game and which requirements you have. The "ticker
recipe" is just one way of cranking the wheels.
The most fine-grained way to manage the flow of time is of course to use [Scripts](Scripts). Many
The most fine-grained way to manage the flow of time is of course to use [Scripts](./Scripts). Many
types of operations (weather being the classic example) are however done on multiple objects in the
same way at regular intervals, and for this, storing separate Scripts on each object is inefficient.
The way to do this is to use a ticker with a "subscription model" - let objects sign up to be
@ -98,7 +98,7 @@ The `callable` can be on any form as long as it accepts the arguments you give t
> Note that everything you supply to the TickerHandler will need to be pickled at some point to be
saved into the database. Most of the time the handler will correctly store things like database
objects, but the same restrictions as for [Attributes](Attributes) apply to what the TickerHandler
objects, but the same restrictions as for [Attributes](./Attributes) apply to what the TickerHandler
may store.
When testing, you can stop all tickers in the entire game with `tickerhandler.clear()`. You can also

28
docs/source/Component/Typeclasses.md
View file

@ -5,8 +5,8 @@
different game entities as Python classes, without having to modify the database schema for every
new type.
In Evennia the most important game entities, [Accounts](Accounts), [Objects](Objects),
[Scripts](Scripts) and [Channels](Communications#Channels) are all Python classes inheriting, at
In Evennia the most important game entities, [Accounts](./Accounts), [Objects](./Objects),
[Scripts](./Scripts) and [Channels](./Communications#Channels) are all Python classes inheriting, at
varying distance, from `evennia.typeclasses.models.TypedObject`. In the documentation we refer to
these objects as being "typeclassed" or even "being a typeclass".
@ -55,7 +55,7 @@ important limitations. This is why we don't simply call them "classes" but "type
1. A typeclass can save itself to the database. This means that some properties (actually not that
many) on the class actually represents database fields and can only hold very specific data types.
This is detailed [below](Typeclasses#about-typeclass-properties).
This is detailed [below](./Typeclasses#about-typeclass-properties).
1. Due to its connection to the database, the typeclass' name must be *unique* across the _entire_
server namespace. That is, there must never be two same-named classes defined anywhere. So the below
code would give an error (since `DefaultObject` is now globally found both in this module and in the
@ -129,8 +129,8 @@ argument; this can both be the actual class or the python path to the typeclass
game directory. So if your `Furniture` typeclass sits in `mygame/typeclasses/furniture.py`, you
could point to it as `typeclasses.furniture.Furniture`. Since Evennia will itself look in
`mygame/typeclasses`, you can shorten this even further to just `furniture.Furniture`. The create-
functions take a lot of extra keywords allowing you to set things like [Attributes](Attributes) and
[Tags](Tags) all in one go. These keywords don't use the `db_*` prefix. This will also automatically
functions take a lot of extra keywords allowing you to set things like [Attributes](./Attributes) and
[Tags](./Tags) all in one go. These keywords don't use the `db_*` prefix. This will also automatically
save the new instance to the database, so you don't need to call `save()` explicitly.
### About typeclass properties
@ -178,22 +178,22 @@ returns the string form "#id".
The typeclassed entity has several common handlers:
- `tags` - the [TagHandler](Tags) that handles tagging. Use `tags.add()` , `tags.get()` etc.
- `locks` - the [LockHandler](Locks) that manages access restrictions. Use `locks.add()`,
- `tags` - the [TagHandler](./Tags) that handles tagging. Use `tags.add()` , `tags.get()` etc.
- `locks` - the [LockHandler](./Locks) that manages access restrictions. Use `locks.add()`,
`locks.get()` etc.
- `attributes` - the [AttributeHandler](Attributes) that manages Attributes on the object. Use
- `attributes` - the [AttributeHandler](./Attributes) that manages Attributes on the object. Use
`attributes.add()`
etc.
- `db` (DataBase) - a shortcut property to the AttributeHandler; allowing `obj.db.attrname = value`
- `nattributes` - the [Non-persistent AttributeHandler](Attributes) for attributes not saved in the
- `nattributes` - the [Non-persistent AttributeHandler](./Attributes) for attributes not saved in the
database.
- `ndb` (NotDataBase) - a shortcut property to the Non-peristent AttributeHandler. Allows
`obj.ndb.attrname = value`
Each of the typeclassed entities then extend this list with their own properties. Go to the
respective pages for [Objects](Objects), [Scripts](Scripts), [Accounts](Accounts) and
[Channels](Communications) for more info. It's also recommended that you explore the available
respective pages for [Objects](./Objects), [Scripts](./Scripts), [Accounts](./Accounts) and
[Channels](./Communications) for more info. It's also recommended that you explore the available
entities using [Evennia's flat API](../Evennia-API) to explore which properties and methods they have
available.
@ -207,7 +207,7 @@ are the `at_login` hook of Accounts and the `at_repeat` hook of Scripts.
### Querying for typeclasses
Most of the time you search for objects in the database by using convenience methods like the
`caller.search()` of [Commands](Commands) or the search functions like `evennia.search_objects`.
`caller.search()` of [Commands](./Commands) or the search functions like `evennia.search_objects`.
You can however also query for them directly using [Django's query
language](https://docs.djangoproject.com/en/1.7/topics/db/queries/). This makes use of a _database
@ -251,7 +251,7 @@ If you already have created instances of Typeclasses, you can modify the *Python
due to how Python inheritance works your changes will automatically be applied to all children once
you have reloaded the server.
However, database-saved data, like `db_*` fields, [Attributes](Attributes), [Tags](Tags) etc, are
However, database-saved data, like `db_*` fields, [Attributes](./Attributes), [Tags](./Tags) etc, are
not themselves embedded into the class and will *not* be updated automatically. This you need to
manage yourself, by searching for all relevant objects and updating or adding the data:
@ -325,7 +325,7 @@ Technically, typeclasses are [Django proxy
models](https://docs.djangoproject.com/en/1.7/topics/db/models/#proxy-models). The only database
models that are "real" in the typeclass system (that is, are represented by actual tables in the
database) are `AccountDB`, `ObjectDB`, `ScriptDB` and `ChannelDB` (there are also
[Attributes](Attributes) and [Tags](Tags) but they are not typeclasses themselves). All the
[Attributes](./Attributes) and [Tags](./Tags) but they are not typeclasses themselves). All the
subclasses of them are "proxies", extending them with Python code without actually modifying the
database layout.