Posts made by Tehom

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

@too-old-for-this said in MU Things I Love:

@sparks Shardhavens are too fun!

Pax's system is basically my favorite thing ever. I know just seeing the different things staff have come up with has completely delighted me, and I can't wait to see more people bump into them.

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.

@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.

@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'.

@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.

I really apologize for coming across as just telling you to try harder - that wasn't what I intended at all. What I meant is that if the code is too intimidating, I'm happy to help you take out whatever features you like and change/adapt it for your game. That sort of taking things out and repurposing them is how I learned, though it's fair to say that the approach doesn't work for everyone. I'm happy to go over code that's confusing (and most of my code isn't clearly written and definitely poorly documented, unlike Evennia) and explain things, or suggest ways to implement features you like.

If using Arx wholesale and changing things is easier for you, I'd be happy to help with that too. I've talked to other people on Discord a lot with some of the setup problems and stuff, I really don't mind.

I just want to echo Griatch and Faraday here - taking stuff apart and playing with it is probably the best way to learn. I'm more than happy to talk about how to adapt any particular feature from Arx, too.

I tested on a new installation after sorting some stuff out (for some reason the version of Twisted I was using previously no longer worked, no idea why), and it does create Limbo and a character as expected with the server initial startup script. It doesn't create some of the one-to-one related models that are extensions of Account/Character, and I'll see about doing something to make that easier when I have time. I'll add something to the wikia page in the meantime, I think.

Yeah, since this was an already working copy, it already had a logs directory. It looks like something went wrong in my virtual environment, so I'll tear everything down and remake it later to test.

Hmm, I'm running into a weird issue. Trying to start the server with a new database after running migrate returns two lines of The system cannot find the path specified. Since the only thing different is that it's a fresh db, I'm not sure what that's about.

@golgoth said in Arx on github:

@tehom Raymond Hettinger said to me and nine other people at a Panda Express: "PEP 8 is a standard you enforce on yourself, not others."

'Python's super() considered super!' won't save you when the angry mobs come, Raymond.

@sparks said in Arx on github:

@tehom said in Arx on github:

@wyrdathru said in Arx on github:

Now, what about tabs or spaces, camelCasing or PascalCasing, Li-nux or Lin-ux and more!

LET THE BLOODSPORTS BEGIN

Guido might have retired, but that hasn't stopped the violent gangs of devotees who lynch developers for flagrant violations of PEP8. Not a day goes by that you can't find a new victim's mangled body with a sign on them saying 'USED CAMELCASE FOR VARIABLES' or the like. I might disapprove of their methods, but I agree with them in principle.

Even PyCharm itself will yell at you for PEP8 violations!

I am confident that this is the only reason I am still alive.

@wyrdathru said in Arx on github:

Now, what about tabs or spaces, camelCasing or PascalCasing, Li-nux or Lin-ux and more!

LET THE BLOODSPORTS BEGIN

Guido might have retired, but that hasn't stopped the violent gangs of devotees who lynch developers for flagrant violations of PEP8. Not a day goes by that you can't find a new victim's mangled body with a sign on them saying 'USED CAMELCASE FOR VARIABLES' or the like. I might disapprove of their methods, but I agree with them in principle.

I am willing to die on the hill of toopul.

@apos said in Arx on github:

I'd just go through the code and identify, 'this is stuff I'd replace' and consider commenting it out, so you don't get to a spot where you are trying to create complex data migrations due to things being stored in the database using existing stuff you think doesn't fit your game. Otherwise, why not? Learning how to change a lot of the stuff to work in a way you want might be one of the best ways to learn Python, as you get practical experience in fixing things.

To add to that, django is designed to sort of have a plugin architecture like that. the INSTALLED_APPS tuple in settings are meant to be distinct packages that you can remove if you don't want to have them - commenting them out means that they'll no longer be detected for migrations or anything else. Some of the apps do use one another as dependencies though, I didn't do a good job in making them self-sufficient.

For commands, removing them is really straightforward. They're added to "command sets" which are either in commands/default_cmdsets, or from the cmdsets directory, usually commands/cmdsets/standard.py. If you don't want a particular command added, you'd just comment out where it's added to the cmdset.

@cobaltasaurus said in Arx on github:

It’s really tempting to grab this and run (as it is I have some stuff I do want to take I just haven’t had a chance to install more than basic code), but I’ve been a little bit worried about seeming to be an “Arx clone” if we went with the same diceroller / system stuff even with changes we’d need to make for our particular thematics.

Personally I don't think you should be that worried about it. You'd probably wind up changing enough that it'd be really hard to tell if you were using code from elsewhere, and the important intellectual property that makes a game distinct will always be in the database, not the code.

I think it depends. If absolutely no one seems to be intrigued by something you thought was cool, then it might just be something that needs to be retooled. But evaluating that can be difficult - people might be more interested than they appear, especially if there's a few louder voices who kind of drown them out. A difficult thing, though, is to try to keep people who don't really care about a particular plot from ruining the fun of people who do want to buy-in to that without being draconian about it

On Arx, we tend to be pretty strict about enforcing theme because it's important both to staff and a lot of players. A player might not really buy into one of the themes, and that's totally okay, but what's not okay is them pretending it doesn't exist and wrecking things for people who enjoy it. Unfortunately, policing that sort of thing is very time-consuming and difficult: unless you have players willing to call stuff out themselves it's probably a losing battle.

Thanks for writing the excellent guide, Griatch! I went with python-decouple for secret settings configuration after reading some horror stories about how difficult debugging can be when using private/secret settings files outside source control that wind up having executable code in them via imports or the like. That should almost never happen with normal use and removing it makes setup a lot easier on people, so I agree with the removal.

@icanbeyourmuse said in Arx on github:

Would it be hard for an Evennia dumb person to install?

It might be a little tricky, since you have to get Evennia installed, and that assumes that you're creating a game from scratch. Instead of the stuff Evennia creates for you, you'd have to replace it all with that repo, and then do additional configuration steps of creating a settings.ini file outside source control. In general, I feel it'd probably be easier for someone to create their own game from scratch and then just grab whatever they like from the repo and use it, but YMMV.