Battletech Live

Online, Turn-Based Battletech – Development Logs

Tanker trailer catches fire on I-80

At around 11:30am today, a multiple vehicle accident closed down I-80 around mile marker 60, one mile from the Sidney exit.  Sidney’s fire department is entirely volunteer and many were on location to assist with containment of the accident and to fight a fire that broke out on the surrounding fields.  The contents of the trailer has not been disclosed but it has been said that it will most likely be a hazardous materials situation.

The Nebraska State Patrol has closed a 10-mile stretch of Interstate 80 near Sidney following a late morning crash involving several vehicles.  It’s believed there is at least one fatality.

Around 11:30 a.m., (MST), a pickup pulling a camper was traveling west near the Sidney exit when the driver lost control of the vehicle.  The vehicle crossed the median and struck a tanker truck headed eastbound on I-80.  The tanker truck, which was hauling a flammable liquid, struck another semi before coming to rest on its side in the eastbound driving lane of I-80 about 1 1/2 miles east of the Sidney exit.  The other semi came to rest upright in the eastbound shoulder of the Interstate.  The tanker truck then caught fire, engulfing both the tanker and the pickup-camper in flames.  The Interstate is closed in both directions as rescue crews work the scene.  Westbound traffic is being detoured at the Sunol exit, ten miles east of the accident scene.  Eastbound traffic is being detoured at the Sidney exit.  Names of the individuals involved in the crash will not be released until notification of the family is made.

The Nebraska State Patrol is working in conjunction with the Nebraska Department of Roads, the Cheyenne County Sheriff’s Office and the Sidney Volunteer Fire Department.

dscf0037

Advertisements

April 23, 2009 Posted by | Off Topic | Leave a comment

Update to Event Calendar

I posted an update last night that fixed a few bugs in the event calendar, although it’s not truly operational by any means.  For anyone who has ever used Mozilla Sunbird, you’ll see some similarities.  It gave me some ideas, such as “Why have one calendar when you can have several?”  Instead of using one massive calendar with everything piled into it, each user should have their own, plus one for any group they belong to, plus a public calendar.  It should keep things more organized.  Another big part of the update was to organize the file structure a little more, getting images put where the belong, and changing the code to reflect these new locations.  As a result, I have a few missing images in the site that I didn’t catch.  I’ll go back and fix those links tonight.

The calendar page does have a very strange issue.  When the calendar loads, it determines the number for the current month (April = 4), and retrieves a list of holidays for the given month.  Using the previous and next buttons either subtracts or adds one to the current month and retrieves the holidays.  But for some reason, if the number for the month is odd, it works,  and if even, it retrieves the first holiday and stops, even though it works when it first loads.  I’m going to work on fixing that this morning, then on getting the calendar system to communicate with the email system.  I’ll come back later to make the small calendar pane, custom calendars and views to work.

picture-5

picture-21

April 23, 2009 Posted by | Project Development | Leave a comment

The importance of caching query results.

Recently, I have begun building the structure and logic for the Technical Readouts, located on the Expanded Universe tab of Battletech Live.  It’s set up so that when you open the Technical Readouts panel and select a book, the system accesses the database and retrieves an XML list for the table of contents and an ID used to represent the book cover.  The table of contents is divided into chapters, which can be browsed to select individual pieces of equipment or units.  When that selection is made, it connects to the server and (so far) retrieves seven pieces of information:  book, name, mass, manufacturer, picture, year, description and type.  Moving from book entry to book entry can be fairly intensive, which I learned last night.  At one point, I apparently spiked the CPU utilization of the web server over 60% and caused an automatic suspension.  It only banned me for 60 seconds, but it was enough of a warning that I needed to start putting caching in place.  I didn’t do this during the build-up phase of the Technical Readouts.

Now, when you select an individual technical readout, it checks a local arrayCollection for the information.  If the information isn’t found, it then sends the query to the server and writes the results to the array.  In this way, each individual element need only be retrieved once.  At present, the arrayCollection is flushed when the webpage is refreshed so I’m working on methods to save the retrieved data to a Shared Object along with a timestamp.  When data is retrieved from the server, it will save it as a Shared Object on the computer along with the timestamp.  The next time the page is loaded, it will check the Shared Object.  If not found, it will retrieve from the server.  If it is found, it will compare the timestamp of the Shared Object with a corresponding record on the server and if they don’t match, it will pull new data.

picture-2

April 16, 2009 Posted by | Project Development | Leave a comment

PHP script to parse XML from mysql.

I got an XML parser up and running today, helping me take some list-based items out of AS3 and a lot of things out of PHP and txt files.  So far, I’ve eliminated about a dozen files, moving the content into the database in a more organized fashion.  It also makes it a lot less likely for formatting errors to occur, wasting time hunting down bugs.  I’ve started putting in some of the structure information for Technical Readouts and hope to have the first one, 2750, up within a couple weeks.  Instead of a book that is turned page by page, it uses a tree menu to separate the books into chapters and chapters into the individual units.  With everything pulled from a database, it should be in a pretty uniform format.  Along with the text from the books, charts will be listed for damage analysis and estimated performance based on piloting and gunnery skills, the optimal range for a given unit, the Battle Value and an estimated cost in C-Bills, if the player should choose to outfit it.  The pages will also eventually be “hot-linked” straight to The Mech Bay so that players can perform immediate modifications for their tastes.  Lastly, an option will be available to export a PDF record sheet which can then be printed.  Of course, some of those features are much further down the road, but display of historical data should be up shortly.

April 14, 2009 Posted by | Project Development | Leave a comment

How should a mail server work?

I spent 20+ hours this weekend working on the email system.  While I got quite a bit accomplished, I ended the weekend with more questions than I had to begin with.  At least for testing purposes, I have the system set up able to compose and send mail, deliver the message and put a message in the outbox or sent items of the sender although the process that I have in place seems way too complicated.  I want to take a step back, analyze things and put together a sequence that makes sense.  The following is my logic, which may or may not be flawed, about how a mail server should work.

  1. When a user composes an email, they supply a title and body and designate who that message is going to be sent to.  If the message is sent, one copy of the message will exist for each intended recipient.  Another copy of the message also exists in the senders mailbox, residing in one of several possible folders such as Outbox, Sent Items or Deleted Items, depending on how the user treats the message.
  2. When each recipient receives the email, it appears in their inbox.  At this point, the user is free to move the message to the folder of their choosing.

The above notes are a somewhat simplified representation of what happens when sending email.  In reality, what takes place is far more complicated:

  1. The composer supplies the title and body of the message and at least one recipient.  Recipient options are To, Cc and Bcc.  For the most part, To and CC are handled the same, the differences existing in the header of the message.  Bcc also receives the message but does not appear in the header of the message and is thereby invisible to other recipients.
    1. A successful email message must have all three components, subject, body and recipient.  The send button should be disabled until all three components are satisfied.  The send button should also be disabled if the only recipient is a Bcc, discouraging anonymous email.
    2. If the sender decides not to send the message, they should be asked if they wish to store it in Drafts, to be sent at a later time.
      1. If the sender says yes, the message is pushed to the server and stored in such a way as to prevent it’s immediate delivery, perhaps a field named Draft that contains a record of who the message is to be sent to.
      2. If the user says no, the form is reset and the user is returned to their previous screen.
    3. If the user is satisfied with the composition of the message and selects to send it, the message specific information is pushed to the server.  If the message is sent to multiple people, the message is essentially replicated and stored once for each recipient, plus once for the sender.
      1. For the outbound message, a number of fields are needed:
        1. The name, id or address of the sender.
        2. The name, id or address of the recipient.
        3. The message subject.
        4. The message body.
        5. A generated timestamp for when the message was sent.
        6. A field to store a value for the messages present location, initially set as inbox.
        7. A field to indicate the timestamp for when the message appeared in the recipients inbox.
        8. A flag to indicate whether or not it should be displayed as bold for unread or plain for read.
        9. Indicate whether the message was sent as To, Cc or Bcc.
      2. The message that appears in the sender’s outbox is similar, but has some differences.
        1. The server should again indicate who sent the message.
        2. The message recipient.
        3. The message subject.
        4. The message body.
        5. Timestamp for when the message was sent.
        6. A text field that holds a collection for who it was sent to, or possibly three fields, one for each possible state.
        7. The folder in which the message currently exists.
    4. Upon sending, all copies of this message should be stamped with the same message ID so that information from one can be referenced through the others.  For example, if a message is sent to four people, each of those four people gets a copy of the message and each copy contains a field to indicate when it was delivered and whether or not it has been read.  Because there are four recipients and only one sender, and because the total number of recipients is indeterminate, the copy that appears in the senders sent items cannot immediately reflect whether or not a message has been delivered.  Instead, there should be a way that the sender can select to view more information about the message, at which point, the server goes out and collects information related to the current message id.  It finds five items with the id, cross-references the information and displays it in a form easy to understand.  For example, three have been delivered and when, and of those three, two have been read and one is still unread.
    5. So, when a message is delivered, the message on the server is updated to list a timestamp for when it was delivered and on the host machine, appears in bold.  When the message is read, the server copy is updated again and the host machine now displays as plain text.  If the message is moved to a saved folder, the server updates the message to indicate the change, as does delete.  The process works similarly for the sender’s copy.

I don’t know if I’ve overlooked anything or not.

April 13, 2009 Posted by | Project Development | Leave a comment

The evil that is htmlText.

I’ve been working on email all weekend, getting the site set up so that users can send, reply to and forward messages.  I ran into one problem a while back and deciding that it wasn’t worth my effort at the time, put it on hold to work on other things.  I’m back at it again and finding it very frustrating.  When dealing with a Rich Text Editor in Flex, the output of the form can be htmlText.  That text can then be submitted to and stored on the server.

<TEXTFORMAT LEADING=\”2\”><P ALIGN=\”LEFT\”><FONT FACE=\”Myriad Web\” SIZE=\”10\” COLOR=\” 0F0F0F\” LETTERSPACING=\”0\” KERNING=\”0\”>This is a test.</FONT></P></TEXTFORMAT>

The problem is that Actionscript is really craptastic at dealing with htmlText imported from an external source.  Lets say that the above is the output from a php file that Flex then pulls as a Result Event.  This string gets stored either as a string variable or within a cell of an array.  When the time comes to display the text in a TextArea, nothing will display.  However, if it’s entered literally into the source of the page with something like the following, it works perfectly:

mailerRead.htmlText = “<TEXTFORMAT LEADING=\”2\”><P ALIGN=\”LEFT\”><FONT FACE=\”Myriad Web\” SIZE=\”10\” COLOR=\” 0F0F0F\” LETTERSPACING=\”0\” KERNING=\”0\”>This is a test.</FONT></P></TEXTFORMAT>”;

I’ve looked all over for how to get it to work and nothing seems to work.  I’ve almost decided that for now, I’m going to have to set it up to be strictly plain text, then later, take time to build a parser to deal with it and reconfigure it as a string that it can recognize.

April 12, 2009 Posted by | Project Development | Leave a comment

Blizzard warnings and activity bars.

It’s really cold outside right now and kind of nasty, so I haven’t been out.  These weather conditions should make for good coding, but I can’t get really motivated so I’ve been wandering around the house doing various things and coming back to the computer when I think of ways to work on the current targets.  We had some rain last night and the current temperature is 19.  We have a decent amout of snow coming down, but we have wind gusts up to 45 which makes it not so good to be out.  Our wind chill is listed as -7.

Last night, I worked on adding an activity bar to the bottom of the application so that users know when tasks are being performed.  At the moment, it activates when the app changes from one state to the next, but I will be setting it up to activate also when it checks for new mail, pushes new updates and such. I think that the development panel will eventually be moved and tied into the notification bar so that it fits more into the layout instead of just a floating box.

Something odd is also happening with a few of the modules.  Even though they appear correct when viewed in Flex, modules sometimes have issues when seen through a browser.  The Mech Lab for instance, loses all text.  The structure of elements is correct but the menus and buttons are all empty.  Even more strange, the issue sometimes moves around.  Every now and then, I’ll compile the files to find that the problem has jumped to the World Builder instead of Mech Lab.  I’ve read that if you have a component in a module that doesn’t exist in the main application file, that module will own the component until it’s unloaded and I’m thinking that might have something to do with it.

picture-12

picture-3

sd531705

sd531706

April 4, 2009 Posted by | Project Development | Leave a comment

Mail composition, adding / removing folders and moving messages

I’m working on a number of things right now and my hosting provider appears to be having an outage.  So, since I can’t update anything on the server, I thought I’d post an update here.  When I first think about setting up a mail system to handle simple text-based messages, it doesn’t seem like it should be all that complicated.  But when I dig deeper into the process, there’s a surprising amount of work that goes into a system.  Right now, the email system works.  I can compose messages, select who to send them to and they go.  I don’t have it enabled for anyone else yet because I still have a number of bugs and some features that don’t work quite right yet.  For instance, moving a message from one folder to another or just deleting messages.  Those are the two biggest things I’m working on right now, or at least I was until my server stopped responding.

When an email message is retrieved, you’d expect that you need to know who it’s from, who it’s to, it’s subject and it’s content.  Those four basic things let you view messages that were sent to or were sent by you.  A number of other things also need to be known, such as which folder the message is supposed to be in and the position at which the message lives on the server.  These two things are important because if you move a message from the inbox to a saved folder, the application need to know the index for where the message was and the index for where it is being moved to so that the server can be updated.  The index of the message itself lets the application simply say message 24 instead of having to search the mail server for the correct message.

So that’s how moving messages works.  The other complicated thing is the actual folder list. Each Battletech Live member has their own folder set.  Everyone has the same basic set of folders shown below.  These folders can’t be deleted, but they can be repositioned.  Members can create new folders that live among and within their basic folders.  If a user wants to keep saved items from a number of people but wants a little more organization, they can create folders inside Saved Items to store messages from specific individuals.  The trick is how to set this system up so that it’s easy to use and requires as little direction as possible.  In most email systems, if you want to move a message, you simply drag the message from the message list onto the folder you want to put it in.  That’s all well and good, but the default drag-and-drop system for Actionscript 3 wants to drop the message among the folder list.  It doesn’t know that you want it to go into the selected item and there’s no automatic way of getting this to work.  I can get it to highlight the folder that the mouse is hovering over but it still puts a line above or below, indicating where the message will be dropped.  So, at present, when a message is selected, a button becomes active, which then brings up a panel that allows the user to select the folder they want to put the message in.  Clicking Confirm, then submits the information back to the server so that it’s positioning can be updated, or at least it would if the server hadn’t gone down.  Later on, I will be building a custom component that will accurately set up the drag-and-drop system so that messages go into the specified folder instead of among the existing folders.  When that function is done, the Move button will be deleted, no longer serving a purpose.

picture-11

Adding and deleting folders.  For a while, I struggled with how to set up the folders and how to get them to display correctly.  I started out with four pieces of information on the server:

  1. The name of the individual folder.
  2. The owner of that folder.
  3. The folders parent, if any.
  4. The position at which the folder should be displayed.

When I started setting it up, I displayed the information in a DataGrid, which I soon realized was the wrong approach.  Since folders can have children as well as siblings, a Tree component was really what I needed.  I started looking up ways to build the tree structure programatically and found that it seems much easier to build the structure of the tree as XML and link it.  Every five minutes, or whenever the member pushes something to the server, it checks new mail and updates the folder structure.  For each folder, it retrieves the four pieces of information above and decides how it should be assembled.  The resulting structre is then assigned to an XML variable which the tree then uses as a DataProvider.  I will be looking into how to set the icon of each item in the XML structure so that Inbox can be visually different from Deleted Items, Sent Items and so on.  Adding folders will be similar to moving messages.  The member clicks Add at the bottom of the list and it asks them to name the new folder and select the folder in which it should reside.  Clicking Confirm will push the updated data back to the server.  Removing folders works the same way.  In the end, I will have context menus set up so that members can right-click an existing folder and click New Folder or Delete Folder, if they should so choose.

April 4, 2009 Posted by | Project Development | Leave a comment