Done!

I presented Friday the 10th of October and received approval. Finished!

Progress update

Today was not nearly as productive as I’d hoped, but what I got done was satisfactory. I finished up the project walk-through portion of my paper, refactored some other parts to match it, and did a major overhaul of documentation and user interface styling on the app. The reason I did not get as much done as I’d hoped is twofold: First I wrestled for hours fixing a bug that prevented me from generating a release build of the app (which I discovered while writing up the project walk-through). Later, after hours of work commenting and prettifying the UI of the app, my computer ran it’s daily auto-backup. I have two internal drives. One is the main drive that I work off of, the other is the backup. Each day the computer automatically writes any new files from the main drive to the backup drive, and deletes any files from the backup drive that aren’t on the main drive. I was working from the backup drive today because when I rebooted from BootCamp, it chose the wrong hard drive. Lost everything I had worked on for hours in my code… which means I stayed up till now rewriting it all from memory.

Kids… make sure you’re running from the correct drive.

Final Report Progress

I’ve finished about 1/3rd of the new written content final report today. I’ve written about my initial research and discussed the majority of the third-party technology I used as well as how I architected the application. Tomorrow night I will write the sections pertaining to the actual process of development as well as the developer framework walkthrough. I then hope to, on Tuesday, write up the end user final product walkthrough, including a basic “Users Guide” in an appendix, and the majority of the conclusion, which will include my foiled expectations and future plans. At that point I will invite commentary from my capstone committee and a few select others while I complete the in-code documentation.

Documentation progress

I’ve finished a good portion of the inline documentation for Paradigm and started in on my final write-up tonight. I started easy by creating a simple abstract for the paper and a relatively detailed outline with some notes on the main topics I want to hit. I’ll be recapping my proposal information and then doing a fairly detailed analysis of my process and final deliverable. I intend to discuss the technical details of the application as well as my thoughts on why each piece makes sense and what I didn’t do and may do in the future.

I’m hoping to have a first draft done within the next week or two.

Short update on documentation progress

“Real life” struck again, but thanks to the labor day weekend (4 days for our company, woot!), I’ve made progress on finishing the documentation for the project. It will be a complete set of ASDocs (actionscript inline documentation compiled by an Adobe tool), as well as a code “style guide” that developers will be able to use to create plugins as well as a very short tutorial or one-page introduction to the application for end-users.

Side-note: It’s amazing how many files I’m deleting from the project (not that many really, just 3-4) that I never actually used. I’m talking completely coded Actionscript classes that I just never got around to using and will not be needed by plugin developers. Yay documentation effort revelations.

Approaching endgame

Mundane business first. Last night I added one new behavior, cleaned up the details definitions for my custom objects, and prettified the details display.

I created a new default behavior called GlowBehavior. This little fella checks the importance of data objects, and if they are greater than 75% “important” it will limn them with a red glow. This was an interesting plugin to write because of how the Papervision3D engine and Flex components interact. Each visual object in a PV3D scene is part of the scenes flex object. This means you can’t apply Flex filters to them directly, unless… There is an option in PV3D to host every visual object in it’s own Flex DisplayContainer. This reduces performance of the engine overall, but allows much greater flexibility when it comes to filters. So it works.

My second task was to finish up the mappings for the Flickr and vCard objects details display. This allows each object to maintain information like filesize, title, creator, address, etc. and then display it in the details drawer.

Finally, I redesigned the details drawer itself to be even more out of the way but still visible, and rearranged how details are displayed inside the drawer.

With that out of the way, we move onto the less mundane business. After meeting with both of my capstone advisers I have received approval to say to myself that I’m done. From this point on, any coding work will simply be cleanup. It’s done! Over the next few weeks (at most a month and a half) I will be finalizing my documentation, writing my final analysis and report, and preparing my final presentation. After that… get my degree! Finally 🙂

New behaviors and module selection functionality

After talking to .5 of my advisers earlier in the week (*waves at Weez*), I intended to get right to work on cleaning up my details and module selection/options UI as well as add some new behaviors. The week did not allow for that. However, I just finished up a 12 hour session of coding during which I got some of that stuff done.

I created a new swimming behavior (creates the illusion that the flocks are swimming, duh). In order to do so I ended up having to rethink how I was applying behaviors that affect the position of visual objects. Previously I was simply changing the value of the objects position from within the behavior, but I found that to be too brute force. It caused problems with flocking calculations. To fix that, I created an offset value on the flock members that I now set, and use that offset in my calculations to more properly handle positional behaviors like the new swimming behavior and the vibration behavior.

I also rewrote some of my module handling code to include the ability for users to enter authentication credentials for modules that need them, and to select local files for modules that can use them. This involved changing my specifications for module interfaces, module definitions (xml), the logic that handles module loading, and the module selection UI. Fun times!

Finally, I tweaked the details interface to be less intrusive by making it a transparent side-docked overlay over the 3D interface instead of a half-screen opaque hog.

A good day all around.

Address Book Module, modular appearances finished

Over the last few days I’ve completed the framework interface for multiple module support, created a new module to load local vCard style address books, and implemented the necessary infrastructure to allow module authors to supply their own appearances for flocking objects. Woohoo!

This means that my remaining work includes the following: provide a details UI for users to see the actual details of the on-screen objects; significant documentation; complete default settings and functionality (behaviors, appearances, etc.); thorough debugging; compile includable swc files for module authors.

In other words, the main functionality of my application is complete. The majority of the remaining work is “meta” work.

Vacation Non-post

I’m out of town and was out all day. No content in the post today!

Behaviors system in place

Over the last few days I have designed and implemented a basic behaviors system. Taking inspiration from the Flint Particle System (an open source particle system generator for Actionscript), this system allows module developers to use pre-defined behaviors or to create their own, and attach them to flock members. The module developer would have to define a behavior type name, any custom behaviors, and a function to assign behaviors to flock members. Anytime a flock members data object has a behavior type matching that of a module, the modules behavior function will assign appropriate behaviors based on whatever attributes it finds appropriate, e.g. importance, size, or time.

This behavior system will allow module developers to define one of the most crucial components to this entire framework: how information is differentiated in order to catch the users attention.