New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Removing direct access to Account.db._playable_characters in favor of… #3179
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this makes for a nice cleanup, but concern is as usual with the naming ... the thing about _playable_characters
is that it's a soft listing of characters you may play. Its main purpose is not to limit who you can play (that's down to the puppet:
lock, but to allow us to show a nice list of characters as a reminder (in the character selection screen).
I fear the add_character
etc naming may suggest that you are creating a stronger link between the Character and the Account than you are.
To make this explicit, maybe this may be better:
add_character_to_playable_list
at_post_add_character_to_playable_list
remove_character_from_playable_list
at_post_remove_character_from_playable_list
It's longer, but makes it much clearer what is actually happening. I'm open to other suggestions though.
But either way, if we do this change, the unit tests should change to make use of the new best practice as well.
d2060f2
to
7535620
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the changes look good overall, I think the renames were done everywhere (but it's a bit hard to track).
- The unit tests doesn't pass for this.
- The install and adding of the Rich library (EvRich) is way beyond the scope of this PR, please remove that. While we may want to add it at some point, it needs to be reviewed separeately.
As a side note, please avoid squashing your commits before review is complete. It throws away the history and means the reviewer has to basically do the entire review all over every time (After approval, one can squash for a better merge history, but we haven't worried too much about that to make it easier for contributors).
evennia/__init__.py
Outdated
@@ -363,6 +364,9 @@ class SystemCmds(_EvContainer): | |||
del SystemCmds | |||
del _EvContainer | |||
|
|||
# Trigger EvRich to monkey-patch Rich in-memory. | |||
install_evrich() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This does not belong with the PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oops I don't know how that snuck in there.
@volundmush Ping. |
1d94f70
to
01c1e67
Compare
Removed the Rich stuff; not at all sure how it snuck in there, I probably got a few commits crossed when experimenting with other things. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the changes to how to operate the db._playable_characters
- using helper methods makes for less code. I have some further comments inline, but two main ones:
- Looking at how these helper methods are used here, in combination with
self.characters
makes me wonder why.characters
is not a handler. Since people are encouraged to look atself.characters
now to see which playable characters they have, it's not at all obvious that you need to calladd/remove_character_to/from_playable_list
to modify.characters
(if you don't know how it works under the hood). It sounds like it would be more intuitive to let.characters
be a handler so you'd doself.characters.add()/.remove()
. Drawback of that is that you'd need to do.characters.get()
to get the characters (so a backwards-incompatible change), but it would be more in line with how these things work elsewhere. - There are a few additions here that seems out of scope of the PR still, including some more Rich-references.
@@ -389,7 +389,7 @@ def resolve_combat(combat_handler, actiondict): | |||
for (char, fleevalue) in flee.items(): | |||
if fleevalue == 2: | |||
combat_handler.msg_all(f"{char} withdraws from combat.") | |||
combat_handler.remove_character(char) | |||
combat_handler.remove_character_from_playable_list(char) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is this change needed on the combat_handler
? That's a Script, not an account? Besides the combathandler's remove_character
was not updated either. So this looks like an search-and-replace gone wrong.
return | ||
target = self.caller.search(self.args) | ||
if not target: | ||
return | ||
# set up combat | ||
if target.ndb.combat_handler: | ||
# target is already in combat - join it | ||
target.ndb.combat_handler.add_character(self.caller) | ||
target.ndb.combat_handler.add_character_to_playable_list(self.caller) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same here. combat_handler
is a Script...
target.ndb.combat_handler.msg_all(f"{self.caller} joins combat!") | ||
else: | ||
# create a new combat handler | ||
chandler = create_script("combat_handler.CombatHandler") | ||
chandler.add_character(self.caller) | ||
chandler.add_character(target) | ||
chandler.add_character_to_playable_list(self.caller) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same here, it doesn't make sense to rename this, especially since the combathandler's code was not updated to match (and it's unrelated to this anyway)
evennia/accounts/accounts.py
Outdated
def add_character_to_playable_list(self, character: "DefaultCharacter"): | ||
""" | ||
Add a character to this account's list of playable characters. | ||
""" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's worth to expand the docstring here, since this list is not really limiting what can be played (the puppet:
lock does). The list is only used as a quick way to show a list on the character-selection screen. Not to mention that this listing is not unique - any number of people can have a character in their playable lists.
@@ -465,3 +465,64 @@ def func(self): | |||
utils.get_evennia_version(), | |||
) | |||
) | |||
|
|||
|
|||
def _create_account(session, accountname, password, permissions, typeclass=None, email=None): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This entire modification seems out of place in this PR? Besides, this looks like a duplication of the Account.create
code ...
evennia/server/serversession.py
Outdated
if hasattr(text, "__rich_console__"): | ||
text = self.print(text) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This again doesn't belong here - Rich was stripped out...
evennia/server/serversession.py
Outdated
if (t := kwargs.get("text", None)): | ||
if hasattr(t, "__rich_console__"): | ||
kwargs["text"] = self.print(t) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does not belong with this PR ...
return new_account | ||
|
||
|
||
def _create_character(session, new_account, typeclass, home, permissions): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks like it's doing what Account.create_character
does with some more reporting ...
Let's do this! |
@volundmush Is this ready to re-review? |
@volundmush This and other older PRs need rebasing since we did a cleanup of the repo lately (reducing its size). Sorry about that. |
… Account.add_character(char) and Account.remove_character(char). Account.characters already handles all filtering so am cleaning up lots of repeated list comprehensions which remove/filter deleted characters.
…e characters to use it.
338d751
to
2bf96f7
Compare
Rebase applied. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the cleanup. I think this looks fine now.
Brief overview of PR changes/additions
Removing direct access to Account.db._playable_characters in favor of Account.add_character(char) and Account.remove_character(char). Account.characters already handles all filtering so am cleaning up lots of repeated list comprehensions which remove/filter deleted characters.
Motivation for adding to Evennia
There's a lot of old code which should probably be cleaned up, and managing which characters are bound to an account is logic that should not be duplicated all over the place in every command. now we have a simple method-based API to handle that task.
Other info (issues closed, discussion etc)
I am unsure if I should modify the tests to use the API. many of them directly access .db._playable_characters. I'm sure SOME could be changed...