setChildIndex on timeline childs

[80prozent]

Description

When script modifies child-index of a child added by timeline, it breaks the timeline playback.
Our timeline internally uses depth-id and sessionID to decide how existing objects on timeline are updated. setChildIndex seem to also modify the depth-id of a object, so this breaks the timeline the next time the playhead is moved.

Platform

all

Steps to reproduce the issue

use setChildIndex on timeline-objects

cave-chaos had this issue: https://github.com/awaystudios/poki-conversions/issues/3
but the swf is already fixed to not use setChildIndex anymore

Expected outcome from steps

to be investigated thouroughly by test-swfs (how exactly does FP handle this)

Actual outcome

timeline breaks

[nanjizal]

Timeline refresh of the flash player is discussed here, I don't know if this is relevant or helpful?
http://www.senocular.com/flash/tutorials/depths/?page=2

[80prozent]

Hey

Thanks for the link. Its definitive usefull information, but i think this article deals with AS2 (AVM1) only (?)

its still worth to double check that our behavior for AVM1 matches what is descripted there (it should be at least very close), but i think for AS3 (AVM2) there will be differences to be aware of and to adjust for.

AS3 ditched the whole getDepth concept of MovieClips, and handles everything via the order of children-list. I think timeline still uses depth internally for adding / updating children, but the AS3 code only sees the final list of children and not the depth assigned to each child. So its still hard to exactly know how reordering the children-lists via code will effect the next timeline navigation.

[nanjizal]

AS3 was just icing for timeline stuff it was the same underneath, I worked quite a bit with timeline depths from flash4->AS3/AIR, I loaded swishmax ( as1/as2 ) and haxe and as2 movies into as3 and got code communicating.

Clients need to label every instance on every keyframe of any MovieClip you want to do any naughty depth mixing with dynamic generated Sprites, then they probably need to handle gotoAndPlay by removing sprites on the re-entry frame using onEventFrame ( was a long time ago ), it's a very tricky area and it's good the client has stopped doing it as it easy to create hard to track down bugs!

Definitely google Senocular he was the expert on depths for avm1 and avm2 and documented many of the players secrets.

[80prozent]

ye. i use Sonocular often as reference for figuring stuff out. espesially his order-of-execution article is very helpful.
but still nothing beats doing own in depth tests in FP to really check what is going on.

we figured as much about AS3 just using same timeline under the hood as good old AS2.

internally we are using 2 properties for childs on the timeline. the depthID (= depth like in AS2) and something called a sessionID (a child has a session-id, so that we can track it over its lifetime)

so atm, when we do any ordering of the children-list via as3 code, the depthID and the sessionID of childs do change, so the timeline no longer understands what was what, and starts messing things up.

this might turn into a fundamental problem with our timeline that will force us to refactor some aspects, but maybe if we are lucky, we will find a way to handle those reordering of children without messing up our current timeline logic.

not yet came around to do create meaningful tests for this as to figure out how exactly FP behaves :(