1

I'm looking for technical documentation on how Flash manages object instances with the same name across key frames.

So far, I've noticed that when the play head moves to another frame, if an object with the same name has the same type, then the instance is preserved along with its dynamically set properties.

On the other hand, as soon as the play head goes to a frame where the named instance is a different type, then it creates a new instance of the new type (with the original name), and the original instance of the old type is permanently discarded and all dynamically set properties on the named instance are lost (because it's a new instance).

If you go back to the original frame, it does not restore the original instance, but treats it as yet another change, and constructs a new instance again. Is there any documentation that describes this behavior?

Similar question on "continuity of timeline instances": http://www.kirupa.com/forum/showthread.php?t=316612 I too was surprised that properties carry over. It seems like a run-time feature, where Flash will create a new instance, only if the (instance name / symbol type) pair changes in the next key frame (i.e. if named instance "obj" refers to a "ball" in both keyframes, then it will remain the same instance; but if "obj" refers to a "square" in the next keyframe, then a new instance of "square" will be created). It makes sense, but is this behavior guaranteed?

Triynko
  • 18,766
  • 21
  • 107
  • 173

3 Answers3

2

This is too long to post in the comments, but I discovered various other behaviors using frame scripts.

So far, an object with the same instance name on different key frames causes new instances to be created only when we have:

  1. different symbol type or
  2. same symbol type and different layer
  3. navigate to an intermediate key frame that does not contain the object

In other words, as long as instance name, symbol type, and layer the object is on remains the same from frame to frame, and each frame contains the named instance, then filters and transforms alone won't cause new instances to be created.

Things get interesting when ActionScript is involved.

---If you REMOVE THE OBJECT WITH A SCRIPT:---

Same instance name, same symbol type, same layer:

  1. If you remove the object with removeChild on frame 1, then on frame 2 no new object is created. In fact, the old object still exists, but it's not visible and NONE of the transforms from frame 2 are applied (i.e. the object retains its original size, filters, etc.).
  2. If you remove the object with removeChild on frame 1, and then immediately re-add the object, then it persists and is visible in frame 2, but still NONE of the transforms from frame 2 are applied (i.e. the object retains its original size, filters, etc.).

Same instance name, same symbol type, different layer:

  1. If you remove the object, a new one is created on the second frame as expected, since it was on a different layer. Being on a differnet layer is almost a guarantee that a new object will be created as you will see from the next statement...

  2. If you remove the object then immediately re-add it (removeChild(obj); addChild(obj);), then you end up with a DUPLICATE, because the new instance with new transforms on frame 2 is still created AND the original object remains (whereas if you had not removed/added it, the key frame change would have destroyed it).

Summary

Across key frames, the only things that will trigger the creation of a new object with the same instance name is if the object has a different symbol type or is on a different layer, or you visit a key frame that does not contain the object and then return to one that does. Nothing else will cause a new instance to be created. Removing the object with ActionScript (even if you immediately re-add it), will cause the player to NOT apply new key frame transformations to the object, but in and of itself will not trigger the creation of a new instance.

Triynko
  • 18,766
  • 21
  • 107
  • 173
1

It isn't a documented behavior but your observations are correct. However, there's a potential snag that can happen to you if your two objects that share the same instance name are of incompatible types in that Flash might try to coerce the second (or all following) into "being" or trying to act like the first one it found. This may have been particular to fp9 but the behavior was 'scarring' enough to advise that you should NEVER have two different objects share the same instance name on the same timeline.

You might want to look at This blog entry on timelines and instance names that I wrote about the subject for a little more illumination.

One other thing that I may or may not have touched on adequately though, is that this behavior can also wreak massive havoc if you've nested timeline sounds in any movieclip that might be "skimmed" over if you use gotoAndStop/Play to "skip" around a timeline.

scriptocalypse
  • 4,942
  • 2
  • 29
  • 41
  • I haven't run into any type-coercion problems so far, and I doubt I would as long as to another as long as the variable used to reference them is of a common base type (e.g. MovieClip or something they both inherit from). – Triynko Mar 10 '11 at 20:11
  • I should mention that while the "same instance name, different symbol type" may seem wierd, it's not. For example, BUTTON STATES. For different button states, it may very well make sense to have an instance named something like "surface" or "highlight" or "focusRect", that needs to be referred to by the same name across frames, but also needs to have different symbol type (different visual appearance) across various frames like "up", "over", "down", etc. The variable would have to have a common base type like MovieClip or DisplayObject, and it should not cause any type coercion errors. – Triynko Mar 10 '11 at 21:06
  • I read the blog entry too. Thanks for that. I think I avoid the type-coercion errors, because I never use "automatically declare stage instances", so I always ensure my variable is a common base type if I'm using different symbol types for the same named instance across key frames. And this is off topic, but turning off the "warnings" compiler mode speeds up compilation tremendously :) – Triynko Mar 10 '11 at 21:19
  • @Triynko From a designer point of view, it isn't weird. And indeed AS2 let you do this freely so designers grew to rely on it. I mention such in the linked article. It doesn't work that way in AS3, though. I've seen this cause problems many times, for at least 3 other people besides myself. There are other ways to achieve the effect of having a different appearance for different states besides giving *incompatibly typed* objects the same instance name. – scriptocalypse Mar 10 '11 at 21:30
  • @Triynko You're right about not automatically declaring stage instances. Taking that approach will pretty much guarantee that you can't work your way into a bind. – scriptocalypse Mar 10 '11 at 21:32
1

I have never seen this officially documented since I started with AS in Flash 5.

Your observations match mine, but another case is "same name, same type, new keyframe, different layer" which reinitializes the object in AVM1. I am not sure what AVM2 does, since I really try to avoid these situations, but this can be a decent way to get a MC to reinit on the timeline if you need to.

mpdonadio
  • 2,891
  • 3
  • 35
  • 54
  • I just checked this, and the AVM1 behavior you described exists in AVM2 as well. I create two layers with a red block named "red" on one, and green block named "green" on the other. On frame two, I swapped the blocks to different layers. I stored references to the "red" and "green" blocks in variables in frame 1 and compared them to the named instances in frame two. They are not equal, and if I switch them back, they are equal. So I think this confirms that new objects are created in AVM2 for the "same name, same type, new keyframe, different layer" condition. Thanks for pointing this out! – Triynko Mar 10 '11 at 20:04
  • I wonder if there's any other condition besides "different layer", where everything else being equal, a new instance would be created? – Triynko Mar 10 '11 at 20:20
  • Another thing to check are scene changes. – mpdonadio Mar 10 '11 at 22:11