mirror of
https://github.com/evennia/evennia.git
synced 2026-03-18 05:46:31 +01:00
Convert master docs to use MyST
This commit is contained in:
parent
6e03216cd9
commit
d229ff024c
359 changed files with 3275 additions and 4567 deletions
|
|
@ -9,33 +9,33 @@ explains Evennia's tools for searching.
|
|||
## Things to search for
|
||||
|
||||
The first thing to consider is the base type of the thing you are searching for. Evennia organizes
|
||||
its database into a few main tables: [Objects](./Objects), [Accounts](./Accounts), [Scripts](./Scripts),
|
||||
[Channels](./Communications#channels), [Messages](Communication#Msg) and [Help Entries](./Help-System).
|
||||
its database into a few main tables: [Objects](./Objects.md), [Accounts](./Accounts.md), [Scripts](./Scripts.md),
|
||||
[Channels](./Communications.md#channels), [Messages](./Communications.md#msg) and [Help Entries](./Help-System.md).
|
||||
Most of the time you'll likely spend your time searching for Objects and the occasional Accounts.
|
||||
|
||||
So to find an entity, what can be searched for?
|
||||
|
||||
- The `key` is the name of the entity. While you can get this from `obj.key` the *database field*
|
||||
is actually named `obj.db_key` - this is useful to know only when you do [direct database
|
||||
queries](Tutorial-Searching-For-Objects#queries-in-django). The one exception is `Accounts`, where
|
||||
queries](./Tutorial-Searching-For-Objects.md#queries-in-django). The one exception is `Accounts`, where
|
||||
the database field for `.key` is instead named `username` (this is a Django requirement). When you
|
||||
don't specify search-type, you'll usually search based on key. *Aliases* are extra names given to
|
||||
Objects using something like `@alias` or `obj.aliases.add('name')`. The main search functions (see
|
||||
below) will automatically search for aliases whenever you search by-key.
|
||||
- [Tags](./Tags) are the main way to group and identify objects in Evennia. Tags can most often be
|
||||
- [Tags](./Tags.md) are the main way to group and identify objects in Evennia. Tags can most often be
|
||||
used (sometimes together with keys) to uniquely identify an object. For example, even though you
|
||||
have two locations with the same name, you can separate them by their tagging (this is how Evennia
|
||||
implements 'zones' seen in other systems). Tags can also have categories, to further organize your
|
||||
data for quick lookups.
|
||||
- An object's [Attributes](./Attributes) can also used to find an object. This can be very useful but
|
||||
- An object's [Attributes](./Attributes.md) can also used to find an object. This can be very useful but
|
||||
since Attributes can store almost any data they are far less optimized to search for than Tags or
|
||||
keys.
|
||||
- The object's [Typeclass](./Typeclasses) indicate the sub-type of entity. A Character, Flower or
|
||||
- The object's [Typeclass](./Typeclasses.md) indicate the sub-type of entity. A Character, Flower or
|
||||
Sword are all types of Objects. A Bot is a kind of Account. The database field is called
|
||||
`typeclass_path` and holds the full Python-path to the class. You can usually specify the
|
||||
`typeclass` as an argument to Evennia's search functions as well as use the class directly to limit
|
||||
queries.
|
||||
- The `location` is only relevant for [Objects](./Objects) but is a very common way to weed down the
|
||||
- The `location` is only relevant for [Objects](./Objects.md) but is a very common way to weed down the
|
||||
number of candidates before starting to search. The reason is that most in-game commands tend to
|
||||
operate on things nearby (in the same room) so the choices can be limited from the start.
|
||||
- The database id or the '#dbref' is unique (and never re-used) within each database table. So while
|
||||
|
|
@ -50,7 +50,7 @@ around and searching by Tags and/or keys will usually get you what you need.
|
|||
|
||||
## Getting objects inside another
|
||||
|
||||
All in-game [Objects](./Objects) have a `.contents` property that returns all objects 'inside' them
|
||||
All in-game [Objects](./Objects.md) have a `.contents` property that returns all objects 'inside' them
|
||||
(that is, all objects which has its `.location` property set to that object. This is a simple way to
|
||||
get everything in a room and is also faster since this lookup is cached and won't hit the database.
|
||||
|
||||
|
|
@ -64,7 +64,7 @@ location except `obj`.
|
|||
|
||||
## Searching using `Object.search`
|
||||
|
||||
Say you have a [command](./Commands), and you want it to do something to a target. You might be
|
||||
Say you have a [command](./Commands.md), and you want it to do something to a target. You might be
|
||||
wondering how you retrieve that target in code, and that's where Evennia's search utilities come in.
|
||||
In the most common case, you'll often use the `search` method of the `Object` or `Account`
|
||||
typeclasses. In a command, the `.caller` property will refer back to the object using the command
|
||||
|
|
@ -131,7 +131,7 @@ class CmdListHangouts(default_cmds.MuxCommand):
|
|||
self.caller.msg(f"Hangouts available: {', '.join(str(ob) for ob in hangouts)}")
|
||||
```
|
||||
|
||||
This uses the `search_tag` function to find all objects previously tagged with [Tags](./Tags)
|
||||
This uses the `search_tag` function to find all objects previously tagged with [Tags](./Tags.md)
|
||||
"hangout" and with category "location tags".
|
||||
|
||||
Other important search methods in `utils.search` are
|
||||
|
|
@ -143,7 +143,7 @@ Other important search methods in `utils.search` are
|
|||
- `search_message`
|
||||
- `search_help`
|
||||
- `search_tag` - find Objects with a given Tag. [See also here for how to search by
|
||||
tag](Tags#searching-for-objects-with-a-given-tag).
|
||||
tag](./Tags.md#searching-for-objects-with-a-given-tag).
|
||||
- `search_account_tag` - find Accounts with a given Tag.
|
||||
- `search_script_tag` - find Scripts with a given Tag.
|
||||
- `search_channel_tag` - find Channels with a given Tag.
|
||||
|
|
@ -302,7 +302,7 @@ nice enough to alias the `db_key` field so you can normally just do `char.key` t
|
|||
name, the database field is actually called `db_key` and the real name must be used for the purpose
|
||||
of building a query.
|
||||
|
||||
> Don't confuse database fields with [Attributes](./Attributes) you set via `obj.db.attr = 'foo'` or
|
||||
> Don't confuse database fields with [Attributes](./Attributes.md) you set via `obj.db.attr = 'foo'` or
|
||||
`obj.attributes.add()`. Attributes are custom database entities *linked* to an object. They are not
|
||||
separate fields *on* that object like `db_key` or `db_location` are. You can get attached Attributes
|
||||
manually through the `db_attributes` many-to-many field in the same way as `db_tags` above.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue