From ae14ffb9981f06702b681a32578a74972fd554f6 Mon Sep 17 00:00:00 2001 From: Wendy Wang Date: Thu, 5 Sep 2024 09:26:45 +0200 Subject: [PATCH 1/3] Minor typo fixes in documentation --- docs/source/Components/Typeclasses.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/source/Components/Typeclasses.md b/docs/source/Components/Typeclasses.md index 19e221ac23..f48ffb5d31 100644 --- a/docs/source/Components/Typeclasses.md +++ b/docs/source/Components/Typeclasses.md @@ -244,18 +244,18 @@ The arguments to this method are described [in the API docs here](github:evennia Technically, typeclasses are [Django proxy models](https://docs.djangoproject.com/en/4.1/topics/db/models/#proxy-models). The only database models that are "real" in the typeclass system (that is, are represented by actual tables in the database) are `AccountDB`, `ObjectDB`, `ScriptDB` and `ChannelDB` (there are also [Attributes](./Attributes.md) and [Tags](./Tags.md) but they are not typeclasses themselves). All the subclasses of them are "proxies", extending them with Python code without actually modifying the database layout. -Evennia modifies Django's proxy model in various ways to allow them to work without any boiler plate (for example you don't need to set the Django "proxy" property in the model `Meta` subclass, Evennia handles this for you using metaclasses). Evennia also makes sure you can query subclasses as well as patches django to allow multiple inheritance from the same base class. +Evennia modifies Django's proxy model in various ways to allow them to work without any boiler plate (for example you don't need to set the Django "proxy" property in the model `Meta` subclass, Evennia handles this for you using metaclasses). Evennia also makes sure you can query subclasses as well as patches Django to allow multiple inheritance from the same base class. ### Caveats -Evennia uses the *idmapper* to cache its typeclasses (Django proxy models) in memory. The idmapper allows things like on-object handlers and properties to be stored on typeclass instances and to not get lost as long as the server is running (they will only be cleared on a Server reload). Django does not work like this by default; by default every time you search for an object in the database you'll get a *different* instance of that object back and anything you stored on it that was not in the database would be lost. The bottom line is that Evennia's Typeclass instances subside in memory a lot longer than vanilla Django model instance do. +Evennia uses the *idmapper* to cache its typeclasses (Django proxy models) in memory. The idmapper allows things like on-object handlers and properties to be stored on typeclass instances and to not get lost as long as the server is running (they will only be cleared on a Server reload). Django does not work like this by default; by default every time you search for an object in the database you'll get a *different* instance of that object back and anything you stored on it that was not in the database would be lost. The bottom line is that Evennia's Typeclass instances subsist in memory a lot longer than vanilla Django model instances do. There is one caveat to consider with this, and that relates to [making your own models](New- Models): Foreign relationships to typeclasses are cached by Django and that means that if you were to change an object in a foreign relationship via some other means than via that relationship, the object seeing the relationship may not reliably update but will still see its old cached version. Due to typeclasses staying so long in memory, stale caches of such relationships could be more visible than common in Django. See the [closed issue #1098 and its comments](https://github.com/evennia/evennia/issues/1098) for examples and solutions. ## Will I run out of dbrefs? -Evennia does not re-use its `#dbrefs`. This means new objects get an ever-increasing `#dbref`, also if you delete older objects. There are technical and safety reasons for this. But you may wonder if this means you have to worry about a big game 'running out' of dbref integers eventually. +Evennia does not re-use its `#dbrefs`. This means new objects get an ever-increasing `#dbref`, even if you delete older objects. There are technical and safety reasons for this. But you may wonder if this means you have to worry about a big game 'running out' of dbref integers eventually. The answer is simply **no**. From 54a0e8c9b18755267f87d594a876c335a344144f Mon Sep 17 00:00:00 2001 From: Wendy Wang Date: Thu, 5 Sep 2024 09:54:25 +0200 Subject: [PATCH 2/3] Typo fix on FuncParser.md --- docs/source/Components/FuncParser.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/source/Components/FuncParser.md b/docs/source/Components/FuncParser.md index 458bbeb3dc..9b348b9af6 100644 --- a/docs/source/Components/FuncParser.md +++ b/docs/source/Components/FuncParser.md @@ -20,7 +20,7 @@ To escape the inlinefunc (e.g. to explain to someone how it works, use `$$`) You say "To get a random value from 1 to 5, use $randint(1,5)." ``` -While `randint` may look and work just like `random.randint` from the standard Python library, it is _not_. Instead it's a `inlinefunc` named `randint` made available to Evennia (which in turn uses the standard library function). For security reasons, only functions explicitly assigned to be used as inlinefuncs are viable. +While `randint` may look and work just like `random.randint` from the standard Python library, it is _not_. Instead it's an `inlinefunc` named `randint` made available to Evennia (which in turn uses the standard library function). For security reasons, only functions explicitly assigned to be used as inlinefuncs are viable. You can apply the `FuncParser` manually. The parser is initialized with the inlinefunc(s) it's supposed to recognize in that string. Below is an example of a parser only understanding a single `$pow` inlinefunc: @@ -84,7 +84,7 @@ parser = FuncParser(["game.myfuncparser_callables", "game.more_funcparser_callab Here, `callables` points to a collection of normal Python functions (see next section) for you to make available to the parser as you parse strings with it. It can either be -- A `dict` of `{"functionname": callable, ...}`. This allows you do pick and choose exactly which callables +- A `dict` of `{"functionname": callable, ...}`. This allows you to pick and choose exactly which callables to include and how they should be named. Do you want a callable to be available under more than one name? Just add it multiple times to the dict, with a different key. - A `module` or (more commonly) a `python-path` to a module. This module can define a dict @@ -235,7 +235,7 @@ everything but the outermost double quotes. Since you don't know in which order users may use your callables, they should always check the types of its inputs and convert to the type the callable needs. -Note also that when converting from strings, there are limits what inputs you +Note also that when converting from strings, there are limits on what inputs you can support. This is because FunctionParser strings can be used by non-developer players/builders and some things (such as complex classes/callables etc) are just not safe/possible to convert from string @@ -339,7 +339,7 @@ Here the `caller` is the one sending the message and `receiver` the one to see i - `$You([key])` - same as `$you` but always capitalized. - `$conj(verb [,key])` ([code](evennia.utils.funcparser.funcparser_callable_conjugate)) - conjugates a verb between 2nd person presence to 3rd person presence depending on who - sees the string. For example `"$You() $conj(smiles)".` will show as "You smile." and "Tom smiles." depending + sees the string. For example `p".` will show as "You smile." and "Tom smiles." depending on who sees it. This makes use of the tools in [evennia.utils.verb_conjugation](evennia.utils.verb_conjugation) to do this, and only works for English verbs. - `$pron(pronoun [,options] [,key])` ([code](evennia.utils.funcparser.funcparser_callable_pronoun)) - Dynamically From 546d5c9239275d099a1c62f873a9903f5c6a1124 Mon Sep 17 00:00:00 2001 From: Wendy Wang Date: Thu, 5 Sep 2024 09:56:00 +0200 Subject: [PATCH 3/3] Update FuncParser.md --- docs/source/Components/FuncParser.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/source/Components/FuncParser.md b/docs/source/Components/FuncParser.md index 9b348b9af6..35abebb65e 100644 --- a/docs/source/Components/FuncParser.md +++ b/docs/source/Components/FuncParser.md @@ -339,7 +339,7 @@ Here the `caller` is the one sending the message and `receiver` the one to see i - `$You([key])` - same as `$you` but always capitalized. - `$conj(verb [,key])` ([code](evennia.utils.funcparser.funcparser_callable_conjugate)) - conjugates a verb between 2nd person presence to 3rd person presence depending on who - sees the string. For example `p".` will show as "You smile." and "Tom smiles." depending + sees the string. For example `"$You() $conj(smiles)".` will show as "You smile." and "Tom smiles." depending on who sees it. This makes use of the tools in [evennia.utils.verb_conjugation](evennia.utils.verb_conjugation) to do this, and only works for English verbs. - `$pron(pronoun [,options] [,key])` ([code](evennia.utils.funcparser.funcparser_callable_pronoun)) - Dynamically