mirror of
https://github.com/evennia/evennia.git
synced 2026-03-27 18:26:32 +01:00
Resync all links and fix issues with auto-relink
This commit is contained in:
Griatch
parent
20a1741f4c
commit
fab769e0d0
107 changed files with 887 additions and 877 deletions
|
|
@ -2,7 +2,7 @@
|
|||
|
||||
|
||||
**Before doing this tutorial you will probably want to read the intro in
|
||||
[Basic Web tutorial](Web-Tutorial).** Reading the three first parts of the
|
||||
[Basic Web tutorial](Howto/StartingTutorial/Web-Tutorial).** Reading the three first parts of the
|
||||
[Django tutorial](https://docs.djangoproject.com/en/1.9/intro/tutorial01/) might help as well.
|
||||
|
||||
This tutorial will provide a step-by-step process to installing a wiki on your website.
|
||||
|
|
|
|||
|
|
@ -28,9 +28,9 @@ Before we continue, let’s make a brief detour. Evennia is very flexible about
|
|||
more flexible about using and adding commands to those objects. Here are some ground rules well
|
||||
worth remembering for the remainder of this article:
|
||||
|
||||
- The [Account](Accounts) represents the real person logging in and has no game-world existence.
|
||||
- Any [Object](Objects) can be puppeted by an Account (with proper permissions).
|
||||
- [Characters](Objects#characters), [Rooms](Objects#rooms), and [Exits](Objects#exits) are just
|
||||
- The [Account](Component/Accounts) represents the real person logging in and has no game-world existence.
|
||||
- Any [Object](Component/Objects) can be puppeted by an Account (with proper permissions).
|
||||
- [Characters](Component/Objects#characters), [Rooms](Component/Objects#rooms), and [Exits](Component/Objects#exits) are just
|
||||
children of normal Objects.
|
||||
- Any Object can be inside another (except if it creates a loop).
|
||||
- Any Object can store custom sets of commands on it. Those commands can:
|
||||
|
|
@ -120,7 +120,7 @@ about the missiles being fired and has different `key` and `aliases`. We leave
|
|||
that up to you to create as an exercise. You could have it print "WOOSH! The
|
||||
mech launches missiles against <target>!", for example.
|
||||
|
||||
Now we shove our commands into a command set. A [Command Set](Command-Sets) (CmdSet) is a container
|
||||
Now we shove our commands into a command set. A [Command Set](Component/Command-Sets) (CmdSet) is a container
|
||||
holding any number of commands. The command set is what we will store on the mech.
|
||||
|
||||
```python
|
||||
|
|
@ -173,7 +173,7 @@ This is great for testing. The way we added it, the MechCmdSet will even go away
|
|||
server. Now we want to make the mech an actual object “type” so we can create mechs without those
|
||||
extra steps. For this we need to create a new Typeclass.
|
||||
|
||||
A [Typeclass](Typeclasses) is a near-normal Python class that stores its existence to the database
|
||||
A [Typeclass](Component/Typeclasses) is a near-normal Python class that stores its existence to the database
|
||||
behind the scenes. A Typeclass is created in a normal Python source file:
|
||||
|
||||
```python
|
||||
|
|
|
|||
|
|
@ -7,28 +7,28 @@ exists before answering - maybe you can clarify that answer rather than to make
|
|||
|
||||
## Table of Contents
|
||||
|
||||
- [Removing default commands](Coding-FAQ#removing-default-commands)
|
||||
- [Preventing character from moving based on a condition](Coding-FAQ#preventing-character-from-
|
||||
- [Removing default commands](Howto/Coding-FAQ#removing-default-commands)
|
||||
- [Preventing character from moving based on a condition](Howto/Coding-FAQ#preventing-character-from-
|
||||
moving-based-on-a-condition)
|
||||
- [Reference initiating object in an EvMenu command](Coding-FAQ#reference-initiating-object-in-an-
|
||||
- [Reference initiating object in an EvMenu command](Howto/Coding-FAQ#reference-initiating-object-in-an-
|
||||
evmenu-command)
|
||||
- [Adding color to default Evennia Channels](Coding-FAQ#adding-color-to-default-evennia-channels)
|
||||
- [Selectively turn off commands in a room](Coding-FAQ#selectively-turn-off-commands-in-a-room)
|
||||
- [Select Command based on a condition](Coding-FAQ#select-command-based-on-a-condition)
|
||||
- [Automatically updating code when reloading](Coding-FAQ#automatically-updating-code-when-
|
||||
- [Adding color to default Evennia Channels](Howto/Coding-FAQ#adding-color-to-default-evennia-channels)
|
||||
- [Selectively turn off commands in a room](Howto/Coding-FAQ#selectively-turn-off-commands-in-a-room)
|
||||
- [Select Command based on a condition](Howto/Coding-FAQ#select-command-based-on-a-condition)
|
||||
- [Automatically updating code when reloading](Howto/Coding-FAQ#automatically-updating-code-when-
|
||||
reloading)
|
||||
- [Changing all exit messages](Coding-FAQ#changing-all-exit-messages)
|
||||
- [Add parsing with the "to" delimiter](Coding-FAQ#add-parsing-with-the-to-delimiter)
|
||||
- [Store last used session IP address](Coding-FAQ#store-last-used-session-ip-address)
|
||||
- [Use wide characters with EvTable](Coding-FAQ#non-latin-characters-in-evtable)
|
||||
- [Changing all exit messages](Howto/Coding-FAQ#changing-all-exit-messages)
|
||||
- [Add parsing with the "to" delimiter](Howto/Coding-FAQ#add-parsing-with-the-to-delimiter)
|
||||
- [Store last used session IP address](Howto/Coding-FAQ#store-last-used-session-ip-address)
|
||||
- [Use wide characters with EvTable](Howto/Coding-FAQ#non-latin-characters-in-evtable)
|
||||
|
||||
## Removing default commands
|
||||
**Q:** How does one *remove* (not replace) e.g. the default `get` [Command](Commands) from the
|
||||
Character [Command Set](Command-Sets)?
|
||||
**Q:** How does one *remove* (not replace) e.g. the default `get` [Command](Component/Commands) from the
|
||||
Character [Command Set](Component/Command-Sets)?
|
||||
|
||||
**A:** Go to `mygame/commands/default_cmdsets.py`. Find the `CharacterCmdSet` class. It has one
|
||||
method named `at_cmdset_creation`. At the end of that method, add the following line:
|
||||
`self.remove(default_cmds.CmdGet())`. See the [Adding Commands Tutorial](Adding-Command-Tutorial)
|
||||
`self.remove(default_cmds.CmdGet())`. See the [Adding Commands Tutorial](Howto/StartingTutorial/Adding-Command-Tutorial)
|
||||
for more info.
|
||||
|
||||
## Preventing character from moving based on a condition
|
||||
|
|
@ -36,7 +36,7 @@ for more info.
|
|||
combat, immobilized, etc.)
|
||||
|
||||
**A:** The `at_before_move` hook is called by Evennia just before performing any move. If it returns
|
||||
`False`, the move is aborted. Let's say we want to check for an [Attribute](Attributes) `cantmove`.
|
||||
`False`, the move is aborted. Let's say we want to check for an [Attribute](Component/Attributes) `cantmove`.
|
||||
Add the following code to the `Character` class:
|
||||
|
||||
```python
|
||||
|
|
@ -52,7 +52,7 @@ def at_before_move(self, destination):
|
|||
**Q:** An object has a Command on it starts up an EvMenu instance. How do I capture a reference to
|
||||
that object for use in the menu?
|
||||
|
||||
**A:** When an [EvMenu](EvMenu) is started, the menu object is stored as `caller.ndb._menutree`.
|
||||
**A:** When an [EvMenu](Component/EvMenu) is started, the menu object is stored as `caller.ndb._menutree`.
|
||||
This is a good place to store menu-specific things since it will clean itself up when the menu
|
||||
closes. When initiating the menu, any additional keywords you give will be available for you as
|
||||
properties on this menu object:
|
||||
|
|
@ -101,7 +101,7 @@ CHANNEL_COLORS`.
|
|||
**Q:** I want certain commands to turn off in a given room. They should still work normally for
|
||||
staff.
|
||||
|
||||
**A:** This is done using a custom cmdset on a room [locked with the 'call' lock type](Locks). Only
|
||||
**A:** This is done using a custom cmdset on a room [locked with the 'call' lock type](Component/Locks). Only
|
||||
if this lock is passed will the commands on the room be made available to an object inside it. Here
|
||||
is an example of a room where certain commands are disabled for non-staff:
|
||||
|
||||
|
|
@ -142,7 +142,7 @@ superusers).
|
|||
command to only be available on a full moon, from midnight to three in-game time.
|
||||
|
||||
**A:** This is easiest accomplished by putting the "werewolf" command on the Character as normal,
|
||||
but to [lock](Locks) it with the "cmd" type lock. Only if the "cmd" lock type is passed will the
|
||||
but to [lock](Component/Locks) it with the "cmd" type lock. Only if the "cmd" lock type is passed will the
|
||||
command be available.
|
||||
|
||||
```python
|
||||
|
|
@ -157,7 +157,7 @@ class CmdWerewolf(Command):
|
|||
def func(self):
|
||||
# ...
|
||||
```
|
||||
Add this to the [default cmdset as usual](Adding-Command-Tutorial). The `is_full_moon` [lock
|
||||
Add this to the [default cmdset as usual](Howto/StartingTutorial/Adding-Command-Tutorial). The `is_full_moon` [lock
|
||||
function](Locks#lock-functions) does not yet exist. We must create that:
|
||||
|
||||
```python
|
||||
|
|
|
|||
|
|
@ -88,7 +88,7 @@ database, you need to use the caster for the storage.
|
|||
self.caller.db.firestorm_lastcast = now
|
||||
```
|
||||
|
||||
Since we are storing as an [Attribute](Attributes), we need to identify the
|
||||
Since we are storing as an [Attribute](Component/Attributes), we need to identify the
|
||||
variable as `firestorm_lastcast` so we are sure we get the right one (we'll
|
||||
likely have other skills with cooldowns after all). But this method of
|
||||
using cooldowns also has the advantage of working *between* commands - you can
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
|
||||
|
||||
Before reading this tutorial, if you haven't done so already, you might want to
|
||||
read [the documentation on commands](Commands) to get a basic understanding of
|
||||
read [the documentation on commands](Component/Commands) to get a basic understanding of
|
||||
how commands work in Evennia.
|
||||
|
||||
In some types of games a command should not start and finish immediately.
|
||||
|
|
@ -40,7 +40,7 @@ class CmdTest(Command):
|
|||
> Important: The `yield` functionality will *only* work in the `func` method of
|
||||
> Commands. It only works because Evennia has especially
|
||||
> catered for it in Commands. If you want the same functionality elsewhere you
|
||||
> must use the [interactive decorator](Async-Process#The-@interactive-decorator).
|
||||
> must use the [interactive decorator](Concept/Async-Process#The-@interactive-decorator).
|
||||
|
||||
The important line is the `yield 10`. It tells Evennia to "pause" the command
|
||||
and to wait for 10 seconds to execute the rest. If you add this command and
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ You can combine the sending of normal text with the sending (updating of the pro
|
|||
self.msg("This is a text", prompt="This is a prompt")
|
||||
```
|
||||
|
||||
You can update the prompt on demand, this is normally done using [OOB](OOB)-tracking of the relevant
|
||||
You can update the prompt on demand, this is normally done using [OOB](Concept/OOB)-tracking of the relevant
|
||||
Attributes (like the character's health). You could also make sure that attacking commands update
|
||||
the prompt when they cause a change in health, for example.
|
||||
|
||||
|
|
|
|||
|
|
@ -23,7 +23,7 @@ instance.
|
|||
## Coordinates as tags
|
||||
|
||||
The first concept might be the most surprising at first glance: we will create coordinates as
|
||||
[tags](Tags).
|
||||
[tags](Component/Tags).
|
||||
|
||||
> Why not attributes, wouldn't that be easier?
|
||||
|
||||
|
|
|
|||
|
|
@ -106,7 +106,7 @@ Evennia is smart enough to understand that when we type `+something`, `+` is the
|
|||
`something` is the command argument. This will, of course, fail if you have a command beginning by
|
||||
`+` conflicting with the `CmdConnect` key.
|
||||
4. We have altered some class attributes, like `auto_help`. If you want to know what they do and
|
||||
why they have changed here, you can check the [documentation on commands](Commands).
|
||||
why they have changed here, you can check the [documentation on commands](Component/Commands).
|
||||
5. In the command body, we begin by extracting the channel name. Remember that this name should be
|
||||
in the command arguments (that is, in `self.args`). Following the same example, if a player enters
|
||||
`+something`, `self.args` should contain `"something"`. We use `search_channel` to see if this
|
||||
|
|
|
|||
|
|
@ -2,8 +2,8 @@
|
|||
|
||||
|
||||
Evennia allows for exits to have any name. The command "kitchen" is a valid exit name as well as
|
||||
"jump out the window" or "north". An exit actually consists of two parts: an [Exit Object](Objects)
|
||||
and an [Exit Command](Commands) stored on said exit object. The command has the same key and aliases
|
||||
"jump out the window" or "north". An exit actually consists of two parts: an [Exit Object](Component/Objects)
|
||||
and an [Exit Command](Component/Commands) stored on said exit object. The command has the same key and aliases
|
||||
as the object, which is why you can see the exit in the room and just write its name to traverse it.
|
||||
|
||||
If you try to enter the name of a non-existing exit, it is thus the same as trying a non-exising
|
||||
|
|
@ -24,7 +24,7 @@ error message just told us that we couldn't go there.
|
|||
|
||||
## Adding default error commands
|
||||
|
||||
To solve this you need to be aware of how to [write and add new commands](Adding-Command-Tutorial).
|
||||
To solve this you need to be aware of how to [write and add new commands](Howto/StartingTutorial/Adding-Command-Tutorial).
|
||||
What you need to do is to create new commands for all directions you want to support in your game.
|
||||
In this example all we'll do is echo an error message, but you could certainly consider more
|
||||
advanced uses. You add these commands to the default command set. Here is an example of such a set
|
||||
|
|
@ -90,7 +90,7 @@ commands:
|
|||
You cannot move east.
|
||||
|
||||
Further expansions by the exit system (including manipulating the way the Exit command itself is
|
||||
created) can be done by modifying the [Exit typeclass](Typeclasses) directly.
|
||||
created) can be done by modifying the [Exit typeclass](Component/Typeclasses) directly.
|
||||
|
||||
## Additional Comments
|
||||
|
||||
|
|
@ -109,7 +109,7 @@ So why didn't we create a single error command above? Something like this:
|
|||
The anwer is that this would *not* work and understanding why is important in order to not be
|
||||
confused when working with commands and command sets.
|
||||
|
||||
The reason it doesn't work is because Evennia's [command system](Commands) compares commands *both*
|
||||
The reason it doesn't work is because Evennia's [command system](Component/Commands) compares commands *both*
|
||||
by `key` and by `aliases`. If *either* of those match, the two commands are considered *identical*
|
||||
as far as cmdset merging system is concerned.
|
||||
|
||||
|
|
|
|||
|
|
@ -38,7 +38,7 @@ to use. So the *Player* usually operates by making use of the tools prepared for
|
|||
|
||||
For a *Player*, collaborating on a game need not be too different between MUSH and Evennia. The
|
||||
building and description of the game world can still happen mostly in-game using build commands,
|
||||
using text tags and [inline functions](TextTags#inline-functions) to prettify and customize the
|
||||
using text tags and [inline functions](Concept/TextTags#inline-functions) to prettify and customize the
|
||||
experience. Evennia offers external ways to build a world but those are optional. There is also
|
||||
nothing *in principle* stopping a Developer from offering a softcode-like language to Players if
|
||||
that is deemed necessary.
|
||||
|
|
@ -204,7 +204,7 @@ developer changing the underlying Python code.
|
|||
## Next steps
|
||||
|
||||
If you are a *Developer* and are interested in making a more MUSH-like Evennia game, a good start is
|
||||
to look into the Evennia [Tutorial for a first MUSH-like game](Tutorial-for-basic-MUSH-like-game).
|
||||
to look into the Evennia [Tutorial for a first MUSH-like game](Howto/StartingTutorial/Tutorial-for-basic-MUSH-like-game).
|
||||
That steps through building a simple little game from scratch and helps to acquaint you with the
|
||||
various corners of Evennia. There is also the [Tutorial for running roleplaying sessions](Evennia-
|
||||
for-roleplaying-sessions) that can be of interest.
|
||||
|
|
|
|||
|
|
@ -44,7 +44,7 @@ to show your renewed GM status to the other accounts.
|
|||
|
||||
### The permission hierarchy
|
||||
|
||||
Evennia has the following [permission hierarchy](Building-Permissions#assigning-permissions) out of
|
||||
Evennia has the following [permission hierarchy](Concept/Building-Permissions#assigning-permissions) out of
|
||||
the box: *Players, Helpers, Builders, Admins* and finally *Developers*. We could change these but
|
||||
then we'd need to update our Default commands to use the changes. We want to keep this simple, so
|
||||
instead we map our different roles on top of this permission ladder.
|
||||
|
|
@ -60,7 +60,7 @@ everyone.
|
|||
5. `Developers`-level permission are the server administrators, the ones with the ability to
|
||||
restart/shutdown the server as well as changing the permission levels.
|
||||
|
||||
> The [superuser](Building-Permissions#the-super-user) is not part of the hierarchy and actually
|
||||
> The [superuser](Concept/Building-Permissions#the-super-user) is not part of the hierarchy and actually
|
||||
completely bypasses it. We'll assume server admin(s) will "just" be Developers.
|
||||
|
||||
### How to grant permissions
|
||||
|
|
@ -102,7 +102,7 @@ its name will have the string`(GM)` added to the end.
|
|||
#### Character modification
|
||||
|
||||
Let's first start by customizing the Character. We recommend you browse the beginning of the
|
||||
[Account](Accounts) page to make sure you know how Evennia differentiates between the OOC "Account
|
||||
[Account](Component/Accounts) page to make sure you know how Evennia differentiates between the OOC "Account
|
||||
objects" (not to be confused with the `Accounts` permission, which is just a string specifying your
|
||||
access) and the IC "Character objects".
|
||||
|
||||
|
|
@ -142,7 +142,7 @@ Above, we change how the Character's name is displayed: If the account controlli
|
|||
a GM, we attach the string `(GM)` to the Character's name so everyone can tell who's the boss. If we
|
||||
ourselves are Developers or GM's we will see database ids attached to Characters names, which can
|
||||
help if doing database searches against Characters of exactly the same name. We base the "gm-
|
||||
ingness" on having an flag (an [Attribute](Attributes)) named `is_gm`. We'll make sure new GM's
|
||||
ingness" on having an flag (an [Attribute](Component/Attributes)) named `is_gm`. We'll make sure new GM's
|
||||
actually get this flag below.
|
||||
|
||||
> **Extra exercise:** This will only show the `(GM)` text on *Characters* puppeted by a GM account,
|
||||
|
|
@ -152,7 +152,7 @@ that is, it will show only to those in the same location. If we wanted it to als
|
|||
|
||||
#### New @gm/@ungm command
|
||||
|
||||
We will describe in some detail how to create and add an Evennia [command](Commands) here with the
|
||||
We will describe in some detail how to create and add an Evennia [command](Component/Commands) here with the
|
||||
hope that we don't need to be as detailed when adding commands in the future. We will build on
|
||||
Evennia's default "mux-like" commands here.
|
||||
|
||||
|
|
@ -704,7 +704,7 @@ access after the fact.
|
|||
|
||||
## Channels
|
||||
|
||||
Evennia comes with [Channels](Communications#Channels) in-built and they are described fully in the
|
||||
Evennia comes with [Channels](Component/Communications#Channels) in-built and they are described fully in the
|
||||
documentation. For brevity, here are the relevant commands for normal use:
|
||||
|
||||
* `@ccreate new_channel;alias;alias = short description` - Creates a new channel.
|
||||
|
|
|
|||
|
|
@ -132,7 +132,7 @@ Talker-type game you *will* have to bite the bullet and code your game (or find
|
|||
do it for you).
|
||||
|
||||
Even if you won't code anything yourself, as a designer you need to at least understand the basic
|
||||
paradigms of Evennia, such as [Objects](Objects), [Commands](Commands) and [Scripts](Scripts) and
|
||||
paradigms of Evennia, such as [Objects](Component/Objects), [Commands](Component/Commands) and [Scripts](Component/Scripts) and
|
||||
how they hang together. We recommend you go through the [Tutorial World](Tutorial-World-
|
||||
Introduction) in detail (as well as glancing at its code) to get at least a feel for what is
|
||||
involved behind the scenes. You could also look through the tutorial for [building a game from
|
||||
|
|
@ -144,7 +144,7 @@ The earlier you revise problems, the easier they will be to fix.
|
|||
|
||||
A good idea is to host your code online (publicly or privately) using version control. Not only will
|
||||
this make it easy for multiple coders to collaborate (and have a bug-tracker etc), it also means
|
||||
your work is backed up at all times. The [Version Control](Version-Control) tutorial has
|
||||
your work is backed up at all times. The [Version Control](Coding/Version-Control) tutorial has
|
||||
instructions for setting up a sane developer environment with proper version control.
|
||||
|
||||
### "Tech Demo" Building
|
||||
|
|
@ -199,7 +199,7 @@ flag and let people try it! Call upon your alpha-players to try everything - the
|
|||
to break your game in ways that you never could have imagined. In Alpha you might be best off to
|
||||
focus on inviting friends and maybe other MUD developers, people who you can pester to give proper
|
||||
feedback and bug reports (there *will* be bugs, there is no way around it). Follow the quick
|
||||
instructions for [Online Setup](Online-Setup) to make your game visible online. If you hadn't
|
||||
instructions for [Online Setup](Setup/Online-Setup) to make your game visible online. If you hadn't
|
||||
already, make sure to put up your game on the [Evennia game index](http://games.evennia.com/) so
|
||||
people know it's in the works (actually, even pre-alpha games are allowed in the index so don't be
|
||||
shy)!
|
||||
|
|
|
|||
|
|
@ -98,7 +98,7 @@ time, and assuming a standard calendar (see below for the same feature with a cu
|
|||
instance, it can be used to have a specific message every (in-game) day at 6:00 AM showing how the
|
||||
sun rises.
|
||||
|
||||
The function `schedule()` should be used here. It will create a [script](Scripts) with some
|
||||
The function `schedule()` should be used here. It will create a [script](Component/Scripts) with some
|
||||
additional features to make sure the script is always executed when the game time matches the given
|
||||
parameters.
|
||||
|
||||
|
|
|
|||
|
|
@ -45,12 +45,12 @@ makes it easier to change and update things in one place later.
|
|||
values for Health, a list of skills etc, store those things on the Character - don't store how to
|
||||
roll or change them.
|
||||
- Next is to determine just how you want to store things on your Objects and Characters. You can
|
||||
choose to either store things as individual [Attributes](Attributes), like `character.db.STR=34` and
|
||||
choose to either store things as individual [Attributes](Component/Attributes), like `character.db.STR=34` and
|
||||
`character.db.Hunting_skill=20`. But you could also use some custom storage method, like a
|
||||
dictionary `character.db.skills = {"Hunting":34, "Fishing":20, ...}`. A much more fancy solution is
|
||||
to look at the Ainneve [Trait
|
||||
handler](https://github.com/evennia/ainneve/blob/master/world/traits.py). Finally you could even go
|
||||
with a [custom django model](New-Models). Which is the better depends on your game and the
|
||||
with a [custom django model](Concept/New-Models). Which is the better depends on your game and the
|
||||
complexity of your system.
|
||||
- Make a clear [API](http://en.wikipedia.org/wiki/Application_programming_interface) into your
|
||||
rules. That is, make methods/functions that you feed with, say, your Character and which skill you
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ This is a small tutorial for customizing your character objects, using the examp
|
|||
turn on and off ANSI color parsing as an example. `@options NOCOLOR=True` will now do what this
|
||||
tutorial shows, but the tutorial subject can be applied to other toggles you may want, as well.
|
||||
|
||||
In the Building guide's [Colors](TextTags#coloured-text) page you can learn how to add color to your
|
||||
In the Building guide's [Colors](Concept/TextTags#coloured-text) page you can learn how to add color to your
|
||||
game by using special markup. Colors enhance the gaming experience, but not all users want color.
|
||||
Examples would be users working from clients that don't support color, or people with various seeing
|
||||
disabilities that rely on screen readers to play your game. Also, whereas Evennia normally
|
||||
|
|
@ -26,7 +26,7 @@ configuration system for your characters. This is the basic sequence:
|
|||
Create a new module in `mygame/typeclasses` named, for example, `mycharacter.py`. Alternatively you
|
||||
can simply add a new class to 'mygamegame/typeclasses/characters.py'.
|
||||
|
||||
In your new module(or characters.py), create a new [Typeclass](Typeclasses) inheriting from
|
||||
In your new module(or characters.py), create a new [Typeclass](Component/Typeclasses) inheriting from
|
||||
`evennia.DefaultCharacter`. We will also import `evennia.utils.ansi`, which we will use later.
|
||||
|
||||
```python
|
||||
|
|
@ -39,7 +39,7 @@ In your new module(or characters.py), create a new [Typeclass](Typeclasses) inhe
|
|||
self.db.config_color = True
|
||||
```
|
||||
|
||||
Above we set a simple config value as an [Attribute](Attributes).
|
||||
Above we set a simple config value as an [Attribute](Component/Attributes).
|
||||
|
||||
Let's make sure that new characters are created of this type. Edit your
|
||||
`mygame/server/conf/settings.py` file and add/change `BASE_CHARACTER_TYPECLASS` to point to your new
|
||||
|
|
@ -158,7 +158,7 @@ class CharacterCmdSet(default_cmds.CharacterCmdSet):
|
|||
|
||||
## More colors
|
||||
|
||||
Apart from ANSI colors, Evennia also supports **Xterm256** colors (See [Colors](TextTags#colored-
|
||||
Apart from ANSI colors, Evennia also supports **Xterm256** colors (See [Colors](Concept/TextTags#colored-
|
||||
text)). The `msg()` method supports the `xterm256` keyword for manually activating/deactiving
|
||||
xterm256. It should be easy to expand the above example to allow players to customize xterm256
|
||||
regardless of if Evennia thinks their client supports it or not.
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# NPC shop Tutorial
|
||||
|
||||
This tutorial will describe how to make an NPC-run shop. We will make use of the [EvMenu](EvMenu)
|
||||
This tutorial will describe how to make an NPC-run shop. We will make use of the [EvMenu](Component/EvMenu)
|
||||
system to present shoppers with a menu where they can buy things from the store's stock.
|
||||
|
||||
Our shop extends over two rooms - a "front" room open to the shop's customers and a locked "store
|
||||
|
|
@ -23,7 +23,7 @@ deducted and the goods transferred from the store room to the inventory of the c
|
|||
|
||||
We want to show a menu to the customer where they can list, examine and buy items in the store. This
|
||||
menu should change depending on what is currently for sale. Evennia's *EvMenu* utility will manage
|
||||
the menu for us. It's a good idea to [read up on EvMenu](EvMenu) if you are not familiar with it.
|
||||
the menu for us. It's a good idea to [read up on EvMenu](Component/EvMenu) if you are not familiar with it.
|
||||
|
||||
#### Designing the menu
|
||||
|
||||
|
|
@ -167,7 +167,7 @@ of the customer.
|
|||
#### The command to start the menu
|
||||
|
||||
We could *in principle* launch the shopping menu the moment a customer steps into our shop room, but
|
||||
this would probably be considered pretty annoying. It's better to create a [Command](Commands) for
|
||||
this would probably be considered pretty annoying. It's better to create a [Command](Component/Commands) for
|
||||
customers to explicitly wanting to shop around.
|
||||
|
||||
```python
|
||||
|
|
@ -200,7 +200,7 @@ class CmdBuy(Command):
|
|||
This will launch the menu. The `EvMenu` instance is initialized with the path to this very module -
|
||||
since the only global functions available in this module are our menu nodes, this will work fine
|
||||
(you could also have put those in a separate module). We now just need to put this command in a
|
||||
[CmdSet](Command-Sets) so we can add it correctly to the game:
|
||||
[CmdSet](Component/Command-Sets) so we can add it correctly to the game:
|
||||
|
||||
```python
|
||||
from evennia import CmdSet
|
||||
|
|
@ -219,7 +219,7 @@ There are really only two things that separate our shop from any other Room:
|
|||
the shop.
|
||||
|
||||
For testing we could easily add these features manually to a room using `@py` or other admin
|
||||
commands. Just to show how it can be done we'll instead make a custom [Typeclass](Typeclasses) for
|
||||
commands. Just to show how it can be done we'll instead make a custom [Typeclass](Component/Typeclasses) for
|
||||
the shop room and make a small command that builders can use to build both the shop and the
|
||||
storeroom at once.
|
||||
|
||||
|
|
@ -295,12 +295,12 @@ class CmdBuildShop(Command):
|
|||
Our typeclass is simple and so is our `buildshop` command. The command (which is for Builders only)
|
||||
just takes the name of the shop and builds the front room and a store room to go with it (always
|
||||
named `"<shopname>-storage"`. It connects the rooms with a two-way exit. You need to add
|
||||
`CmdBuildShop` [to the default cmdset](Adding-Command-Tutorial#step-2-adding-the-command-to-a-
|
||||
`CmdBuildShop` [to the default cmdset](Howto/StartingTutorial/Adding-Command-Tutorial#step-2-adding-the-command-to-a-
|
||||
default-cmdset) before you can use it. Once having created the shop you can now `@teleport` to it or
|
||||
`@open` a new exit to it. You could also easily expand the above command to automatically create
|
||||
exits to and from the new shop from your current location.
|
||||
|
||||
To avoid customers walking in and stealing everything, we create a [Lock](Locks) on the storage
|
||||
To avoid customers walking in and stealing everything, we create a [Lock](Component/Locks) on the storage
|
||||
door. It's a simple lock that requires the one entering to carry an object named
|
||||
`<shopname>-storekey`. We even create such a key object and drop it in the shop for the new shop
|
||||
keeper to pick up.
|
||||
|
|
@ -328,7 +328,7 @@ would then be gone and the counter be wrong - the shop would pass us the next it
|
|||
|
||||
Fixing these issues are left as an exercise.
|
||||
|
||||
If you want to keep the shop fully NPC-run you could add a [Script](Scripts) to restock the shop's
|
||||
If you want to keep the shop fully NPC-run you could add a [Script](Component/Scripts) to restock the shop's
|
||||
store room regularly. This shop example could also easily be owned by a human Player (run for them
|
||||
by a hired NPC) - the shop owner would get the key to the store room and be responsible for keeping
|
||||
it well stocked.
|
||||
|
|
@ -1,6 +1,6 @@
|
|||
# Adding Command Tutorial
|
||||
|
||||
This is a quick first-time tutorial expanding on the [Commands](Commands) documentation.
|
||||
This is a quick first-time tutorial expanding on the [Commands](Component/Commands) documentation.
|
||||
|
||||
Let's assume you have just downloaded Evennia, installed it and created your game folder (let's call
|
||||
it just `mygame` here). Now you want to try to add a new command. This is the fastest way to do it.
|
||||
|
|
@ -16,7 +16,7 @@ example code.
|
|||
1. Give your class a useful _docstring_. A docstring is the string at the very top of a class or
|
||||
function/method. The docstring at the top of the command class is read by Evennia to become the help
|
||||
entry for the Command (see
|
||||
[Command Auto-help](Help-System#command-auto-help-system)).
|
||||
[Command Auto-help](Component/Help-System#command-auto-help-system)).
|
||||
1. Define a class method `func(self)` that echoes your input back to you.
|
||||
|
||||
Below is an example how this all could look for the echo command:
|
||||
|
|
@ -47,7 +47,7 @@ Below is an example how this all could look for the echo command:
|
|||
|
||||
## Step 2: Adding the Command to a default Cmdset
|
||||
|
||||
The command is not available to use until it is part of a [Command Set](Command-Sets). In this
|
||||
The command is not available to use until it is part of a [Command Set](Component/Command-Sets). In this
|
||||
example we will go the easiest route and add it to the default Character commandset that already
|
||||
exists.
|
||||
|
||||
|
|
@ -93,7 +93,7 @@ If you want to overload existing default commands (such as `look` or `get`), jus
|
|||
command with the same key as the old one - it will then replace it. Just remember that you must use
|
||||
`@reload` to see any changes.
|
||||
|
||||
See [Commands](Commands) for many more details and possibilities when defining Commands and using
|
||||
See [Commands](Component/Commands) for many more details and possibilities when defining Commands and using
|
||||
Cmdsets in various ways.
|
||||
|
||||
|
||||
|
|
@ -131,7 +131,7 @@ only make the new merged cmdset permanent on that *single* object. Often you wan
|
|||
this particular class to have this cmdset.
|
||||
|
||||
To make sure all new created objects get your new merged set, put the `cmdset.add` call in your
|
||||
custom [Typeclasses](Typeclasses)' `at_object_creation` method:
|
||||
custom [Typeclasses](Component/Typeclasses)' `at_object_creation` method:
|
||||
|
||||
```python
|
||||
# e.g. in mygame/typeclasses/objects.py
|
||||
|
|
|
|||
|
|
@ -13,9 +13,9 @@ When you create a new Evennia game (with for example `evennia --init mygame`) Ev
|
|||
automatically create empty child classes `Object`, `Character`, `Room` and `Exit` respectively. They
|
||||
are found `mygame/typeclasses/objects.py`, `mygame/typeclasses/rooms.py` etc.
|
||||
|
||||
> Technically these are all [Typeclassed](Typeclasses), which can be ignored for now. In
|
||||
> Technically these are all [Typeclassed](Component/Typeclasses), which can be ignored for now. In
|
||||
> `mygame/typeclasses` are also base typeclasses for out-of-character things, notably
|
||||
> [Channels](Communications), [Accounts](Accounts) and [Scripts](Scripts). We don't cover those in
|
||||
> [Channels](Component/Communications), [Accounts](Component/Accounts) and [Scripts](Component/Scripts). We don't cover those in
|
||||
> this tutorial.
|
||||
|
||||
For your own game you will most likely want to expand on these very simple beginnings. It's normal
|
||||
|
|
@ -62,13 +62,13 @@ up.
|
|||
you will find the traceback. The most common error is that you have some sort of syntax error in
|
||||
your class.
|
||||
|
||||
Note that the [Locks](Locks) and [Attribute](Attributes) which are set in the typeclass could just
|
||||
Note that the [Locks](Component/Locks) and [Attribute](Component/Attributes) which are set in the typeclass could just
|
||||
as well have been set using commands in-game, so this is a *very* simple example.
|
||||
|
||||
## Storing data on initialization
|
||||
|
||||
The `at_object_creation` is only called once, when the object is first created. This makes it ideal
|
||||
for database-bound things like [Attributes](Attributes). But sometimes you want to create temporary
|
||||
for database-bound things like [Attributes](Component/Attributes). But sometimes you want to create temporary
|
||||
properties (things that are not to be stored in the database but still always exist every time the
|
||||
object is created). Such properties can be initialized in the `at_init` method on the object.
|
||||
`at_init` is called every time the object is loaded into memory.
|
||||
|
|
@ -86,7 +86,7 @@ def at_init(self):
|
|||
self.ndb.mylist = []
|
||||
```
|
||||
|
||||
> Note: As mentioned in the [Typeclasses](Typeclasses) documentation, `at_init` replaces the use of
|
||||
> Note: As mentioned in the [Typeclasses](Component/Typeclasses) documentation, `at_init` replaces the use of
|
||||
> the standard `__init__` method of typeclasses due to how the latter may be called in situations
|
||||
> other than you'd expect. So use `at_init` where you would normally use `__init__`.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,8 +1,8 @@
|
|||
# Building Quickstart
|
||||
|
||||
|
||||
The [default command](Default-Command-Help) definitions coming with Evennia
|
||||
follows a style [similar](Using-MUX-as-a-Standard) to that of MUX, so the
|
||||
The [default command](Component/Default-Command-Help) definitions coming with Evennia
|
||||
follows a style [similar](Concept/Using-MUX-as-a-Standard) to that of MUX, so the
|
||||
commands should be familiar if you used any such code bases before.
|
||||
|
||||
> Throughout the larger documentation you may come across commands prefixed
|
||||
|
|
@ -85,14 +85,14 @@ dropped in the room, then try this:
|
|||
|
||||
lock box = get:false()
|
||||
|
||||
Locks represent a rather [big topic](Locks), but for now that will do what we want. This will lock
|
||||
Locks represent a rather [big topic](Component/Locks), but for now that will do what we want. This will lock
|
||||
the box so noone can lift it. The exception is superusers, they override all locks and will pick it
|
||||
up anyway. Make sure you are quelling your superuser powers and try to get the box now:
|
||||
|
||||
> get box
|
||||
You can't get that.
|
||||
|
||||
Think thís default error message looks dull? The `get` command looks for an [Attribute](Attributes)
|
||||
Think thís default error message looks dull? The `get` command looks for an [Attribute](Component/Attributes)
|
||||
named `get_err_msg` for returning a nicer error message (we just happen to know this, you would need
|
||||
to peek into the
|
||||
[code](https://github.com/evennia/evennia/blob/master/evennia/commands/default/general.py#L235) for
|
||||
|
|
@ -114,7 +114,7 @@ Commands tutorial](Adding-Command-Tutorial) for help with creating your first ow
|
|||
|
||||
## Get a Personality
|
||||
|
||||
[Scripts](Scripts) are powerful out-of-character objects useful for many "under the hood" things.
|
||||
[Scripts](Component/Scripts) are powerful out-of-character objects useful for many "under the hood" things.
|
||||
One of their optional abilities is to do things on a timer. To try out a first script, let's put one
|
||||
on ourselves. There is an example script in `evennia/contrib/tutorial_examples/bodyfunctions.py`
|
||||
that is called `BodyFunctions`. To add this to us we will use the `script` command:
|
||||
|
|
@ -137,14 +137,14 @@ When you are tired of your character's "insights", kill the script with
|
|||
script/stop self = tutorial_examples.bodyfunctions.BodyFunctions
|
||||
|
||||
You create your own scripts in Python, outside the game; the path you give to `script` is literally
|
||||
the Python path to your script file. The [Scripts](Scripts) page explains more details.
|
||||
the Python path to your script file. The [Scripts](Component/Scripts) page explains more details.
|
||||
|
||||
## Pushing Your Buttons
|
||||
|
||||
If we get back to the box we made, there is only so much fun you can do with it at this point. It's
|
||||
just a dumb generic object. If you renamed it to `stone` and changed its description noone would be
|
||||
the wiser. However, with the combined use of custom [Typeclasses](Typeclasses), [Scripts](Scripts)
|
||||
and object-based [Commands](Commands), you could expand it and other items to be as unique, complex
|
||||
the wiser. However, with the combined use of custom [Typeclasses](Component/Typeclasses), [Scripts](Component/Scripts)
|
||||
and object-based [Commands](Component/Commands), you could expand it and other items to be as unique, complex
|
||||
and interactive as you want.
|
||||
|
||||
Let's take an example. So far we have only created objects that use the default object typeclass
|
||||
|
|
@ -161,7 +161,7 @@ sure to look in`evennia/contrib/` so you don't have to write the full path every
|
|||
- one red button.
|
||||
|
||||
The RedButton is an example object intended to show off a few of Evennia's features. You will find
|
||||
that the [Typeclass](Typeclasses) and [Commands](Commands) controlling it are inside
|
||||
that the [Typeclass](Component/Typeclasses) and [Commands](Component/Commands) controlling it are inside
|
||||
`evennia/contrib/tutorial_examples/`.
|
||||
|
||||
If you wait for a while (make sure you dropped it!) the button will blink invitingly. Why don't you
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ Here are some pointers to get you going.
|
|||
|
||||
Evennia is developed using Python. Even if you are more of a designer than a coder, it is wise to
|
||||
learn how to read and understand basic Python code. If you are new to Python, or need a refresher,
|
||||
take a look at our two-part [Python introduction](Python-basic-introduction).
|
||||
take a look at our two-part [Python introduction](Howto/StartingTutorial/Python-basic-introduction).
|
||||
|
||||
### Explore Evennia interactively
|
||||
|
||||
|
|
@ -31,7 +31,7 @@ This will open an Evennia-aware python shell (using ipython). From within this s
|
|||
evennia.<TAB>
|
||||
|
||||
That is, enter `evennia.` and press the `<TAB>` key. This will show you all the resources made
|
||||
available at the top level of Evennia's "flat API". See the [flat API](Evennia-API) page for more
|
||||
available at the top level of Evennia's "flat API". See the [flat API](Coding/Evennia-API) page for more
|
||||
info on how to explore it efficiently.
|
||||
|
||||
You can complement your exploration by peeking at the sections of the much more detailed [Developer
|
||||
|
|
@ -52,7 +52,7 @@ using such a checker can be a good start to weed out the simple problems.
|
|||
|
||||
### Plan before you code
|
||||
|
||||
Before you start coding away at your dream game, take a look at our [Game Planning](Game-Planning)
|
||||
Before you start coding away at your dream game, take a look at our [Game Planning](Howto/Game-Planning)
|
||||
page. It might hopefully help you avoid some common pitfalls and time sinks.
|
||||
|
||||
### Code in your game folder, not in the evennia/ repository
|
||||
|
|
@ -98,7 +98,5 @@ chat](http://webchat.freenode.net/?channels=evennia) are also there for you.
|
|||
|
||||
And finally, of course, have fun!
|
||||
|
||||
[feature-request]:
|
||||
(https://github.com/evennia/evennia/issues/new?title=Feature+Request%3a+%3Cdescriptive+title+here%3E&body=%23%23%23%23+Description+of+the+suggested+feature+and+how+it+is+supposed+to+work+for+the+admin%2fend+user%3a%0D%0A%0D%0A%0D%0A%23%23%23%23+A+list+of+arguments+for+why+you+think+this+new+feature+should+be+included+in+Evennia%3a%0D%0A%0D%0A1.%0D%0A2.%0D%0A%0D%0A%23%23%23%23+Extra+information%2c+such+as+requirements+or+ideas+on+implementation%3a%0D%0A%0D%0A
|
||||
[bug]:
|
||||
https://github.com/evennia/evennia/issues/new?title=Bug%3a+%3Cdescriptive+title+here%3E&body=%23%23%23%23+Steps+to+reproduce+the+issue%3a%0D%0A%0D%0A1.+%0D%0A2.+%0D%0A3.+%0D%0A%0D%0A%23%23%23%23+What+I+expect+to+see+and+what+I+actually+see+%28tracebacks%2c+error+messages+etc%29%3a%0D%0A%0D%0A%0D%0A%0D%0A%23%23%23%23+Extra+information%2c+such+as+Evennia+revision%2frepo%2fbranch%2c+operating+system+and+ideas+for+how+to+solve%3a%0D%0A%0D%0A
|
||||
[feature-request]: (https://github.com/evennia/evennia/issues/new?title=Feature+Request%3a+%3Cdescriptive+title+here%3E&body=%23%23%23%23+Description+of+the+suggested+feature+and+how+it+is+supposed+to+work+for+the+admin%2fend+user%3a%0D%0A%0D%0A%0D%0A%23%23%23%23+A+list+of+arguments+for+why+you+think+this+new+feature+should+be+included+in+Evennia%3a%0D%0A%0D%0A1.%0D%0A2.%0D%0A%0D%0A%23%23%23%23+Extra+information%2c+such+as+requirements+or+ideas+on+implementation%3a%0D%0A%0D%0A
|
||||
[bug]: https://github.com/evennia/evennia/issues/new?title=Bug%3a+%3Cdescriptive+title+here%3E&body=%23%23%23%23+Steps+to+reproduce+the+issue%3a%0D%0A%0D%0A1.+%0D%0A2.+%0D%0A3.+%0D%0A%0D%0A%23%23%23%23+What+I+expect+to+see+and+what+I+actually+see+%28tracebacks%2c+error+messages+etc%29%3a%0D%0A%0D%0A%0D%0A%0D%0A%23%23%23%23+Extra+information%2c+such+as+Evennia+revision%2frepo%2fbranch%2c+operating+system+and+ideas+for+how+to+solve%3a%0D%0A%0D%0A
|
||||
|
|
@ -16,11 +16,11 @@ system.
|
|||
|
||||
- **self** / **me** - the calling object (i.e. you)
|
||||
- **here** - the current caller's location
|
||||
- **obj** - a dummy [Object](Objects) instance
|
||||
- **evennia** - Evennia's [flat API](Evennia-API) - through this you can access all of Evennia.
|
||||
- **obj** - a dummy [Object](Component/Objects) instance
|
||||
- **evennia** - Evennia's [flat API](Coding/Evennia-API) - through this you can access all of Evennia.
|
||||
|
||||
For accessing other objects in the same room you need to use `self.search(name)`. For objects in
|
||||
other locations, use one of the `evennia.search_*` methods. See [below](Execute-Python-Code#finding-
|
||||
other locations, use one of the `evennia.search_*` methods. See [below](Howto/StartingTutorial/Execute-Python-Code#finding-
|
||||
objects).
|
||||
|
||||
## Returning output
|
||||
|
|
@ -117,4 +117,4 @@ of other editing features, such as tab-completion and `__doc__`-string reading.
|
|||
In [2]: evennia.managers.objects.all()
|
||||
Out[3]: [<ObjectDB: Harry>, <ObjectDB: Limbo>, ...]
|
||||
|
||||
See the page about the [Evennia-API](Evennia-API) for more things to explore.
|
||||
See the page about the [Evennia-API](Coding/Evennia-API) for more things to explore.
|
||||
|
|
@ -10,7 +10,7 @@ Started](Getting-Started) instructions. You should have initialized a new game f
|
|||
`evennia --init foldername` command. We will in the following assume this folder is called
|
||||
"mygame".
|
||||
|
||||
It might be a good idea to eye through the brief [Coding Introduction](Coding-Introduction) too
|
||||
It might be a good idea to eye through the brief [Coding Introduction](Howto/StartingTutorial/Coding-Introduction) too
|
||||
(especially the recommendations in the section about the evennia "flat" API and about using `evennia
|
||||
shell` will help you here and in the future).
|
||||
|
||||
|
|
@ -57,13 +57,13 @@ up with a new command to view those attributes.
|
|||
return self.db.strength, self.db.agility, self.db.magic
|
||||
```
|
||||
|
||||
1. [Reload](Start-Stop-Reload) the server (you will still be connected to the game after doing
|
||||
1. [Reload](Setup/Start-Stop-Reload) the server (you will still be connected to the game after doing
|
||||
this). Note that if you examine *yourself* you will *not* see any new Attributes appear yet. Read
|
||||
the next section to understand why.
|
||||
|
||||
#### Updating Yourself
|
||||
|
||||
It's important to note that the new [Attributes](Attributes) we added above will only be stored on
|
||||
It's important to note that the new [Attributes](Component/Attributes) we added above will only be stored on
|
||||
*newly* created characters. The reason for this is simple: The `at_object_creation` method, where we
|
||||
added those Attributes, is per definition only called when the object is *first created*, then never
|
||||
again. This is usually a good thing since those Attributes may change over time - calling that hook
|
||||
|
|
@ -112,8 +112,8 @@ what the `@update` command does under the hood). From in-game you can do the sam
|
|||
MyClass.objects.all()]
|
||||
```
|
||||
|
||||
See the [Object Typeclass tutorial](Adding-Object-Typeclass-Tutorial) for more help and the
|
||||
[Typeclasses](Typeclasses) and [Attributes](Attributes) page for detailed documentation about
|
||||
See the [Object Typeclass tutorial](Howto/StartingTutorial/Adding-Object-Typeclass-Tutorial) for more help and the
|
||||
[Typeclasses](Component/Typeclasses) and [Attributes](Component/Attributes) page for detailed documentation about
|
||||
Typeclasses and Attributes.
|
||||
|
||||
#### Troubleshooting: Updating Yourself
|
||||
|
|
@ -159,7 +159,7 @@ tracebacks and you'll be able to resolve the vast majority of common errors easi
|
|||
### Add a New Default Command
|
||||
|
||||
The `@py` command used above is only available to privileged users. We want any player to be able to
|
||||
see their stats. Let's add a new [command](Commands) to list the abilities we added in the previous
|
||||
see their stats. Let's add a new [command](Component/Commands) to list the abilities we added in the previous
|
||||
section.
|
||||
|
||||
1. Open `mygame/commands/command.py`. You could in principle put your command anywhere but this
|
||||
|
|
@ -201,7 +201,7 @@ the bottom of this file:
|
|||
self.add(CmdAbilities())
|
||||
```
|
||||
|
||||
1. [Reload](Start-Stop-Reload) the server (noone will be disconnected by doing this).
|
||||
1. [Reload](Setup/Start-Stop-Reload) the server (noone will be disconnected by doing this).
|
||||
|
||||
You (and anyone else) should now be able to use `abilities` (or its alias `abi`) as part of your
|
||||
normal commands in-game:
|
||||
|
|
@ -211,8 +211,8 @@ abilities
|
|||
STR: 5, AGI: 4, MAG: 2
|
||||
```
|
||||
|
||||
See the [Adding a Command tutorial](Adding-Command-Tutorial) for more examples and the
|
||||
[Commands](Commands) section for detailed documentation about the Command system.
|
||||
See the [Adding a Command tutorial](Howto/StartingTutorial/Adding-Command-Tutorial) for more examples and the
|
||||
[Commands](Component/Commands) section for detailed documentation about the Command system.
|
||||
|
||||
### Make a New Type of Object
|
||||
|
||||
|
|
@ -263,7 +263,7 @@ functionality. Here is an example of how the file could look:
|
|||
|
||||
1. Check your code for bugs. Tracebacks will appear on your command line or log. If you have a grave
|
||||
Syntax Error in your code, the source file itself will fail to load which can cause issues with the
|
||||
entire cmdset. If so, fix your bug and [reload the server from the command line](Start-Stop-Reload)
|
||||
entire cmdset. If so, fix your bug and [reload the server from the command line](Setup/Start-Stop-Reload)
|
||||
(noone will be disconnected by doing this).
|
||||
1. Use `@create/drop stone:wiseobject.WiseObject` to create a talkative stone. If the `@create`
|
||||
command spits out a warning or cannot find the typeclass (it will tell you which paths it searched),
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
|
||||
|
||||
This tutorial will elaborate on the many ways one can parse command arguments. The first step after
|
||||
[adding a command](Adding-Command-Tutorial) usually is to parse its arguments. There are lots of
|
||||
[adding a command](Howto/StartingTutorial/Adding-Command-Tutorial) usually is to parse its arguments. There are lots of
|
||||
ways to do it, but some are indeed better than others and this tutorial will try to present them.
|
||||
|
||||
If you're a Python beginner, this tutorial might help you a lot. If you're already familiar with
|
||||
|
|
@ -652,7 +652,7 @@ about... what is this `"book"`?
|
|||
|
||||
To get an object from a string, we perform an Evennia search. Evennia provides a `search` method on
|
||||
all typeclassed objects (you will most likely use the one on characters or accounts). This method
|
||||
supports a very wide array of arguments and has [its own tutorial](Tutorial-Searching-For-Objects).
|
||||
supports a very wide array of arguments and has [its own tutorial](Howto/StartingTutorial/Tutorial-Searching-For-Objects).
|
||||
Some examples of useful cases follow:
|
||||
|
||||
### Local searches
|
||||
|
|
|
|||
|
|
@ -7,14 +7,14 @@ and low on detail. There are countless Python guides and tutorials, books and vi
|
|||
learning more in-depth - use them!
|
||||
|
||||
**Contents:**
|
||||
- [Evennia Hello world](Python-basic-introduction#evennia-hello-world)
|
||||
- [Importing modules](Python-basic-introduction#importing-modules)
|
||||
- [Parsing Python errors](Python-basic-introduction#parsing-python-errors)
|
||||
- [Our first function](Python-basic-introduction#our-first-function)
|
||||
- [Looking at the log](Python-basic-introduction#looking-at-the-log)
|
||||
- (continued in [part 2](Python-basic-tutorial-part-two))
|
||||
- [Evennia Hello world](Howto/StartingTutorial/Python-basic-introduction#evennia-hello-world)
|
||||
- [Importing modules](Howto/StartingTutorial/Python-basic-introduction#importing-modules)
|
||||
- [Parsing Python errors](Howto/StartingTutorial/Python-basic-introduction#parsing-python-errors)
|
||||
- [Our first function](Howto/StartingTutorial/Python-basic-introduction#our-first-function)
|
||||
- [Looking at the log](Howto/StartingTutorial/Python-basic-introduction#looking-at-the-log)
|
||||
- (continued in [part 2](Howto/StartingTutorial/Python-basic-tutorial-part-two))
|
||||
|
||||
This quickstart assumes you have [gotten Evennia started](Getting-Started). You should make sure
|
||||
This quickstart assumes you have [gotten Evennia started](Setup/Getting-Started). You should make sure
|
||||
that you are able to see the output from the server in the console from which you started it. Log
|
||||
into the game either with a mud client on `localhost:4000` or by pointing a web browser to
|
||||
`localhost:4001/webclient`. Log in as your superuser (the user you created during install).
|
||||
|
|
@ -263,5 +263,5 @@ enter `Ctrl-C` or `Cmd-C` depending on your system. As a game dev it is importa
|
|||
log output when working in Evennia - many errors will only appear with full details here. You may
|
||||
sometimes have to scroll up in the history if you miss it.
|
||||
|
||||
This tutorial is continued in [Part 2](Python-basic-tutorial-part-two), where we'll start learning
|
||||
This tutorial is continued in [Part 2](Howto/StartingTutorial/Python-basic-tutorial-part-two), where we'll start learning
|
||||
about objects and to explore the Evennia library.
|
||||
|
|
@ -1,16 +1,16 @@
|
|||
# Python basic tutorial part two
|
||||
|
||||
[In the first part](Python-basic-introduction) of this Python-for-Evennia basic tutorial we learned
|
||||
[In the first part](Howto/StartingTutorial/Python-basic-introduction) of this Python-for-Evennia basic tutorial we learned
|
||||
how to run some simple Python code from inside the game. We also made our first new *module*
|
||||
containing a *function* that we called. Now we're going to start exploring the very important
|
||||
subject of *objects*.
|
||||
|
||||
**Contents:**
|
||||
- [On the subject of objects](Python-basic-tutorial-part-two#on-the-subject-of-objects)
|
||||
- [Exploring the Evennia library](Python-basic-tutorial-part-two#exploring-the-evennia-library)
|
||||
- [Tweaking our Character class](Python-basic-tutorial-part-two#tweaking-our-character-class)
|
||||
- [The Evennia shell](Python-basic-tutorial-part-two#the-evennia-shell)
|
||||
- [Where to go from here](Python-basic-tutorial-part-two#where-to-go-from-here)
|
||||
- [On the subject of objects](Howto/StartingTutorial/Python-basic-tutorial-part-two#on-the-subject-of-objects)
|
||||
- [Exploring the Evennia library](Howto/StartingTutorial/Python-basic-tutorial-part-two#exploring-the-evennia-library)
|
||||
- [Tweaking our Character class](Howto/StartingTutorial/Python-basic-tutorial-part-two#tweaking-our-character-class)
|
||||
- [The Evennia shell](Howto/StartingTutorial/Python-basic-tutorial-part-two#the-evennia-shell)
|
||||
- [Where to go from here](Howto/StartingTutorial/Python-basic-tutorial-part-two#where-to-go-from-here)
|
||||
|
||||
### On the subject of objects
|
||||
|
||||
|
|
@ -171,7 +171,7 @@ There are lots of things in there. There are some docs but most of those have to
|
|||
distribution of Evennia and does not concern us right now. The `evennia` subfolder is what we are
|
||||
looking for. *This* is what you are accessing when you do `from evennia import ...`. It's set up by
|
||||
Evennia as a good place to find modules when the server starts. The exact layout of the Evennia
|
||||
library [is covered by our directory overview](Directory-Overview#evennia-library-layout). You can
|
||||
library [is covered by our directory overview](Coding/Directory-Overview#evennia-library-layout). You can
|
||||
also explore it [online on github](https://github.com/evennia/evennia/tree/master/evennia).
|
||||
|
||||
The structure of the library directly reflects how you import from it.
|
||||
|
|
@ -224,7 +224,7 @@ is the same thing, just a little easier to remember.
|
|||
|
||||
> To access the shortcuts of the flat API you *must* use `from evennia import
|
||||
> ...`. Using something like `import evennia.DefaultCharacter` will not work.
|
||||
> See [more about the Flat API here](Evennia-API).
|
||||
> See [more about the Flat API here](Coding/Evennia-API).
|
||||
|
||||
|
||||
### Tweaking our Character class
|
||||
|
|
@ -283,8 +283,8 @@ brief summary of the methods we find in `DefaultCharacter` (follow in the code t
|
|||
roughly where things happen)::
|
||||
|
||||
- `basetype_setup` is called by Evennia only once, when a Character is first created. In the
|
||||
`DefaultCharacter` class it sets some particular [Locks](Locks) so that people can't pick up and
|
||||
puppet Characters just like that. It also adds the [Character Cmdset](Command-Sets) so that
|
||||
`DefaultCharacter` class it sets some particular [Locks](Component/Locks) so that people can't pick up and
|
||||
puppet Characters just like that. It also adds the [Character Cmdset](Component/Command-Sets) so that
|
||||
Characters always can accept command-input (this should usually not be modified - the normal hook to
|
||||
override is `at_object_creation`, which is called after `basetype_setup` (it's in the parent)).
|
||||
- `at_after_move` makes it so that every time the Character moves, the `look` command is
|
||||
|
|
@ -454,8 +454,7 @@ program.
|
|||
|
||||
IPython ...
|
||||
...
|
||||
In [1]:
|
||||
|
||||
In [1]:
|
||||
IPython has some very nice ways to explore what Evennia has to offer.
|
||||
|
||||
> import evennia
|
||||
|
|
|
|||
|
|
@ -31,7 +31,7 @@ allows for emoting as part of combat which is an advantage for roleplay-heavy ga
|
|||
To implement a freeform combat system all you need is a dice roller and a roleplaying rulebook. See
|
||||
[contrib/dice.py](https://github.com/evennia/evennia/blob/master/evennia/contrib/dice.py) for an
|
||||
example dice roller. To implement at twitch-based system you basically need a few combat
|
||||
[commands](Commands), possibly ones with a [cooldown](Command-Cooldown). You also need a [game rule
|
||||
[commands](Component/Commands), possibly ones with a [cooldown](Howto/Command-Cooldown). You also need a [game rule
|
||||
module](Implementing-a-game-rule-system) that makes use of it. We will focus on the turn-based
|
||||
variety here.
|
||||
|
||||
|
|
@ -61,22 +61,22 @@ reported. A new turn then begins.
|
|||
|
||||
For creating the combat system we will need the following components:
|
||||
|
||||
- A combat handler. This is the main mechanic of the system. This is a [Script](Scripts) object
|
||||
- A combat handler. This is the main mechanic of the system. This is a [Script](Component/Scripts) object
|
||||
created for each combat. It is not assigned to a specific object but is shared by the combating
|
||||
characters and handles all the combat information. Since Scripts are database entities it also means
|
||||
that the combat will not be affected by a server reload.
|
||||
- A combat [command set](Command-Sets) with the relevant commands needed for combat, such as the
|
||||
- A combat [command set](Component/Command-Sets) with the relevant commands needed for combat, such as the
|
||||
various attack/defend options and the `flee/disengage` command to leave the combat mode.
|
||||
- A rule resolution system. The basics of making such a module is described in the [rule system
|
||||
tutorial](Implementing-a-game-rule-system). We will only sketch such a module here for our end-turn
|
||||
combat resolution.
|
||||
- An `attack` [command](Commands) for initiating the combat mode. This is added to the default
|
||||
- An `attack` [command](Component/Commands) for initiating the combat mode. This is added to the default
|
||||
command set. It will create the combat handler and add the character(s) to it. It will also assign
|
||||
the combat command set to the characters.
|
||||
|
||||
## The combat handler
|
||||
|
||||
The _combat handler_ is implemented as a stand-alone [Script](Scripts). This Script is created when
|
||||
The _combat handler_ is implemented as a stand-alone [Script](Component/Scripts). This Script is created when
|
||||
the first Character decides to attack another and is deleted when no one is fighting any more. Each
|
||||
handler represents one instance of combat and one combat only. Each instance of combat can hold any
|
||||
number of characters but each character can only be part of one combat at a time (a player would
|
||||
|
|
@ -89,7 +89,7 @@ don't use this very much here this might allow the combat commands on the charac
|
|||
update the combat handler state directly.
|
||||
|
||||
_Note: Another way to implement a combat handler would be to use a normal Python object and handle
|
||||
time-keeping with the [TickerHandler](TickerHandler). This would require either adding custom hook
|
||||
time-keeping with the [TickerHandler](Component/TickerHandler). This would require either adding custom hook
|
||||
methods on the character or to implement a custom child of the TickerHandler class to track turns.
|
||||
Whereas the TickerHandler is easy to use, a Script offers more power in this case._
|
||||
|
||||
|
|
@ -506,7 +506,7 @@ class CmdAttack(Command):
|
|||
```
|
||||
|
||||
The `attack` command will not go into the combat cmdset but rather into the default cmdset. See e.g.
|
||||
the [Adding Command Tutorial](Adding-Command-Tutorial) if you are unsure about how to do this.
|
||||
the [Adding Command Tutorial](Howto/StartingTutorial/Adding-Command-Tutorial) if you are unsure about how to do this.
|
||||
|
||||
## Expanding the example
|
||||
|
||||
|
|
|
|||
|
|
@ -9,8 +9,8 @@ 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](Component/Objects), [Accounts](Component/Accounts), [Scripts](Component/Scripts),
|
||||
[Channels](Component/Communications#channels), [Messages](Communication#Msg) and [Help Entries](Component/Help-System).
|
||||
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?
|
||||
|
|
@ -22,20 +22,20 @@ the database field for `.key` is instead named `username` (this is a Django requ
|
|||
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](Component/Tags) 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](Component/Attributes) 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](Component/Typeclasses) 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](Component/Objects) 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](Component/Objects) 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](Component/Commands), 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
|
||||
|
|
@ -133,7 +133,7 @@ class CmdListHangouts(default_cmds.MuxCommand):
|
|||
", ".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](Component/Tags)
|
||||
"hangout" and with category "location tags".
|
||||
|
||||
Other important search methods in `utils.search` are
|
||||
|
|
@ -303,7 +303,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](Component/Attributes) 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.
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ focused on free form storytelling. Even if you are not interested in MUSH:es, th
|
|||
first game-type to try since it's not so code heavy. You will be able to use the same principles for
|
||||
building other types of games.
|
||||
|
||||
The tutorial starts from scratch. If you did the [First Steps Coding](First-Steps-Coding) tutorial
|
||||
The tutorial starts from scratch. If you did the [First Steps Coding](Howto/StartingTutorial/First-Steps-Coding) tutorial
|
||||
already you should have some ideas about how to do some of the steps already.
|
||||
|
||||
The following are the (very simplistic and cut-down) features we will implement (this was taken from
|
||||
|
|
@ -61,7 +61,7 @@ class Character(DefaultCharacter):
|
|||
self.db.combat_score = 1
|
||||
```
|
||||
|
||||
We defined two new [Attributes](Attributes) `power` and `combat_score` and set them to default
|
||||
We defined two new [Attributes](Component/Attributes) `power` and `combat_score` and set them to default
|
||||
values. Make sure to `@reload` the server if you had it already running (you need to reload every
|
||||
time you update your python code, don't worry, no accounts will be disconnected by the reload).
|
||||
|
||||
|
|
@ -94,8 +94,8 @@ check it. Using this method however will make it easy to add more functionality
|
|||
|
||||
What we need are the following:
|
||||
|
||||
- One character generation [Command](Commands) to set the "Power" on the `Character`.
|
||||
- A chargen [CmdSet](Command-Sets) to hold this command. Lets call it `ChargenCmdset`.
|
||||
- One character generation [Command](Component/Commands) to set the "Power" on the `Character`.
|
||||
- A chargen [CmdSet](Component/Command-Sets) to hold this command. Lets call it `ChargenCmdset`.
|
||||
- A custom `ChargenRoom` type that makes this set of commands available to players in such rooms.
|
||||
- One such room to test things in.
|
||||
|
||||
|
|
@ -104,7 +104,7 @@ What we need are the following:
|
|||
For this tutorial we will add all our new commands to `mygame/commands/command.py` but you could
|
||||
split your commands into multiple module if you prefered.
|
||||
|
||||
For this tutorial character generation will only consist of one [Command](Commands) to set the
|
||||
For this tutorial character generation will only consist of one [Command](Component/Commands) to set the
|
||||
Character s "power" stat. It will be called on the following MUSH-like form:
|
||||
|
||||
+setpower 4
|
||||
|
|
@ -156,7 +156,7 @@ This is a pretty straightforward command. We do some error checking, then set th
|
|||
We use a `help_category` of "mush" for all our commands, just so they are easy to find and separate
|
||||
in the help list.
|
||||
|
||||
Save the file. We will now add it to a new [CmdSet](Command-Sets) so it can be accessed (in a full
|
||||
Save the file. We will now add it to a new [CmdSet](Component/Command-Sets) so it can be accessed (in a full
|
||||
chargen system you would of course have more than one command here).
|
||||
|
||||
Open `mygame/commands/default_cmdsets.py` and import your `command.py` module at the top. We also
|
||||
|
|
@ -210,7 +210,7 @@ class ChargenRoom(Room):
|
|||
```
|
||||
Note how new rooms created with this typeclass will always start with `ChargenCmdset` on themselves.
|
||||
Don't forget the `permanent=True` keyword or you will lose the cmdset after a server reload. For
|
||||
more information about [Command Sets](Command-Sets) and [Commands](Commands), see the respective
|
||||
more information about [Command Sets](Component/Command-Sets) and [Commands](Component/Commands), see the respective
|
||||
links.
|
||||
|
||||
### Testing chargen
|
||||
|
|
@ -242,7 +242,7 @@ between fixes. Don't continue until the creation seems to have worked okay.
|
|||
This should bring you to the chargen room. Being in there you should now have the `+setpower`
|
||||
command available, so test it out. When you leave (via the `finish` exit), the command will go away
|
||||
and trying `+setpower` should now give you a command-not-found error. Use `ex me` (as a privileged
|
||||
user) to check so the `Power` [Attribute](Attributes) has been set correctly.
|
||||
user) to check so the `Power` [Attribute](Component/Attributes) has been set correctly.
|
||||
|
||||
If things are not working, make sure your typeclasses and commands are free of bugs and that you
|
||||
have entered the paths to the various command sets and commands correctly. Check the logs or command
|
||||
|
|
@ -391,7 +391,7 @@ There are a few ways to define the NPC class. We could in theory create a custom
|
|||
and put a custom NPC-specific cmdset on all NPCs. This cmdset could hold all manipulation commands.
|
||||
Since we expect NPC manipulation to be a common occurrence among the user base however, we will
|
||||
instead put all relevant NPC commands in the default command set and limit eventual access with
|
||||
[Permissions and Locks](Locks#Permissions).
|
||||
[Permissions and Locks](Component/Locks#Permissions).
|
||||
|
||||
### Creating an NPC with +createNPC
|
||||
|
||||
|
|
@ -443,13 +443,13 @@ class CmdCreateNPC(Command):
|
|||
exclude=caller)
|
||||
```
|
||||
Here we define a `+createnpc` (`+createNPC` works too) that is callable by everyone *not* having the
|
||||
`nonpcs` "[permission](Locks#Permissions)" (in Evennia, a "permission" can just as well be used to
|
||||
`nonpcs` "[permission](Component/Locks#Permissions)" (in Evennia, a "permission" can just as well be used to
|
||||
block access, it depends on the lock we define). We create the NPC object in the caller's current
|
||||
location, using our custom `Character` typeclass to do so.
|
||||
|
||||
We set an extra lock condition on the NPC, which we will use to check who may edit the NPC later --
|
||||
we allow the creator to do so, and anyone with the Builders permission (or higher). See
|
||||
[Locks](Locks) for more information about the lock system.
|
||||
[Locks](Component/Locks) for more information about the lock system.
|
||||
|
||||
Note that we just give the object default permissions (by not specifying the `permissions` keyword
|
||||
to the `create_object()` call). In some games one might want to give the NPC the same permissions
|
||||
|
|
@ -464,7 +464,7 @@ Since we re-used our custom character typeclass, our new NPC already has a *Powe
|
|||
defaults to 1. How do we change this?
|
||||
|
||||
There are a few ways we can do this. The easiest is to remember that the `power` attribute is just a
|
||||
simple [Attribute](Attributes) stored on the NPC object. So as a Builder or Admin we could set this
|
||||
simple [Attribute](Component/Attributes) stored on the NPC object. So as a Builder or Admin we could set this
|
||||
right away with the default `@set` command:
|
||||
|
||||
@set mynpc/power = 6
|
||||
|
|
@ -649,6 +649,6 @@ The simple "Power" game mechanic should be easily expandable to something more f
|
|||
useful, same is true for the combat score principle. The `+attack` could be made to target a
|
||||
specific player (or npc) and automatically compare their relevant attributes to determine a result.
|
||||
|
||||
To continue from here, you can take a look at the [Tutorial World](Tutorial-World-Introduction). For
|
||||
To continue from here, you can take a look at the [Tutorial World](Contrib/Tutorial-World-Introduction). For
|
||||
more specific ideas, see the [other tutorials and hints](Tutorials) as well
|
||||
as the [Developer Central](Developer-Central).
|
||||
|
|
@ -5,17 +5,17 @@ This tutorial shows the implementation of an NPC object that responds to charact
|
|||
location. In this example the NPC has the option to respond aggressively or not, but any actions
|
||||
could be triggered this way.
|
||||
|
||||
One could imagine using a [Script](Scripts) that is constantly checking for newcomers. This would be
|
||||
One could imagine using a [Script](Component/Scripts) that is constantly checking for newcomers. This would be
|
||||
highly inefficient (most of the time its check would fail). Instead we handle this on-demand by
|
||||
using a couple of existing object hooks to inform the NPC that a Character has entered.
|
||||
|
||||
It is assumed that you already know how to create custom room and character typeclasses, please see
|
||||
the [Basic Game tutorial](Tutorial-for-basic-MUSH-like-game) if you haven't already done this.
|
||||
the [Basic Game tutorial](Howto/StartingTutorial/Tutorial-for-basic-MUSH-like-game) if you haven't already done this.
|
||||
|
||||
What we will need is the following:
|
||||
|
||||
- An NPC typeclass that can react when someone enters.
|
||||
- A custom [Room](Objects#rooms) typeclass that can tell the NPC that someone entered.
|
||||
- A custom [Room](Component/Objects#rooms) typeclass that can tell the NPC that someone entered.
|
||||
- We will also tweak our default `Character` typeclass a little.
|
||||
|
||||
To begin with, we need to create an NPC typeclass. Create a new file inside of your typeclasses
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ their location. In this example the NPC parrots what is said, but any actions co
|
|||
this way.
|
||||
|
||||
It is assumed that you already know how to create custom room and character typeclasses, please see
|
||||
the [Basic Game tutorial](Tutorial-for-basic-MUSH-like-game) if you haven't already done this.
|
||||
the [Basic Game tutorial](Howto/StartingTutorial/Tutorial-for-basic-MUSH-like-game) if you haven't already done this.
|
||||
|
||||
What we will need is simply a new NPC typeclass that can react when someone speaks.
|
||||
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
|
||||
|
||||
This tutorial will create a simple script that will send a tweet to your already configured twitter
|
||||
account. Please see: [How to connect Evennia to Twitter](How-to-connect-Evennia-to-Twitter) if you
|
||||
account. Please see: [How to connect Evennia to Twitter](Setup/How-to-connect-Evennia-to-Twitter) if you
|
||||
haven't already done so.
|
||||
|
||||
The script could be expanded to cover a variety of statistics you might wish to tweet about
|
||||
|
|
@ -89,7 +89,7 @@ randomly choosing between these outputs.
|
|||
1. Shows the number of Player Characters, Rooms and Other/Objects
|
||||
2. Shows the number of prototypes currently in the game and then selects 3 random keys to show
|
||||
|
||||
[Scripts Information](Scripts) will show you how to add it as a Global script, however, for testing
|
||||
[Scripts Information](Component/Scripts) will show you how to add it as a Global script, however, for testing
|
||||
it may be useful to start/stop it quickly from within the game. Assuming that you create the file
|
||||
as `mygame/typeclasses/tweet_stats.py` it can be started by using the following command
|
||||
|
||||
|
|
|
|||
|
|
@ -50,7 +50,7 @@ and back (assuming we created it in limbo).
|
|||
|
||||
Using the `@tel`command like shown above is obviously not what we want. `@tel` is an admin command
|
||||
and normal players will thus never be able to enter the train! It is also not really a good idea to
|
||||
use [Exits](Objects#exits) to get in and out of the train - Exits are (at least by default) objects
|
||||
use [Exits](Component/Objects#exits) to get in and out of the train - Exits are (at least by default) objects
|
||||
too. They point to a specific destination. If we put an Exit in this room leading inside the train
|
||||
it would stay here when the train moved away (still leading into the train like a magic portal!). In
|
||||
the same way, if we put an Exit object inside the train, it would always point back to this room,
|
||||
|
|
@ -58,7 +58,7 @@ regardless of where the Train has moved. Now, one *could* define custom Exit typ
|
|||
the train or change their destination in the right way - but this seems to be a pretty cumbersome
|
||||
solution.
|
||||
|
||||
What we will do instead is to create some new [commands](Commands): one for entering the train and
|
||||
What we will do instead is to create some new [commands](Component/Commands): one for entering the train and
|
||||
another for leaving it again. These will be stored *on the train object* and will thus be made
|
||||
available to whomever is either inside it or in the same room as the train.
|
||||
|
||||
|
|
@ -122,7 +122,7 @@ documentation.
|
|||
These commands are work in a pretty straightforward way: `CmdEnterTrain` moves the location of the
|
||||
player to inside the train and `CmdLeaveTrain` does the opposite: it moves the player back to the
|
||||
current location of the train (back outside to its current location). We stacked them in a
|
||||
[cmdset](Command-Sets) `CmdSetTrain` so they can be used.
|
||||
[cmdset](Component/Command-Sets) `CmdSetTrain` so they can be used.
|
||||
|
||||
To make the commands work we need to add this cmdset to our train typeclass:
|
||||
|
||||
|
|
@ -159,7 +159,7 @@ As seen above, when this hook is called on our train, our new cmdset will be loa
|
|||
If you have played around a bit, you've probably figured out that you can use `leave train` when
|
||||
outside the train and `enter train` when inside. This doesn't make any sense ... so let's go ahead
|
||||
and fix that. We need to tell Evennia that you can not enter the train when you're already inside
|
||||
or leave the train when you're outside. One solution to this is [locks](Locks): we will lock down
|
||||
or leave the train when you're outside. One solution to this is [locks](Component/Locks): we will lock down
|
||||
the commands so that they can only be called if the player is at the correct location.
|
||||
|
||||
Right now commands defaults to the lock `cmd:all()`. The `cmd` lock type in combination with the
|
||||
|
|
@ -322,7 +322,7 @@ If we wanted full control of the train we could now just add a command to step i
|
|||
when desired. We want the train to move on its own though, without us having to force it by manually
|
||||
calling the `goto_next_room` method.
|
||||
|
||||
To do this we will create two [scripts](Scripts): one script that runs when the train has stopped at
|
||||
To do this we will create two [scripts](Component/Scripts): one script that runs when the train has stopped at
|
||||
a station and is responsible for starting the train again after a while. The other script will take
|
||||
care of the driving.
|
||||
|
||||
|
|
@ -416,7 +416,7 @@ enter/exit commands check so the train is not moving before allowing the caller
|
|||
* Have train conductor commands that can override the automatic start/stop.
|
||||
* Allow for in-between stops between the start- and end station
|
||||
* Have a rail road track instead of hard-coding the rooms in the train object. This could for
|
||||
example be a custom [Exit](Objects#exits) only traversable by trains. The train will follow the
|
||||
example be a custom [Exit](Component/Objects#exits) only traversable by trains. The train will follow the
|
||||
track. Some track segments can split to lead to two different rooms and a player can switch the
|
||||
direction to which room it goes.
|
||||
* Create another kind of vehicle!
|
||||
|
|
@ -2,10 +2,10 @@
|
|||
|
||||
This tutorial aims at dispelling confusions regarding the use of color tags within Evennia.
|
||||
|
||||
Correct understanding of this topic requires having read the [TextTags](TextTags) page and learned
|
||||
Correct understanding of this topic requires having read the [TextTags](Concept/TextTags) page and learned
|
||||
Evennia's color tags. Here we'll explain by examples the reasons behind the unexpected (or
|
||||
apparently incoherent) behaviors of some color tags, as mentioned _en passant_ in the
|
||||
[TextTags](TextTags) page.
|
||||
[TextTags](Concept/TextTags) page.
|
||||
|
||||
|
||||
All you'll need for this tutorial is access to a running instance of Evennia via a color-enabled
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ individually track the time, they instead subscribe to be called by a global tic
|
|||
keeping. Not only does this centralize and organize much of the code in one place, it also has less
|
||||
computing overhead.
|
||||
|
||||
Evennia offers the [TickerHandler](TickerHandler) specifically for using the subscription model. We
|
||||
Evennia offers the [TickerHandler](Component/TickerHandler) specifically for using the subscription model. We
|
||||
will use it for our weather system.
|
||||
|
||||
We will assume you know how to make your own Typeclasses. If not see one of the beginning tutorials.
|
||||
|
|
|
|||
|
|
@ -82,7 +82,7 @@ and *templates* (how the web page should be structured).
|
|||
|
||||
Models are created in `mygame/web/chargen/models.py`.
|
||||
|
||||
A [Django database model](New-Models) is a Python class that describes the database storage of the
|
||||
A [Django database model](Concept/New-Models) is a Python class that describes the database storage of the
|
||||
data you want to manage. Any data you choose to store is stored in the same database as the game and
|
||||
you have access to all the game's objects here.
|
||||
|
||||
|
|
@ -262,9 +262,9 @@ create_object function to properly process the permissions.
|
|||
|
||||
Most importantly, the following attributes must be set on the created character object:
|
||||
|
||||
* Evennia [permissions](Locks#permissions) (copied from the `AccountDB`).
|
||||
* The right `puppet` [locks](Locks) so the Account can actually play as this Character later.
|
||||
* The relevant Character [typeclass](Typeclasses)
|
||||
* Evennia [permissions](Component/Locks#permissions) (copied from the `AccountDB`).
|
||||
* The right `puppet` [locks](Component/Locks) so the Account can actually play as this Character later.
|
||||
* The relevant Character [typeclass](Component/Typeclasses)
|
||||
* Character name (key)
|
||||
* The Character's home room location (`#2` by default)
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue