Search

Rss Posts

Rss Comments

Login

 

Let There Be Genres!

Aug 18

The title says it all.  A few weeks back, I built the code that would put the genre tables into the database.  Okay, that helps when there’s no data in those tables, right?  Well, thanks to some excellent expertise from two forum members (ladythorne and Moss for those keeping track), I can now install SMS 3 with either sets of data.  (In the future, I’ll also be able to go in and install the other genres as well in the event that I want to test all of them.)  This is actually a really big milestone in SMS 3 M1 and means we really are moving forward toward something very awesome.

So for those of you who are curious how you’ll set your genre, we’ve had to take a slight step backwards from SMS 3 (but really, it’s a step back to take about 200 steps forward).  Genre is controlled through a PHP config file in the application.  Before you even install the system, you set your genre through the file.  Currently, you can set ENT or BSG as your genre.  The third step of the install will grab the genre file, rip through it, and create the ranks, positions, departments, and rank catalogue tables for the system.  Just like that, you’ve created a sim that has a genre of your choosing and not one that we’ve told you you need to use.

Trust me, I realize the pain it takes to modify SMS to use a different genre, but SMS 3 is going to make it a lot easier.  Plus, with this data in hand, there might even be a possibility of creating official MODs for BSG and ENT in the near future.  ;)

The Road Ahead

Aug 13

I’ve gotten a lot of questions lately about things like SMS 2.6.1 and a handful about when people will start to hear more about working going in to SMS 3.  I figured now was as good a time as any to lay some of those questions to rest.

SMS 2.6

All in all, the launch of SMS 2.6 was pretty successful and I was thankful to see that there weren’t any show-stopping bugs (all the bugs could be remedied by the user if they so chose to).  It was also great to see that they were all update related bugs.  While that may seem like an odd thing to say, it means that the system core is rock-solid (save for a couple minor bugs) which makes updates a little easier.  Now, it all rests in the update scripts which are arguably the hardest part of the entire process.  So the next question is, when do we get the first update?  I’ve been working on SMS 2.6.1 since a few days after 2.6.0 was released, but a series of unfortunate events have delayed things.

First off, I fell pretty ill for over a week which took a good chunk out of development time.  Even after as I better, I was way behind at work, so things were crazy there.  At the end of catching up, I entertained a guest for several days at my apartment, so it’s been a busy two and a half weeks.  Rest assured though, I’m focusing my efforts of late on getting 2.6.1 finished up and out to everyone to fix most of the issues that are plaguing sims these days.

There is a second update planned as well, but the things being addressed in that release are relatively minor.  It was discovered after release that Firefox 3 has some display issues with SMS 2.6.  I’ll be doing some research and trying to patch those issues in all of our skins and pass along those tweaks to the entire community so that their skins don’t suffer the same way.  There’s also a bug that’s re-surfaced where SMS sites on the same domain get a weird cross-site access issue going on.  I think I finally have a solution for it, but it’ll require a hefty amount of testing just to be safe.  There’s currently no targeted release date for 2.6.2.  Also, any additional issues found from 2.6.1 will obviously be patched in that release as well.  I don’t have a timeframe for 2.6.1 yet, but I’m hoping to have everything wrapped up in the next few days.

SMS 3

So what’s going on with SMS 3 these days?  Quite a lot actually.  I’ve been working pretty steadily on getting the framework in place and ready to go for development.  The milestones have been set up and the database schema is nearly complete.  There was a development meeting on Monday and there will be a couple more in the future as we get things moving.  Talk has already begun about how we’re going to revamp the entire QA process and we’ll hopefully be making some decisions in the coming weeks and taking some more action.  The more I work on SMS 3, the more excited I get about what this release is going to mean to Anodyne and simming in general!

I’ve started working on a site for SMS 3 too.  Unlike SMS 2, we want to be more open with people about what’s happening with development.  To that end, there are probably going to be a lot more blog posts about SMS 3 in the future and the site will track development and, at the completion of a milestone, have a full-blown report on what was added and all the different things that milestone paves the way for.  I haven’t decided the format for that, but it’s coming in the next few months.  I also laid the groundwork by putting together a new section of the forums (it’s hidden right now) for SMS 3 that will be launched once the SMS 3 site launches.

Finally, just as a note on how things are moving along on SMS 3, the database schema is, so far, the biggest piece of the puzzle.  Once that’s finalized, things are really going to take off fast.  Just to give people an idea, SMS 2.6 utilitizes 26 tables (not done on purpose, I swear).  Right now, even with an incomplete schema, SMS 3 is already using 36 tables with at least another 10 just commented out and waiting to be finished.  On top of there, there’s another 4 to 6 that’ll be added later on, so we’re talking about somewhere in the ballpark of 50 to 52 database tables to run SMS 3.  That should give you an idea of how much bigger of a system this is going to be.  I’m really excited about it and I’m looking forward to sharing more information in the coming weeks and months!

Until next time.

Another One (or the Last One) Bites the Dust

Jul 27

Yesterday saw the sixth major release to the SMS 2 finally hit the streets.  There were some incredibly anxious individuals (who will remain nameless … for now) who were basically camped out in IRC all day on Saturday as I prepped things left and right, constantly asking me if it was time and refreshing the Anodyne site repeatedly.  (Thanks guys, you’ve officially skewed our traffic reports.  :P)  But as the dust settles from this final SMS 2 release, I can’t help but look back (a whole 24 hours, I know).

In terms of a catastrophe, this release looked like it was going to be a bad one when the first few bug reports came in.  It wasn’t just one or two things going wrong, it seemed like 6 to 8 things were failing and it was never consistent.  It made my head hurt just thinking about it.  It took a while, but I did track the bug down.  Turns out, it wasn’t a failure on QA’s part, nor was it failure on my part, it was just a bug.  (For those interested, the next paragraph is the technical explanation of what was going on; if you’re not interested, just skip over.)

Turns out that we were testing for the system version in the URL from the update script.  To protect against someone doing anything malicious, we tested to make sure the variable existed in the URL and that it was numeric (since there would never be a valid non-numeric version number).  The else statement in that logic set the version variable to FALSE.  Then, later on, we were checking to see if the version variable was set, and if it wasn’t, go into the database to figure out what version they were running.  Sounds pretty simple.  Only problem is that in the event that the version wasn’t passed in the URL, the version variable was set to FALSE, meaning it was in fact set.  Had it been set to NULL, then everything would have evaluated fine, but instead, the update page was seeing that it was a set variable and ignoring the whole check for version code, and since it didn’t have a version, it never called the update script.  But, the database was updated so it appeared that both the files and database were running 2.6 when the files were 2.6 and the database was 2.5.6.  You see the problem: people were trying to use 2.6 with a 2.5 database.  Doesn’t work so well.  Needless to say, the issue has been resolved and will be in the 2.6.1 update.

After that bug was solved, suddenly issues were dropping off our radar like flies.  It was a good feeling and definitely took this release down from catastrophe to just about an average major new product launch.  There are still some annoying little bugs to fix, but this time around, we’re not dealing with the massive data corruption stuff we were seeing with SMS 2.5, which is a huge relief.

I suspect that 2.6.1 will drop later this week with the potential for 2.6.2 in the coming weeks to solve some issues that have been created by Mozilla with their updates to the Gecko rendering engine in Firefox 3.  (For those reading who have noticed the issues, it’s not supposed to look like that, but our focus at the time was testing for Firefox 2.  We know those issues exist and we’ll be working to remedy them in the near future.)

All in all, I’m very pleased with how this release has gone and I’m looking forward to talking a lot more about SMS 3 in the coming months as we really hit the ground running!

SMS3: More On the Database Issue

Jul 23

A few months back I posted a blog entry about the possibility that SMS 3 may be able to run on more than just MySQL.  Since the first released version of SMS (1.2), Anodyne has catered exclusively to MySQL, and why not, it’s one of the most popular database system and is free.  On top of that, most hosts trust MySQL because of its price tag and the fact that more people know about it than, say, PostgreSQL or SQLite.  For some of these low cost hosts, it’s just absurd to think about using Oracle because the costs can be so prohibitive.  Still, there are hosts out there that offer more than just MySQL.  A host with Windows servers would probably off MS SQL as an option, and since PostgreSQL is free, that’s also a possibility if a host chose to go that route.  Which brings us back to the question, why does SMS only support MySQL?

That question got to bugging me about a year ago, but given the SMS 2 setup, it wasn’t plausible to even attempt to address (not to mention my complete lack of understanding what would go into some type of database abstraction layer).  This is another one of those great places where CodeIgniter comes in so handy, because they’ve already thought of that.  Frameworks like CakePHP and symfony have full-blown ORM (object relational mapping) to make jumping between database drivers easy, but CI doesn’t have that.  Instead, they’ve opted to go with something called Active Record which is based off the Active Record of Ruby fame.  It’s really straightforward and makes building queries a helluva lot easier than I’ve done it in the past.  For instance, in SMS 2, there might be a query that looks like:

$query = “SELECT * FROM sms_messages WHERE message_id = 1″;
$result = mysql_query($query);

That’s a very simple query and too tough to write.  CI makes it a tad easier:

$query = $this->db->get_where(’sms_messages’, array(’message_id’ => 1));
return $query;

That example may not seem like it’s a lot more efficient, but as the queries get bigger and bigger, the Active Record code doesn’t get that much bigger.  Take another query for example:

$query = “SELECT a,b,c FROM table WHERE var1 = ’something’ AND var2 = ’something else’ AND var3 = ’something completely different’ ORDER BY d ASC”;
$result = mysql_query($query);

Again, not too bad, but here it goes in CI:

$this->db->select(’a,b,c’);
$this->db->from(’table’);
$this->db->where(’var1′, ’something’);
$this->db->where(’var2′, ’something else’);
$this->db->where(’var3′, ’something completely different’);
$this->db->order_by(’d', ‘asc’);

$query = $this->db->get();

return $query;

First reaction: but wait, that’s more lines of code, why would I want to do that?  Pretty simple answer actually: the first query only works in MySQL, the second one, works in MySQL, MySQLi, MS SQL, ODBC, Oracle, SQLite, and PostgreSQL … all by changing a single line of code.  CI makes it a lot easier to build applications that work across multiple platforms.

To that end, I can say that Anodyne will officially be supporting MySQL and MySQLi for SMS 3.  In addition, we’ll be providing at least experimental support for Oracle, MS SQL, and ODBC.  Finally, there will be some limited support provided for PostgreSQL as well as SQLite.  There’s a lot of testing that’ll have to be done with some of this stuff, but it’s really exciting to see SMS 3 be able to expand beyond just one database platform.

SMS3: Back to the Way It Was

Jul 21

Seems like it wasn’t all that long ago that I was mentioning on the forums that SMS 2.5 was going to be switching form buttons from traditional buttons to image-based buttons.  At the time, it made a lot of sense.  Image-based buttons would give skin developers the opportunitities to make sure their skin buttons lined up perfectly with their skin.  Unfortunately, the idea never took off and there has only been one or two button sets released on the forums since SMS 2.5.  Combine that fact with accessibility and internationalization, and you can see why SMS is going back to traditional form buttons for version 3.0.

The decision wasn’t an easy one to come to, because I really like how some of the buttons look in SMS 2.6, but when it came down to it, it just wasn’t plausible for us to keep doing image-based buttons.  Why?  Well, the first issue is internationalization.  If the buttons have to be able to be translated, it’s better to have someone do all the translation from a single file and not have to go through and change all kinds of images.  That just makes it ugly.  So that was a major factor in the decision.  After that was accessibility and the fact that the images (currently) don’t have ALT tags, so screen readers would have a hard time with them.

Now, people shouldn’t be worrying that we’re gonna make buttons look ugly or anything, because we’re not.  It just means that people will need to actually style the buttons again, like they did before SMS 2.5.  There will still be the ability to set a background image on a submit button, but there will be a little more CSS involved than there is now.  Never fear though, we’ll have a full-blown tutorial on styling buttons when the time comes, plus, with the API, you’ll have plenty of time to be getting your SMS3 skinning skills up to snuff before release.

For those interested, the following is a good article on styling form buttons with CSS and PNGs.  Enjoy!

http://www.monc.se/kitchen/59/scalable-css-buttons-using-png-and-background-colors