Okay. So over a month ago I mumbled something about the next few Flash CS3 extensions I had planned to release, and here I am a month later and you haven’t seen much. In case you’re wondering “whassup, dog?” the answer is simple: Clients and conversion. I got hammered with a lot of clients who wanted numerious Flash projects developed in a very short period of time. While this effectively prevented me from doing much work on my JSFL extensions, it did give me the chance to really test out a few of them “in the field.” And I have to say I’m pleased with the results. The CS3 extensions I built earlier saved me a nice little snippet of time here and there… and perhaps more importantly, they saved me the burden of having to change my focus from one task to another.

But enough about that, the real news is that in the leftover time between deadlines I’ve been busy converting my current Flash CS3 extensions to work as Flash MX 2004 extensions. This takes time, mind you, and most of the coversion work I’ve done so far is simply preparing my JSFL files so that I have a library of JSFL fuctions. This way I can port the functions over from CS3 extension compatibility to Flash MX and Flash 8 extension compatibility… starting with a set for Flash 8 and then moving to MX. So while you might not see any new Flash extensions for the next chunk of time, more are on the way and in the works. It just doesn’t make sense to build more Flash extensions without cleaning up an organizing my JSFL code library first. 

So, not much else to say on this post, other than “I’m not dead.” It looks like my time could be very well packed with another large Flash project, but I will continue to build the CS3 extensions I promised earlier, as well as start releasing a few versions of my extensions for Flash 8. Stay posted, and again, if you’re on my list, I’ll let you know when the new stuff is ready.

So, after doing the survey of Flash users, I’ve made few decisions about how I’m going to continue the development of Flash extensions. Even though a majority of respondents said they were using CS3, there’s still a fair percentage of you folks still using Flash 8 (Flash CS3 was spendy, so who can blame you, right?) so I’ve decided to translate my current Flash tools from CS3 to Flash 8. This won’t be immediate, as I plan to kick out a few other extensions first, and I have to re-write a chunk of code and test it, as there are some important differences between the two Flash versions.

Now then, about Macs. Uh, no real noise from the Mac folks, so I’m not going to test these on a Mac. If you use a Mac and you use Flash CS3, then the Flash extensions I’ve built should work for you. The key word there is “should.” Like I’ve said before, JSFL is a funky language. Test it out and see for yourself. If one of them doesn’t work, let me know and I might get to it.

As for the type of extensions people wanted, they gravitated towards the Designer/Animator tools, then library and file management stuff, and finally code extensions. I’ll build for all 3 groups, but probably lean more on the design and animation extensions until I hear differently.

Thanks again to everyone who filled out the survey. I’ve decided to keep it posted, and thus created a second copy to gather more answers. If you have any Flash extensions you’d like developed, or any other comments, feel free to take the Flash Extensions survey and leave your suggestions.

So I’m ready to do a public release of my latest Flash extension, the “Duplicate Frames Remover” (or DupeFrameRemover for short) extension. In order to get a feel for what it does, and before you download it to expand your repetiore of Flash commands, let me talk for just a moment about the problems this Flash doo-dad solves.

Extra keyframes are not uncommon. I’ve worked with a lot of Flash animators and developers on litterally hundreds of projects over the course of the last decade, and I’d be lucky if more than 2% of all the FLA’s I opened up didn’t have half a dozen or more unneccessary keyframes. These little additions to your timeline might seem harmless, but when you open up an FLA that you need to make an edit on, your mind needs to take a moment to assess what each and every keyframe is doing. Have you ever looked at a timeline– even one of your own Flash animations– just to stare at it and wonder what the hell you were doing?

I’m a neat freak. I like speed and efficiency (thus the massive compulsion to create expansions to the Flash authoring environment). I’m not fond of killing even a minute of my time staring at a keyframe to understand it’s place in the animation I’m looking at, only to discover that the keyframe is an unneccessary extra. That is to say, if it didn’t exist, nothing about the animation would change. It is a worthless extra that clutters the view and slows me down.

I would ask my designers to clean up their timelines for this very reason, but sometimes it’s too tedious a task to be worth the effort. Well, not any more. This Flash CS3 Extension does it for you. I’ve wanted to do this for a long time and I finally built it. This JSFL command removes all unneccessary duplicate keyframes from the currently selected timeline, and I’m not just talking about blank keyframes. I’m talking about ALL keyframes, whether the keyframe is in the midst of a shape or motion tween or not.

To run the command, simply select the layers you want to remove duplicates from, choose the FlashWhip DupeFramesRemover option from the commands menu, and bam– it remove all the un-needed additional keyframes. I’ve tested it a bit and it works quite well, only removing extras. When your done, your timeline looks much cleaner, is way easier to understand, and yet runs exactly the same.

This command is very careful not to remove a keyframe if it would change an animation in any way. It looks at every aspect of the keyframe down to the filter settings of any instance, instance names — it even examines the tween sequences and the frame labels, sounds, and actionscript. If it compares text, it compares the text formatting as well.

There are TWO EXCEPTIONS TO BE AWARE OF:

• ActionScript: The Flash Extension doesn’t treat identical frames with identical actionscript on them as duplicates. This is because it doesn’t assume to know the intentions of the programmer. Often one might find a sequence of blank keyframes containing identical “stop();” scripts, for example. (When examing Flash keyframe code for duplicates I thought it a bad idea to just wing it.)
• Sounds: In addition, the two identical frames with identical sounds are not seen as extras. This is because the extension considers the fact that you might have several identical sounds played back to back on the same layer.

That said, knock yerselves out. The new expansion to the my JSFL collection is available on the free Flash extensions page.