Hi,
At 11:29 AM 5/3/2002 -0500, you wrote:
>> I do understand what you mean. It is not necessary to use a few frames
>> when one would suffice.
>>
>>However, if I wanted a sound file to finish playing how do I do it?
>>
>>I can�t use a frame script
>>
>>on exitFrame me
>> go the frame
>>end
>>
>>because it loops.
>
>Quickest way would probably be to set a cue point in the tempo channel,
>telling Director to hold on that frame until the sound was finished playing.
To set a cue point, I need to set the cue points in an external program
like Cool Edit first, then re-import the sound file right? If I am
unable to do this, are there any other suggestions?
>>What is the purpose of using a timer in Director?
>
>Um, timing things. ;)
I gather that you seldom use timers, if at all.
> From the help file:
>>
>>If multiple timers are required, you must create and manage your own.(�)
>>Typically, you use the ticks property to track time in this manner.
>>
>>Is this the reason why timers should not be used ?
>
>There's no reason they shouldn't be used. There's nothing wrong with
>timing things. Sometimes you have to time things. (Like if you are making
>a quiz game and you want to give the user 30 seconds to answer a question.)
Thanks, I understand this. But what did Irv mean, when he wrote this:
�If you are doing timing somewhere else in your program, then there might
be an interaction�? Does he mean a conflict?
I hope you don't mind answering this.
>>What is the difference between endSprite and exitFrame?
>
>With a one-frame span you might not think it, but endSprite happens only
>once -- when the playhead leaves the frame containing that behavior.
>exitFrame happens, in essence, when the playhead is *about to* leave that
>frame. So an exitFrame script that contains 'go to the frame' will keep
>your playhead there until you explicitly send it someplace else -- but
>also will *not* result in endSprite executing until *after* the playhead
>has been ordered to go elsewhere.
>
>Try this, for instance. Put the following behavior in your script channel,
>spanning across perhaps half a dozen frames:
>
> on exitFrame me
> put "exiting frame"
> end
>
> on endSprite me
> put "ending sprite"
> end
>
>...When you click play, you will see a half dozen frame-exit messages, but
>only one endSprite message.
Yes, I see that.
>[Note: If you put the above into only one frame script channel, and then
>copy and paste that so they *appear* to span across half a dozen frames
>immediately adjacent to each other, you will get different results. Try it
>and see, and think about what happened and why.]
This is the result I received:
frame exit, endSprite, frame exit, endSprite, frame exit, endSprite,
frame exit, endSprite, frame exit, endSprite, frame exit, endSprite
frame exit, endSprite occurs six times.
endSprite happens only once in a single frame span. exitFrame happens
when the playhead is about to leave the frame. And as each frame is a
copied and pasted behavior, you have in essence provided six
�different� behaviors in six frames. Even though technically it is the *
same * behavior.
>Now if you modify the above a little, you'll get another result:
>
> PROPERTY pnFrameCount
>
> on beginSprite me
> pnFrameCount = 0
> END beginSprite
>
> on exitFrame me
> pnFrameCount = pnFrameCount + 1
> if pnFrameCount < 6 then
> put "looping frame"
> go the frame
> else
> put "exiting frame"
> go ( the frame + 1 )
> end if
> end
>
> on endSprite me
> put "ending sprite"
> end
>
>Put this into just one frame script channel and play.Again you will see
>different results from what you've seen until now.
1a. This is what I see:
looping frame, looping frame, looping frame, looping frame, looping
frame, exiting frame, ending sprite
5 looping frames, 1 exit frame , 1 ending sprite in this order.
I get this result because you write that the pnFrameCount on exitFrame
adds an additional looping frame to it if it is below six. If it
reached six, this stopped and exiting frame was
placed. endSprite happens only at the end of the frame span, so it always
appears last.
>Now span the above script across several frames and play, and see what
happens then.
1b. looping frame, looping frame, looping frame, looping frame, looping
frame, exiting frame, exiting frame, exiting frame, exiting frame, exiting
frame, exiting frame, ending sprite
5 looping frames, 6 exit frames, 1 ending sprite in this order.
I think that exitFrame occurs six times because you put the line go (
the frame + 1 ). And so when exiting the frame, it appeared. It appeared
six times because there are six frames. But I think I am wrong, as
exitFrame happens when the playhead leaves the frame?
endSprite occurs at the end of the frame span i.e. it appears once only, as
the behavior spanned six continuous frames.
>Finally, copy and paste the above script into adjacent frames so they
*appear* to be spans of one behavior, but are not. Play again.
>Compare the results.
1c. looping frame, looping frame, looping frame, looping frame, looping
frame, exiting frame, ending sprite . And this loop appears a total of six
times.
5 looping frames, 1 exit frame , 1 ending sprite, 5 looping frames, 1 exit
frame , 1 ending sprite, 5 looping frames, 1 exit frame , 1 ending sprite,
5 looping frames, 1 exit frame , 1 ending sprite, 5 looping frames, 1 exit
frame , 1 ending sprite, 5 looping frames, 1 exit frame , 1 ending sprite
in this order.
I think it is the repetition of the one frame script (1a) six times which
produces this result?
>This should illustrate how Director handles exitFrame events as compared
>to endSprite events.
endSprite occurs once only at the end of the frame
span. exitFrame happens whenever the playhead leaves a frame. So if there
are six frames, there will be six exitFrames and only one endSprite.
>[Note: Instead of the line "go ( the frame + 1 )", you can put in the word
>HALT (look the keyword up in the docs). Try it and see what happens. How
>does this affect endSprite? *Does* it affect endSprite?]
To HALT is to stop the movie in author-mode. It stops the playback of the
movie without quitting Director.
If I use this in a single frame, this is the result I receive:
looping frame, looping frame, looping frame, looping frame, looping
frame, exiting frame, ending sprite.
5 looping frames, 1 exit frame, 1 ending sprite.
The playhead stops at the next frame. So HALT doesn�t affect
endSprite. But I am not sure why- is it because of the loop?
If it stretches across half a dozen frames:
looping frame, looping frame, looping frame, looping frame, looping
frame, exiting frame, ending sprite.
5 looping frames, 1 exit frame, 1 ending sprite.
The playhead stopped immediately on the next frame and stopped executing
the rest of the commands.
It is different when compared to 1b above. Is it because the HALT stopped
the execution of further commands? But the endSprite command still
executed? I�m guessing here - because there is a loop in the script?
If I copied and pasted it six times,
looping frame, looping frame, looping frame, looping frame, looping
frame, exiting frame, ending sprite, ending sprite?
5 looping frames, 1 exit frame, 2 ending sprite
Why are there two endsprites before the playhead stopped? So HALT does
affect endSprite? Is it in essence because of the six so-called
�different� behavior scripts? (or rather more than one?)
I see it but I do not understand why�
Thank you. I appreciate your asking me to try this. I am learning more,
much more than when you just simply provided an explanation.
It does take time to do the exercises but I believe I am all the richer for it.
I think I can answer the question myself now. This is how the script
should look like (for a single frame span).
property pEndTicks
on enterFrame me
pEndTicks = the ticks + (4*60) -
end
on exitFrame me
if the ticks < pEndTicks then
go to the frame
end if
end
This is because I wanted the playhead to go to the next frame. If the
ticks have not reached the required number (4*60), there is a loop on the
frame.
And once the ticks has reached the required seconds (4*60) it will exit the
frame and move forward to the next frame. Is this correct?
>>OnGetPropertyDescriptionList is a system handler. What does this mean?
>>So there are different types of handlers?
>
>There are indeed. At minimum there are handlers *you* define, such as the
>custom ones I made in the volume behavior; and ones that Director is
>designed to recognize, such as frame, sprite and mouse events. Of the
>latter I believe Macromedia has created several distinctions, but I'm not
>sure how well defined those distinctions are.
Sorry, but what do you mean by these distinctions are not well defined?
A frame event occurs within the frame?
A sprite event occurs within the sprite?
A mouse event occurs when I do something with my mouse?
Is there is a difference between a handler and an event?:
If �on mouseUp� is a handler, then what is a mouseUp? Is there such a thing?
Noelle
[To remove yourself from this list, or to change to digest mode, go to
http://www.penworks.com/lingo-l.cgi To post messages to the list, email
[EMAIL PROTECTED] (Problems, email [EMAIL PROTECTED]). Lingo-L is for
learning and helping with programming Lingo. Thanks!]
