Considering that M5 began right after last month’s build was pushed out, the fact that we were able to get over half of the M5 functionality done in a month bodes well for the end of this milestone coming in on time or even a little early.  While some of the major functionality (like approving and rejecting characters) hasn’t been built yet, we’re well on our way to closing out M5 in short order.  Without further ado, here is what was done in July.  This report covers revs 1241 through 1426.

Added:

• User management features
• Some character management features
• Experimental base URL (still commented out)
• Credentials verification method to the Auth library
• View files
• Icons
• Babylon 5 genre
• Dungeons and Dragons genre
• link_to_if() function to the URL helper
• link_to_unless() function to the URL helper
• form_dropdown_characters() function to the MY_form_helper
• Sunny skin
• Some missing index.html files
• parse_name() function to the utility helper
• The ability to restrict access to a menu based on access level and not just the access item
• Descriptions to the access pages
• qTip plugin
• The ability to upload images to the assets/images director for character, award, mission and tour images
• An uploads database table
• A player LOA database table for tracking LOAs

Updated:

• Install files and images with M5 information and branding
• Language files
• Install data
• Some links on the user panel
• Icons
• Andromeda genre file
• Controllers with better language code
• The entire system now uses lang() instead of $this->lang->line()
• System controller with a better get_skinsec method
• Redmond skin
• Lightness skin
• Site options now shows a preview of the skin that’s selected
• The positions dropdown references the form_dropdown function instead of copying it
• Roles pages now use tooltips to show what an access level can do
• The manifest will no long show active players who do not have a player assigned to them

Fixed:

• Undefined variables on the missions page
• Undefined variables on the post mission entry page
• Player model updated methods now optimize the database when they’re run
• Mission page bugs
• Ahead/behind were flipped when reference whether another player was ahead or behind of the player they’re viewing’s timezone
• Fatal error in the MY_form_helper where the session library wasn’t loaded at the time (only an issue during installation)
• Skins weren’t being referenced properly on the sim section
• Attempting an autologin from the Ajax controller would cause a fatal error because of missing libraries
• Specs table didn’t have any blank data causing errors to be thrown when updating
• All timespans were way off
• Duplicate rank image in the BSG rank data

It’s been really interesting to watch as development has steamed along now for over a year at the differences between Nova and SMS.  Yeah, there are plenty of feature differences, bug fixes and enhancements, but when you start looking under the hood, the systems look nothing alike and one way to know that pretty quickly is by taking a look at the database.

One of the big focuses for Nova was to make the database itself more extensible.  We’ve managed to do that as admins can now create their own site messages and settings as well.  Add to that dynamic bios, specs and tour items and you can see how things start to add up pretty quickly.  What is interesting though is to just look at the raw numbers and see how Nova has grown (and not grown) over the last year.

Database Tables

SMS clocks in at a respectable 26 tables.  Considering everything it does, that’s nothing to sneeze at.  There would certainly be ways to improve on it, but remember that when SMS 2.0 launched in the summer of 2006, it only had 20 tables.  Between 2.0 and 2.6.8, we added 6 tables to the database for things like access levels, the database feature, an awards queue, system plugin tracking, a deck listing table and private messages.  Not bad for 6 tables.

Nova, however, bends SMS over its knee with whopping 56 tables.  You read that right, Nova has over twice the number of tables as SMS … 30 more tables.  What kills me is that we still have several more tables to add.  It’s more than likely Nova clocks in with over 60 tables when all is said and done.

The reason for the massive influx of tables is things like the dynamic bio/join form.  Character information alone in Nova spans 8 tables (including the chain of command) instead of 1 in SMS.  Why so many?  Well, we have to be able to create all those form elements, populate select forms, track promotion history, build tabs and store the data.  That’s just one example, but throughout the system, we’ve spread things out by normalizing our database schema.  It makes the database faster for reading and writing and makes the entire thing far more scalable in the long run.

Database Table Columns

So since we’ve increased the size of the database by over a factor of two in Nova, that means the number of table columns had to have gone up by that much or nearly that much, right?  Wrong.  In a very interesting twist, the number of columns don’t line up with the number of tables.  SMS, for instance, contains 327 table columns for storing data.  Nova only sees an increase of 73 to and even 400 columns.

A lot of that has to do with things like character information.  In SMS, all character information was stored in a single table of 77 columns; Nova does the same thing with 34 columns.  By shifting the entire database over to be more flexible and extensible, we’ve also reduced the number of columns the system has to sift through when it’s querying for information.  That reduction, like normalizing the schema, provides us with some more speed.

Just a few interesting observations from development land.