This content has been marked as final. Show 14 replies
Look about the setInterval function.
Place this script on the very first frame of your animation on the main time line:
then on the very last frame, where you want to pause to happen, put this script:
I tried your script. No errors, but the resulting animation didn't change.
My first frame (main timeline) looks like this:
...and my last frame on the main timeline looks now like this. Perhaps I should delete the Play and Stop lines that were there from the beginning?
arunbe: You are not connected right now to your messenger... Have you got ten minutes for a quick guided tour? : )
Hey Mosh, this is the sort of thing that I like to do with reusable code instead of just hard-wiring in a solution. Try sticking the attached code somewhere in the first frame of your movie. Then, where you want to pause, just type something like:
This should automatically stop() the current timeline, then issue a play() command two seconds later.
By default the play head on your main time line will start to play without any instruction. In fact it will "loop" without any external help unless you tell it otherwise.
If you want to be sure that your animation plays all you need is "play()" or even "this.play()" but the result is the same. "this" is refering to _level0 if you did put a trace on it.
So, replace your "gotoAndPlay(1)" with "play()" on the very first frame
on the very last frame remove the "gotoAndPlay(1)" as you are now controling this action on the call back function within "executeCallback()".
I know it says "play()" in the function that has been created, which is fine, but you can change that to "gotoAndPlay(1)" if it helps you to understand it a little better.
All we are doing here is establishing the function at the start and calling it into action when we need it. It does nothing until we call it in the final frame with:
intervalId = setInterval(this, "executeCallback", seconds*1000);
The "stop()" function on the final does what it says on the tin. It stops the play head dead in its tracks and then the play head waits for something to tell it to do something else. Hence the "intervalId" declaration.
So in short all we are doing here is sticking an object into "intervalId" that says "trigger the executeCallback() function" after " seconds*1000" (the 1000 is being used here becuase Flash works with milliseconds) has gone by. And the reason why this is saying this is because we have passed 3 parameters into the setInterval() function. Hence >>>this, "executeCallback", seconds*1000<<<. Strange though why you dont need to include the "()" right after "executeCallback". But hey it works.
Thats a more effective way of doing it ClayHalliwell true but then its a real head **** trying to understand the principals of prototype's.
I don't want to seem rude, but adding a method to the prototype of the MovieClip class is VERY bad form. DazFaz is also right. It's confusing. In OOP programming terms it is called "breaking encapsulation. " Besides being "worst practice" Messing with the prototype chain is really a holdover from ActionScript 1. Certain classes like MovieClip are "dynamic" meaning that you can add members (functions and variables) to the class its self not just instances (or objects) derived from the class. Because of the nature of mo0vie clips, this was necessary. But good programmers use inheritance in a more traditional way - make a new class extend MovieClip.
The thing to do is to build your delay mechanism into the body of the function that you're calling with setInterval().
Originally posted by: sl0beck
But good programmers use inheritance in a more traditional way - make a new class extend MovieClip.
That may be fine for wannabe Java coders, but when you're writing functions for use by a team of programming-illiterate graphic designers, extending Flash in the most transparent way possible is the way to go. Perhaps it's not OOP best practice, but doing it the "right way" yields so much cruft that the functionality ends up not getting used at all.
Besides, teaching the MovieClip class new tricks is great fun!
Still, if you're making any attempt to be a programmer, best practices are more than a nicety. Why teach a new dog bad tricks? It just creates bad habits which lead to bad code, which leads to greatly increased debugging time which leads to headaches and angry co-programmers;. If a trick like adding methods to the prototype of a class was the ONLY way to do something, then sure by all means use it. But that's not the case here, and the "right way" in this case is quite simple.
DazFaz, thank you for your simple explanation: much appreciated. Arunbe was kind enough to contact me via IM. I sent him my file and he attached a piece of script, so it now does what I wanted.
Sl0beck: thanks for your patience. Your message was a little too technical for my programming-wise ignorant self, but I thank you anyway.
Clay: A heartfelt thank you for the script and the explanation.
My problem is resolved, but I will save your responses to study them, as well as the logic behind the script that Arunbe gave to me.
You are very welcome Mosh. Always remember "simple is best"