Loader.close(): Does It Work or Not?

The short answer: Yes and no.

Or slightly more accurately, No and yes.

Confused? As was I. On to the long answer (don’t worry, not as long as is usual for me):

The addition of the close method on the Loader class is pretty great. We can now finally stop a load in progress if, for whatever reason, we deem it necessary. Maybe the user changed her mind and clicked another button while one SWF (no longer needed) was loading. Maybe we want to do something tricksy like start loading an asset, but not fully, to get the bytesTotal.

MovieClipLoader in AS2 had unloadClip, and you could interrupt a load in progress by telling it to load a non-existant URL into the same clip…but this is agreeably messy. So hurrah for Loader.close!

Except…if you try it out, it most likely won’t work. Create a simple test FLA with a clip set to be a button, called “btn_mc” and add the following code to the first frame:

var l:Loader = new Loader();
addChildAt(l, 0);
l.load(new URLRequest("path/to/some/large/asset.swf"));

btn_mc.addEventListener(MouseEvent.CLICK, doit);

function doit(me:MouseEvent):void {
	trace('doing it');
	l.close();
}

Now test the SWF, and then enter bandwidth simulation mode (press Command/Control-Enter again), and while the asset is still loading, click the button. But wait for it…and you’ll see it show up anyway? Wisconsin Tourism Federation? (work out the acronym…)

This is the “no” in the “no and yes” answer. I put the “no” first because this is likely the first thing you’ll try when working with Loader.close. So what about that “yes?” Is there some extra step to take? Some undocumented feature to enable?

No, it’s even simpler than that. You need to load your asset from a server.

Replace the “path/to/some/large/asset.swf” with “http://some.domain/path/to/some/large/asset.swf” and you should be good.

Needless to say, this can be the source of confusion. I don’t know what makes an HTTP stream different from a local file stream, but I concede that there are differences and that that probably accounts for this behavior. But it sure would be great if this behavior were mentioned in the documentation. It would be even better if this method just worked. Why can’t we close a Loader when loading an asset locally? This is how 99% of our development takes place; we almost always use a relative path to the asset, and we almost always develop on our local boxes without worrying about servers initially.

DisplayObjects Round Their X and Y Properties, Makes Brownian Motion Difficult

Earl and I just hammered out a weird issue in some code that involved Brownian motion. Check this out, assuming p is a MovieClip on the stage:

addEventListener(Event.ENTER_FRAME, animate);

function animate(e:Event):void {
    p.x += Math.random() * 2 - 1;
    p.y += Math.random() * 2 - 1;
}

Seems simple enough, right? The particle p should move randomly, and produce what is called “Brownian motion.” It should wander, but ultimately stay within a general area, on average.

However, if you let it run long, you’ll find the particle tending to gravitate to 0, 0. If you’re impatient, you can speed up the process like this:

addEventListener(Event.ENTER_FRAME, animate);

function animate(e:Event):void {
    for (var i:int = 0; i < 100; i++) {
        p.x += Math.random() * 2 - 1;
        p.y += Math.random() * 2 - 1;
    }
}

After trying quite a few things, we eventually tried the following:

addEventListener(Event.ENTER_FRAME, animate);

var realX:Number = p.x;
var realY:Number = p.y;

function animate(e:Event):void {
    realX += Math.random() * 2 - 1;
    realY += Math.random() * 2 - 1;
    p.x = realX;
    p.y = realY;
}

Again, you can wrap that up in the loop to speed things up.

Either way, you’ll notice that we get proper motion now. What gives?

Well, the suspicion that lead to us trying that was confirmed when we added a trace:

addEventListener(Event.ENTER_FRAME, animate);

var realX:Number = p.x;
var realY:Number = p.y;

function animate(e:Event):void {
    realX += Math.random() * 2 - 1;
    realY += Math.random() * 2 - 1;
    p.x = realX;
    p.y = realY;

    trace(realX, p.x);
}

You’ll see something like this:

310.60525778401643 310.6
311.387398567982 311.35
312.1899666218087 312.15
311.5306175108999 311.5
311.22865250799805 311.2
311.0907105393708 311.05
310.28716491162777 310.25
309.4788754032925 309.45
309.128194604069 309.1
308.98307433445007 308.95
309.23653392959386 309.2
308.6192215178162 308.6
309.3771039834246 309.35

Check that out! The x property (and the y, too, we checked) is rounded internally to the nearest .05. Actually, it’s not even rounded, it’s floored (my assumption is that it’s just truncating some bits resulting in a floor effect, which would presumably be a faster operation that Math.floor).

So, basically, we’re talking about rounding errors that, when piled up, result in a gradual approach to 0. For example, say you start at 10. You generate your random number, and it’s -1.46. You take x property of 10, subtract 1.46, and you’d expect to end up at 8.54. Instead, you end up 8.5. Confirm it with the following code:

p.x = 10;
p.x += -1.46
trace(p.x);
trace(10 - 1.46)

A similar effect happens with positive numbers…you end up smaller than you think you will. Thus, a gradual approach to 0.

The fix involves tracking a high-precision Number value as the “real” x and y, and adding to that. Then, simply assigning that value to the MovieClip’s x and y still results in rounding, but without any cumulative effects. Anyone else remember the similar problem from ActionScript 2 days with _alpha?

My theory is that since there is a finite precision to Numbers, we’d still see a gradual approach to 0, only it’ll take MUCH longer.

So, I’m not necessarily pointing the finger at Adobe here and saying this is a bug; this is clearly intentional behavior, and 99% of the time you don’t even notice. But when you do have that situation where it matters, you need to know about it.

Beware of DisplayObject.getBounds

It may not be obvious until you actually make the mistake and spend half a day trying to find the miscalculation in what you thought was an intuitive use of flash’s built in tools. DisplayObjects have the getBounds method, allowing you to quickly retrieve a Rectangle object containing size and location properties pertaining to that object in relation to any other display object, whether on the stage or not. Passing a reference of a clip into its own getBounds method returns a rectangle complete relative to itself, very handy for quickly retrieving an object’s dimensions.

Be careful, however, because using this method of retrieving an object’s dimensions is very relative. When asked for dimensions relative to itself, a DisplayObject will return unscaled values. So if you’ve rescaled a MovieClip on the stage and plan to quickly pass around its size dimensions, you’ll be better off creating your own Rectangle than relying  on getBounds, especially when there’s a possibility that the object is not its original width or height.

Furthermore, it may be dangerous in a dynamic situation to simply getBounds against the object’s parent, and the object’s root property is only valid if the clip is somewhere on the stage. In these situations it may be best to either go through the extra motions of constructing your own rectangle or only use object.getBounds(object) when you’re positive the object is not scaled.

var square:Sprite = new Sprite();
addChild(square);
square.graphics.beginFill(0x0000FF);
square.graphics.drawRect(0,0,100,100);
square.graphics.endFill();
square.x = stage.stageWidth/2 - square.width/2;
square.y = stage.stageHeight/2 - square.height/2;

var b:Rectangle;
b = square.getBounds(this);
trace(b); // traces (x=225, y=150, w=100, h=100)

square.scaleX = 2;

b = square.getBounds(square);
trace(b); // traces (x=0, y=0, w=100, h=100)


So do not expect the second trace in this code block to return a rectangle with a width of 200. Being a completely relative call it will return the object’s independent width within its scaled universe. As I mentioned, it makes sense from an oop standpoint, but its easy to hope or expect a scaled return if you’re needing that returned in a situation.

Did You Know? Get Compiled Actionscript File Bytes via SWC Export

We’ve often gone about the run-around method to find out how many bytes a particular class or package of Actionscript files adds to a compiled swf. In the pre CS4 days (unless there was something of which we were unawares) we often created a new AS3 fla, imported and declared only the classes to be tested, and then compared the swf filesize to that of an empty swf. Not a terribly friendly method.

I haven’t seen a better method documented anywhere. Though I’ve recently found that Flash CS4 will include a list of compiled classes and their corresponding byte counts when using Generate Size Report. The trick, however, is that you also have to use the publish settings to automatically export a swc.

Here’s an example of a list of compiled classes produced when both “Generate size report” and “Export SWC” are checked:

Of course this could have been expected. A swc is just a zipped up swf and catalog.xml, listing all the compiled classes in the swf. I’m not sure why Flash doesn’t have a better system (and a more obvious reporting system) in the first place, but this hidden perk certainly reinforces the sensical quirkiness of the IDE we’ve all come to love over the years. The more you love the quirks, the more the IDE will love you back.

A Subtle SWFObject Situation

We’re working on a site right now whose individual pages are comprised of a stack of separately embedded swfs. Long story short, most of the content loaded into these swfs is dependent on particular flashVar data. Since I have one collection of variables intended to be global (passed into every embedded swf), I’d created a global generic object to store those name-value pairs and then assigned individualized objects per swf to the global object (var localObject = globalObject; ) before assigning that swf its unique properties. What I didn’t realize was that the JavaScript, of course, wasn’t copying the globalObject but simply referencing it, so by the time the entire page was computed there was still only one object, it just contained all properties that were suppose to instead be set per swf embed.

What this led me to illustrate through firebug introspection and flash tracing once the swfs were loaded was that even if a generic object was set with properties to be passed into a swfobject embed as flashVars, and then passed into that swfobject embed, any changes to that generic object after the embed will be reflected by the swf once loaded. So if I type in Javascript:

var flashVarsObject = {};
flashVarsObject.foo = "bar";
swfobject.embedSWF("example.swf", "example", "400", "300", "9.0.0", "expressInstall.swf", flashVarsObject);


… the flash trace for stage.loaderInfo.foo would be “bar”.
But if, after the swfobject.embedSWF call, I further set the foo variable, such as:

var flashVarsObject = {};
flashVarsObject.foo = "bar";
swfobject.embedSWF("example.swf", "example", "400", "300", "9.0.0", "expressInstall.swf", flashVarsObject);
flashVarsObject.foo = "fighters";


… the flash trace would be “fighters”.

FlashVar name/value pairs are apparently not passed in upon calling embedSWF, but rather, the flashVar object appears to simply be referenced. This of course makes just as much sense, but what seemed to make it out of place was that using firebug, I could see the actual <object> and <param> tags rendered by swfobject. At the core, thats really all swfobject does. What is strange about it is that a <param> tag includes attributes for “name” and “value”, appearing as literal strings when rendered. Somehow, this param tag synchronously represents the flashVars object passed into embedSWF, even though the param appears to be simple strings. Keep an eye out for this little catch, and of course its best to keep JavaScript objects well separated for this sort of use.

JSFL Script: Get ColorTransform

Here’s a real quick JSFL trick. We all know that working with color transforms in code is cool, except that it’s usually easier to design a transform using the Color: Advanced setting in the Properties panel. Here ya go:

var s = fl.getDocumentDOM().selection[0];

fl.trace("new ColorTransform("
            + (s.colorRedPercent   / 100) + ", "
            + (s.colorGreenPercent / 100) + ", "
            + (s.colorBluePercent  / 100) + ", "
            + (s.colorAlphaPercent / 100) + ", "
            + (s.colorRedAmount  ) + ", "
            + (s.colorGreenAmount) + ", "
            + (s.colorBlueAmount ) + ", "
            + (s.colorAlphaAmount)
            +")");

Just select an object and run the script. You’ll get a trace in the Output panel with the equivalent ActionScript ColorTransform. If you like, you can even modify it like so:

fl.trace(s.name + ".transform.colorTransform = new ColorTransform("

If you’ll be applying this ColorTransform to the instance you selected, rather than using the selection as a temporary guide.

JSFL Script: Move Registration Point

Ever make a symbol with the registration point in the, say, default top left corner, and then later realize you need it in the center for rotation or scaling purposes? But you’ve already placed the instance on stage where it needs to be, so not only do you have to move the symbol’s contents, you have to move the whole instance on stage by a complementary amount. Unless you have this script! Check it out:

fl.outputPanel.clear();

function run() {

    var e = fl.getDocumentDOM().selection[0];
    if (!e) return;

    var x = parseFloat(prompt("Enter new x:", e.x));
    if (isNaN(x)) return;

    var y = parseFloat(prompt("Enter new y:", e.y));
    if (isNaN(y)) return;

    fl.trace("Moving element from (" + e.x + ", " + e.y + ") to (" + x + ", " + y + ")");

    var diffX = e.x - x;
    var diffY = e.y - y;

    e.x = x;
    e.y = y;

    // Get the Timeline of the object in question.
    var tl = e.libraryItem.timeline;
    // Loop over the Timeline's Layers.
    var iLen = tl.layers.length;
    for (var i = 0; i < iLen; i++) {
        var l = tl.layers[i];
        fl.trace("Layer: " + l.name);
        // Loop over each Layer's Frames.
        var jLen = l.frames.length;
        for (var j = 0; j < jLen; j++) {
            var f = l.frames[j];
            // Don't mess with elements in frames that aren't keyframes...
            if (f.startFrame != j) continue;
            fl.trace("\tFrame: " + (j+1));
            // Loop over each keyframe's elements.
            var kLen = f.elements.length;
            for (var k = 0; k < kLen; k++) {
                // Move the element.
                var child = f.elements[k];
                fl.trace("\t\t" + child + " " + k + " :: " + child.name
                        + "("+child.x+","+child.y+") => ("+(child.x+diffX)+","+(child.y+diffY)+")");
                child.x += diffX;
                child.y += diffY;
            }
        }
    }
}

run();

Select an item (one item at a time, please, although it shouldn’t be hard to expand this to loop over every item in the selection, assuming you want to move a bunch of items by the same amount). You’ll be prompted for a new x and a new y. This is the x,y of the registration point of the instance. Plugging in new values that are, say, 100 pixels greater than the current values will move the symbol’s contents up and to the left by 100 pixels, while moving the instance down and to the right by 100 pixels. It even traverses the keyframes of each layer, so a timeline animation should get adjusted all at once.

A log of what happened will show up in your Output panel:

Moving element from (116, 148) to (216, 248)
Layer: Layer 3
    Frame: 1
        [object SymbolInstance] 0 :: (53.7,42.7) => (-46.3,-57.3)
Layer: Layer 2
    Frame: 1
        [object Shape] 0 :: (43.45,85.45) => (-56.55,-14.549999999999997)
Layer: Layer 1
    Frame: 1
        [object Shape] 0 :: (100.95,38.95) => (0.9500000000000028,-61.05)

It’s worked reasonably well for me so far, but this is one of those things where the logic is complicated enough to possibly fail in certain situations. If you run into such a situation, please let us know in the comments. I’d love to improve this script if it needs it.

JSFL Script: Find Instance in Library

We’ll just make this JSFL kick a mini-series. Here’s another handy script. I think I originally wrote this while working in Flash CS3, because Flash CS4 provides a “search in library” field. Even so, this can save a few steps. Simply select an instance on the stage, and run the script, and the instance’s symbol will be selected in the Library. One failing is that if the Library is not already showing, the script can’t do anything to open it. The item does get selected, though. You just need to open the Library manually.

// Get the objects we'll need to work with.
var doc = fl.getDocumentDOM();
var sel = doc.selection[0];
var lib = doc.library;

// Grab the name of the LibraryItem object of the current selection.
var libItem = sel.libraryItem.name;

// Take that name and split it into "crumbs."  If we have more than one
// crumb, the item is nested into a folder and we need to make sure
// the folder is expanded.
var path = libItem.split("/");
if (path.length > 0) {
    path.pop();
    var folderItem = path.join("/");
    lib.expandFolder(true, true, folderItem);
}

// Select the item.
lib.selectItem(libItem);

If anyone knows of a way to make sure the Library panel opens up, please leave a comment!

JSFL Script: Search Timeline Layers

Continuing on the theme from my last post on a quick JSFL script, here’s another one that can be handy when working in an unfamiliar FLA with tonnes of layers:

var doc = fl.getDocumentDOM();
var prevTerm = doc.getDataFromDocument("layerSearchTerm");
if (!prevTerm) prevTerm = "";

var searchTerm = prompt("Search timeline layer names for:", prevTerm);
doc.addDataToDocument("layerSearchTerm", "string", searchTerm);

if (searchTerm) {
    var term = searchTerm.toLowerCase();
    var tl = doc.getTimeline();
    var lyrs = tl.layers;

    var layerIndex = tl.getSelectedLayers()[0];
    var startIndex = layerIndex;

    do {
        layerIndex++;
        if (layerIndex >= lyrs.length) layerIndex = 0;
        var lyr = lyrs[layerIndex];
        if (lyr.name.toLowerCase().indexOf(term) > -1) {
            tl.setSelectedLayers(layerIndex);
            break;
        }
    } while (layerIndex != startIndex);

    if (layerIndex == startIndex) {
        alert("Search term \"" + searchTerm + "\" not found.");
    }
}

This will prompt you for a search term, and will then proceed to search through the timeline layer names for that term. When it finds one, that layer will be selected. If you run the search again, you’ll see your previous term still in the field. Just hit “OK” and the search will continue from the currently selected layer (that is, the first match).

I found this guy useful a few times when opening up complex files that I haven’t touched in a while. The 20 minutes it took to write has probably paid for itself by now.

JSFL Script: Sort and Name Clips from Left to Right

We’ve been neglecting our blog. For our regular readers, we apologize. We’ve been pretty busy lately, and while we should probably recount some of our recent adventures, I thought I’d kick things back in order with a quick post on a little JSFL script I wrote to help alleviate some pain in a recent task. Another win for automation; it took about 15 minutes to get the script right, and then proceeded to save me about 2 hours of manual work.

To use, first select a bunch of MovieClips on the stage, then run the script.

What will happen is that all of your clips will get named, starting with “item1” and incrementing the number until all items have been named.

More than that, though, it sorts the selection from left to right, so that

1. the item with the left-most x value is “item1”, and the item with the right-most x value is “itemN”
2. ActionScript code is printed to the Output panel that creates an Array and lists all of the clips by name, in order from left to right.

It’s easily modifyable, especially if your familiar with Array.sort’s compareFunction. Here’s the script:

var sel = fl.getDocumentDOM().selection;

sel.sort(sortByX);
function sortByX(a, b) {
    if (a.x < b.x) return -1;
    else if (a.x > b.x) return 1;
    return 0;
}

fl.trace("var clips:Array = [");

var iLen = sel.length;
for (var i = 0; i < iLen; i++) {
    var e = sel[i];
    e.name = "item" + (i+1);
    fl.trace("\t" + e.name + (i == iLen-1 ? "" : ","));
}

fl.trace("]");

Example output:

var clips:Array = [
    item1,
    item2,
    item3,
    item4,
    item5,
    item6,
    item7,
    item8,
    item9,
    item10
]