Best posts made by Tehom

@Tinuviel said in Coming Soon: Arx, After the Reckoning:

@Tehom Fix chest locks.

/wrists

@griatch said in Make Evennia 'more accessibility' - ideas?:

I'll move this here so as to avoid derailing @Cobaltasaurus' thread

There, among others, @Thenomain said this:

I'd rather give the money to the Evennia team to get someone on board to make the system more accessible to learn, even if that person is Tehom. I'm ready to tear Evennia apart but I'm still very nervous at all the layers I don't understand to start getting into the layers that I do.

The getting someone on board to make make the system more accessible to learn makes me curious, because it suggests there are obvious things for that person to do. Never mind the pay, I'd be interested in what kind of features you would be looking for in order to have an easier time getting into Evennia - in short, what would you have that hypothetical person do?

I am as usual honestly interested in constructive feedback; it's always good to get pointers from non-users of the library to help influence future development.
.
Griatch

I think the two major pain points are not having some common features out of the box that people need to implement themselves, like bulletin boards, and the difficulty in installation/configuration. While I think the 'getting started' guide is great, it's still not a trivial matter for people who are new to python or otherwise uncomfortable with setting up an environment. I don't know if there's really any easy solutions to the latter, aside from far-off-in-the-future solutions like having an installer on windows that'd prompt them for configuration choices and handle most things for them. It'd probably make the most sense to get a checklist of features that MUSH players would want supported out of the box, and add them as contribs or even to core as example commands.

Maybe some of the existing tutorials could then focus on common use-cases of extending the existing contribs to add functionality that we don't necessarily want in an unopinionated framework but would be commonly requested.

There's a Node codebase called RanvierMUD, but the impression I got from it is that it doesn't use an ORM or database at all, but json flatfiles for storage. I much prefer using django's ORM, but maybe it'd be easier for you to convert Ranvier into using a database with your Node background, I wouldn't know. Evennia is my chosen favorite, though AresMUSH is great too.

@Thenomain said in Coming Soon: Arx, After the Reckoning:

@Sunny

That would make sense. I'm not going to make a technical comment about it. I know of one simple workaround for that using Evennia, but I also know what it's like for someone to come in, look at your code, and say, "Why didn't you do this differently from the start?" Sometimes the answer is, "Because I didn't, and if you keep on going about it I'm going to take this code and shove it somewhere that you'd regret."

Make fun of neckbeards if you'd like, but they are some of the most chill people on the planet. Not all of us coders are Big Bang Theory tropes. (n.b., I am not a neckbeard. I'm a skinny neurotic beta nerd, thank you.)

I could easily see alternate implementations that don't use email at all, but create a throw-away player account that restricts their permissions (and that of the associated character they create) during character creation and while waiting for approval, then grants it to them post-approval. It might be cleaner overall, honestly, but I don't feel redoing the entire process at this point would be a good use of my time.

Evennia doesn't have any use of email built-in, but django does, which is what the user/player account model for Evennia is built upon, so extending it to send emails out is fairly trivial (it's something I should probably revisit at some point to use twisted's email package rather than django's for better error handling, but whatever). Additionally, most django packages you can add have some expectation of email being used (like a helpdesk package that I grabbed and turned into our +request/@job system), and while I wasn't using those features, I could imagine a time where we might wish to. For example, by default the helpdesk would have sent out emails to anyone with a response of some boilerplate for any ticket that was answered, and I had to rework that since I thought it would startle people.

That said, email was never really meant to be a hard requirement, because I could foresee people who would be uncomfortable giving it out, it just seemed to make the whole process a lot smoother. Given the ease of getting temporary email addresses that exist specifically for the purpose of people registering for things, or being able to get a new dedicated email address that's a throw-away/spam-absorbing thing, I didn't think it'd be a show-stopper for anyone, but as I said, I would be willing to manually go through the approval process for someone who was uncomfortable using those things.

That was great. And now we know the dark secret of where the name 'Evennia' comes from.

@sparks said in Make Evennia 'more accessible' - ideas?:

Okay, here's a question. Instead of trying to write a really verbose tutorial like the half-done one I linked before, would it be easier for folks if there was just a really basic Evennia-in-a-box that provided some nice basic systems, like a bboard system, a mail system, and so on? (If the systems were really well commented in the source code, I mean. Commented on the level of that last code listing in the tutorial.)

Because writing the tutorial is slow and kind of painful as I try to think what I need to explain, while just writing the code would be much faster.

I personally feel that'd be the way to go. I think learning coding as you go via modifying existing features is much less intimidating than trying to implement them yourself, and tutorials would probably feel less daunting if they're more along the lines of 'Add a character's signature to their mail' than 'Create a simple version of a mail command'.

@sparks said in Make Evennia 'more accessible' - ideas?:

• It's not recommended to use filter (nor map) in modern Python code. These can always be written using a list comprehension, without any lambdas:

I admit this one was a conscious choice to go against the grain. I chose to use a lambda there because I'd already explained lambdas in the sorted example, and I didn't really want to write a section on list comprehension too, since I worried about confusing people with too many concepts in short order.

You're probably correct, though, that it makes more sense to just bite the bullet and add the explanation, since it is the better way to do it.

My personal feeling is that in example code, it'd be better to create small helper functions and avoid lambda entirely. In my experience, lambda in particular is pretty scary to non-coders. It's not very intuitive to a lot of people without a math background to see something that's literally Greek to them and immediately go, "Aha! Like a math function!" Meanwhile, we use regular functions/methods everywhere, so making some nested helper function or a global function that a command refers to is kind of a helpful example of their use. Turning the definition of lambdas into more emphasis of how functions are first-order objects and can be themselves passed to functions like sorted() might be more useful to people too. I know you did explain it in your example, I just think that particular bit might be more intimidating to a total newcomer than it looks.