This content has been marked as final. Show 6 replies
"I would've thought that things like loc would not carry over on the
channel between different sprites, but apparently that's not the case."
I have never experienced Director working this way. I too have used many
times the beginSprite event to store a sprites initial location without
ever a problem. You can build a simple movie in 5 minutes to prove this
is not the case.
My suspicion is that your trouble lies elsewhere.
> I have never experienced Director working this way. I too have used many
> times the beginSprite event to store a sprites initial location without
> ever a problem. You can build a simple movie in 5 minutes to prove this is
> not the case.
> My suspicion is that your trouble lies elsewhere.
It does seem to occur mostly when both the old and new sprites have a
homeLoc property on them. (Sometimes from the same behavior, sometimes
not.) Could that be carrying over, maybe? I can't think of anything else
that would be causing this. Even if the sprite were scripted to return to
its homeLoc on exitFrame (which it's not), the score's default location
should come into play before the new sprite's beginSprite code runs, but
that doesn't seem to be happening.
It shouldn't matter if it's the same behavior or not (of course we all
know about the theoretical).
If you haven't done so yet, try adding sprite(1).homeLoc (or whatever
channel you want to monitor) to the Watcher window and run your movie.
If the value of the sprite's property does not change when a new sprite
appears in the channel then something weird is going on. Put a break
point on the first line of the beginSprite handler to make sure the
handler is getting triggered. Step through the script, and verify that
the line that sets the property is being executed.
If things aren't working as expected, then perhaps you have stumbled on
a bug, or maybe your movie is somehow corrupt? The beginSprite event is
the first (I think) event when Director plays a frame so I can't imagine
what could possibly interrupt it. Perhaps someone more knowledgeable can
provide an answer.
Definitely let us know what you find out! Best of luck.
I ran a quick test and this strikes me as a bug.
If you jump between two sprites in the same channel and they are set to "Moveable" then the sprite you jump to picks up the location of the previous sprite.
One solution is to turn off Moveable in the sprite inspector and use the following:
on beginsprite me
pMe = sprite(me.spriteNum)
pHomeLoc = pMe.loc
pMe.moveableSprite = true
As for not being able to use the Visible property because it affects the entire channel, just set it to true on endsprite.
on endSprite me
sprite(me.spriteNum).visible = true
The endSprite event will be called on all sprites before jumping to any marker and calling beginsprite on the new set of sprites.
Nice catch. I had missed the part about the sprites being moveable. If
both sprites are moveable, then indeed the loc property does not change.
If either sprite is not moveable, then the loc property does change as
you would expect. And it has nothing to do with the begonSprite event,
as the same bug occurs if you set the prop with enterFrame. I have to
agree with calling it a bug. Good solution too...
Sure enough, that was the problem, I think. At least it seems to be fixed
now. I've added:
sprite(me.spriteNum).moveableSprite = FALSE
to each of the behaviors on the moveable sprites, and it seems to do the
trick. The thing was, the bug was happening even if the new sprite was NOT
a moveable sprite. The old sprite's moveable status apparently carries over
into the new sprite even if it's not itself moveable. At least I'm glad to
discover it's a bug and not just sloppy coding on my part as usual. (Not
that I'm glad there's a bug, but I feel better knowing the mistake wasn't