A lot of people have been posting in the forums lately about getting the SMS warning message about SQL injection.  The message states that someone has attempted an illegal operation from the activation page.  I think I’ve found out what’s causing the problem, but just to be sure, I’ve made some modifications to my personal site (I’ve gotten 7 of these messages in the last 48 hours) that should give me some more information.  Once I know more, it’ll be easier for me to triage the bug and spin off a quick update to patch it.

Progress during the week on SMS was sparse because of a project at work that needed a lot more attention, but today was all about awards.  Last week I managed to put some code into place that added more information every time an award is given.  Now, instead of just award, it also gives when the award was given and the reason for giving that award.  The page where a CO gives the award was updated to put the right information into the database, and because we’ve moved to a category-based system (meaning NPCs can be given awards), the “landing page” had to updated to provide a list of not only active and inactive crew members, but also NPCs.  After that, the remove award page had to be updated as well.  Once I finished those, I started thinking about how it would look on my own sim.  Let’s face it, some sims have more people than others.  Mine currently has 20 some-odd players, plus another 40 or so inactive crew, and that’s not even talking about NPCs.  Enter tabs (again).  A nice tabbed interface now makes it easy to get right to the type of player you’re looking for.  There might have to be a few more tweaks the NPC stuff, but we’ll take that as it comes.

Next up was updating the bio page.  There are a few players on my own sim that have gotten a ton of awards, so the pages were getting super long.  The beauty of using something like jQuery is that there are a lot of options, hence a nice little hide/show feature was added for the awards and posting stats to reduce the amount of scrolling on the bio pages.  After that, getting the bio to display the new award information was a little tricky.  There was twice as much info, but not much more space.  In the end, I decided that the award description was probably unnecessary and it was pulled, leaving just the award image, the award name, the reason why they received it and the date they received it.  Add to that a zebra table and the awards section of the bio looks 100% better than it did before.

Finally, the last major revision of the awards system was the nomination process.  Since SMS 2.0, when you want to nominate someone for an award, you go to the nomination page, fill everything out and it gets emailed to the CO and XO for their consideration.  That’s all well and good, but that still leaves the CO (and/or XO) to input those awards manually.  Why not cut a step of that out?  Players filling out the nomination form won’t see any difference whatsoever.  However, once they hit Nominate, their nomination is dropped into the database and an email is sent notifying anyone with the ability to give awards that there’s been a new nomination.  The next time they log in to the site, right where all the post and user activation stuff is, there’s now a new option for award nominations.  Go to the activation page and there at the bottom will be all the nominations that are pending.  With a couple clicks, the CO can see the nomination and choose to either accept it or reject it.  If it’s rejected, it goes away, otherwise, it gets added to that person’s bio and the CO has just done half the work.  There’s still some work to do on the award queue stuff and the email that’s sent out after a nomination is submitted, but in the next week or two, it should all be polished up with a brand, spankin’ new award system!

One final note.  The last check-in for the awards stuff was 101.  Hard to believe there’s been over a hundred check-ins already and we’ve still got a lot left to do.  We’re making progress though.

Two years ago when I laid down the first SMS2 code (though at the time I didn’t know it’d become SMS2), I had these visions of grandeur for making the code so flexible that there literally wouldn’t be a single thing that couldn’t be added in the future.  It was a noble goal to be sure, but my attempts were far from successful.  At some level, assumptions were made about how things on a sim would be run.  It made sense since I was coding just for my own sim at the time, but as the code I started working on became SMS2, it became clear that some of those assumptions were off.  Still, the codebase remained pretty flexible for things that were being added.  Enter SMS 2.5.

One of the biggest reasons SMS 2.5 took so long was that there were a lot of pieces that had to be re-engineered to work properly.  This was due, in large part, to the fact that I didn’t foresee SMS2 becoming what it’s become today, hence problems arise when you try to take the system to another level because you have to respect all the co-dependencies within the system.  During SMS 2.5’s development, those were system-wide and it was sometimes tricky to navigate them.  But even as SMS 2.6 takes a step down from the system-wide things, there are still some assumptions that remain lodged in the code.  The awards system is an excellent example.

For SMS 2.6, one area that’s getting some love is the awards system (this is actually one of the features that came over from 2.7).  As it stands now, you give an award and that’s it.  You have no additional information about WHY that player received that award.  This was requested quite a while ago and I’m just now getting around to adding it.  Come the next release of SMS, both the date as well as a reason will be appended to the award.  Of course, this gets back to my point of making assumptions.  When the awards system was developed, I assumed I’d just remember why I gave someone an award.  Yeah, bad assumption.  So the entire awards code was developed on that faulty assumption.  This one’s about fixing that mistake.  But still, it isn’t easy because there’s a lot of code there that has to be re-examined and, in some cases, completely rewritten.  Still, it’s a good lesson in keeping things a little more flexible in the future.

On top of that, I’d never thought COs would want to give NPCs awards.  But after being a CO for almost 3 years now, I can see why that might be the case.  Of course, an NPC can’t do OOC things though, so there has to be a whole set of logic in place there for how awards are pulled, in addition to a new database flag for whether the award indicates in character actions, out of character actions or both.  There’s a few layers of logic, but in the end, it makes the award system a bit more robust and allows COs to give awards more how they see fit instead of being locked in to my paradigm.

The first code to do this was checked in to the trunk a few minutes ago, so it’s on its way.  For those of you who read the blog, there’s another feature you can add to the list. 

Over the last few weeks, I’ve been carefully contemplating a few things regarding the future of SMS, specifically, SMS2.  There’s been a lot of talk about SMS3 already and I’ve had quite a few people come to me already asking me more about it, to which I have to kindly tell them nothing’s set in stone.  On the other hand, with all the 2.6 development, I’ve been waist deep in the current code and have really come to realize how limiting it is and how quickly it became a mess.  A fresh start is definitely in order.  Enter Jefferson (aka SMS3’s codename).  Of course, I’ve publicly stated a few times that Jefferson would be a long, hard road and that still remains true, but my goal is to shorten that road a little by shuffling some SMS2 stuff around.  So, effective on Saturday, SMS 2.7 is no more.  I took a long, hard look at the feature set being planned for 2.7 and slid what I felt were the two biggest features of the release over to 2.6 in the hopes of finalizing the SMS2 line a little sooner so I can get things started on Jefferson.  The way the timelines were falling, Jefferson probably wouldn’t have started development for upwards of a year.  Cutting 2.7 out of the picture means that Jefferson work will start sometime this summer.

For the curious, the dropped features from 2.7 were rank and skin catalogues for managing both, rich text editing, and a new strike management system.  Of course, those were only preliminary features, but those were the ones that, unfortunately, didn’t make the cut for the 2.x line.  In some form, all of those features will find their way into Jefferson, so all isn’t lost for anyone really pining for those things.

In terms of support, with the release of 2.6, Anodyne will officially drop all SMS1 support.  We won’t provide upgrade scripts like we do now.  SMS1 will be dead once and for all.  We’ll also stop support SMS versions 2.0 through 2.3.1, meaning that we’ll only be providing forum help for SMS 2.4.x (for anyone who really wants to keep IE6 support) and SMS 2.5.x, plus full support for 2.6.x.  Once Jefferson is released, we’ll drop all support for anything short of the latest stable version.  Of course, that’s a ways out, but that’s the current plan.

As we get closer to the beta period for 2.6, I’ll be sharing a lot more about the feature set for the release, but for now, we’ll keep people guessing a little longer.

I’ve been looking through Wordpress themes for weeks now trying to find something that caught my eye and I finally found one.  There are some color changes that have to be made, so I’ll have to dig in with Photoshop in the next few days, but this should provide a nice facelift to the blog.