Re: [Gnash-dev] Re: gotoAndPlay bug in Gnash

[strk]

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;