Experiences with AresMUSH installs

Firstly, thanks are owed to @Faraday for all the hard work on what I think could be a very needed update to how we all MUSH. I’ve been wanting to take the plunge on AresMUSH for some time and I’ve liked what I have seen so far. I wanted to make a post with a mixture of questions and observations.

I set up two servers just to go through the install process: once on a fresh new digitalocean droplet as specified in the documentation, and once on my regular server which has a few other other MUSHes, a website, some MediaWikis, etc. on it already, just to see how it plays on a server that has had me messing around on it for 2+ years.

My main question so far is that I’m curious about any future plans for the hosting of multiple AresMUSH games on a single server. Hoping for this functionality down the line, as the current infrastructure appears to hardcode specific install/deploy locations for the game and web portal files, meaning you can only install one ‘out of the box’ (so far as I can tell, at least).

Related, the install also currently assumes you’re not already running an unrelated website in the /var/www/html location. Since I was, I needed to dig into the installation and /home/ares/ares-webportal/bin/deploy scripts in order to change those locations to (in my case) /var/www/aresmush/html. I am not sure if there a better way I haven’t found.

A more minor thing: when the install is asking for such things as database location, default ports, etc., I just hit enter at each prompt without inputting anything in the assumption that ‘writing nothing’ would automatically use the defaults. These first few attempts to install didn’t work, which might have been for unrelated reasons, but I started actually manually entering ‘4202,’ ‘4303,’ etc. at the prompts jut to be safe. I’m still not sure whether they can be left blank if you just want to use the defaults. That was one of the main ambiguities I remember along the way.

Otherwise, both installs went pretty well, though on the clean server I did find myself having to run the setup_server script twice due to some issues with Redis not installing properly on the first go-around. I really should have saved the output; if I see it again I will capture it.

I tested playing and logging a scene, which leads to I think my last question for this post: I really liked the formatting of the log while it was an ‘active log’ (where each pose was clearly delineated from the next, and labeled with the poser’s name and avatar) and assumed this format would carry over when the scene was ‘published.’ Once published, however, all the avatars and name labels were removed and the log became a continuous page of text. Would it be possible to just keep that ‘active scene’ format for finished scenes?

Again, however, I like what I have seen so far in terms of ease of use. I’m trying to encourage some friends to use one of my AresMUSH installations for an upcoming small sandbox in order to see how it plays in practice.

1 Like

Thanks for the feedback.

The automated installation scripts are designed for the simplest case - a single MU on a stand-alone server with nothing else running. If you want to install it on some other environment, that presumes some server admin experience and I figured somebody could look at the installation scripts, as you did, and adjust the installs accordingly.

It is theoretically possible to run multiple games on a single server, but I haven’t really explored that at this point. From the preliminary research I did, it would require multiple redis instances for separate databases. There are some articles on the 'net about how to do that, like this one.

The configuration script does choose the listed default if you just hit enter. I’ll see if there’s a way to make that more clear.

The overwhelming feedback from the early beta testers was that they preferred the continuous log view once the scene was finished. This also proved far more practical when editing of a log after it’s been shared. (Otherwise you’d have to edit individual poses, which was highly annoying.) So that’s why the scene converts over to the continuous format after the scene is shared.

Thanks for the quick reply. I forget that the most base intention for AresMUSH is to be accessible to a new user with no experience with servers, which makes the idea of installing into non-default locations or into existing server/website infrastructures a little less relevant.

About the most I could see such a user trying is putting another AresMUSH onto their server when they want to run another game, though these days new droplets are pretty inexpensive to spin up. I might look into the multiple redis instances thing myself.

I also see what you mean about the log format in terms of post-publishing edits. I’ll have to mess more with the editing function myself to see how it all works, and if I can introduce some kind of pose separator on my own via adjusting the code.

1 Like

Your easiest bet there would be to modify the code that merges all the poses together into the continuous format. It already throws <div>'s in there for combat output and system output. Would be easy enough to add a custom div around everything and then style it. It becomes more difficult to edit logs then, if you need to remove double-poses, fix typos, etc.

That code is here.

Thanks for pointing out the code in question! It may be something I decide whether or not to look into on my own in the future, when I understand more about how log editing works and the challenges there.

9 posts were split to a new topic: Installing on Linode

What actually wound up working for what I was trying to achieve, was moving one line of code in the helpers.rb file that was linked.

I took log << "\n<hr class=\"pose-divider\"/>\n" from line 196, and moved it up under log << "\n\n" on line 190.

This had the effect of inserting a horizontal rule after each pose, as a separator.

So far it doesn’t seem to impact my ease of editing the shared scene on the webportal. In fact it is easier for me to tell where multi-paragraph poses end and begin.

If this change has implications for editing a scene and its poses while the scene is still active, I am not sure yet! A cursory test indicates not, but will experiment further.

Thanks for your help!

1 Like

So, ironically… it looks like I had actually intended that to be up after line 188 all along. It serves no useful purpose where it’s at now.

I would suggest line 188 instead of 190 because you don’t really need an extra hr under the system and setpose emits. They already have their on divs you can style.

I’m torn whether to do this in the core release because I think people who edit the log will either be confused by all the extra hr’s or possibly move poses around and forget them. I’ll decide in the next patch whether to remove the default pose divider, move it, or perhaps make it a configuration option.

Yeah, after a read of the code it looked like the rule was being placed at the very end, after the loop to insert poses finished in its entirety. I moved it back into the loop – thanks for the tip on where exactly to move it. I’ll try the divider at 188 too, and see where I like it and how it looks with the setpose and system emits.

I’m a bit biased towards the route of making it a configuration option myself, with no hrs being the default so the average user doesn’t panic on seeing code in the edit box, but however you choose to do it, I know how to tweak it on my end now!

1 Like

I installed fresh today (a tinker/test) site, and ran into an error (that repeated with three attempts).

My setup is on Digital Ocean:

1 GB Memory / 25 GB Disk / SFO2 - Ubuntu 16.04.5 x64

As I’m installing, I see a few errors fly by:

An error occurred while installing sassc (2.0.0), and Bundler cannot continue.
Make sure that gem install sassc -v '2.0.0' succeeds before bundling.
Could not find aws-sdk-s3-1.8.2 in any of the sources

Could not find aws-sdk-s3-1.8.2 in any of the sources

An error occurred while installing sassc (2.0.0), and Bundler cannot continue.
Make sure that gem install sassc -v '2.0.0' succeeds before bundling.

AresMUSH failed to start. Check the highest-numbered log in game/logs for more information.

The errors.txt log says:

/usr/lib/ruby/vendor_ruby/bundler/spec_set.rb:94:in `block in materialize': Could not find aws-sdk-s3-1.8.2 in any of the sources (Bundler::GemNotFound)
	from /usr/lib/ruby/vendor_ruby/bundler/spec_set.rb:87:in `map!'
	from /usr/lib/ruby/vendor_ruby/bundler/spec_set.rb:87:in `materialize'
	from /usr/lib/ruby/vendor_ruby/bundler/definition.rb:137:in `specs'
	from /usr/lib/ruby/vendor_ruby/bundler/definition.rb:182:in `specs_for'
	from /usr/lib/ruby/vendor_ruby/bundler/definition.rb:171:in `requested_specs'
	from /usr/lib/ruby/vendor_ruby/bundler/environment.rb:18:in `requested_specs'
	from /usr/lib/ruby/vendor_ruby/bundler/runtime.rb:13:in `setup'
	from /usr/lib/ruby/vendor_ruby/bundler.rb:92:in `setup'
	from /usr/lib/ruby/vendor_ruby/bundler/setup.rb:18:in `<top (required)>'
	from /usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require'
	from /usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require'

Is this a me-problem?

It looks like RVM (Ruby version manager, which is how the installer gets its Ruby installed) changed its installation instructions. This caused errors in the installer. It must have happened in the past few days since I just did an install for someone earlier this week.

I changed the install script to match their new instructions. If you try it again it should work now.

1 Like

That worked. Thank you kindly! :slight_smile:

1 Like