Help with set my anchor

[cinnapoca]

In a custom sprite tiling block, I’m successfully creating clones and reporting references to them in a viewport row/col list of lists. I can do almost anything by [tell]ing these references to do things like move or set their name, but I can’t seem to set the anchor like this:

This script is running from the main sprite (the one creating the clones) and clone is one of the references to a previously created clone. The name set works perfectly. The anchor set does not. If I remove the set my anchor, everything works fine. What am I doing wrong? Thank you for your help.

[gplb2718]

is anchor a global variable or a sprite variable? im pretty sure that, as in scratch, clones have their own copies of sprite variables. however, you could use the inherit block to tell each clone to use the main sprite’s anchor variable instead

[sunnyandshivcodebros]

can you share the project so we can try helping you further?

[gplb2718]

these scripts might be able to help you figure it out: when the clones are initialised, use the when I start as clone block to tell them to inherit [anchor]. then, you can use set [anchor] to (my [self]) to set the clone’s sprite-specific anchor variable, which is what the clone’s anchor will be set to

[ego-lay_atman-bay]

I would assume it’s a script variable, and this is just a small snippet of a larger script. What kind of variable it is wouldn’t matter, because of context. The grey ring is in the context of the script, so it should be able to access the variables in that script.

I don’t know why it’s not working for @cinnapoca, because it works fine for me

One thing that might be cause for confusion is what setting the anchor really does. When you set the anchor, the clone follows the sprite wherever it goes. So for example, the parent sprite moves 10 steps, the clone, a part, will also move 10 steps. However, the clone can still move independently, so if the clone moves 10 steps, the parent sprite will not move.

[gplb2718]

legit forgot script vairables exist lol
but yeah i guess without the context of what @cinnapoca is trying to do there’s not much anyone else can help with

[bh]

This script is running from the main sprite (the one creating the clones)

Are you sure the clones aren’t also running the script?

[cinnapoca]

Thank you all so much for the quick help. I was at an activity yesterday, so I didn’t get back to coding until today. I didn’t think you’d need my full block, because I thought I was doing something wrong that might be easy to spot. Here’s the full block. It’s designed to be run in any sprite.

And below is also the exported block, in case that helps. You can see the “ignore” block is where I commented out the line that doesn’t work. If you put that line back in, it doesn’t work. If you leave it out (in the ignore ring), it works fine.

@bh, I’m testing it by just putting the block in any sprite and clicking it to see if it reports the grid of sprite pointers. I don’t think that means it’s running in the clones, but I might be wrong. The part that’s so strange to me is why it works without the set anchor line, but not with it. With set anchor, it seems like it makes an endless loop, since it runs out of sprites.

Yes, @ego-lay_atman-bay, that’s the reason I was trying to use set anchor. My goal in using it is to be able to slide this whole grid around by moving the sprite that was cloned and is hidden. That’s the best way, correct?

And based on gplb2718, do I have to actually inherit the anchor variable before I can set it from outside with tell? Since there will potentially be a lot of clones in this grid, my goal was to keep the clones free of code as much as possible. I was going to try to ask/tell things from outside the clones.

Even if I haven’t written this block in the best way, can you tell me the minimum changes to make it work, and then I’m also interested in your comments and rewrites too. I just want to know specifically what I did wrong so I can learn for the future. Thank you!

Here is a test project containing the custom block:

clone tile debug

Thanks for looking at it for me.

[sunnyandshivcodebros]

not sure if the is the best solution but:

[bh]

Interesting. It’s indeed making a lot of clones, but not because of the clones running the script. In trying to debug this I made the following tests:

So only 12 clones are doing the SET MY NAME and SET MY ANCHOR.

But… When you attach a sprite to an anchor, for most purposes the resulting combination is treated as one. For example, if you move the anchor, all the parts move with it.

And if you clone the anchor, it clones all the parts, too!

[cinnapoca]

Thanks for sending this. I still don’t see what’s causing this though. I’ve updated the test project below:

test clone tiles project (updated)

There are two blocks there, that both use the same custom block. You can see that drawing a 3x3 tile matrix works fine, even with the set anchor; however, drawing the 4x4 in the block below doesn’t work at all and hits some maximum number of clones limit. But then if you remove the set anchor in the tell of the custom blocks, it works for any size grid. I really don’t understand why this happens.

[sunnyandshivcodebros]

this ties into @bh’s post where

@bh
… if you clone the anchor, it clones all the parts …

[cinnapoca]

Thank you for trying this for me. I just sent another updated test. I don’t know if you saw my updates in the project before you did your tests, but it seems like it’s maybe that a 3x4 works and a 4x4 doesn’t because when anchors are involved it’s exponential growth of sprites or something? I would have thought if I tell a clone to anchor to its parent it wouldn’t change the number of clones. I will keep rereading your answers and see if I can understand. Thank you!

P.S. I think I also need to learn more about parts. Maybe that’s my problem. Do you think this is the way it is supposed to work? If so, I just need to learn it better maybe. Maybe the picture in my head of what is happening isn’t right.

[bh]

When you attach a part to an anchor, it’s because you want the combination to act like a single sprite, as far as the outside world is concerned, even though internally the parts can move relative to the anchor. So when you duplicate or clone the anchor, you are really asking to duplicate or clone the entire connected multi-sprite.

So, look at that list of names. When you make the first clone, it clones only the anchor, because that’s all there is to clone at that point. But after that, there are two sprites to clone, the anchor and one part. So two new clones are made, one of each. We can see from the name list that the parts are cloned before the anchor, because the next two clones are an unnamed one followed by the named one; that named one is the clone of the original sprite.

Now there are three clones. Next time through the loop, all of these are cloned, making three unnamed ones, and finally the named clone of the parent itself is made.

Now there are seven clones… and so on.

@sunnyandshivcodebros’s patch works because you do all the cloning before making any part-to-anchor attachments. Cloning a sprite with children (clones) doesn’t clone the children; it’s just cloning a sprite with parts that makes more clones than you’re expecting.

If you look at Open>Examples>Swimmer, which is the canonical example of nested sprites, you’ll see one anchor, the torso, with several attached parts for the arms and legs. Now, suppose you asked to clone the swimmer. Would you mean that you want just another torso, or would you mean that you want an entire new swimmer? That’s why it works the way it does.

[sunnyandshivcodebros]

@bh

In trying to debug this I made the following tests:

hmm… looks like the amount of “clones” is 1 + the sum of 2^x (makes sense as you’re just doubling on accident)

also, the whole thing hides if you tell it to hide because it’s a “multi-sprite”, hence it not showing without the fix.

[cinnapoca]

@bh, you are so nice. That’s why you’re a legend! One answer, and I understand it all. The step-by-step explanation makes it clear:

• why smaller grids work but larger ones don’t
• why separating the loops works by cloning all of them before anchoring any of them
• and why I should be thinking of multi-part sprites (like the swimmer) when thinking of anchors

This is so great. I wish I had a time machine so I could go back in time to Berkeley and take your class! My dad says thank you too. He couldn’t figure it out either. (And thanks to everyone else who helped explain it too!) Off-topic, but I hope you guys do a Snap!Con. I really want to go this time.

[bh]

Thank you! I’m a teacher; this is what I do. :~)

You can sort of take my class; there are lecture videos on YouTube and all the handouts and stuff on my web site.

No Snap!Con this summer, obviously I guess, but we’re hoping to organize a smaller event in the winter. Stay tuned.

[gplb2718]

@cinnapoca

And based on gplb2718, do I have to actually inherit the anchor variable before I can set it from outside with tell? Since there will potentially be a lot of clones in this grid, my goal was to keep the clones free of code as much as possible. I was going to try to ask/tell things from outside the clones.

you can tell a new clone of [myself] to inherit the variable like so, but only if the variable is a sprite-only variable!

your script uses script variables, and so the sprite will work in that regard without modification.
also, as others have pointed out, this script also clones all the sprites before telling them to anchor to the sprite, meaning the clones will not exponentially grow in number.