Andreas/evennia
1
0
Fork 0
mirror of https://github.com/evennia/evennia.git synced 2026-03-16 21:06:30 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions

Update docs to reference _evmenu rather than old _menutree NAttribute. Resolve #2731

Browse source
This commit is contained in:
Griatch 2022-11-01 23:40:36 +01:00
parent de3729103e
commit 6e4bb8047b
2 changed files with 15 additions and 15 deletions
Download patch file Download diff file Expand all files Collapse all files

26
docs/source/Components/EvMenu.md
View file

@ -273,13 +273,13 @@ after
list the current state of the menu and use `menudebug <variable>` to inspect a specific state
variable from the list.
- All other keyword arguments will be available as initial data for the nodes. They will be
available in all nodes as properties on `caller.ndb._menutree` (see below). These will also
available in all nodes as properties on `caller.ndb._evmenu` (see below). These will also
survive a `@reload` if the menu is `persistent`.
You don't need to store the EvMenu instance anywhere - the very act of initializing it will store it
as `caller.ndb._menutree` on the `caller`. This object will be deleted automatically when the menu
as `caller.ndb._evmenu` on the `caller`. This object will be deleted automatically when the menu
is exited and you can also use it to store your own temporary variables for access throughout the
menu. Temporary variables you store on a persistent `_menutree` as it runs will
menu. Temporary variables you store on a persistent `_evmenu` as it runs will
*not* survive a `@reload`, only those you set as part of the original `EvMenu` call.
@ -508,10 +508,10 @@ manipulated for every iteration.
## Temporary storage
When the menu starts, the EvMenu instance is stored on the caller as `caller.ndb._menutree`. Through
When the menu starts, the EvMenu instance is stored on the caller as `caller.ndb._evmenu`. Through
this object you can in principle reach the menu's internal state if you know what you are doing.
This is also a good place to store temporary, more global variables that may be cumbersome to keep
passing from node to node via the `**kwargs`. The `_menutree` will be deleted automatically when the
passing from node to node via the `**kwargs`. The `_evmnenu` will be deleted automatically when the
menu closes, meaning you don't need to worry about cleaning anything up.
If you want *permanent* state storage, it's instead better to use an Attribute on `caller`. Remember
@ -944,16 +944,16 @@ previous node, but updating its ingoing kwargs to tell it to display a different
### Example: Storing data between nodes
A convenient way to store data is to store it on the `caller.ndb._menutree` which you can reach from
every node. The advantage of doing this is that the `_menutree` NAttribute will be deleted
A convenient way to store data is to store it on the `caller.ndb._evmenu` which you can reach from
every node. The advantage of doing this is that the `_evmenu` NAttribute will be deleted
automatically when you exit the menu.
```python
def _set_name(caller, raw_string, **kwargs):
caller.ndb._menutree.charactersheet = {}
caller.ndb._menutree.charactersheet['name'] = raw_string
caller.ndb._evmenu.charactersheet = {}
caller.ndb._evmenu.charactersheet['name'] = raw_string
caller.msg(f"You set your name to {raw_string}")
return "background"
@ -968,7 +968,7 @@ def node_set_name(caller):
def node_view_sheet(caller):
text = f"Character sheet:\n {self.ndb._menutree.charactersheet}"
text = f"Character sheet:\n {self.ndb._evmenu.charactersheet}"
options = ({"key": "Accept",
"goto": "finish_chargen"},
@ -980,11 +980,11 @@ def node_view_sheet(caller):
```
Instead of passing the character sheet along from node to node through the `kwargs` we instead
set it up temporarily on `caller.ndb._menutree.charactersheet`. This makes it easy to reach from
set it up temporarily on `caller.ndb._evmenu.charactersheet`. This makes it easy to reach from
all nodes. At the end we look at it and, if we accept the character the menu will likely save the
result to permanent storage and exit.
> One point to remember though is that storage on `caller.ndb._menutree` is not persistent across
> One point to remember though is that storage on `caller.ndb._evmenu` is not persistent across
> `@reloads`. If you are using a persistent menu (using `EvMenu(..., persistent=True)` you should
use
> `caller.db` to store in-menu data like this as well. You must then yourself make sure to clean it
@ -1307,5 +1307,5 @@ The EvMenu is implemented using [Commands](./Commands.md). When you start a new
menu will be assigned a [CmdSet](./Command-Sets.md) with the commands they need to navigate the menu.
This means that if you were to, from inside the menu, assign a new command set to the caller, *you
may override the Menu Cmdset and kill the menu*. If you want to assign cmdsets to the caller as part
of the menu, you should store the cmdset on `caller.ndb._menutree` and wait to actually assign it
of the menu, you should store the cmdset on `caller.ndb._evmenu` and wait to actually assign it
until the exit node.

4
docs/source/Howtos/Coding-FAQ.md
View file

@ -52,7 +52,7 @@ def at_pre_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](../Components/EvMenu.md) is started, the menu object is stored as `caller.ndb._menutree`.
**A:** When an [EvMenu](../Components/EvMenu.md) is started, the menu object is stored as `caller.ndb._evmenu`.
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:
@ -67,7 +67,7 @@ class MyObjectCommand(Command):
```
Inside the menu you can now access the object through `caller.ndb._menutree.stored_obj`.
Inside the menu you can now access the object through `caller.ndb._evmenu.stored_obj`.
## Adding color to default Evennia Channels