Clean up contrib docs, autogeneration
This commit is contained in:
Griatch
parent
b922cf9b3c
commit
e96bbb4b86
94 changed files with 4126 additions and 2536 deletions
|
|
@ -1,12 +1,10 @@
|
|||
# AWSstorage system
|
||||
|
||||
Contrib by The Right Honourable Reverend (trhr) 2020
|
||||
|
||||
## What is this for?
|
||||
Contrib by The Right Honourable Reverend (trhr), 2020
|
||||
|
||||
This plugin migrates the Web-based portion of Evennia, namely images,
|
||||
javascript, and other items located inside staticfiles into Amazon AWS (S3) for
|
||||
hosting.
|
||||
javascript, and other items located inside staticfiles into Amazon AWS (S3)
|
||||
cloud hosting. Great for those serving media with the game.
|
||||
|
||||
Files hosted on S3 are "in the cloud," and while your personal
|
||||
server may be sufficient for serving multimedia to a minimal number of users,
|
||||
|
|
|
|||
|
|
@ -1,15 +1,13 @@
|
|||
# Building menu
|
||||
|
||||
Module containing the building menu system.
|
||||
|
||||
Evennia contributor: vincent-lg 2018
|
||||
Contrib by vincent-lg, 2018
|
||||
|
||||
Building menus are in-game menus, not unlike `EvMenu` though using a
|
||||
different approach. Building menus have been specifically designed to edit
|
||||
information as a builder. Creating a building menu in a command allows
|
||||
builders quick-editing of a given object, like a room. If you follow the
|
||||
steps below to add the contrib, you will have access to an `@edit` command
|
||||
that will edit any default object offering to change its key and description.
|
||||
different approach. Building menus have been specifically designed to edit
|
||||
information as a builder. Creating a building menu in a command allows
|
||||
builders quick-editing of a given object, like a room. If you follow the
|
||||
steps to add the contrib, you will have access to an `edit` command
|
||||
that will edit any default object, offering to change its key and description.
|
||||
|
||||
## Install
|
||||
|
||||
|
|
|
|||
|
|
@ -1,9 +1,10 @@
|
|||
# Color markups
|
||||
|
||||
Contribution, Griatch 2017
|
||||
Contrib by Griatch, 2017
|
||||
|
||||
Additional color markup styles for Evennia (extending or replacing the default
|
||||
`|r`, `|234` etc).
|
||||
`|r`, `|234`). Adds support for MUSH-style (`%cr`, `%c123`) and/or legacy-Evennia
|
||||
(`{r`, `{123`).
|
||||
|
||||
|
||||
## Installation
|
||||
|
|
|
|||
|
|
@ -1,10 +1,11 @@
|
|||
# Custom gameime
|
||||
|
||||
Contrib - Griatch 2017, vlgeoff 2017
|
||||
Contrib by vlgeoff, 2017 - based on Griatch's core original
|
||||
|
||||
This reimplements the `evennia.utils.gametime` module but supporting a custom
|
||||
calendar for your game world. It allows for scheduling events to happen at given
|
||||
in-game times, taking this custom calendar into account.
|
||||
This reimplements the `evennia.utils.gametime` module but with a _custom_
|
||||
calendar (unusual number of days per week/month/year etc) for your game world.
|
||||
Like the original, it allows for scheduling events to happen at given
|
||||
in-game times, but now taking this custom calendar into account.
|
||||
|
||||
## Installation
|
||||
|
||||
|
|
|
|||
|
|
@ -1,9 +1,10 @@
|
|||
# Email-based login system
|
||||
|
||||
Evennia contrib - Griatch 2012
|
||||
Contrib by Griatch, 2012
|
||||
|
||||
This is a variant of the login system that requires an email-address
|
||||
instead of a username to login.
|
||||
This is a variant of the login system that asks for an email-address
|
||||
instead of a username to login. Note that it does not verify the email,
|
||||
it just uses it as the identifier rather than a username.
|
||||
|
||||
This used to be the default Evennia login before replacing it with a
|
||||
more standard username + password system (having to supply an email
|
||||
|
|
|
|||
|
|
@ -1,15 +1,15 @@
|
|||
# Evennia in-game Python system
|
||||
|
||||
Vincent Le Goff 2017
|
||||
Contrib by Vincent Le Goff 2017
|
||||
|
||||
This contrib adds the system of in-game Python in Evennia, allowing immortals
|
||||
(or other trusted builders) to dynamically add features to individual objects.
|
||||
Using custom Python set in-game, every immortal or privileged users could have a
|
||||
specific room, exit, character, object or something else behave differently from
|
||||
its "cousins". For these familiar with the use of softcode in MU`*`, like SMAUG
|
||||
MudProgs, the ability to add arbitrary behavior to individual objects is a step
|
||||
toward freedom. Keep in mind, however, the warning below, and read it carefully
|
||||
before the rest of the documentation.
|
||||
This contrib adds the ability to script with Python in-game. It allows trusted
|
||||
staff/builders to dynamically add features and triggers to individual objects
|
||||
without needing to do it in external Python modules. Using custom Python in-game,
|
||||
specific rooms, exits, characters, objects etc can be made to behave differently from
|
||||
its "cousins". This is similar to how softcode works for MU or MudProgs for DIKU.
|
||||
Keep in mind, however, that allowing Python in-game comes with _severe_
|
||||
security concerns (you must trust your builders deeply), so read the warnings in
|
||||
this module carefully before continuing.
|
||||
|
||||
## A WARNING REGARDING SECURITY
|
||||
|
||||
|
|
@ -22,6 +22,17 @@ will have to keep in mind these points before deciding to install it:
|
|||
2. You can do all of this in Python outside the game. The in-game Python system
|
||||
is not to replace all your game feature.
|
||||
|
||||
## Extra tutorials
|
||||
|
||||
These tutorials cover examples of using ingame python. Once you have the system
|
||||
installed (see below) they may be an easier way to learn than reading the full
|
||||
documentation from beginning to end.
|
||||
|
||||
- [Dialogue events](Contribs/Contrib-Ingame-Python-Tutorial-Dialogue.md), where
|
||||
NPCs react to things said.
|
||||
- [A voice operated elevator](Contribs/Contrib-Ingame-Python-Tutorial-Elevator.md)
|
||||
using ingame-python events.
|
||||
|
||||
## Basic structure and vocabulary
|
||||
|
||||
- At the basis of the in-game Python system are **events**. An **event**
|
||||
|
|
@ -73,7 +84,9 @@ default. You need to do it manually, following these steps:
|
|||
This is the quick summary. Scroll down for more detailed help on each step.
|
||||
|
||||
1. Launch the main script (important!):
|
||||
```py evennia.create_script("evennia.contrib.base_systems.ingame_python.scripts.EventHandler")```
|
||||
|
||||
py evennia.create_script("evennia.contrib.base_systems.ingame_python.scripts.EventHandler")
|
||||
|
||||
2. Set the permissions (optional):
|
||||
- `EVENTS_WITH_VALIDATION`: a group that can edit callbacks, but will need approval (default to
|
||||
`None`).
|
||||
|
|
@ -176,7 +189,7 @@ the `EVENTS_WITH_VALIDATION` setting will be able to call the command (with diff
|
|||
### Adding the `call` command
|
||||
|
||||
You also have to add the `@call` command to your Character CmdSet. This command allows your users
|
||||
to add, edit and delete callbacks in-game. In your `commands/default_cmdsets, it might look like
|
||||
to add, edit and delete callbacks in-game. In your `commands/default_cmdsets`, it might look like
|
||||
this:
|
||||
|
||||
```python
|
||||
|
|
@ -277,7 +290,7 @@ We'll see callbacks with parameters later. For the time being, let's try to pre
|
|||
from going through the "north" exit of this room:
|
||||
|
||||
```
|
||||
@call north
|
||||
call north
|
||||
+------------------+---------+-----------------------------------------------+
|
||||
| Event name | Number | Description |
|
||||
+~~~~~~~~~~~~~~~~~~+~~~~~~~~~+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
|
||||
|
|
|
|||
|
|
@ -1,10 +1,10 @@
|
|||
# Menu-based login system
|
||||
|
||||
Contribution - Vincent-lg 2016, Griatch 2019 (rework for modern EvMenu)
|
||||
Contribution by Vincent-lg 2016. Reworked for modern EvMenu by Griatch, 2019.
|
||||
|
||||
This changes the Evennia login to ask for the account name and password in
|
||||
sequence instead of requiring you to enter both at once. It uses EvMenu under
|
||||
the hood.
|
||||
This changes the Evennia login to ask for the account name and password as a series
|
||||
of questions instead of requiring you to enter both at once. It uses Evennia's
|
||||
menu system `EvMenu` under the hood.
|
||||
|
||||
## Installation
|
||||
|
||||
|
|
|
|||
|
|
@ -1,22 +1,24 @@
|
|||
# Legacy Comms-commands
|
||||
|
||||
Contribution - Griatch 2021
|
||||
Contribution by Griatch 2021
|
||||
|
||||
In Evennia 1.0, the old Channel commands (originally inspired by MUX) were
|
||||
replaced by the single `channel` command that performs all these function.
|
||||
That command is still required to talk on channels. This contrib (extracted
|
||||
from Evennia 0.9.5) reuses the channel-management of the base Channel command
|
||||
but breaks out its functionality into separate Commands with MUX-familiar names.
|
||||
In Evennia 1.0+, the old Channel commands (originally inspired by MUX) were
|
||||
replaced by the single `channel` command that performs all these functions.
|
||||
This contrib (extracted from Evennia 0.9.5) breaks out the functionality into
|
||||
separate Commands more familiar to MU* users. This is just for show though, the
|
||||
main `channel` command is still called under the hood.
|
||||
|
||||
- `allcom` - `channel/all` and `channel`
|
||||
- `addcom` - `channel/alias`, `channel/sub` and `channel/unmute`
|
||||
- `delcom` - `channel/unalias`, `alias/unsub` and `channel/mute`
|
||||
- `cboot` - `channel/boot` (`channel/ban` and `/unban` not supported)
|
||||
- `cwho` - `channel/who`
|
||||
- `ccreate` - `channel/create`
|
||||
- `cdestroy` - `channel/destroy`
|
||||
- `clock` - `channel/lock`
|
||||
- `cdesc` - `channel/desc`
|
||||
| Contrib syntax | Default `channel` syntax |
|
||||
| -------------- | --------------------------------------------------------- |
|
||||
| `allcom` | `channel/all` and `channel` |
|
||||
| `addcom` | `channel/alias`, `channel/sub` and `channel/unmute` |
|
||||
| `delcom` | `channel/unalias`, `alias/unsub` and `channel/mute` |
|
||||
| `cboot` | `channel/boot` (`channel/ban` and `/unban` not supported) |
|
||||
| `cwho` | `channel/who` |
|
||||
| `ccreate` | `channel/create` |
|
||||
| `cdestroy` | `channel/destroy` |
|
||||
| `clock` | `channel/lock` |
|
||||
| `cdesc` | `channel/desc` |
|
||||
|
||||
## Installation
|
||||
|
||||
|
|
|
|||
|
|
@ -1,12 +1,12 @@
|
|||
# Unix-like Command style parent
|
||||
|
||||
Evennia contribution, Vincent Le Geoff 2017
|
||||
Contribution by Vincent Le Geoff (vlgeoff), 2017
|
||||
|
||||
This module contains a command class that allows for unix-style command syntax
|
||||
in-game, using --options, positional arguments and stuff like -n 10 etc
|
||||
similarly to a unix command. It might not the best syntax for the average player
|
||||
This module contains a command class with an alternate syntax parser implementing
|
||||
Unix-style command syntax in-game. This means `--options`, positional arguments
|
||||
and stuff like `-n 10`. It might not the best syntax for the average player
|
||||
but can be really useful for builders when they need to have a single command do
|
||||
many things with many options. It uses the ArgumentParser from Python's standard
|
||||
many things with many options. It uses the `ArgumentParser` from Python's standard
|
||||
library under the hood.
|
||||
|
||||
## Installation
|
||||
|
|
|
|||
|
|
@ -1,16 +1,18 @@
|
|||
# EvscapeRoom
|
||||
|
||||
Evennia contrib - Griatch 2019
|
||||
Contribution by Griatch, 2019
|
||||
|
||||
This 'Evennia escaperoom game engine' was created for the MUD Coders Guild game
|
||||
Jam, April 14-May 15 2019. The theme for the jam was "One Room". This contains the
|
||||
utilities and base classes and an empty example room.
|
||||
A full engine for creating multiplayer escape-rooms in Evennia. Allows players to
|
||||
spawn and join puzzle rooms that track their state independently. Any number of players
|
||||
can join to solve a room together. This is the engine created for 'EvscapeRoom', which won
|
||||
the MUD Coders Guild "One Room" Game Jam in April-May, 2019. The contrib has no game
|
||||
content but contains the utilities and base classes and an empty example room.
|
||||
|
||||
The original code for the contest is found at
|
||||
https://github.com/Griatch/evscaperoom but the version on the public Evennia
|
||||
demo is more updated, so if you really want the latest bug fixes etc you should
|
||||
rather look at https://github.com/evennia/evdemo/tree/master/evdemo/evscaperoom
|
||||
instead. A copy of the full game can also be played on the Evennia demo server
|
||||
instead. A copy of the full game can also be played on the Evennia demo server
|
||||
at https://demo.evennia.com - just connect to the server and write `evscaperoom`
|
||||
in the first room to start!
|
||||
|
||||
|
|
|
|||
|
|
@ -1,18 +1,14 @@
|
|||
# Barter system
|
||||
|
||||
Evennia contribution - Griatch 2012
|
||||
Contribution by Griatch, 2012
|
||||
|
||||
This implements a full barter system - a way for players to safely
|
||||
trade items between each other using code rather than simple free-form
|
||||
talking. The advantage of this is increased buy/sell safety but it
|
||||
also streamlines the process and makes it faster when doing many
|
||||
transactions (since goods are automatically exchanged once both
|
||||
agree).
|
||||
|
||||
This system is primarily intended for a barter economy, but can easily
|
||||
be used in a monetary economy as well -- just let the "goods" on one
|
||||
side be coin objects (this is more flexible than a simple "buy"
|
||||
command since you can mix coins and goods in your trade).
|
||||
trade items between each other in code rather than simple `give/get`
|
||||
commands. This increases both safety (at no time will one player have
|
||||
both goods and payment in-hand) and speed, since agreed goods will
|
||||
be moved automatically). By just replacing one side with coin objects,
|
||||
(or a mix of coins and goods), this also works fine for regular money
|
||||
transactions.
|
||||
|
||||
## Installation
|
||||
|
||||
|
|
|
|||
|
|
@ -1,9 +1,9 @@
|
|||
# Clothing
|
||||
|
||||
Evennia contribution - Tim Ashley Jenkins 2017
|
||||
Contribution by Tim Ashley Jenkins, 2017
|
||||
|
||||
Provides a typeclass and commands for wearable clothing,
|
||||
which is appended to a character's description when worn.
|
||||
Provides a typeclass and commands for wearable clothing. These
|
||||
look of these clothes are appended to the character's description when worn.
|
||||
|
||||
Clothing items, when worn, are added to the character's description
|
||||
in a list. For example, if wearing the following clothing items:
|
||||
|
|
@ -13,6 +13,11 @@ in a list. For example, if wearing the following clothing items:
|
|||
one nice hat
|
||||
a very pretty dress
|
||||
|
||||
Would result in this added description:
|
||||
|
||||
Tim is wearing one nice hat, a thin and delicate necklace,
|
||||
a very pretty dress and a pair of regular ol' shoes.
|
||||
|
||||
## Installation
|
||||
|
||||
To install, import this module and have your default character
|
||||
|
|
|
|||
|
|
@ -1,13 +1,12 @@
|
|||
# Cooldown contrib module.
|
||||
# Cooldowns
|
||||
|
||||
Evennia contrib - owllex, 2021
|
||||
Contribution by owllex, 2021
|
||||
|
||||
This contrib provides a simple cooldown handler that can be attached to any
|
||||
typeclassed Object or Account. A cooldown is a lightweight persistent
|
||||
asynchronous timer that you can query to see if it is ready.
|
||||
|
||||
Cooldowns are good for modelling rate-limited actions, like how often a
|
||||
character can perform a given command.
|
||||
Cooldowns are used modelling rate-limited actions, like how often a
|
||||
character can perform a given action; until a certain time has passed their
|
||||
command can not be used again. This contrib provides a simple cooldown
|
||||
handler that can be attached to any typeclass. A cooldown is a lightweight persistent
|
||||
asynchronous timer that you can query to see if a certain time has yet passed.
|
||||
|
||||
Cooldowns are completely asynchronous and must be queried to know their
|
||||
state. They do not fire callbacks, so are not a good fit for use cases
|
||||
|
|
|
|||
|
|
@ -1,25 +1,46 @@
|
|||
# Crafting system
|
||||
|
||||
Contrib - Griatch 2020
|
||||
Contribution by Griatch 2020
|
||||
|
||||
This implements a full crafting system. The principle is that of a 'recipe':
|
||||
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
|
||||
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'.
|
||||
|
||||
ingredient1 + ingredient2 + ... + tool1 + tool2 + ... + craft_recipe -> objectA, objectB, ...
|
||||
The recipe process can be understood like this:
|
||||
|
||||
ingredient(s) + tool(s) + recipe -> object(s)
|
||||
|
||||
Here, 'ingredients' are consumed by the crafting process, whereas 'tools' are
|
||||
necessary for the process by will not be destroyed by it.
|
||||
necessary for the process but will not be destroyed by it.
|
||||
|
||||
An example would be to use the tools 'bowl' and 'oven' to use the ingredients
|
||||
'flour', 'salt', 'yeast' and 'water' to create 'bread' using the 'bread recipe'.
|
||||
The included `craft` command works like this:
|
||||
|
||||
A recipe does not have to use tools, like 'snow' + 'snowball-recipe' becomes
|
||||
'snowball'. Conversely one could also imagine using tools without consumables,
|
||||
like using 'spell book' and 'wand' to produce 'fireball' by having the recipe
|
||||
check some magic skill on the character.
|
||||
craft <recipe> [from <ingredient>,...] [using <tool>, ...]
|
||||
|
||||
The system is generic enough to be used also for adventure-like puzzles, like
|
||||
combining 'stick', 'string' and 'hook' to get a 'makeshift fishing rod' that
|
||||
you can use with 'storm drain' (treated as a tool) to get 'key' ...
|
||||
## Examples
|
||||
|
||||
Using the `craft` command:
|
||||
|
||||
craft toy car from plank, wooden wheels, nails using saw, hammer
|
||||
|
||||
A recipe does not have to use tools or even multiple ingredients:
|
||||
|
||||
snow + snowball_recipe -> snowball
|
||||
|
||||
Conversely one could also imagine using tools without consumables, like
|
||||
|
||||
spell_book + wand + fireball_recipe -> fireball
|
||||
|
||||
The system is generic enough to be used also for adventure-like puzzles (but
|
||||
one would need to change the command and determine the recipe on based on what
|
||||
is being combined instead):
|
||||
|
||||
stick + string + hook -> makeshift_fishing_rod
|
||||
makeshift_fishing_rod + storm_drain -> key
|
||||
|
||||
See the [sword example](evennia.contrib.game_systems.crafting.example_recipes) for an example
|
||||
of how to design a recipe tree for crafting a sword from base elements.
|
||||
|
||||
## Intallation and Usage
|
||||
|
||||
|
|
@ -29,18 +50,30 @@ available to you:
|
|||
|
||||
craft <recipe> [from <ingredient>,...] [using <tool>, ...]
|
||||
|
||||
For example
|
||||
In code, you can craft using the
|
||||
`evennia.contrib.game_systems.crafting.craft` function:
|
||||
|
||||
craft toy car from plank, wooden wheels, nails using saw, hammer
|
||||
```python
|
||||
from evennia.contrib.game_systems.crafting import craft
|
||||
|
||||
To use crafting you need recipes. Add a new variable to `mygame/server/conf/settings.py`:
|
||||
result = craft(caller, "recipename", *inputs)
|
||||
|
||||
```
|
||||
Here, `caller` is the one doing the crafting and `*inputs` is any combination of
|
||||
consumables and/or tool Objects. The system will identify which is which by the
|
||||
[Tags](../Components/Tags.md) on them (see below) The `result` is always a list.
|
||||
|
||||
To use crafting you need recipes. Add a new variable to
|
||||
`mygame/server/conf/settings.py`:
|
||||
|
||||
CRAFT_RECIPE_MODULES = ['world.recipes']
|
||||
|
||||
All top-level classes in these modules (whose name does not start with `_`)
|
||||
will be parsed by Evennia as recipes to make available to the crafting system.
|
||||
Using the above example, create `mygame/world/recipes.py` and add your recipies
|
||||
in there:
|
||||
All top-level classes in these modules (whose name does not start with `_`) will
|
||||
be parsed by Evennia as recipes to make available to the crafting system. Using
|
||||
the above example, create `mygame/world/recipes.py` and add your recipies in
|
||||
there:
|
||||
|
||||
A quick example (read on for more details):
|
||||
|
||||
```python
|
||||
|
||||
|
|
@ -69,34 +102,199 @@ class RecipeBread(CraftingRecipe):
|
|||
def pre_craft(self, **kwargs):
|
||||
# validates inputs etc. Raise `CraftingValidationError` if fails
|
||||
|
||||
def craft(self, **kwargs):
|
||||
# performs the craft - but it can still fail (check skills etc here)
|
||||
def do_craft(self, **kwargs):
|
||||
# performs the craft - report errors directly to user and return None (if
|
||||
# failed) and the created object(s) if successful.
|
||||
|
||||
def craft(self, result, **kwargs):
|
||||
# any post-crafting effects. Always called, even if crafting failed (be
|
||||
def post_craft(self, result, **kwargs):
|
||||
# any post-crafting effects. Always called, even if do_craft failed (the
|
||||
# result would be None then)
|
||||
|
||||
```
|
||||
|
||||
## Technical
|
||||
## Adding new recipes
|
||||
|
||||
The Recipe is a class that specifies the consumables, tools and output along
|
||||
with various methods (that you can override) to do the the validation of inputs
|
||||
and perform the crafting itself.
|
||||
A *recipe* is a class inheriting from
|
||||
`evennia.contrib.crafting.crafting.CraftingRecipe`. This class implements the
|
||||
most common form of crafting - that using in-game objects. Each recipe is a
|
||||
separate class which gets initialized with the consumables/tools you provide.
|
||||
|
||||
By default the input is a list of object-tags (using the "crafting_material"
|
||||
and "crafting_tool" tag-categories respectively). Providing a set of objects
|
||||
matching these tags are required for the crafting to be done. The use of tags
|
||||
means that multiple different objects could all work for the same recipe, as
|
||||
long as they have the right tag. This can be very useful for allowing players
|
||||
to experiment and explore alternative ways to create things!
|
||||
For the `craft` command to find your custom recipes, you need to tell Evennia
|
||||
where they are. Add a new line to your `mygame/server/conf/settings.py` file,
|
||||
with a list to any new modules with recipe classes.
|
||||
|
||||
The output is given by a set of prototype-dicts. If the input is correct and
|
||||
other checks are passed (such as crafting skill, for example), these prototypes
|
||||
will be used to generate the new object(s) being crafted.
|
||||
```python
|
||||
CRAFT_RECIPE_MODULES = ["world.myrecipes"]
|
||||
```
|
||||
|
||||
(You need to reload after adding this). All global-level classes in these
|
||||
modules (whose names don't start with underscore) are considered by the system
|
||||
as viable recipes.
|
||||
|
||||
Here we assume you created `mygame/world/myrecipes.py` to match the above
|
||||
example setting:
|
||||
|
||||
```python
|
||||
# in mygame/world/myrecipes.py
|
||||
|
||||
from evennia.contrib.crafting.crafting import CraftingRecipe
|
||||
|
||||
class WoodenPuppetRecipe(CraftingRecipe):
|
||||
"""A puppet""""
|
||||
name = "wooden puppet" # name to refer to this recipe as
|
||||
tool_tags = ["knife"]
|
||||
consumable_tags = ["wood"]
|
||||
output_prototypes = [
|
||||
{"key": "A carved wooden doll",
|
||||
"typeclass": "typeclasses.objects.decorations.Toys",
|
||||
"desc": "A small carved doll"}
|
||||
]
|
||||
|
||||
```
|
||||
|
||||
This specifies which tags to look for in the inputs. It defines a
|
||||
[Prototype](../Components/Prototypes.md) for the recipe to use to spawn the
|
||||
result on the fly (a recipe could spawn more than one result if needed).
|
||||
Instead of specifying the full prototype-dict, you could also just provide a
|
||||
list of `prototype_key`s to existing prototypes you have.
|
||||
|
||||
After reloading the server, this recipe would now be available to use. To try it
|
||||
we should create materials and tools to insert into the recipe.
|
||||
|
||||
|
||||
The recipe analyzes inputs, looking for [Tags](../Components/Tags.md) with
|
||||
specific tag-categories. The tag-category used can be set per-recipe using the
|
||||
(`.consumable_tag_category` and `.tool_tag_category` respectively). The defaults
|
||||
are `crafting_material` and `crafting_tool`. For
|
||||
the puppet we need one object with the `wood` tag and another with the `knife`
|
||||
tag:
|
||||
|
||||
```python
|
||||
from evennia import create_object
|
||||
|
||||
knife = create_object(key="Hobby knife", tags=[("knife", "crafting_tool")])
|
||||
wood = create_object(key="Piece of wood", tags[("wood", "crafting_material")])
|
||||
```
|
||||
|
||||
Note that the objects can have any name, all that matters is the
|
||||
tag/tag-category. This means if a "bayonet" also had the "knife" crafting tag,
|
||||
it could also be used to carve a puppet. This is also potentially interesting
|
||||
for use in puzzles and to allow users to experiment and find alternatives to
|
||||
know ingredients.
|
||||
|
||||
By the way, there is also a simple shortcut for doing this:
|
||||
|
||||
```
|
||||
tools, consumables = WoodenPuppetRecipe.seed()
|
||||
```
|
||||
|
||||
The `seed` class-method will create simple dummy objects that fulfills the
|
||||
recipe's requirements. This is great for testing.
|
||||
|
||||
Assuming these objects were put in our inventory, we could now craft using the
|
||||
in-game command:
|
||||
|
||||
```bash
|
||||
> craft wooden puppet from wood using hobby knife
|
||||
```
|
||||
In code we would do
|
||||
|
||||
```python
|
||||
from evennia.contrub.crafting.crafting import craft
|
||||
puppet = craft(crafter, "wooden puppet", knife, wood)
|
||||
|
||||
```
|
||||
In the call to `craft`, the order of `knife` and `wood` doesn't matter - the
|
||||
recipe will sort out which is which based on their tags.
|
||||
|
||||
## Deeper customization of recipes
|
||||
|
||||
For customizing recipes further, it helps to understand how to use the
|
||||
recipe-class directly:
|
||||
|
||||
```python
|
||||
class MyRecipe(CraftingRecipe):
|
||||
# ...
|
||||
|
||||
tools, consumables = MyRecipe.seed()
|
||||
recipe = MyRecipe(crafter, *(tools + consumables))
|
||||
result = recipe.craft()
|
||||
|
||||
```
|
||||
This is useful for testing and allows you to use the class directly without
|
||||
adding it to a module in `settings.CRAFTING_RECIPE_MODULES`.
|
||||
|
||||
Even without modifying more than the class properties, there are a lot of
|
||||
options to set on the `CraftingRecipe` class. Easiest is to refer to the
|
||||
[CraftingRecipe api
|
||||
documentation](evennia.contrib.game_systems.crafting.crafting.CraftingRecipe). For example,
|
||||
you can customize the validation-error messages, decide if the ingredients have
|
||||
to be exactly right, if a failure still consumes the ingredients or not, and
|
||||
much more.
|
||||
|
||||
For even more control you can override hooks in your own class:
|
||||
|
||||
- `pre_craft` - this should handle input validation and store its data in `.validated_consumables` and
|
||||
`validated_tools` respectively. On error, this reports the error to the crafter and raises the
|
||||
`CraftingValidationError`.
|
||||
- `craft` - this will only be called if `pre_craft` finished without an exception. This should
|
||||
return the result of the crafting, by spawnging the prototypes. Or the empty list if crafting
|
||||
fails for some reason. This is the place to add skill-checks or random chance if you need it
|
||||
for your game.
|
||||
- `post_craft` - this receives the result from `craft` and handles error messages and also deletes
|
||||
any consumables as needed. It may also modify the result before returning it.
|
||||
- `msg` - this is a wrapper for `self.crafter.msg` and should be used to send messages to the
|
||||
crafter. Centralizing this means you can also easily modify the sending style in one place later.
|
||||
|
||||
The class constructor (and the `craft` access function) takes optional `**kwargs`. These are passed
|
||||
into each crafting hook. These are unused by default but could be used to customize things per-call.
|
||||
|
||||
### Skilled crafters
|
||||
|
||||
What the crafting system does not have out of the box is a 'skill' system - the
|
||||
notion of being able to fail the craft if you are not skilled enough. Just how
|
||||
skills work is game-dependent, so to add this you need to make your own recipe
|
||||
parent class and have your recipes inherit from this.
|
||||
|
||||
|
||||
```python
|
||||
from random import randint
|
||||
from evennia.contrib.crafting.crafting import CraftingRecipe
|
||||
|
||||
class SkillRecipe(CraftingRecipe):
|
||||
"""A recipe that considers skill"""
|
||||
|
||||
difficulty = 20
|
||||
|
||||
def craft(self, **kwargs):
|
||||
"""The input is ok. Determine if crafting succeeds"""
|
||||
|
||||
# this is set at initialization
|
||||
crafter = self.crafte
|
||||
|
||||
# let's assume the skill is stored directly on the crafter
|
||||
# - the skill is 0..100.
|
||||
crafting_skill = crafter.db.skill_crafting
|
||||
# roll for success:
|
||||
if randint(1, 100) <= (crafting_skill - self.difficulty):
|
||||
# all is good, craft away
|
||||
return super().craft()
|
||||
else:
|
||||
self.msg("You are not good enough to craft this. Better luck next time!")
|
||||
return []
|
||||
```
|
||||
In this example we introduce a `.difficulty` for the recipe and makes a 'dice roll' to see
|
||||
if we succed. We would of course make this a lot more immersive and detailed in a full game. In
|
||||
principle you could customize each recipe just the way you want it, but you could also inherit from
|
||||
a central parent like this to cut down on work.
|
||||
|
||||
The [sword recipe example module](evennia.contrib.game_systems.crafting.example_recipes) also shows an example
|
||||
of a random skill-check being implemented in a parent and then inherited for multiple use.
|
||||
|
||||
## Even more customization
|
||||
|
||||
If you want to build something even more custom (maybe using different input types of validation logic)
|
||||
you could also look at the `CraftingRecipe` parent class `CraftingRecipeBase`.
|
||||
It implements just the minimum needed to be a recipe and for big changes you may be better off starting
|
||||
from this rather than the more opinionated `CraftingRecipe`.
|
||||
|
||||
Each recipe is a stand-alone entity which allows for very advanced
|
||||
customization for every recipe - for example one could have a recipe that
|
||||
checks other properties of the inputs (like quality, color etc) and have that
|
||||
affect the result. Your recipes could also (and likely would) tie into your
|
||||
game's skill system to determine the success or outcome of the crafting.
|
||||
|
|
|
|||
|
|
@ -3,5 +3,7 @@ Crafting - Griatch 2020
|
|||
|
||||
"""
|
||||
|
||||
from .crafting import craft # noqa
|
||||
from .crafting import CraftingRecipe # noqa
|
||||
from .crafting import CraftingValidationError # noqa
|
||||
from .crafting import CraftingRecipeBase # noqa
|
||||
from .crafting import CraftingError, CraftingValidationError # noqa
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# Gendersub
|
||||
|
||||
Contrib - Griatch 2015
|
||||
Contribution by Griatch 2015
|
||||
|
||||
This is a simple gender-aware Character class for allowing users to
|
||||
insert custom markers in their text to indicate gender-aware
|
||||
|
|
|
|||
|
|
@ -1,13 +1,15 @@
|
|||
# In-Game Mail system
|
||||
|
||||
Evennia Contribution - grungies1138 2016
|
||||
Contribution by grungies1138 2016
|
||||
|
||||
A simple Brandymail style mail system that uses the Msg class from Evennia
|
||||
Core. It has two Commands, both of which can be used on their own:
|
||||
A simple Brandymail style mail system that uses the `Msg` class from Evennia
|
||||
Core. It has two Commands for either sending mails between Accounts (out of game)
|
||||
or between Characters (in-game). The two types of mails can be used together or
|
||||
on their own.
|
||||
|
||||
- CmdMail - this should sit on the Account cmdset and makes the `mail` command
|
||||
- `CmdMail` - this should sit on the Account cmdset and makes the `mail` command
|
||||
available both IC and OOC. Mails will always go to Accounts (other players).
|
||||
- CmdMailCharacter - this should sit on the Character cmdset and makes the `mail`
|
||||
- `CmdMailCharacter` - this should sit on the Character cmdset and makes the `mail`
|
||||
command ONLY available when puppeting a character. Mails will be sent to other
|
||||
Characters only and will not be available when OOC.
|
||||
- If adding *both* commands to their respective cmdsets, you'll get two separate
|
||||
|
|
|
|||
|
|
@ -1,15 +1,16 @@
|
|||
# Evennia Multidescer
|
||||
|
||||
Contrib - Griatch 2016
|
||||
Contribution by Griatch 2016
|
||||
|
||||
A "multidescer" is a concept from the MUSH world. It allows for
|
||||
creating, managing and switching between multiple character
|
||||
descriptions. This multidescer will not require any changes to the
|
||||
Character class, rather it will use the `multidescs` Attribute (a
|
||||
list) and create it if it does not exist.
|
||||
descriptions and is a way for quickly managing your look (such as when
|
||||
changing clothes) in more free-form roleplaying systems. This will also
|
||||
work well together with the `rpsystem` contrib.
|
||||
|
||||
This contrib also works well together with the rpsystem contrib (which
|
||||
also adds the short descriptions and the `sdesc` command).
|
||||
This multidescer will not
|
||||
require any changes to the Character class, rather it will use the `multidescs`
|
||||
Attribute (a list) and create it if it does not exist.
|
||||
|
||||
## Installation
|
||||
|
||||
|
|
|
|||
|
|
@ -1,18 +1,21 @@
|
|||
# Puzzles System
|
||||
|
||||
Evennia contribution - Henddher 2018
|
||||
Contribution by Henddher 2018
|
||||
|
||||
Provides a typeclass and commands for objects that can be combined (i.e. 'use'd)
|
||||
to produce new objects.
|
||||
Intended for adventure-game style combination puzzles, such as combining fruits
|
||||
and a blender to create a smoothie. Provides a typeclass and commands for objects
|
||||
that can be combined (i.e. used together). Unlike the `crafting` contrib, each
|
||||
puzzle is built from unique objects rather than using tags and a builder can create
|
||||
the puzzle entirely from in-game.
|
||||
|
||||
A Puzzle is a recipe of what objects (aka parts) must be combined by a player so
|
||||
A `Puzzle` is a recipe of what objects (aka parts) must be combined by a player so
|
||||
a new set of objects (aka results) are automatically created.
|
||||
|
||||
## Installation
|
||||
|
||||
Add the PuzzleSystemCmdSet to all players (e.g. in their Character typeclass).
|
||||
Add the `PuzzleSystemCmdSet` to all players (e.g. in their Character typeclass).
|
||||
|
||||
Alternatively:
|
||||
Alternatively (for quick testing):
|
||||
|
||||
py self.cmdset.add('evennia.contrib.game_systems.puzzles.PuzzleSystemCmdSet')
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# Turn based battle system framework
|
||||
|
||||
Contrib - Tim Ashley Jenkins 2017
|
||||
Contribution by Tim Ashley Jenkins, 2017
|
||||
|
||||
This is a framework for a simple turn-based combat system, similar
|
||||
to those used in D&D-style tabletop role playing games. It allows
|
||||
|
|
|
|||
|
|
@ -1,10 +1,11 @@
|
|||
# Extended Room
|
||||
|
||||
Evennia Contribution - Griatch 2012, vincent-lg 2019
|
||||
Contribution - Griatch 2012, vincent-lg 2019
|
||||
|
||||
This is an extended Room typeclass for Evennia. It is supported
|
||||
by an extended `Look` command and an extended `desc` command, also
|
||||
in this module.
|
||||
This extends the normal `Room` typeclass to allow its description to change
|
||||
with time-of-day and/or season. It also adds 'details' for the player to look at
|
||||
in the room (without having to create a new in-game object for each). The room is
|
||||
supported by new `look` and `desc` commands.
|
||||
|
||||
## Installation/testing:
|
||||
|
||||
|
|
|
|||
|
|
@ -1,8 +1,8 @@
|
|||
# Map Builder
|
||||
|
||||
Contribution - Cloud_Keeper 2016
|
||||
Contribution by Cloud_Keeper 2016
|
||||
|
||||
Build a map from a 2D ASCII map.
|
||||
Build a game map from the drawing of a 2D ASCII map.
|
||||
|
||||
This is a command which takes two inputs:
|
||||
|
||||
|
|
|
|||
|
|
@ -1,13 +1,15 @@
|
|||
# SimpleDoor
|
||||
|
||||
Contribution - Griatch 2016
|
||||
Contribution by Griatch, 2016
|
||||
|
||||
A simple two-way exit that represents a door that can be opened and
|
||||
closed. Can easily be expanded from to make it lockable, destroyable
|
||||
etc. Note that the simpledoor is based on Evennia locks, so it will
|
||||
not work for a superuser (which bypasses all locks) - the superuser
|
||||
closed from both sides. Can easily be expanded to make it lockable,
|
||||
destroyable etc.
|
||||
|
||||
Note that the simpledoor is based on Evennia locks, so it will
|
||||
not work for a superuser (which bypasses all locks). The superuser
|
||||
will always appear to be able to close/open the door over and over
|
||||
without the locks stopping you. To use the door, use `@quell` or a
|
||||
without the locks stopping you. To use the door, use `quell` or a
|
||||
non-superuser account.
|
||||
|
||||
## Installation:
|
||||
|
|
|
|||
|
|
@ -1,10 +1,10 @@
|
|||
# Slow Exit
|
||||
|
||||
Contribution - Griatch 2014
|
||||
Contribution by Griatch 2014
|
||||
|
||||
This is an example of an Exit-type that delays its traversal. This simulates
|
||||
slow movement, common in many different types of games. The contrib also
|
||||
contains two commands, `CmdSetSpeed` and CmdStop for changing the movement speed
|
||||
An example of an Exit-type that delays its traversal. This simulates
|
||||
slow movement, common in many games. The contrib also
|
||||
contains two commands, `setspeed` and `stop` for changing the movement speed
|
||||
and abort an ongoing traversal, respectively.
|
||||
|
||||
## Installation:
|
||||
|
|
|
|||
|
|
@ -1,10 +1,10 @@
|
|||
# Wilderness system
|
||||
|
||||
Evennia contrib - titeuf87 2017
|
||||
Contribution by titeuf87, 2017
|
||||
|
||||
This contrib provides a wilderness map without actually creating a large number
|
||||
of rooms - as you move, your room is instead updated with different
|
||||
descriptions. This means you can make huge areas with little database use as
|
||||
of rooms - as you move, you instead end up back in the same room but its description
|
||||
changes. This means you can make huge areas with little database use as
|
||||
long as the rooms are relatively similar (name/desc changing).
|
||||
|
||||
## Installation
|
||||
|
|
|
|||
File diff suppressed because it is too large
Load diff
|
|
@ -1,8 +1,12 @@
|
|||
# Dice
|
||||
|
||||
Rolls dice for roleplaying, in-game gambling or GM:ing
|
||||
Contribution by Griatch, 2012
|
||||
|
||||
A dice roller for any number and side of dice. Adds in-game dice rolling
|
||||
(`roll 2d10 + 1`) as well as conditionals (roll under/over/equal to a target)
|
||||
and functions for rolling dice in code. Command also supports hidden or secret
|
||||
rolls for use by a human game master.
|
||||
|
||||
Evennia contribution - Griatch 2012
|
||||
|
||||
# Installation:
|
||||
|
||||
|
|
|
|||
|
|
@ -1,11 +1,11 @@
|
|||
# Health Bar
|
||||
|
||||
Contrib - Tim Ashley Jenkins 2017
|
||||
Contribution by Tim Ashley Jenkins, 2017
|
||||
|
||||
The function provided in this module lets you easily display visual
|
||||
bars or meters - "health bar" is merely the most obvious use for this,
|
||||
though these bars are highly customizable and can be used for any sort
|
||||
of appropriate data besides player health.
|
||||
bars or meters as a colorful bar instead of just a number. A "health bar"
|
||||
is merely the most obvious use for this, but the bar is highly customizable
|
||||
and can be used for any sort of appropriate data besides player health.
|
||||
|
||||
Today's players may be more used to seeing statistics like health,
|
||||
stamina, magic, and etc. displayed as bars rather than bare numerical
|
||||
|
|
|
|||
|
|
@ -1,7 +1,17 @@
|
|||
# Roleplaying base system for Evennia
|
||||
|
||||
Roleplaying emotes/sdescs - Griatch, 2015
|
||||
Language/whisper emotes - Griatch, 2015
|
||||
Contribution by Griatch, 2015
|
||||
|
||||
A full roleplaying emote system. Short-descriptions and recognition (only
|
||||
know people by their looks until you assign a name to them). Room poses. Masks/disguises
|
||||
(hide your description). Speak directly in emote, with optional language obscuration
|
||||
(words get garbled if you don't know the language, you can also have different languages
|
||||
with different 'sounding' garbling). Whispers can be partly overheard from a distance. A
|
||||
very powerful in-emote reference system, for referencing and differentiate targets
|
||||
(including objects).
|
||||
|
||||
The system contains of two main modules - the roleplaying emote system and the language
|
||||
obscuration module.
|
||||
|
||||
## Roleplaying emotes
|
||||
|
||||
|
|
|
|||
|
|
@ -1,12 +1,10 @@
|
|||
# Traits
|
||||
|
||||
Whitenoise 2014, Ainneve contributors,
|
||||
Griatch 2020
|
||||
Contribution by Griatch 2020, based on code by Whitenoise and Ainneve contribs, 2014
|
||||
|
||||
A `Trait` represents a modifiable property on (usually) a Character. They can
|
||||
be used to represent everything from attributes (str, agi etc) to skills
|
||||
(hunting 10, swords 14 etc) and dynamically changing things like HP, XP etc.
|
||||
|
||||
(hunting 10, swords 14 etc) and dynamically changing things like HP, XP etc.
|
||||
Traits differ from normal Attributes in that they track their changes and limit
|
||||
themselves to particular value-ranges. One can add/subtract from them easily and
|
||||
they can even change dynamically at a particular rate (like you being poisoned or
|
||||
|
|
|
|||
|
|
@ -1,10 +1,10 @@
|
|||
# Batch processor examples
|
||||
|
||||
Contibution - Griatch 2012
|
||||
Contibution by Griatch, 2012
|
||||
|
||||
The batch processor is used for generating in-game content from one or more
|
||||
static files. Files can be stored with version control and then 'applied'
|
||||
to the game to create content.
|
||||
Simple examples for the batch-processor. The batch processor is used for generating
|
||||
in-game content from one or more static files. Files can be stored with version
|
||||
control and then 'applied' to the game to create content.
|
||||
|
||||
There are two batch processor types:
|
||||
|
||||
|
|
|
|||
|
|
@ -1,9 +1,9 @@
|
|||
# Script example
|
||||
|
||||
Griatch - 2012
|
||||
Contribution by Griatch, 2012
|
||||
|
||||
Example script for testing. This adds a simple timer that has your
|
||||
character make observations and notices at irregular intervals.
|
||||
character make small verbal observations at irregular intervals.
|
||||
|
||||
To test, use (in game)
|
||||
|
||||
|
|
|
|||
|
|
@ -1,8 +1,8 @@
|
|||
# TutorialMirror
|
||||
|
||||
A simple mirror object to experiment with.
|
||||
Contribution by Griatch, 2017
|
||||
|
||||
A simple mirror object that
|
||||
A simple mirror object to experiment with. It will respond to being looked at.
|
||||
|
||||
- echoes back the description of the object looking at it
|
||||
- echoes back whatever is being sent to its .msg - to the
|
||||
|
|
|
|||
|
|
@ -1,9 +1,9 @@
|
|||
# Red Button example
|
||||
|
||||
Griatch - 2011
|
||||
Contribution by Griatch, 2011
|
||||
|
||||
This is a more advanced example object with its own functionality (commands)
|
||||
on it.
|
||||
A red button that you can press to have an effect. This is a more advanced example
|
||||
object with its own functionality and state tracking.
|
||||
|
||||
Create the button with
|
||||
|
||||
|
|
|
|||
|
|
@ -1,9 +1,9 @@
|
|||
# Talkative NPC example
|
||||
|
||||
Contribution - Griatch 2011, grungies1138, 2016
|
||||
Contribution by Griatch 2011. Updated by grungies1138, 2016
|
||||
|
||||
This is a static NPC object capable of holding a simple menu-driven
|
||||
conversation. It's just meant as an example.
|
||||
This is an example of a static NPC object capable of holding a simple menu-driven
|
||||
conversation. Suitable for example as a quest giver or merchant.
|
||||
|
||||
## Installation
|
||||
|
||||
|
|
|
|||
|
|
@ -1,13 +1,14 @@
|
|||
# Evennia Tutorial World
|
||||
|
||||
Griatch 2011, 2015
|
||||
Contribution by Griatch 2011, 2015
|
||||
|
||||
This is a stand-alone tutorial area for an unmodified Evennia install.
|
||||
A stand-alone tutorial area for an unmodified Evennia install.
|
||||
Think of it as a sort of single-player adventure rather than a
|
||||
full-fledged multi-player game world. The various rooms and objects
|
||||
herein are designed to show off features of the engine, not to be a
|
||||
are designed to show off features of Evennia, not to be a
|
||||
very challenging (nor long) gaming experience. As such it's of course
|
||||
only skimming the surface of what is possible.
|
||||
only skimming the surface of what is possible. Taking this apart
|
||||
is a great way to start learning the system.
|
||||
|
||||
The tutorial world also includes a game tutor menu example, exemplifying
|
||||
Evmenu.
|
||||
|
|
|
|||
|
|
@ -1,15 +1,15 @@
|
|||
# Input/Output Auditing
|
||||
|
||||
Contrib - Johnny 2017
|
||||
Contribution by Johnny, 2017
|
||||
|
||||
This is a tap that optionally intercepts all data sent to/from clients and the
|
||||
server and passes it to a callback of your choosing.
|
||||
Utility that taps and intercepts all data sent to/from clients and the
|
||||
server and passes it to a callback of your choosing. This is intended for
|
||||
quality assurance, post-incident investigations and debugging.
|
||||
|
||||
It is intended for quality assurance, post-incident investigations and debugging
|
||||
but obviously can be abused. All data is recorded in cleartext. Please
|
||||
be ethical, and if you are unwilling to properly deal with the implications of
|
||||
recording user passwords or private communications, please do not enable
|
||||
this module.
|
||||
Note that this should be used with care since it can obviously be abused. All
|
||||
data is recorded in cleartext. Please be ethical, and if you are unwilling to
|
||||
properly deal with the implications of recording user passwords or private
|
||||
communications, please do not enable this module.
|
||||
|
||||
Some checks have been implemented to protect the privacy of users.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,14 +1,16 @@
|
|||
# Easy fillable form
|
||||
|
||||
Contrib - Tim Ashley Jenkins 2018
|
||||
Contribution by Tim Ashley Jenkins, 2018
|
||||
|
||||
This module contains a function that calls an easily customizable EvMenu - this
|
||||
menu presents the player with a fillable form, with fields that can be filled
|
||||
out in any order. Each field's value can be verified, with the function
|
||||
allowing easy checks for text and integer input, minimum and maximum values /
|
||||
character lengths, or can even be verified by a custom function. Once the form
|
||||
is submitted, the form's data is submitted as a dictionary to any callable of
|
||||
your choice.
|
||||
This module contains a function that generates an `EvMenu` for you - this
|
||||
menu presents the player with a form of fields that can be filled
|
||||
out in any order (e.g. for character generation or building). Each field's value can
|
||||
be verified, with the function allowing easy checks for text and integer input,
|
||||
minimum and maximum values / character lengths, or can even be verified by a custom
|
||||
function. Once the form is submitted, the form's data is submitted as a dictionary
|
||||
to any callable of your choice.
|
||||
|
||||
## Usage
|
||||
|
||||
The function that initializes the fillable form menu is fairly simple, and
|
||||
includes the caller, the template for the form, and the callback(caller, result)
|
||||
|
|
|
|||
|
|
@ -1,12 +1,14 @@
|
|||
# Pseudo-random generator and registry
|
||||
|
||||
Contribution - Vincent Le Goff 2017
|
||||
Contribution by Vincent Le Goff (vlgeoff), 2017
|
||||
|
||||
This contrib can be used to generate pseudo-random strings of information
|
||||
This utility can be used to generate pseudo-random strings of information
|
||||
with specific criteria. You could, for instance, use it to generate
|
||||
phone numbers, license plate numbers, validation codes, non-sensivite
|
||||
passwords and so on. The strings generated by the generator will be
|
||||
stored and won't be available again in order to avoid repetition.
|
||||
phone numbers, license plate numbers, validation codes, in-game security
|
||||
passwords and so on. The strings generated will be stored and won't be repeated.
|
||||
|
||||
## Usage Example
|
||||
|
||||
Here's a very simple example:
|
||||
|
||||
```python
|
||||
|
|
|
|||
|
|
@ -1,14 +1,16 @@
|
|||
# Easy menu selection tree
|
||||
|
||||
Contrib - Tim Ashley Jenkins 2017
|
||||
Contribution by Tim Ashley Jenkins, 2017
|
||||
|
||||
This module allows you to create and initialize an entire branching EvMenu
|
||||
instance with nothing but a multi-line string passed to one function.
|
||||
This utility allows you to create and initialize an entire branching EvMenu
|
||||
instance from a multi-line string passed to one function.
|
||||
|
||||
EvMenu is incredibly powerful and flexible, but using it for simple menus
|
||||
can often be fairly cumbersome - a simple menu that can branch into five
|
||||
categories would require six nodes, each with options represented as a list
|
||||
of dictionaries.
|
||||
> Note: Since the time this contrib was created, EvMenu itself got its own templating
|
||||
> language that has more features and is not compatible with the style used in
|
||||
> this contrib. Both can still be used in parallel.
|
||||
|
||||
`EvMenu` is incredibly powerful and flexible but it can be a little overwhelming
|
||||
and offers a lot of power that may not be needed for a simple multiple-choice menu.
|
||||
|
||||
This module provides a function, `init_tree_selection`, which acts as a frontend
|
||||
for EvMenu, dynamically sourcing the options from a multi-line string you
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue