i'm not sure how it's ever possible to create 1023 clones with this setup. all the clones should be created before they get to run their script. either way, clicking a script should have the same behavior as when it runs via the flag (or whatever other hat block method)
i think what's happening here is that the "when I start as a clone" scripts are running immediately after the "create clone" blocks, and I guess creating a clone of a sprite with attached sprites also creates a clone of all the attached sprites too (probably intentional behavior). as for the wait block/click part, maybe it's due to the green flag's clone deletion causing something?
(EDIT: if you don't have a wait block, then the clone scripts do all run after the warped scripts. EDIT 2: this is apparently intentional behavior too! though this does seem a bit obscure and weird)
TL;DR: if it's the first step of a thread, clones created by that thread will run their "when I start as a clone" scripts later, instead of doing so immediately after the "create clone" block. maybe this is to prevent infinite looping from clones creating clones of eachother without waiting (Scratch 3.0 does fall into a similar trap if you have a clone that creates a clone and deletes itself; it's a pretty famous way to freeze the page.)
removing the warp block as the same issue (when i depress the green flag)
it's exponential: you can try to click manually on this block 5-10 times
The sequence
1
3
7
15
31
63
127
255
511
1023
2047
...
adding a wait 0 secs block (when you warp the clone creation) right after when 1 start as a clone seems to solve the problem like this:
if you remove the warp same problem:
but if you wait much more:
That'll be because clicking that script runs it in all the clones as well. The first time there is one clone created. The second time, the original sprite and the clone are cloned, creating 2 new clones (for a total of 3 clones). Then, the 3 clones and the original sprite all clone themselves, for a total of 7 clones. And so on.
Based upon my research, scripts that are activated by a click don't run in clones - but clones' scripts still have haloes drawn:
This means that we have a bit of a weird interaction between clones and their parents when looking at the palette. As far as I can tell, the
block is running in all the clones when it is clicked if those very clones have anchored themselves to the parent. My best guess is that, just as clicking a move block when the clone is anchored to the parent moves the clone as well, the same is happening with the create clone. The "when I start as clone" block seems to start running in spite of the warp block, but when it yields (with a wait block) it doesn't set its anchor until after all the clones are made. Thus unwarping yields the same effects, and when you add the additional yield fewer clones are made:
Waiting longer thus allows the clones to be made before any of the anchors are set:
It seems that warp blocks are more extensive when the green flag is clicked (the when I start as clone scripts don't start) versus clicking on the script.
A simpler example of how the create a clone of block is glitched would be this:
good sleuthing. either way, it shouldn't behave differently between when it's clicked and when it's ran with the flag. it's pretty inconvenient that i can't just clone only the anchor sprite too.
I think the idea is that when you anchor one sprite to another, you are creating a super-sprite that you think of as one object with flexible parts. I agree that that doesn't cover every possible use of anchoring, but it's the one we chose to emphasize.
The unknown part is that "when I start as a clone" is NOT executed in the same frame/step when called by the "green flag" script, just like in the "regular" script. It behaves like
The "when I start as a clone" was executed after the "warp". If it's intended behavior, it seems to be not documented nor intuitive
If it's a new problem, it's probably a bug.
The strange thing is that the hat block should run first, as it is what starts the script. If the warp ran first, how would the program know when to start the main script?
Actually, the when flag clicked block is running first, then the warp, and then the when I start as a clone was run after the warp block. However, when the script is clicked on, the when I start as a clone script runs during the warp block.
I think you were confusing when the when I start as a clone block would run with when the when flag clicked block would run.
A simpler example:
Says 0 on flag press, 1 on click-to-run.
This example I just gave (and probably some of the others in this thread) has the same issue in Version 9.
Edit: I checked, and it is in all versions of Snap! (right all the way down to V4). Interestingly, in V4, clicking the green flag did not delete clones - only the stop sign did. This changed in V5.
How about, it's just race conditions.
*rare conditions?
No, race conditions. Race conditions refer to 2 threads running a script at the same time, but you don't know which thread will end first.
We try pretty hard to schedule threads so as to avoid common race conditions. The behavior discussed in this thread, in which a child thread is scheduled before or after the thread that started it continues, is often the way it is for that reason. (But of course I don't remember any of the details. :~/ )
This exactly describes what's going on.