New Update Breaks Some Projects

The new way Snap handles loops seems to break some projects.

Before Update:
https://snap.berkeley.edu/versions/previous/snap.html#present:Username=joecooldoo&ProjectName=Bouncing%20Circles
https://snap.berkeley.edu/versions/previous/snap.html#present:Username=cornelios207&ProjectName=parallax%20effect

After Update:
https://snap.berkeley.edu/snap/snap.html#present:Username=joecooldoo&ProjectName=Bouncing%20Circles
https://snap.berkeley.edu/snap/snap.html#present:Username=cornelios207&ProjectName=parallax%20effect

For the first one, the problem is that the velocity script is relying on the screen refreshing at the end of the loop. Of course if the script inside the loop has to refresh the screen, like a move (10) steps block, then the loop will yield at the end of the loop. Because the yield is happening only when the screen has to refresh, you can just add a move (0) steps block and then the script will run as it did before.

(yes, I tried adding a wait (0) secs block at the end, but that also required one in the script for edge bouncing)

I don't really want this to be reverted back to the old way, however I think adding a toggle might be better.

Well in my opinion I liked it the old one better

I think I missed this. What is the new way Snap! handles loops?

Loops that don't update the stage run astronomically faster.

v9

v10

(v9 actually took too much time with larger numbers and I'm impatient so I lowered the loop number to just 100, but the idea still persists)

However if the loop updates the stage, it goes back to being as slow as it was in v9

v9

v10

Yes, I know it's better to time scripts multiple times and average the resulting times, however I feel like even without doing that, this still shows how much faster the new behavior is.

I personally like this new behavior better because it would mean that large calculations in loops can be a whole lot faster. In time you'll come to appreciate the speed.

this. i feel like by default it should be off for older projects for compatibility.

Yes I think it should be like that too @joecooldoo

That's what I was implying.

That's so nice! I can see a lot of useful stuff I can do with faster loops (like calculating stuff without having to wait as long, stuff like that.)

Thank you for showing this. I went back to some of my old projects and was beyond confused why everything had broken. I'll be going back and adding that to fix them now.

you could have always warp { ed...

Every Snap! project has the version number from when it was last saved in the XML, so whenever the editor loads a project and sees that its from a version before V10, it should automatically use old loops

v10.4

i know, thats what i was suggesting

I have a question @sathvikrias why do you want stuff to be so specific? (Not trying to be mean)

Versions 10.0, 10.1, 10.2, and 10.3 did not have the faster loops, and thus any feature for backwards compatibility would need to be specific, and more so than just applying to projects made before V10.

no need to @mention me. you're already replying to my post.
to answer your question, imagine if one single character in snap's code was wrong. in this case, it's 10.0.0, vs 10.4.0. but in other cases, that could be the difference from staying safe, or accidentally enabling JavaScript extensions from when the project opens, and leaking security data from thousands, leaving everyone's projects at risk. yes, that is an extreme, but this example of 10.0.0 vs 10.4.0 could break hundreds of projects if done wrong.

I believe that actually happened! (somewhat)
In 2020 some guy used JavaScript maliciously and got data of whoever happened the project I believe, which is why you must now manually select to enable the option.

Though, I think the only non-staff member active at the time that is still active on the forums now is @ego-lay_atman-bay

Oh ok I understand now!