Trying to use 'Touching' for BJC disease spread

I'm a part-time teacher (and full-time software engineer!) trying to write the disease spread simulation for BJC U5L2 before I have to teach it, and I gotta say, I'm not finding it easy. The jump from the cloning examples in TicTacToe and the touching sensing with Alonzo early on, to the disease spread simulation, seems a pretty big jump, unless I'm missing something obvious. Do other teachers report they are able to turn their students loose on this assignment as written in BJC and they are able to figure it out? I'm pretty sure almost none of my students could.

Anyways, here's what I've come up with for a start. But whether the clones successfully detect that they are touching each other and change their costumes depends how much wait time is given before the next 'move' signal is broadcast.

Is there some rule about timing for the 'touching' block? Have I organized the per-clone code in such an inefficient way the touching tests are taking longer than they should?

DO NOT USE CLONES!
Use STAMP and GOTO instead
oh,and dont do touching tests we have our handy CCC tests.

OK, I had never seen 'Stamp' mentioned in the BJC curriculum, or noticed it in Snap!, but searching, there it is. BJC suggests using clones for this exercise.

Also, what's 'CCC'?

Pay no attention to him, of course you should use clones, because they move around.

The most important way to speed this up is to use the MY NEIGHBORS block, in Sensing. It gives you a list of the sprites (including clones) that are near the current sprite. When there are a lot of clones running around this is especially important.

Do you have access to our solution file for this page? If not, drop me an email (bh@cs.berkeley.edu).

Circle Collides Circle

oh thats my habit i like using lists and stamp

OK, well if stamps don't move, then it doesn't suit my purpose. Thanks though.

Oh yeah, I forgot about the teacher's resource guide, I do have access and will check that out.

I saw 'my neighbors', but didn't get an understanding of what 'near' means.

I was a little concerned whether a mostly-solution should be posted, as an online shortcut that shouldn't be available to students. If necessary, I can de-embed from my original post.

OK I found the solution script, and played with it a little bit.

I was surprised, inside the 'touching infected person?' custom block, the touching and ask blocks left the first argument unfilled, rather than having to drag 'item' in from the for block. Is that a thing, for unfilled parameters inside for/item? I am familiar with keep/combine/map, but didn't know it was more general.

13 posts were split to a new topic: Upvars vs. empty input slots

back to the original post, I was revisiting the bjc teachers' guide solution for the U5L2 disease spread simulation, and for some reason it is not operating correctly. All the clones initialize with a handful red/infected, and they wander around and quite clearly touch each other but no infection is ever passed on. Did something change?

(More generally, are the BJC materials to any extent a work in progress? or are they finalized/tightly version-controlled?)

ANNNNND today when I look at the same snap project I left in a tab, it's working as expected again.

Is there any reason (other than 'rebooting fixes things') a snap project would work one day and not the next? Or more probably run fast (enough) one day and not the next?

Yeah, someone posted about this problem on Piazza and I fixed it. The problem wasn't an error in the solution; it's that Snap! 6.7.2 changed the behavior of FOR EACH and I was relying on the old behavior, which was fine until a few days ago.

Oh sweet, so I'm not going crazy!

(Well I probably already am, but that still counts, because it means I'm no longer going crazy)

Took a look at the difference, and it has to do with empty slots that I was asking about before.

So it used to be that For would autofill its iterator variable into empty slots in enclosed blocks, but now the iterator has to be manually applied?

FOR EACH. The numeric FOR always behaved this way.

FOR EACH is like the child of FOR and MAP. In its youth, it didn't have the ITEM upvar; its name was FOR EACH ITEM OF, and it used implicit substitution, like MAP. Then we added the upvar, and for a long time it worked both ways. But every so often someone would want to use an empty text string as an input and would be confused by the result, so I finally gave in.