@faraday It turns out not to be too terribly difficult, at least at the level I'm working at right now. There's certainly more advanced Docker stuff that will probably result in images that are more secure and which do things 'properly' but for now what I'm doing seems to work.
What I did was I created a Docker instance for Ubuntu (I actually tried some more minimal setups at first but went back to Ubuntu because of some of the tools I wanted). Once you spin that up you can log into it using a command similar to docker exec -i -t mocker_game_1 /bin/bash (mocker_game_1 is the name of the Docker instance I'm running and /bin/bash gives me a shell inside of it).
From there I basically figured out all the steps that I would have to run to setup a new tinyMux server (downloading build tools, configuring, compiling, etc.). You then create a Dockerfile (not to be confused with docker-compose.yml) that repeats those instructions. You run a new command along the lines of docker build -ttinymux:2.10-U ~/Docker/mocker/release/ which tells Docker to build a new image called tinymux:2.10-U using the Dockerfile found in ~/Docker/mocker/release/.
That's sort of the 'elevator pitch' version of it, anyway. It does get a little tricky since the commands in the file can't pause for input and you need to work in stuff so that when you run things for the very first time data gets moved around so it is accessible from outside docker (for persistence and so you can back it up) but if you're already capable of compiling a game on a new machine you can probably handle those extra issues.
Like I said, I will provide more complete details about everything I was doing so that you can build your own Arcker (or whatever you'd like to call it) image. I just want to wait a day or two in case someone says 'oh, Holy Hell, the way you've done this will lead to the eventual extinction of life on Earth. Don't do it that way' or something similar before I write out the more detailed account. This is just to show you that it is probably not hard at all (having never spun up a copy of Ares I don't want to absolutely promise it will be easy since there might be some gotcha I don't know about) for you to build your own image.
@melpomene This is awesome. Plushelp if it's of any use:
Messaging is vital to roleplay, whether through text, phone, or IM. Messages
are sent whether or not the recipient is online. When they next log in, they
will see an alert notifying them that they have messages in their queue.
Syntax: msg <player>=<text> - Send a message to the specified player.
msg/<type> <player>=<text> - Send <type> message, for example, phone.
msg <text> - Send a message with the same settings as the last one.
&msg-send-ra me=%%cw%%cR%%[RED ALERT%%]%%xn - Example of custom colorcoding.
msg/off - Turn off messages, putting up to 50 into your queue.
msg/on - Turns messages back on and displays message queue.
msg/block <name>[=<reason>] - Openly block target from sending messages.
msg/unblock <name> - Unblock a person who was blocked.
msg/hide <name> - Secretly blocks target from messaging, queue disabled.
msg/unhide <name> - Removes a secret/quiet block from the target.
msg/view - Display any queued messages.
msg/summary - View a summary of your message status.
After a message is sent, the system remembers the last person (or group of
people) you messaged, and the last type of message you sent.
Messages display special behaviors when they start with :, ;, or |.
:tests <-- Gallifrey tests
;'s test <-- Gallifrey's test
|A test happens. <-- A test happens.
Testing! <-- Gallifrey says, "Testing!"
Custom colorcoding can be set with variables on your character object. Using the
example under the syntax list, anyone who receives a message from you with the
'ra' switch (msg/ra <player>=<message>) will see a bright RED ALERT tag.
Messages System by Melpomene@MUSoapbox.
While testing I noticed that the built-in switches don't seem to work. For example, MSG/VIEW seems to think I'm trying to send a custom messaging type rather than checking the message queue:
@Melpomene, I can't really extend it because I know about as much about code as a llama knows about pasteurization. But it's good that you're opening it up for other coders to expand upon. It's a good idea.
Maybe I'm crazy. I probably am. (Okay, definitely.) But I'm curious.. how difficult would it be to configure the list of displayed jobs (i.e. when you type +jobs) to include the name of the submitting player as well as bucket, job name, due date, assigned, status?
(Ssssh, I'm not supposed to post.)
But this is actually already a function. You just change your &jobs me=<stuff>. For example: &jobs me=BOTD will give you bucket, opened by, title, and date. &jobs me=BOTDS gives bucket, opened by, title, date, status.