Potential Bug with PARTS / ANCHOR feature of Sprites

Hi everyone,

Common method is to drag and drop a part Sprite onto another main one in order to create a PART relationship betweeen the two. Then when the main one is queried with "my parts" reporter it lists the parts in a table.

To break the PARTS relationship, one normally right clicks on a part Sprite and selects "detach from" in the menu, which only appears if a part is anchored to another Sprite.

Now here is what I have done:

I have attached two circle sprites (green and blue) to the main Turtle Sprite. And confirmed the PARTS status via the "my parts" reporter. Also when each circle Sprite is right-clicked it correctly displays the "detach from" option, as well as reports the Turtle sprite as its anchor via the "my anchor" reporter.

Now I select the main Turtle sprite and using the "my parts" reporter make it display the two circles (red and green) in a list. Since the list has controls for deleting items, I clicked on one of the "-" signs and deleted the blue circle from the list. This produced no visible effect on the sprites in the sprite corral.

  1. Blue sprite's "my anchor" reporter still shows the Turtle Sprite.

  2. The Turtle sprite in the sprite corral still has both blue and green sprites on it, indicating the PARTS relationship is valid. Yet when the Turtle sprite is moved via commands it only moves with the Green circle attached.

  3. Selecting the Turtle sprite and using its "my parts" reporter only reports the green sprite.

  4. Right Clicking on the Turtle sprite in the corral and selecting "detach all parts" erases both the two blue and green circle images on the Turtle sprite. However, when the Blue sprite is selected and "my anchor" reporter is used, it still reports the Turtle as the anchor. However the Turtle sprite moves by itself without the Blue sprite.

  5. I have also tried the modification of the PARTS list of the Turtle via code: "delete 2 of (my parts)" block and achieved the same result.

  6. Finally, if I programmatically add the two parts to the Turtle sprite using code:
    "add (object part1) to list (my parts)" and "add (object part2) to list (my parts)" both circles get added to the parts list of the Turtle and when the Turtle is moved they are moved with it. Yet neither circle part's sprite shows the Turtle as the anchor !

I know this has been a convoluted description but there it is!

I have no idea if this out of synch reporting and display is normal or a bug - I am just reporting it. However the condition created caused a lot of confusion.

Please fill out these questions for all feature requests and bug reports. If you're requesting a feature, please let us know why this feature is important or useful, not just what it should do.

  1. What browsers show this problem?
    Google Chrome
    Version 77.0.3865.90 (Official Build) (64-bit)

  2. Please share an example project (if possible).

  3. Describes the steps to reproduce this issue.

  4. What does Snap! currently do?
    Described in text above.

  5. What should Snap! do instead?
    Provide a synched display of relationship status on the Sprite Corral images and individual sprite reporter outputs.

Ah, that sure sounds like a bug, thank you. Point is, it should not be possible to mutate the list of parts, it should be read-only, at least that's what I intended it to be. More to the point, it should be shallow copy of the actual parts, and adding or removing a sprite from that list should not affect the actual behavior.

Yes Jens,

Before your answer, I was wondering if there would be other solutions... but not, "sprite.parts" changes can not trigger a "sprite2.anchor" change.

But thinking about this issue, maybe we must check all the list attribute reporters.

  • I see sprite.children has the same problem.
  • And different, but also "r-g-b-a at Sprite" similar problems.

We can check all our attribute reporters.


Funny that we are having the same bug that users of lists have when they don't understand sharing. :~)

Copying the list is the obvious solution. I guess the MY ___ lists are too small to worry about efficiency? It could be a problem if some sprite has 10,000 clones. Would it be worthwhile to instead invent read-only lists?

yep, I've thought about this, too. Read-Only Lists are definitely something to explore in the future, I agree.

This doesn't happen for me. Instead, the (my [parts v]) block just returns a new list with all the sprite's parts.

yeah, I fixed this a while ago...