My daughter is getting ready for her Snap!Con presentation and she reminded me that I never did what I promised to help her to understand why this didn't work (and revise accordingly). I think that @bh and I agreed that all change blocks should be executed here... so response should end at a value of 30? Instead, it erroneously ends at 12.
I know you guys (like @dardoro and joecooldoo and @bh) gave me some great workarounds. I will use one of those if this isn't fixable in time for the Snap!Con. I just thought I'd check in, in case I was supposed to report it in some other Forum thread... and didn't because I don't know what I'm doing in these forums!
Any updates would be greatly appreciated. Thanks again for your time.
Hmm, 12 is the answer I'd expect if you run this script in the sprite hidden1. The change by 2 will never happen because it comes after an infinite loop, and the change by 16 will never happen because of the STOP OTHER SCRIPTS.
And that suggests something to me about what's going on here. Under the hood, things that affect a sprite, such as MOVE 10 STEPS, aren't really global blocks, even though they seem to be. Each sprite has its own MOVE block with that sprite as an implicit input. When you copy a script from one sprite to another, or do the equivalent with TELL, Snap! has to replace those blocks with the ones native to the target sprite.
So I'm going to guess that STOP OTHER SCRIPTS IN SPRITE has that nature, too, but isn't among the ones Snap! knows to replace with the target-native equivalents. I'll look into it, but everyone is hugely busy right now and I doubt anything will change before Snap!shot.
Thanks so much for the quick reply, and even especially so, given all you guys have going on right now. Also, it's no problem for us to use the workarounds we discussed in the previous thread. I figured I might be doing it wrong, but just in case, I'll respond to your questions/comments below. Even if you can't answer or work on a fix right away, just your answer above improves my understanding of things.
I'm hoping the project link is still working, but as you point out, this block was supposed to be running outside the sprite hidden1. But it behaves as though it's being run from inside hidden1.
I know you can never tell/rely precisely the order that multiple threads handle things (hence race conditions), but this is roughly what I was thinking should happen: Response is set to 0 initially. Then, after a second, the first LAUNCH kicks off the TELL...FOREVER block. Then the second LAUNCH kicks off the TELL...WAIT block, which after 1 sec, stops the the prior TELL...FOREVER from the previous thread (but not itself or the initial thread running outside of hidden1) and the execution of that first LAUNCH falls to response += 2. Simultaneously, the second TELL thread executes response += 4 (since it wasn't stopped), followed by the second TELL ending and the second LAUNCH setting response += 8. Finally, the original thread waits 3 seconds and sets response += 16. Is that roughly correct as to how it should execute? I'll paste the block pic below again for ease of reference, but there are no changes to the block since my prior comment.
So I think your prior answer meant that if there's a bug or unexpected outcome, it's that STOP OTHER SCRIPTS IN SPRITE is stopping the main thread. I think you said it's doing so because maybe the TELL is not generating a STOP OTHER block that takes hidden1 as its object. Instead, it is executing a STOP OTHER block that takes the original thread in the non-hidden1 sprite as its object. Is that right? But that's not the way you'd ideally want it to be, right? (That is, of course, assuming there were eventually time for a fix...) Is there anything else I need to do/post/etc. to get it into the queue for bugs, once you've had time to confirm it? I know some languages have an issue queue you need to post to... and I'm happy to do whatever is required. Just let me know.
Thanks again for all the help!!! Cinnapoca and I are looking forward to seeing you all on screen at Snap!shot... This online community you've developed is just another thing that makes Snap! so great. My daughter and I have been watching the presentations from August and reading forum posts together as we've been polishing up her project. What a great community you've fostered here from all over the world! Thanks again!
Thanks so much for this! This is really cool. I modified your test project slightly to apply it to an ask. Here's the custom block that incorporates that. Your solution works very nicely.
The only problem is that I can't figure out how to make it return early (i.e., in this sample, before the 5 seconds are up, if the user has responded before that time). Can you help me? Is there a way to terminate early before the seconds have elapsed?
Part of the problem is that my block will wait the amount of seconds even after the block is finished running. I updated it and it works now. I also updated my project with an example (Your problem).
or could it just include these calculations in the WAIT UNTIL? I wasn't sure if there was some magic that was happening there to keep the thread alive or force it to update or something.
This is to just accurately keep time, because I couldn't use the wait block for this purpose, or else the block would keep waiting until time is up, even though the script ended.
Partially screen updating. If you remove it and put a say block right after the block in another script, and the block is running something like FOREVER SAY, the say block after the custom block will appear to not work.
You are awesome, @bh! Thanks so much. And thanks as well to @joecooldoo for an even more streamlined workaround. My daughter will be excited to include this in her project once I get to explain to her how it works. That will be our homeschool STEM lesson du jour.
