In BJC U1L1P4, the instructions end with #7 'if (ghost effect == 100) {clear graphic effect; stop all}' But midway up the same page, the students are instructed to 'change ghost effect by -5' every time a click is missed, so they very well might land in an unwinnable situation.
Since there is no >= operator built-in, and custom blocks are just about to be introduced in U1L2, I'm instructing my students to test 'if (ghost effect > 99)'.
In other contexts, this bug might be considered a teachable moment, but right out of the gate Unit 1 Lab 1 I think it would be better if the students were not instructed to code bugs.
I don't know if there's any editing process for BJC, but for new teachers, it would be helpful to be aware of this. At a minimum, I think this deserves a note in the teacher's guide
Good point. I tested this increasing by 5 when hit, so it was always a multiple of 5, and forgot that the instructions didn't specify how many percent to increase. I'll fix this tonight.
EDIT: Whew! It's actually not a problem. The effect values max out at 100; if you set it to 103 or 110 or whatever, and then read it with the reporter, you get 100.
Oh, probably you were getting a 99% invisible Alonzo or something like that. As a refinement, someone might want to make it IF ((GHOST EFFECT) > 90) ... so it'll be easier to win while you can still see him.
Looks like you're right (of course); also the -5 doesn't go negative. However, I had alonzo say the ghost effect whenever he's clicked, and it's pretty common for him to say like 44.99999999999 or 55.0000000001. When does Snap! use ints vs floats?
I thought all integers (unless they are too big) could be represented exactly with IEEE floating point convention. Is Javascript doing something different?
Question: the [when I am clicked] block has a [forever] loop in it. What happens when the code is in that forever loop, and the user clicks Alonzo again -- does entering the top of that script cause the previously-running instance to abort?
What made me think of this question is, I had a student submit an implementation with two [when I am clicked] blocks; one for managing ghost effect and costume and jumping, and another to start a new forever[wait/jump] timer. So I was thinking how can these both be going, and then I was thinking, how can all the scripts launched by [when I am clicked] all be going?!
Another note: I went to the teacher guide to check the golden solution, and it's got a bug, the forever loop needs the wait up front, otherwise the +5 ghost effect is always immediately undone and the game is impossible to win
Unless I'm misunderstanding, your question boils down to "how can any two scripts be running at the same time?" And the answer is that at the bottom of the script inside any looping primitive there's an implicit yield, so each script gets to run one cycle of its running loop, then everyone else gets a turn, including the redisplay of the screen.
That's part of it, but if you click on Alonzo a first time to enter the script and then the forever loop that moves it around, say, every second, and then eventually click Alonzo again, why is it that there are not two copies/threads of the script, both in their forever loops, making Alonzo jump twice per second?
It must be the case that starting at the top again causes the previously/currently running thread through the script to stop, yes?
Oh, I see, yes, a script can only be running once at a time per sprite.
If the sprite has clones that inherit the script, it'll be badged with the number of sprites currently running it.
If a hatted script is running and a second event comes in for it, the default behavior is to drop the existing run and start a new one for the new event.
In the Settings menu, you can choose "thread-safe scripts" and that will cause the new event to be dropped, allowing the original thread to complete its work.
Exception: Keyboard events are always thread-safe.
Neither of these is the official right thing, which is to maintain an event queue so nothing is dropped. Maybe someday, maybe not.
ok cool that is helpful. I suppose it could be useful for new events not to cause other runs to drop, but then again if that is desired you can achieve that with clones.
