Yes, you could certainly put your random number into the HTML, but then you’d have to use JavaScript to produce that random number, which means you’d also have to use JavaScript to write out that part of the HTML. You could use the JavaScript document.write() method or DOM scripting to do that, or — since it’s a good idea to use something like SWFObject anyway — just use your JS-based Active Content workaround of choice to introduce the random number at that point (see my reply to Jeremy and Rich on April 2, 2007).

( param name=”movie” value=”yourMovieHere.swf?rand=[random number]” )
( embed src=”yourMovieHere.swf?rand=[random number]” )

That isn’t something I’ve definitively tried to nail down. Thinking back over my own experiences — happenstance, where I would partially download a video and recompile, because I was testing something else — I, too, would say I’ve had inconsistent results. In my own endeavors, the default buffer time is usually adequate; the minor pause before the video starts has been fine.

If you goal is to avoid the pause, I believe your best bet is true streaming, by way of Flash Media Server, Red5, and the like.

Wish I had a handy answer for you!

I have been trying with inconsitent results…

any ideas?

A compiler directive would be really nice for something like this, but the API provides a quick way to determine what mode you’re in. See the System.capabilities class, which has a static playerType property. An if statement is all you need:

if (System.capabilities.playerType == "External") {
  // this is the value for test movie mode
} else {
  // not in the IDE, so use cacheing workaround
}

Of course, that doesn’t provide a way to cause the hack to work locally, but it sounds like you’re just looking for a way to turn it on or off depending on the circumstances. (The funny thing is, I haven’t noticed the technique to fail locally, but I don’t currently run a server on my local machines.)

I think you’re asking how to keep ActionScript (.as) files from cacheing, but that’s not what AS files do — in fact, they shouldn’t be on the server at all. The #include directive in ActionScript is significantly different from the concept of includes in PHP or ASP. In the latter, include files percolate to the pages that call them as soon as they’re uploaded. In ActionScript, code is compiled, or “baked,” into the SWF at compile time, at which point it becomes immutable.

I’ve seen many developers update the contents of an AS file, then upload that AS file to the server, hoping the SWF will look to the update and behave differently, but #include only works at compile time. It literally copies/pastes the AS file’s content into the FLA as if you had typed it there by hand … only as the SWF is generated. If you want to pull in data at runtime, you’ll have to read the contents of a text file that stores name/value pairs in the same format as a query string, or read the contents of an XML file, or hit a database, etc.

Does that make sense?

My code in frame 1 (of 1) is:

> #include “test.as”
> bar.text = ‘working’;

test.as code is:

> foo.text = ‘bar’;

I run the movie and get ‘bar’ and ‘working’. Great. I change test.as to:

> foo.text = ‘bar2′;

and I still get ‘bar’ and ‘working’. No amount of cache clearing or restarting will clear it up.

I think it’d make a great blog post if you can solve it. The Google, she does nothing.

–Shawn

To add a random number to the HTML itself, you’ll need to use JavaScript. The least complicated way I can think of is to use an approach that already uses JavaScript to embed the SWF, such as Geoff Stearns’ SWFObject. Scroll up just a bit and see my reply to Jeremy and Rich (April 2, 2007) and you’ll see an example.