AresMUSH Updates

RnMissionRun

@rnmissionrun said in AresMUSH Updates:

I think I got as far as the "Coding for Ares" page, saw that it didn't really tell me anything, and stopped reading.

Hmm... was this awhile ago? Because yes, during the alpha stages the installation scripts had various issues and the tutorials were virtually non-existent. I wouldn't be surprised if someone got frustrated trying to figure it out - but it wasn't really ready for public consumption yet.

Since then, though, I've polished up the install scripts to be as hands-free as possible and spent considerable time trying to make the documentation as robust as I could as @tat and @krmbm mentioned (thanks!) It doesn't just cover Ruby but goes into the various components of the Ares code. It has two step-by-step tutorials (Quickstart and Creating a Plugin) that give an overview of how to use the basic building blocks. If you saw all that and still feel that it "doesn't really tell me anything" then please feel free to submit ideas for what sort of tutorials you would like to see.

It was the date of my last post in this thread prior to today, so Dec 7th.

faraday

@rnmissionrun said in AresMUSH Updates:

It was the date of my last post in this thread prior to today, so Dec 7th.

Ah, yeah, I should've thought to check the backscroll. The install scripts were still a work-in-progress then, and as I mentioned at the time my primary focus was on documentation...

@faraday said in AresMUSH Updates:

So, y'know, people who are not me will actually know how to use it.

Anyway, if you prefer waiting until the 1.0 release that's groovy. I'm not generally a fan of being a beta-tester myself with most things, so I don't hold that against anyone!

My only point was that things are in a much better state now than they were a few months ago. And if anyone is still having issues either installing it or figuring out which end is up, I'd love to know about it so I can make it better.

faraday

@ixokai - I wrapped up my earlier response into a Replacing FS3 tutorial in the coding section. Hope that helps.

Griatch

Good work with getting Ares into shape. I'd not be too fixated on the "1.0" version number though. Just be clear on what level of stability you think your system is and communicate that so people know what to expect.
.
Griatch

faraday

@griatch said in AresMUSH Updates:

I'd not be too fixated on the "1.0" version number though.

Thanks. While I agree that the stability is more important than the actual number, I do think that in the software world numbers have meaning. People generally have certain expectations from 1.0 no matter what you say (ETA: I meant no matter what the software publisher says.. not you specifically!) Then again, there are always exceptions - how long was Gmail in "beta"? Is it still? Heh.

Thenomain

@griatch

I think she should give it names instead. Might I suggest each major release is a different sci-fi show, and each point release something from that show.

And then not use numerical releases at all, except for a lingering build code.

... Tho I want to see the resulting bug reports.

Griatch

@thenomain said in AresMUSH Updates:

@griatch

I think she should give it names instead. Might I suggest each major release is a different sci-fi show, and each point release something from that show.

And then not use numerical releases at all, except for a lingering build code.

... Tho I want to see the resulting bug reports.

Many Linux distros does this for some strange reason (they have a number too, but the name is usually what the advertise). I never understood the benefit: When debugging an issue or reading up on some feature I always have to go and double-check in some release list somewhere to find out if my version is older or newer than the one mentioned on Stack Overflow. A number is certainly easier on the user's sanity ...

... That said, It might be worth it just for the sake of being able to look forward to the Firefly release with the Mal minor version and the River bug fix ...

Tinuviel

@griatch Most software have codenames that they go by, for various reasons, and it's easier to advertise Android Kitkat than Android 6.01.20199.

Griatch

@tinuviel said in AresMUSH Updates:

@griatch Most software have codenames that they go by, for various reasons, and it's easier to advertise Android Kitkat than Android 6.01.20199.

I see the reason but I'd still prefer it being referred to as Android 6 so I directly know it came after Android 5. Now in the case of Android code names they are actually increasing alphabetically. But if I didn't know that (and I didn't until I just looked it up) there is no telling where in the order "Kitkat" is related to "Lollipop". I just find it silly, I guess. Except for the Firefly bit, that is.
.
Griatch

Tinuviel

@griatch Oh yeah, don't get me wrong. It's stupid-pants. But it is what it is. The number of times I've had to shout at people "I don't care what they call it. What's the goddamn patch number?"

ixokai

@faraday said in AresMUSH Updates:

@ixokai - I wrapped up my earlier response into a Replacing FS3 tutorial in the coding section. Hope that helps.

I did see this stuff, but like, your example other-system is a traits thing, and that's not really useful. When I suggested a blog post for a simple skill/stat/rpg system I mean like, a basic FUDGE system maybe, or even just a pretendy funtime system you make up on the spot.

Like, if I was making a WOD game, there's attributes, which are str/dex/con/etc, there's skills, there's merits, there's some other points. I get from your example how I can store the eventual values by extending the Character class (I assume ruby calls it something besides extending since it seems Ruby's classes are open), but I'm not sure how to approach making a database of available merits, for example. Or skills, for that matter: should they be hardcoded in a plugin? My instinct says not. Looking over the fs3skills plugin, I find things like:

https://github.com/AresMUSH/aresmush/blob/master/plugins/fs3skills/public/fs3_action_skill.rb

which seem to support my instinct, it looks like you have a data model for action skills. But for the life of me I can't find where they're defined to mimic such a setup for a different RPG entirely.

faraday

@ixokai said in AresMUSH Updates:

which seem to support my instinct, it looks like you have a data model for action skills. But for the life of me I can't find where they're defined to mimic such a setup for a different RPG entirely.

Okay, I can add a few more details about that. But basically - you can do it however you want.

A data model makes it easier if your abilities have their own properties (like FS3 has ruling attribute, rating, XP spent, last learned, etc.) but not every system needs that level of complexity. You can store everything in a simple hash, just like the traits example.

Similarly, FS3 is designed to be configurable without touching the code, so the list of abilities are stored in config files - config_fs3skills_action.yml and so forth. But for a system you're designing for your own game, there's probably no need to do that. A simple Ruby array in the code could suffice.

I really don't think there is such a thing as a "simple" RPG skill/stat/RPG system, which is why I don't feel that a concrete example is going to help anyone. They'd all be as complex as FS3 - and you've already got an example coded for that.

ixokai

@faraday Whyyy is this setup script installing emacs? Installing it ended up pulling in X11 and allll kinds of stuff I don't want on a server >.>

Also, I got this error on install:

<INSTALL> Give ares user access to www and redis directory
chgrp: cannot access '/var/lib/redis/dump.rdb': No such file or directory
chmod: cannot access '/var/lib/redis/dump.rdb': No such file or directory

Redis seemed to install without error, is it possible the script needs to start redis?

-- And I just realized this is a better discussion on AresMUSH's forums. Ahem.

faraday

@ixokai I didn't realize emacs installed all that junk - I just hate vi and had it installed as a convenience. I can remove it. We'll hash out the redis thing on the Ares forum.

Auspice

One piece of feedback I have (working with someone on installing Ares on a non-Ubuntu server; he has root, so tagteaming it)...

I know updating scripts to make it a more clean/easy process on other servers may be much further down the road, but something more short-term, possibly:

The script assumes your username will be ares. Which is fine if you're setting it up on a Droplet/your own server. But if you manage a server for people (some of us do!), that's not always going to be the case. It definitely won't if those of us who help with hosting begin setting up Ares installs for others.

Can the script be altered, perhaps, to input the username of the account that will be used for the day-to-day operations?

faraday

@auspice Thanks for the feedback.

The automatic scripts are for a super-easy install when you're using a standalone Ubuntu VPS (Digital Ocean, Linode, or whatever). That is the standard, supported configuration for Ares.

If you're going outside of that configuration, I assume that you (or a buddy) already has some server-admin experience and can follow along the comments in the scripts to make whatever necessary adjustments make sense for your environment.

Your specific use-case was pretty simple (supplying a different username), but there are a million other possible subtle variations like that (changing usernames, directories, apache instead of nginx, yum instead of apt-get, etc. etc.) and it really isn't practical for me to make an installer flexible enough to support them all.

I've toyed with the idea of creating a text version of the script (like "install X then Y" in generic terms), but honestly I think the commands with comments would be more useful to server admins than plain text that's liable to get out of date. If the prevailing sentiment says otherwise, though, I can certainly create that.

Auspice

@faraday

We were able to modify most of it without trouble, but that was the big piece of feedback he passed along to me: the username. Everything else, totally understandable (altering scripts, making adjustments). Most of it makes sense, such as ports, et al.

But the default username was one of the bigger ones we realized might be a trip because of how early it comes up in the setup.

faraday

@auspice Maybe I'm just being dense and not understanding where the hangup is...

The script does stuff like:

echo -e "${ARES_INSTALL_TEXT} Create an ares user"
adduser --disabled-password --gecos "" ares

I assumed that as you walked through the script to see what needed to be installed for a custom environment, you'd just remove/change those bits, just as you would for any other custom server environment quirk.

Is it just because the /home/ares path shows up in a couple of places? If that's the issue then I could probably make that a variable in the shell script so you only have to change it in a single place, at least.

What I really don't want to do, though, is add all kinds of "Do you want to do this? What username do you want?" type of if/else questions to the super-simple automatic installer, because that kinda goes away from the goal of making it super-simple A system admin is going to know the answers to those questions easily enough, but Ares is intended to be installable by folks without admin experience. Extra questions make the installation more intimidating.

Auspice

@faraday said in AresMUSH Updates:

@auspice Maybe I'm just being dense and not understanding where the hangup is...

The script does stuff like:

echo -e "${ARES_INSTALL_TEXT} Create an ares user"
adduser --disabled-password --gecos "" ares

I assumed that as you walked through the script to see what needed to be installed for a custom environment, you'd just remove/change those bits, just as you would for any other custom server environment quirk.

Is it just because the /home/ares path shows up in a couple of places? If that's the issue then I could probably make that a variable in the shell script so you only have to change it in a single place, at least.

What I really don't want to do, though, is add all kinds of "Do you want to do this? What username do you want?" type of if/else questions to the super-simple automatic installer, because that kinda goes away from the goal of making it super-simple A system admin is going to know the answers to those questions easily enough, but Ares is intended to be installable by folks without admin experience. Extra questions make the installation more intimidating.

Oh, for sure. The username was really the kicker. I think if it was a single variable, that'd make a big difference. Like I said, that was the big one.

faraday

@auspice said in AresMUSH Updates:

those of us who help with hosting begin setting up Ares installs for others.

Random side note. The standard server setup script installs a single redis database instance as a global system service. If you're going to be running multiple ares installs on a single server with different usernames, each user will need their own redis instance. This article may help.