SceneSys: A roleplaying log system for MySQL

Submitted by Mercutio on Tue, 2010-01-05 14:27

Over time, PennMUSH has been seeing more and more connectivity with MySQL and other such server software. Forums, bboards - even rumors of the Anomaly Jobs system stepping onto MySQL.
Ever since I started touching MySQL on my sandbox, ideas have begun to grow. SceneSys is one such idea. In this post, I will lay out this system for you. If you have any questions, leave me a comment! I'd love to answer any questions you may have.

I've had many little projects over time, that were planned by me to learn how to best tackle some major things in SceneSys. How to set up tables. How to write the code. How to make things modular. Some of these projects are listed below.


Player Connection Logger
When are people most on, how long are they on, etc.
Who Display
For website to display the +who - updated every 5 seconds & on {dis}connects.
Apples to Apples
The Apples to Apples game, brought to MySQL. (In progress)
+system
A +help/theme/whateveryouwant system, using a markup to allow easy export to HTML. (In progress)

Time passed quickly, and it was interesting to see how often I was wrong on how to tackle a table-setup. I must thank the people on M*U*S*H for pointing me in the right direction on how to do things better; and as I practiced more, I also noticed some bugs that were needing to be fixed before SceneSys could be started on.

Listens were not taking colors, the @message/nospoof bug that was not reporting correctly. Things like that. But now that 1.8.3p11 has officially been released, I can finally start on this project.

But all of this of course raises the question...


What is SceneSys?

SceneSys, short for - as you may have figured out on your own - 'Scene System', is a system to keep track of your scenes, making logging a pinch, keep track of posing orders, allow for scene announcement, join-locking, tagging, and quite some things more. Only for PennMUSH 1.8.3p11 and over.
SceneSys, the objects.

SceneSys uses rooms to listen to, what can be considered, RP. With other words, any 'say', 'pose', '@emit' etc gets captured by the <SceneSys Room Parent : SSRP>. To do this, it uses a ^-listen pattern on the parent room, then requires each room underneath it to be set 'LISTEN_PARENT' and 'MONITOR'. This likely can be considered to be a pain in the ass for initial setup, and I will be looking into seeing if something better can be worked out, perhaps.

Whatever it hears, it then sends to the <SceneSys Object : SSO>, which should be in #2. It gives this object all information it can find, after having filtered out whether or not something is an RP pose. This object will include a lot of commands for the player to use. And will use @triggers for a lot of it's actions.

For the <SSO> to interact with MySQL, it will also use <Walker's MySQL Wrapper : WMW>. So it will be more readable and organized.


SceneSys, what is a pose?
To figure out whether something is a pose or not, there will be multiple filters and 'smart systems' in place.

First, <SSRP> filters based on what type the object is, and how large the pose was. These are settings that will be sitting in the MySQL tables. It will also check if something was OOC, by checking the first X characters for whether or not it had 'OOC' in it, without being part of a word.

After this, <SSO> will check if the player who posed is active in a scene. If they have never used/joined a scene, we can assume that this was not a pose. If they went beyond X amount of time since their last pose, we can assume it is not a pose. But, within a certain amount of time, the player will be warned that they posed without activating a scene - just to double check.


SceneSys, where are we RPing?

Unlike normal object-type loggers, this system can follow players anywhere they go. If player-A,B,C,D are all in the same scene, but A + B are in ROOM 1, and C + D are in ROOM 2, it logs these just fine. And will transmit the poses to the players who are outside of the room - so they can (possibly) sync up their poses. But more importantly, this is for a different case: I player A is idle, and players B,C,D have gone to a different room to continue the RP, player A will not have missed a thing.
I missed a pose! What will SceneSys do for me?

It is impossible to miss a pose. As long as a scene is using the SceneSys and the player is part of the scene, a player can easily do a recall on the scene, to read previous poses in that scene! More importantly, if someone was offline while poses were added to the scene... they will be notified of this upon connection.
SceneSys! Yummy Spam!

If someone tries to spam the system, since all poses have a timestamp, SceneSys will detect this. You can easily set up how many poses per 10 seconds to accept to prevent spam. And of course, there will be a trigger for you to modify to do something to the perpetrator if they do this. The default will be that the scene will be locked against this player.
SceneSys, a pain to use?

Sure! Starting a scene is often not something you want to be using commands for. You go on some channel, say you want to start a scene, organize... and pose! So, how many commands would one need to use SceneSys?

Let us assume a standard scene, nothing private: announce its creation, and to generally just go with the defaults. Just... a standard scene.

< +scene/create
> SceneSys: Scene (number) created!
> (Public) A scene has been created by <CreatorName> in <Room Name>.

And a player wants to join?

< +scene/join
> SceneSys: You have joined the most recently active scene (number) in this room.

Done. Of course. This means that the system assumes a lot of things, and uses quite a lot of defaults.


SceneSys, scene defaults.
Scene Lock
NULL
Scene Title
NULL
Scene Desc
NULL
Scene Announce upon creation
True
Scene Private - will lock against everyone, including log reading.
False
Scene Order - Police the scene order?
True
Timeout (idle time), before a player is set 'away'.
1200 seconds
Timeout (idle time), before a player is set 'skipped in order'.
2400 seconds
Timeout (activity time), before a scene is set 'paused'.
7200 seconds
Timeout (activity time), before a scene is set 'unfinished'.
25200 seconds

SceneSys, I am a coder, and I wanna know exactly what it is doing!

Unlike most of my code, this system is actually going to be heavily commented. Most of the attributes should definitely speak for themselves in what they do. On another note, this code is formatted (rather oddly) so that if one views it in MUSHclient, at 78 width, it lines up real nice like - and looks readable.
SceneSys, you said modular... does that mean it is easy to change?

Yes actually. A lot of SceneSys will use triggers, which each will state what their input values are. This way, if you know your way around MUSHcode, it is easy to change or add on to what gets done on what event. Want announcements to go to the public channel, then check the <SSO> object for TRIG`ANNOUNCE, etc. Whether or not we are actually 'announcing' will only get checked in the actual trigger, so you do not have to mess with the core. Sure, it means that the object is going to use a bit more time and processing than normal, if one would @assert before the @trigs - but it's all for the good of modularity and easy-of-change.
More information to come. Leave comments to ask questions about the system, or things you want to know!