Mercutio @ M*U*S*H

I’ve got a small project in the works that may or may not take root in the same way that SceneSys did. The idea is a Graph-Based SQL database backend for PennMUSH storage. This means that instead of storing everything on a character, or your BBoard on boards, or your helpfiles on objects, you’ll be storing it in a Graph-format on SQL. 

Problem is of course, SQL hardly supports Graph-based things on a large scale. But datasets in PennMUSH are rarely that sizable. I’d loved to have used OQGraph, but it’s simply too unreliable. It loves to crash the SQL server. 

So instead I’ve gone over to the far less capable Stored Procedures... and so far, this is what I’ve worked up with a _great_ deal of help from http://www.artfulsoftware.com/ - to the point that I’m basically copying their stuff, and then enhancing it for my needs:

http://pastebin.com/BVgxMzkH http://pastebin.com/JMFBdZDa

I already have a Proof of Concept working on my TestMUSH: (Currently: telnet://twilightdays.org:7705)

This semester has been tough and busy, but it's not stopped me from starting a new project on the side - mostly for myself to learn to code a more complex project.

Having been introduced to C# last semester, I've begun work on a C# based MU* code-base, trying to stick close to something like PennMUSH, RhostMUSH and TinyMUX, while also adding new features; protocol-specific representation and that lot.

It's been interesting so far, and a proper learning experience. Currently, I'm working on creating a way to do a Markup representation of strings, and I've just finished a _very_ rudimentary dynamic-string parser.

| MAIN PAGE | THEME | RULES | APPLY | CHARACTERS | CONNECT | LOGS |

Final Kingdom is a year old Kingdom Hearts MUSH which further integrates and emphasizes the worlds and themes of both Final Fantasy and Disney alike. We invite you to visit us and become part of our community.

Here is a guide on how to install SceneSys:

* GitHub page: here.

Choose if you want constant updates or not. If you do, log onto M*U*S*H at mush.pennmush.org:4201 and ask for Walker to connect the SVC bot to your MUSH (Recommended). If not, look through this list for the most recent version. If you need any help with any of these steps, contact me at M*U*S*H or on Final Kingdom MUSH.

Make sure you have the following items installed on your system: MySQL, PHP5, Apache2, PHPmyadmin.

On PHPmyadmin, use the root/admin user to create a new database, OR, use one of your old databases. Now use the SQL tab and paste in what is found on the GitHub site.

Go into your pennmush/game folder, and replace the existing text in the GETDATE.TEMPLATE file with the information found on the GitHub site.

If using the SVC bot, use the following commands that follow underneath at step 6. If not, use the installer and skip to step 7. 

Ensure that you do these one at a time, until the commands seem to indicate they are 'done'.

+svc create SVC SceneSys=Mercutio_SceneSys NULL +svc checkout +svc client SVC SceneSys

@tel first(get(SVC SceneSys/LOCAL`OBJMAP),:)=config(master_room) th ansi(hr,SceneSys object is DBref [first(get(SVC SceneSys/LOCAL`OBJMAP),:)])!

Look at the attributes found in DATA`SQL`DATABASE and the leaves under DATA`SQL`TABLE in case you changed database settings from the standard.

Using Myrddin's BBoard system, create a new board for the Scheduler to post to. +bbnewgroup Scene Announcements

Edit the DATA`SCHEDULEBOARD attribute to the 'number' of the Schedule Board (alternatively, set it to its name), and edit DATA`SCHEDULEBOARD_DB to give it the DBref that was made for the schedule board. (@find Scene Announcements)

Ensure you have an isic() function, or otherwise edit the FN`IS`IC function for it. The system should only be recording when someone is IC!

Ensure you have a ancestor_player set (@config ancestor_player)

@trig Scene System/DATA`INSTALL`ANCESTOR

Assuming you don't mind us changing the way your @emit, SAY, POSE and SEMIPOSE work, go to the next step. If you don't want this, you're most likely going to need to get some help from me personally on how to set up your game.  

@trigger Scene System/startup. 

PHP files are here: the wiki page is set up specifically for a type of Form for SymanticMediawiki. If you want help with this, contact me, or wait for a later Tutorial. You want to change the db.php file with your own information. It is highly recommended you use a seperate user for this, which is only able to 'select' from the SQL database. That way, you can be sure in the knowledge that nothing insecure will happen. Files are found on the GitHub site.

First off, this tutorial will concentrate on using Debian 7. It will also presume you know what a MUSH is, and how to connect to one! If your VPS uses an older Distro, say Debian 6, or if you decide you really rather have Ubuntu, I suggest logging in onto M*U*S*H for assistance. 

M*U*S*H can be found at: mush.pennmush.org 4201 

Tools:

VPS: First, you need to have a VPS. I personally suggest CloudVPS as one of the better cost:stuff ratios out there. They're a Dutch company, and if you drag everything to the Minimum (which is more than your MUSH will need by far), you'll only be paying ~ €10.95

SSH Client: A lot of people swear by PuTTy, but I'm going to keep this simpler. I suggest you get the Windows client called Bitvise Tunnelier. Found here. Its setup should speak for itself. We'll get to 'how to connect to your VPS' during the Tutorial. If you are using a Mac, it comes with 'terminal' built in. Please refer to this tutorial for Mac's SSH client.

Let's assume you have gotten a VPS, and you selected that you wanted Debian 7 as your Linux Distro. You should be given some IP address that you can 'connect' to. An IP address will most likely come in IPv4 and IPv6 flavor. You won't need to worry about that, but let's just use the IPv4 for the sake of sanity. It'll look something like: 33.423.54.121 or something.

Now, let's connect to it. Open up Bitvise Tunnelier (Bitvise SSH Client.exe). You should also have been given a username and password for the 'root' account on your system. First, let's log in. Fill the following sections out with the information given by your VPS provider.

Host: IPv4 address goes here. Port: 22 (~ most likely, just leave it alone) Username: root Initial Method: Password Password: Your VPS password for root

Click Login. If it doesn't succeed, be sure to doublecheck that you copied and did everything succesfully.

You are now logged in as root. We don't actually want you to be doing stuff 'as' root though. So let's make you a proper user account. I suggest to keep your username in lower caps, without any special symbols like spaces - for simplicity's sake. (one command)

useradd --create-home yourusername --password yourpassword

Now we need them to also be able to do administrative stuff. We do this by adding them to the '''sudo''' list. (Super User Do. This should be simply if you are on Debian 7:  (one command)

adduser foo sudo

Now, log out (command: logout) and change the information for your login in the Bitvise Tunnelier. By this time, when you finish putting in your new user's username and password, you probably want to 'save' the information, and heck, you can have it save your password. It should be safe, as it gets stored in a secure manner. You'll be using this now and again in case your game goes down for whatever reason, or because you want to do more!

Now come the actual fun PennMUSH related stuff. Let's make sure you have the bare minimum of stuff! Let's first make sure you can sudo, using a simple command that doesn't really need sudo: (one command)

sudo ls

Note that it'll ask for your password. I hope you remember your password! Also note that you won't /see/ that you are typing things in. It won't 'appear' on your Bitvise xterm program. But trust me, each keystroke is being fed in. Press enter when done typing your password. If succesful, you won't need to run your password again for the rest of this 'session' (opening until closing your 'terminal').

Let's ensure we have all the packages, and some extra just in case. (one command)

sudo apt-get install build-essential git perl libpcre3 libpcre3-dev openssl nano libevent-core* libevent-dev libssl-dev mysql-common mysql-client mysql-server libmysqlclient-dev

Let's download the latest PennMUSH (one command)

git clone https://github.com/pennmush/pennmush.git

And run all the required commands, one at a time. When you hit 'make update', just press 'enter' a few times on each 'question' to use all the defaults.

cd pennmush sh configure   make update make install

Now, for the last steps. Go to the game folder by using: 

cd game

(Change Directory). There's one file in particular you are going to want to edit. And to do so, we're going to use the program 'nano'. Type in the following to edit the mush configuration file. (mush.cnf). Controls you are going to want to know are: CTRL-O (As in Ooooh) to save the current file. Ctrl-X to exit.

nano mush.cnf

You will likely want to change a few. Your mud_name etc is important. You can leave the port alone, or set it to something more memorable than the PennMUSH default of 4201. You will want to come back here later to change your connect_html_file or connect_file items to #DBref/Attribute references if you want to make things easier on yourself. Probably also want to change some of the Ancestor references (without the # in the DBref).

Last step! To start your game running on the port indicated in mush.cnf, run the following: 

sh restart

http://svc.pennmush.org/installers/Mercutio_SceneSys_73.txt

I've now reached a point where SceneSys is almost packagable. I just need to do a few more things, because I can probably make it so that it 'automatically installs' with some very simple commands run.

A few years ago, I started that section on the PennMUSH community blog. It's good to look back at one's past, and I think this was one of my best moments. Even now, there are still people who use the information there; including myself.

I know there's at least one game now which is using SceneSys, as I've helped them install it; and there's another where it is being suggested as a startup item. 

In setting up SceneSys on Tenebrae MUSH's dev server, I found some simple bugs that were in need of fixing, but nothing too weird. I found a few times where in fact, the way I coded things allowed for easy expansion, so that made me happy. I'm glad they saw the Light and switched over from TinyMUX to PennMUSH.

I recently (finally) made the simple addition to make idle scenes go proper idle - it took me a while to figure out the SQL statement. Luckily, Mike@M*U*S*H helped me half the way there. 

This is a prepared statement in Walker's SQL Prep Format running my Extensions ~ and could probably do with improvement:

SELECT scene_id FROM ( SELECT DISTINCT config.`scene_id`,`scene_ctime`,MAX(`pose_time`) as pose_time,`timeout_unfinished` FROM `$DATABASE$`.`$POSES$` as poses INNER JOIN `$DATABASE$`.`$CONFIG$` as config ON poses.`scene_id`=config.`scene_id` AND `scene_state` IN ('0','1') GROUP BY config.`scene_id` ) as groupedcontent WHERE NOT ( (`pose_time` BETWEEN (NOW()- INTERVAL `timeout_unfinished` SECOND) AND NOW()) OR (`scene_ctime` BETWEEN (NOW()- INTERVAL `timeout_unfinished` SECOND) AND NOW() ) )

So where should I go from here? 

Providing updates will probably have to become a 'thing' at some point, after all; I am not done yet. This thing can become more robust. It can use some code enhancements. The new named variables from PennMUSH are likely to be a useful thing, especially within the mapsql() function. The Scene Recall system could certainly use a touch-up, as it is visually not too appealing, and could use @mapsql.

There's two features that are basically coded up, but I've either de-activated, or are otherwise just not being used. There is also a 'journal' table that is meant for so called 'cutscenes' and 'diary entries' which is low-priority and has not seen any work done.

Chapter / Plot table. I could link you to the page, but it won't do you any good as it isn't filled at the moment. But basically, it allows you to view 'plots', and see the scenes that were under them. Interestingly enough, you could have plots in plots in plots in... yeah - recursion. I stopped using it because there's too large of a 'non-plot' to 'plot' ratio in most MUSH scenes. But what's more, since SceneSys is now aimed towards Semantic MediaWiki and storing scenes that you /wish/ to put in there, the admin can indicate plots themselves for a scene and list it based on a semantic attribute.

SceneSys isn't perfect, and one of the largest parts of that is because of how the connection between SQL and PennMUSH works. When SceneSys receives a pose on the MUSH side of things, it has the ANSI markup along with it. I won't bore you with the details, but basically, there's some weird character voodoo that goes on around it. Now, if we have the game drag this stuff back down from the SQL database, we're cool - because PennMUSH knows how to handle that stuff.

PHP does not. What this means, is that by the time I dredge it up using SQL on a webpage, I have to parse over everything that I drag up that might contain PennMUSH's ansi markup, and have to draw a large regular expression over it to convert to <span> tags. And if you've ever looked at the 'help file' for 'ansi()' on PennMUSH, you'll note that there's more than just colors to this mess. 

Long story short, the current implementation is /not perfect/. I'm also coming across some strange artifacts now and again which I can only presume to be escaped characters of a sorts. This is an item of constant research for me. I know there's someone on M*U*S*H called Sketch, who has a better parser for it, but it doesn't seem to /work/ with my system. I will have to look into this.

I will be blunt. The scene scheduling system was not my idea. Since late 2010, I've played on a game called Super Robot Taisen MUSH, where people often crowd around larger scheduled scenes. It's a faction based game, so in-character conflict is common and on a larger scale -- meaning it works well with this system. But I think all MUSHes benefit from such a thing.

The logic is simple. Someone uses a command to 'schedule' a scene on a certain date and time, indicating a title and a description. There's a command to look at all the scenes scheduled in the next two weeks, and then there's a command to look at the scene itself. It also makes a BBpost to ensure people are aware of the scenes being scheduled.

It's simple, it's to the point, it gets people organized, and it works!

I expanded mildly from what I experienced on that game and put much of what I saw into SceneSys' scheduling system - from the syntax up to the logic of listing the scenes. A recent addition was to indicate which room a scene is going to play in - so people can easily @tel (or similar) over when the scene begins. Other things are being able to 'reschedule' the scene in the schedule.

About two years ago, I started a project that I worked on now and again, off-and-on, called the Scene System, or SceneSys for short. The idea was simple; make it simpler for a MUSH to have a scene with however many players get 'logged' automatically, and stick it onto SQL because I was on a web-integration kick.

Now here I am, two years later, and SceneSys is basically finished. It was up and running in its Alpha state the moment Final Kingdom MUSH opened up. Since then, over the course of less than a year, there have been almost 1500 logged scenes on the game, counting for almost 50.000 individual poses. The scene listing can be found here.

That means that, according to the game census, 7.25 poses are being made on average per hour. Yes, that's a little pat on my own back I guess. But the more interesting part is - people like it. People love it - and people are making use of it. And no, none of our game's policies require it being used - short of one +scene per month for the FCs.