Dynamic Flash

I’ve created a Python script that will output ’simple’ swfmill XML, allowing you to pack whole directories of GIF, JPEG, PNG and SWF assets into a shared library swf with the minimum of fuss.

Download library.py 0.1

Usage


library.py [options] [paths]


Options

-r, --recursive

Include subdirectories of [paths] in the search for assets.

-c ID, --clip=ID

Create an empty clip with an id of ID. You can have as many of these arguments as you need.

-e ENC, --encoding=ENC

Use ENC as the encoding XML declaration attribute value. Defaults to iso-8859-1.

Assets are exported with an id of the base part of the filename, so a file called DynamicFlash.png will have an id of DynamicFlash.

Examples

To generate ’smple’ XML for all the assets in a folder called ‘assets’, including subfolders:

> library.py -r assets
<?xml version=”1.0″ encoding=”iso-8859-1″?>
<movie width=”1″ height=”1″ framerate=”12″>
  <frame>
    <library>
      <clip id=”at” import=”assets/at.png”/>
      <!–– more ––>
    </library>
  </frame>
</movie>


This will output the XML to the command line, which isn’t exactly useful except to make sure that the script is behaving as it should. If you get an error message instead of XML you may need to invoke Python manually:

> python library.py -r assets
<?xml version=”1.0″ encoding=”iso-8859-1″?>
<movie width=”1″ height=”1″ framerate=”12″>
  <!–– etc. ––>
</movie>


Once you manage to get some likely looking XML, run the command again, this time redirecting the output to a file called library.xml:

> library.py -r assets > library.xml


…and then using this file to feed swfmill:

> swfmill simple library.xml library.swf
swfmill 0.2.2
Reading from library.xml
Writing SWF to library.swf
SWF saved to library.swf (457775 bytes).


Congratulations. If your output from swfmill looks like the above, you’ve just created a shared library swf file packed with all your assets.

You can avoid having to create an intermediary XML file by piping the output directly into swfmill:

> library.py -r assets | swfmill simple stdin library.swf
swfmill 0.2.2
Reading from stdin
Writing SWF to library.swf
SWF saved to library.swf (457775 bytes).


The key here is the second argument to the swfmill command. Usually swfmill required you to specify the name of an xml file to parse here, but stdin tells swfmill to parse the standard input stream instead. Using a pipe (denoted by the | symbol) we direct the output of library.py to the input stream of swfmill, cutting out the need for an intermediary file.

END

That’s all the documentation I’ve got time for. Have a play around, and if you’ve got any suggestions or feedback them please let me know via the comments here.

I’ve compiled MTASC 1.04 for linux and created a binary package. Download MTASC 1.04 for Linux. If you’re an OS X user, see my MTASC 1.04 OSX package entry.

For more information about MTASC, visit mtasc.org.

Niclas Cannasse has just released MTASC 1.04. As usual I’ve compiled MTASC on OS X and created a distribution package. Download MTASC 1.04 OS X.

What’s new?

• for optional first parameter and expression
• fixed while( o )++ i;
• added error when duplicate import statement (with same or different
  package)
• added class-exist import check
• import will now link classes
• fixed typing error with single var in a block
• fixed parser error with a ? b : c and big left-expression
• fixed bug when catching “imported” exception class
• changed boolean operators typing
• added -flash6 for F6 compilation
• added -trace for custom trace function
• added optional color component for -header

See mtasc.org for more info.

– Update –

I have updated MTASC 1.04 OS X to reflect the updated Nicolas has just made to the MTASC source code that fixes a few important issues…

• The bug in MTASC 1.04 have been found and fixed, it was some quick and dirty
  buggy in-memory mutation when handling catch clauses.
• A && B and A || B types as the most common type between A and B. That means that 0 || true type is Object, and that still if B extends A, you have B || A type is A.

I would recommend redownloading this release.

Like most Flash developers I have procrastinated over the quality and efficiency of Macromedia’s V2 Component Set. And like most Flash developers, I tell myself that I don’t have the time to do anything about it. Well, thankfully we’re not all like that. Introducing ActionStep.

ActionStep is an Actionscript 2.0 implementation of a subset of the OpenStep Application Kit. The intent is to create an open-source component framework for writing Rich Internet Applications for the Flash Player.

Though the project hasn’t yet released any code, it looks like something worth keeping an eye on.

[via Darron Schall]

A while back I came across an obscure bug with the type checking in Macromedia's Actionscript compiler. It seems that the compiler calculates that the result of a boolean expression involving only getter functions is of type Function.

Take the following class:

If you try and compile this, you will get the following error:

**Error** [...] Test.as: Line 14: Type mismatch in assignment statement: found Function where Boolean is required.
var test:Boolean = field1 || field2;

This only seems to be a compile time checking issue. If you remove the data type from the test variable the code will compile fine, and the trace statement will output true as it should.

Changing line 14 to...

...seems to fix the problem.