Let me briefly cover two additional topics on the matter. One's about how to proceed once some ideas have trickled in. One's on, more or less, what the protocol would do as I envision it (but not yet HOW). I strongly suggest not reading this post until after you've made your suggestion on the previous one, if you're planning to do that.
Huge disclaimer to start: Nothing may come of this.
If you can live with that, let me add a redeeming thingy: If I don't actually work on this at all, at least the data will be available for future reference.
So are you ready? Okay.. Given an implementation of a new protocol to do the sort of thing Pueblo does, but isn't Pueblo, what sort of things would you require? What sort of things would you suggest avoiding?
In my first post, I discussed briefly the setting for the game, and in my second, I talked very briefly about the "feudal anarchy" which was said to have spread across Europe in the 10th and 11th centuries. I'll talk a little bit more about that here, and will get into more depth about the history of 12th-century Europe, as well as some of the reasons why I chose this period and not, as I discussed in my first post, the 10th or 11th centuries.
This is the second post in what will hopefully continue to be an ongoing series dealing with the development of ''Imperium Romanorum'', the MUSH I'm currently working on. Part I was an overview of the project. This will deal with narrative and RP, the community features that hopefully will enhance the experience of playing the game, and the administrative structure and techniques that will ideally avoid the pitfalls that have faced game admins in the past. A quick note on terminology: HC means Historical Character, and OC means Original Character.
As many know, I have been working for some time on a historical-themed game set in Medieval Germany, around the mid-12th Century, which I am calling Imperium Romanorum, which is how it was known contemporaneously. Although my historical studies have been getting the best of me, I've been meaning to blog about the process of developing the game for some time as a means of keeping track of where I'm at on the project as well as inviting feedback on my ideas for the game. This will be the first post in what will hopefully turn into an ongoing series, assuming I can keep myself on-track.
I've edited this to post an announcement here, and update the original post to the latest version. If people want to archive the earlier versions on this blog, I can do that instead.
All right, here's a real introduction. This project is a major re-write and expansion of one by Raevnos. The code that follows implements a number (111, to be precise) of functions from other codebases in PennMUSH. Nearly all of these are from TinyMUSH or TinyMUX, which are the two other codebases I've written a significant amount of code for, but there are also a few from RhostMUSH. I hope this would be useful in porting code. A full list of functions and known incompatibilities is in the main object's @DESCRIBE, but it would be easier to list the functions that I didn't port:
You might know me from M*U*S*H; from Shangrila; or from the TinyMUSH I joined years ago, started coding at, and ended up running. I'm here now because, thanks to a chain of events that started when that MUSH briefly went down, the other wizards and I amicably agreed that it would be a good idea to start a new MUSH and learn from our mistakes. I decided to make that a PennMUSH, I've spent the last few weeks coding on it, and the people on M*U*S*H suggested that I post about that here. I'm happy to do so.
I'm hoping to create a softcode widget that will e-mail players a warning when they are at risk of being idlenuked.
I've seen in a feature request thread somewhere that softcoded e-mail won't be implemented any time soon, if ever. People in the thread mentioned that a bot could potentially do this, but I've never worked with bots before.
Does anybody have any idea where I can start?
Commands like @switch and @dolist that can put multiple entries into the queue will interact badly when the command that uses them is run at the same time, especially if the queue entries depend on object state like the value of an attribute being the same value at the start of entry N+1 as it was at the end of entry N. If entry M from a separate run of the command also modifies the attribute between N and N+1's execution, things break. Semaphores help control race conditions like these.