**credits to @imfh for figuring this out!** "The end of a repeat block yields for a single step rather than until the next frame." full details: https://scratch.mit.edu/discuss/post/5293236/ click/tap beachballs to make them act like balloons! click again to let go. this is just a proof of concept showing off the custom fast "broadcast and wait" by @imfh working to send messages between a number of sprites and clones, with a focus on data/script encapsulation; instead of global variables/lists, data is stored on clones themselves, and broadcasts (and temporary global "return" variables) are used to retrieve this data. key sprite/clone interactions: 1) the Demo sprite activates the Beachball sprite's script for creating a beachball. (this script returns the beachball ID via global variable, though it is not used in this project.) 2) the Beachball sprite activates the "refs" sprite's script for getting a new "reference ID" (i.e. unique object identifier). this is implemented as a simple counter, though the Beachball sprite intentionally does not know—or need to know—so. 3) the Beachball sprite activates the Demo sprite's script for handling a beachball being clicked, which adds (or removes) it to (from) a list of selected beachballs. ("event listeners" could be coded in a way more robust/interesting way, but i decided to do something simple for this small demo.) 4) the Demo sprite loops over its selected beachball list and activates each beachball's "animate" and then "get position" scripts in turn, storing the positions in a local list. importantly, this loop all happens instantaneously, even though it includes a lot of broadcasting! finally, during a "render" broadcast, every sprite/clone *independently* renders its data, meaning the Demo sprite draws green lines and the Beachballs move to their specified position. this has to happen only once per frame and right at the end, because otherwise it will trigger a screen refresh, activating the 1/30th-second frame delay in the middle of broadcast processing rather than at the end of the frame. thanks again to @imfh for figuring out a clever way to make use of multiple ticks between two frame renders, and writing the custom broadcast blocks i showed off in this project!
