Annikka/evennia
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Fix merge conflicts

Browse source
This commit is contained in:
Griatch 2022-09-13 20:14:39 +02:00
commit a974a2843c
2 changed files with 188 additions and 140 deletions
Download patch file Download diff file Expand all files Collapse all files

43
docs/source/Howtos/Tutorial-Persistent-Handler.md
View file

@ -24,7 +24,7 @@ class NameChanger:
class MyObject(DefaultObject):
@lazy_property:
def namechange(self):
return MyHandler(self)
return NameChanger(self)
obj = create_object(MyObject, key="test")
@ -35,13 +35,23 @@ print(obj.key)
>>> "test_extra"
```
What happens here is that we make a new class `MyHandler`. We use the `@lazy_property` decorator to set it up - this means the handler will not be actually created until someone really wants to use it, by accessing `obj.namechange` later. The decorated `namechange` method returns the handler and makes sure to initialize it with `self` - this becomes the `obj` inside the handler!
What happens here is that we make a new class `NameChanger`. We use the
`@lazy_property` decorator to set it up - this means the handler will not be
actually created until someone really wants to use it, by accessing
`obj.namechange` later. The decorated `namechange` method returns the handler
and makes sure to initialize it with `self` - this becomes the `obj` inside the
handler!
We then make a silly method `add_to_key` that uses the handler to manipulate the key of the object. In this example, the handler is pretty pointless, but grouping functionality this way can both make for an easy-to-remember API and can also allow you cache data for easy access - this is how the `AttributeHandler` (`.attributes`) and `TagHandler` (`.tags`) works.
We then make a silly method `add_to_key` that uses the handler to manipulate the
key of the object. In this example, the handler is pretty pointless, but
grouping functionality this way can both make for an easy-to-remember API and
can also allow you cache data for easy access - this is how the
`AttributeHandler` (`.attributes`) and `TagHandler` (`.tags`) works.
## Persistent storage of data in handler
Let's say we want to track 'quests' in our handler. A 'quest' is a regular class that represents the quest. Let's make it simple as an example:
Let's say we want to track 'quests' in our handler. A 'quest' is a regular class
that represents the quest. Let's make it simple as an example:
```python
# for example in mygame/world/quests.py
@ -103,7 +113,6 @@ class QuestHandler:
self._save()
def check_progress(self):
for quest in self.storage.values():
quest.check_progress()
if self.do_save:
# .do_save is set on handler by Quest if it wants to save progress
@ -159,9 +168,18 @@ class Quest:
```
The `Quest.__init__` now takes `obj` as argument, to match what we pass to it in `QuestHandler.add`. We want to monitor the changing of `current_step`, so we make it into a `property`. When we edit that value, we set the `do_save` flag on the handler, which means it will save the status to database once it has checked progress on all its quests.
The `Quest.__init__` now takes `obj` as argument, to match what we pass to it in
`QuestHandler.add`. We want to monitor the changing of `current_step`, so we
make it into a `property`. When we edit that value, we set the `do_save` flag on
the handler, which means it will save the status to database once it has checked
progress on all its quests. The `Quest.questhandler` property allows to easily
get back to the handler (and the object on which it sits).
The `__serialize__dbobjs__` and `__deserialize_dbobjs__` methods are needed because `Attributes` can't store 'hidden' database objects (the `Quest.obj` property. The methods help Evennia serialize/deserialize `Quest` propertly when the handler saves it. For more information, see [Storing Single objects](../Components/Attributes.md#storing-single-objects) in the Attributes documentation.
The `__serialize__dbobjs__` and `__deserialize_dbobjs__` methods are needed
because `Attributes` can't store 'hidden' database objects (the `Quest.obj`
property. The methods help Evennia serialize/deserialize `Quest` propertly when
the handler saves it. For more information, see [Storing Single
objects](../Components/Attributes.md#storing-single-objects) in the Attributes
### Tying it all together
@ -184,14 +202,21 @@ class Character(DefaultCharacter):
```
You can now make your Quest classes to describe your quests and add them to characters with
You can now make your Quest classes to describe your quests and add them to
characters with
```python
character.quests.add(FindTheRedKey)
```
and can later do
```python
character.quests.check_progress()
```
and be sure that quest data is not lost between reloads.
You can find a full-fledged quest-handler example as [EvAdventure quests](evennia.contribs.tutorials.evadventure.quests) contrib in the Evennia repository.
You can find a full-fledged quest-handler example as [EvAdventure
quests](evennia.contribs.tutorials.evadventure.quests) contrib in the Evennia
repository.

41
evennia/contrib/rpg/rpsystem/rplanguage.py
View file

@ -17,7 +17,7 @@ in the game in various ways:
overhear (for example "s" sounds tend to be audible even when no other
meaning can be determined).
Usage:
## Usage
```python
from evennia.contrib import rplanguage
@ -48,15 +48,38 @@ Usage:
```
To set up new languages, import and use the `add_language()`
helper method in this module. This allows you to customize the
"feel" of the semi-random language you are creating. Especially
## Custom languages
To set up new languages, you need to run `add_language()`
helper function in this module. The arguments of this function (see below)
are used to store the new language in the database (in the LanguageHandler,
which is a type of Script).
If you want to remember the language definitions, you could put them all
in a module along with the `add_language` call as a quick way to
rebuild the language on a db reset:
```python
# a stand-alone module somewhere under mygame. Just import this
# once to automatically add the language!
from evennia.contrib.rpg.rpsystem import rplanguage
grammar = (...)
vowels = "eaouy"
# etc
rplanguage.add_language(grammar=grammar, vowels=vowels, ...)
```
The variables of `add_language` allows you to customize the "feel" of
the semi-random language you are creating. Especially
the `word_length_variance` helps vary the length of translated
words compared to the original and can help change the "feel" for
the language you are creating. You can also add your own
words compared to the original. You can also add your own
dictionary and "fix" random words for a list of input words.
Below is an example of "elvish", using "rounder" vowels and sounds:
## Example
Below is an example module creating "elvish", using "rounder" vowels and sounds:
```python
# vowel/consonant grammar possibilities
@ -115,12 +138,12 @@ Usage:
"""
import re
from random import choice, randint
from collections import defaultdict
from random import choice, randint
from evennia import DefaultScript
from evennia.utils import logger
# ------------------------------------------------------------
#
# Obfuscate language