I have been working on a project which allows clones to create and control other clones in a very adaptable way, but I am having trouble with the complicated details of OOP with the clones in Snap! when creating more than one of these objects. I have a description inside of this project: Adaptable Clones of how I would want it to function if I knew how to write it correctly. How could I make this work?
Also, about the bugs part of title, I somehow made the Snap! block scheduler run two things at the same time without warp (or at least it appears that way with stepping mode on) in a separate project: Odd clones bug
That's how the scheduler is designed... it's made to run multiple scripts at once. Warp prioritizes the script in the warp block, making it run without refreshing the screen or running other scripts (except for certain exceptions).
Why do you use that complicated business with flag variables and WHEN I START, instead of just putting RUN >CODE in the TELL's code input?
I mean, I haven't traced it through in detail, but it wouldn't astonish me if the TELL code runs before the WHEN I START code, which would mess up your synchronization effort.
@dardoro I implemented the changes that you showed in your post, and my code (as far as I have tested) is working perfectly now, thank you for providing your help with my code.
@bh I was using the flag variables and "when I start" because I originally learned all of my block-based coding in scratch, where "a new clone of" and launch/run does not exist, so I didn't know how to use the blocks Snap! offers until recently (I am still learning). From experimenting with snap, I will hopefully learn about the more advanced features and different implementations that Snap! offers, and write code more efficiently.
(can only mention two people) [ego-lay_atman-bay] I know that the scheduler is designed to make two things be able to run at the same time (I read the post that jens made about that) but (how I think it works) not literally at the same time, just run right after each other in a way that makes sense and is intuitive to a programmer. What I saw from the stepping behavior, which I have never seen before, is two things being highlighted blue, and then changing color at the same time to indicate something being processed. Typically it is only one thing at a time, but I would guess (assuming this is intended behavior) that there is some check to see if those two blocks running at the same time would interfere with each other, and then seeing that they don't, run in the same update.
It's not that smart. Every script runs in every display cycle, unless you change that with WARP. Of course they aren't truly simultaneous; only one script can run at a time. A script yields when it reaches the bottom of a REPEAT, FOREVER, FOR, or FOR EACH (the primitive blocks with ⬏ at the bottom). After every script has a turn, the display is refreshed. One of the goals is that if a sprite has two scripts
what you see is a circle, not a random walk.
The only real effort to avoid script collisions is that if you use one of the IF variants, it is guaranteed that the selected alternative starts running as soon as the condition is tested, with no yield in between. (Fine print: If the condition test takes a really long time to run, it may be interrupted, so that you can escape from infinite loops in your predicate code.)
While technically they're not running at the same time, snap shows that, because that's what the scheduler is made to make users think. Visible stepping isn't actually "step through every single step the scheduler takes", it's more like "step through the code in every single script, as if they're running at the same time". I personally find this much better, especially when you're debugging a script, you want to be able to click the step button to see the next block run, not have to click step a couple times before the next block runs.
