I have the following setup.
The FOR EACH block does launch three times but I never get the first sprite processed.
It processes the third one two times.
However, if I use the TELL block, then everyting works OK. I get three circles around the three cubes.
tell is synchronous and
launch is asynchronous; is it possible that
item is changed before
CIRCLE Obj: is called in
Since LAUNCH starts a new thread, it doesn't share the variables of the starting thread. That's sort of a misfeature, I guess... Anyway, try
it does share the starting thead's scope, but there is a race condition! It's the sharing that's actually causing it
Oh! Right, I'm an idiot. There's only one binding for ITEM. But my solution ("with inputs") still works.
Yes, your solution utilizes applicative order of operations to make sure there is no race condition. It's my model example for how to write a musical chord using LAUNCH. If you do it by referencing the item directly inside the ring it will have changed in the outer (shared) scope by the time the inner script evaluates it, and hence it will appear to "skip" some items.
I believe you guys need to write a manual on "how to use blocks if you want them to do what you want done" manual.
These explanations are "I have no words for them" .
I was going to write a snarky response pointing out the page in the Reference Manual that explains about how to get your own variables into another thread using WITH INPUTS, but to my embarrassment there is no such page. There's a page about WITH INPUTS, but it doesn't explain that purpose for it. Mea culpa!
We're making a whole online course about it! This is the closing example of week 1 in our upcoming course of 4 weeks starting this September. Registrations (free) opens during SnapCon20!
How do I join this?It isn't open yet, but where will it open?