[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnash-dev] Re: gotoAndPlay bug in Gnash
From: |
strk |
Subject: |
Re: [Gnash-dev] Re: gotoAndPlay bug in Gnash |
Date: |
Wed, 9 May 2007 23:59:21 +0200 |
On Wed, May 09, 2007 at 11:13:31PM +0200, Udo Giacomozzi wrote:
> Hello strk,
>
> Wednesday, May 9, 2007, 10:26:20 PM, you wrote:
> >> when jumping from frame 4 to frame 14 (or the other way round), there
> >> won't be a instance "B" created at any time.
>
> s> Please test this by adding load and unload event handler to clip B.
>
> Confirmed.
>
> s> I mean *clip* events (those found in the PlaceObject2 tag).
>
> Huh? I simply added trace()s to the three different sprite
> definitions.
Find some way to define a "CONSTUCT" event handler.
You can use Ming's 'listswf' to verify it's an onConstruct handler and
not a DOACTION block defined in the first frame.
> >> - instances *created* dynamically never care about gotoAndXXXX
>
> s> dynamically-created instances do NOT have a timeline.
> s> Their frame count is always 1. Single-frame. gotoAndXXX makes no sense.
> s> Just to make your statment above stronger and fixed in mind.
>
> Hold on, I'm talking about *instances*. When you call attachMovie() in
> _root, and do _root.gotoAndPlay() to an earlier frame, then that
> instance will be still there.
Right, dynamically instances do can be multiframed then. Sorry.
The "never care about gotoAndXXXX" was unclear, as gotoAndXXXX
is applied o a target. You're talking about applying to the instance
parent. Let's rephrase:
- instances *created* dynamically never care about gotoAndXXXX
applied to their parent
> - unless you give it a depth < 0 (just checked).
Oookey. I tried giving *statically* created instances a dapth > 1
instead. And they don't care either.
So I guess this reduces to:
- instances at depths > 0 never care about gotoAndXXXX applied to their parent
Which is, from the wiki:
2. Remove from m_display_list all chars in the "static depth zone"
except the ones found in step 1
Let alone the exception, but we never talk about removing chars in the "dynamic
depth zone",
which is equivalent to say that instances at depths > 0 (dynamic depth zone)
are immune
to this.
Right ?
> s> Instances created statically, which we called "Timeline instances" on
> s> the wiki page, are the ones created by PlaceObject{,2,3} tags.
>
> Right.
>
> s> They are instances of *definitions* created by definition tags
> s> (DefineSprite, DefineTextField, ...).
>
> Right, but dynamic instances can be defined by DefineSprite too (when
> exported).
Confirmed (wasn't considering duplicateMovieClip and attachMovieClip).
> s> Definition tags declare dictionary items (templates/classes).
> s> Control tags create instances of those classes/definitions, and control
> s> their aspect and lifetime.
>
> I thought you call these "events" ?
Yes, I think we called control tags "events" on the wiki.
> s> Removal and modification of instances trough control tags always use
> s> the "Timeline instance" *depth* as the identifying key.
>
> In a SWF file, yes, but have a look at the wiki. Even when the depth
> is changed by the script, then the control tags still influence the
> instance.
The results of your tests are still higly experimental I'd say.
The only two cases in which "did move?" is true are weird
(moved in frame 15 ??).
Take a look at my latest test (displaylist_depths_test2.swf).
It shows that a control tag (PlaceObject2 with MOVE flag) can
not find the instance it meant to refer to since it was moved
to another depth (yes, a dynamic zone depth, should add a test for
a static zone depth next).
> s> For example, a RemoveObject tag will say to remove the instance
> s> at depth 5 from the stage.
>
> It also removes it when you do swapDepth(9) before!
>
> So: it's *not* simply identified by the depth at *play* time.
Are you sure ? :)
Did you dump the actual SWF to see what it contains ?
The RemoveObject tag (SWF1..2) contains both 'character id' and 'depth' fields.
The RemoveObject2 tag (introduced in SWF3) contains only 'depth' field.
--strk;
- Re: Re[2]: [Gnash-dev] Re: gotoAndPlay bug in Gnash, (continued)
- Re: Re[2]: [Gnash-dev] Re: gotoAndPlay bug in Gnash, strk, 2007/05/09
- Re[4]: [Gnash-dev] Re: gotoAndPlay bug in Gnash, Udo Giacomozzi, 2007/05/09
- Message not available
- Re: [Gnash-dev] Re: gotoAndPlay bug in Gnash, Eric Hughes, 2007/05/09
- Re[2]: [Gnash-dev] Re: gotoAndPlay bug in Gnash, Udo Giacomozzi, 2007/05/09
- Re[2]: [Gnash-dev] Re: gotoAndPlay bug in Gnash, Eric Hughes, 2007/05/09
- Re[3]: [Gnash-dev] Re: gotoAndPlay bug in Gnash, Udo Giacomozzi, 2007/05/09
- Re[3]: [Gnash-dev] Re: gotoAndPlay bug in Gnash, Eric Hughes, 2007/05/09
- Re[4]: [Gnash-dev] Re: gotoAndPlay bug in Gnash, Udo Giacomozzi, 2007/05/09
- Re: [Gnash-dev] Re: gotoAndPlay bug in Gnash, strk, 2007/05/09
- Re[2]: [Gnash-dev] Re: gotoAndPlay bug in Gnash, Udo Giacomozzi, 2007/05/09
- Re: [Gnash-dev] Re: gotoAndPlay bug in Gnash,
strk <=