From 00c2c924729fac5f361bc461c83e12d6738d60e9 Mon Sep 17 00:00:00 2001 From: amfl Date: Mon, 30 Jan 2023 16:51:30 +1300 Subject: [PATCH] Fix various typos --- docs/source/Components/MonitorHandler.md | 2 +- docs/source/Components/Objects.md | 2 +- docs/source/Components/Scripts.md | 4 ++-- docs/source/Concepts/Messagepath.md | 2 +- docs/source/Contribs/Contrib-Crafting.md | 2 +- evennia/commands/default/account.py | 2 +- evennia/contrib/base_systems/ingame_python/typeclasses.py | 2 +- evennia/contrib/game_systems/crafting/crafting.py | 4 +++- 8 files changed, 11 insertions(+), 9 deletions(-) diff --git a/docs/source/Components/MonitorHandler.md b/docs/source/Components/MonitorHandler.md index 9948389427..fd2e2f3b8a 100644 --- a/docs/source/Components/MonitorHandler.md +++ b/docs/source/Components/MonitorHandler.md @@ -5,7 +5,7 @@ The *MonitorHandler* is a system for watching changes in properties or Attribute monitor can be thought of as a sort of trigger that responds to change. The main use for the MonitorHandler is to report changes to the client; for example the client -Session may ask Evennia to monitor the value of the Characer's `health` attribute and report +Session may ask Evennia to monitor the value of the Character's `health` attribute and report whenever it changes. This way the client could for example update its health bar graphic as needed. ## Using the MonitorHandler diff --git a/docs/source/Components/Objects.md b/docs/source/Components/Objects.md index 4923a2e49e..789dcc444a 100644 --- a/docs/source/Components/Objects.md +++ b/docs/source/Components/Objects.md @@ -34,7 +34,7 @@ An Evennia Object is, by definition, a Python class that includes [evennia.obje Here, arrows indicate inheritance and point from-child-to-parent. -So, for example `DefaultObjet` is a child of `DefaultCharacter` (in the Evennia library), which is a parent of `Character` (in the game dir). The class in the game-dir is the one you should modify for your game. +So, for example `DefaultObject` is a child of `DefaultCharacter` (in the Evennia library), which is a parent of `Character` (in the game dir). The class in the game-dir is the one you should modify for your game. > Note the `ObjectParent` class. This is an empty mix-in that all classes in the game-dir inherits from. It's where you put things you want _all_ these classes to have. diff --git a/docs/source/Components/Scripts.md b/docs/source/Components/Scripts.md index 4e5aeb7e7a..d4e8b4ada7 100644 --- a/docs/source/Components/Scripts.md +++ b/docs/source/Components/Scripts.md @@ -11,7 +11,7 @@ If you ever consider creating an [Object](./Objects.md) with a `None`-location j - Scripts can _attach_ to Objects and Accounts via e.g. `obj.scripts.add/remove`. In the script you can then access the object/account as `self.obj` or `self.account`. This can be used to dynamically extend other typeclasses but also to use the timer component to affect the parent object in various ways. For historical reasons, a Script _not_ attached to an object is referred to as a _Global_ Script. ```{versionchanged} 1.0 - In previus Evennia versions, stopping the Script's timer also meant deleting the Script object. + In previous Evennia versions, stopping the Script's timer also meant deleting the Script object. Starting with this version, the timer can be start/stopped separately and `.delete()` must be called on the Script explicitly to delete it. @@ -333,7 +333,7 @@ GLOBAL_SCRIPTS.weather.db.current_weather = "Cloudy" ``` ```{warning} -Note that global scripts appear as properties on `GLOBAL_SCRIPTS` based on their `key`. If you were to create two global scripts with the same `key` (even with different typeclasses), the `GLOBAL_SCRIPTS` container will only return one of them (which one depends on order in the database). Best is to organize your scripts so that this does not happen. Otherwise, use `evennia.search_scripts` to get exactly the script you want. +Note that global scripts appear as properties on `GLOBAL_SCRIPTS` based on their `key`. If you were to create two global scripts with the same `key` (even with different typeclasses), the `GLOBAL_SCRIPTS` container will only return one of them (which one depends on order in the database). Best is to organize your scripts so that this does not happen. Otherwise, use `evennia.search_script` to get exactly the script you want. ``` There are two ways to make a script appear as a property on `GLOBAL_SCRIPTS`: diff --git a/docs/source/Concepts/Messagepath.md b/docs/source/Concepts/Messagepath.md index d2938ed7e8..73dc7567fa 100644 --- a/docs/source/Concepts/Messagepath.md +++ b/docs/source/Concepts/Messagepath.md @@ -11,7 +11,7 @@ You see: a flower Exits: north, east ``` -When you send a command like `look` into Evennia - what actually happens? How does that `look` string end up being handled by the `CmdLook` class? What happens when we use e.g. `caller.msg()` to send the message back +When you send a command like `look` into Evennia - what actually happens? How does that `look` string end up being handled by the `CmdLook` class? What happens when we use e.g. `caller.msg()` to send the message back? Understanding this flow of data - the _message path_ is important in order to understand how Evennia works. diff --git a/docs/source/Contribs/Contrib-Crafting.md b/docs/source/Contribs/Contrib-Crafting.md index efe8639b0c..32dcc40257 100644 --- a/docs/source/Contribs/Contrib-Crafting.md +++ b/docs/source/Contribs/Contrib-Crafting.md @@ -3,7 +3,7 @@ Contribution by Griatch 2020 This implements a full crafting system. The principle is that of a 'recipe', -where you combine items (tagged as ingredients) create something new. The recipe can also +where you combine items (tagged as ingredients) to create something new. The recipe can also require certain (non-consumed) tools. An example would be to use the 'bread recipe' to combine 'flour', 'water' and 'yeast' with an 'oven' to bake a 'loaf of bread'. diff --git a/evennia/commands/default/account.py b/evennia/commands/default/account.py index 0001dd543a..6fb8bbb3f2 100644 --- a/evennia/commands/default/account.py +++ b/evennia/commands/default/account.py @@ -344,7 +344,7 @@ class CmdIC(COMMAND_DEFAULT_CLASS): ] if not character_candidates: # fall back to global search only if Builder+ has no - # playable_characers in list and is not standing in a room + # playable_characters in list and is not standing in a room # with a matching char. character_candidates.extend( [ diff --git a/evennia/contrib/base_systems/ingame_python/typeclasses.py b/evennia/contrib/base_systems/ingame_python/typeclasses.py index 1a49318132..3922ffd11d 100644 --- a/evennia/contrib/base_systems/ingame_python/typeclasses.py +++ b/evennia/contrib/base_systems/ingame_python/typeclasses.py @@ -609,7 +609,7 @@ Variables you can use in this event: """ EXIT_TRAVERSE = """ -After the characer has traversed through this exit. +After the character has traversed through this exit. This event is called after a character has traversed through this exit. Traversing cannot be prevented using 'deny()' at this point. The character will be in a different room and she will diff --git a/evennia/contrib/game_systems/crafting/crafting.py b/evennia/contrib/game_systems/crafting/crafting.py index 485227dd8f..7f70559272 100644 --- a/evennia/contrib/game_systems/crafting/crafting.py +++ b/evennia/contrib/game_systems/crafting/crafting.py @@ -386,8 +386,9 @@ class CraftingRecipe(CraftingRecipeBase): {"key": "Bag of flour", "typeclass": "typeclasses.food.Flour", "desc": "A small bag of flour." - "tags": [("flour", "crafting_material"), + "tags": [("flour", "crafting_material")], } + ] class BreadRecipe(CraftRecipe): name = "bread" @@ -397,6 +398,7 @@ class CraftingRecipe(CraftingRecipeBase): {"key": "bread", "desc": "A tasty bread." } + ] ## Properties on the class level: