I don't know if the following is a bug or a wanted behavior.
I noticed that whereas in Scratch all graphic effects are cleared when a project stops, in Snap! graphic effects do not change their value on stop. This mechanism is used a lot in Scratch projects to create splash screens that hide as soon as the project is started with green flag and then get visible again when the project stops by setting the ghost effect to 100 on green flag for the splash screen sprite. So Scratch projects imported with Snapinator that use this strategy do not work as expected in Snap. Is there a reason not to clear all graphic effects in Snap! on stop?
This is a very reasonable solution. As the project is coming from Scratch, and Scratch uses this strategy, this could be added to the Stage, maybe with a post-it comment.
That is a good point. A person using Snapinator would more likely want to keep the clear fx on stop, which would likely use the script I showed. If somebody for some reason doesn't want that feature (maybe that's why they convert it to Snap!?) they can deliberately remove the script.
To be clear, this is exactly what I would have expected in Scratch. So the fact that this doesn't happen in Snap is no surprise to me. On the contrary. But a project imported from Scratch must do what it has been designed to do. So it is necessary to make it work via Snapinator.
There are several reasons I haven't put that when stopped script in every project. The simple one is that "when I am stopped" didn't exist when I wrote Snapin8r2, but I still haven't done it because it raises plenty of other issues:
Does that script need to go in every sprite or just the ones using graphic effects? In other words, are users going to expect the Scratch behavior in every sprite, even if graphic effects are only added after the project is converted to Snap!?
Where in the scripts pane is that script supposed to go?
Is it going to be clear to users why that script is there? Do I need to write a comment to explain it?
If I replicate Scratch's stop behavior, I need to replicate the green flag behavior of stopping all scripts before launching green flag scripts. This can be done with:
when green flag clicked
stop [all v]
but this only works if this script is run before every other green flag script, and it breaks as soon as the user drags and drops this script. Of course, I could comment something like "DO NOT TOUCH. DOING SO WILL CHANGE SCRIPT EXECUTION ORDER AND BREAK YOUR PROJECT." But if the solution is so fragile, then why am I doing it in the first place?
There only needs to be one copy of the green flag script per project. Where does it go? The stage? What if the user never looks at the stage? How are they supposed to know why the green flag is working differently than in a normal Snap! project?
My idea is that, "coming" from Scratch, the user would expect the Scratch behavior for every sprite. You can add the "remove graphic effects" script in each sprite, or you can add a single script (in this case I would add the script to the Stage) that runs the block for every other sprite (using the "attribute" block).
The script should be well visible, so I would add it at the top position in the script area. And yes to the comment.
In this case, given the fragility of the solution, I would not take care of the green flag behavior.
As this cannot be done easily by Snapin8r, I would leave them discover that this is the new behavior in Snap. This won't affect at least the very first run of the project, as all scripts at that time are not running.
I'm getting more and more convinced that we should leave well enough alone. Perhaps a better approach would be to have a Scratch compatibility library in which all these little differences are collected. (Then we could get rid of CHANGE var BY delta and other such redundant blocks.)
Having a Scratch compatibility library is an excellent idea. But, if there are reasons for a different behavior in Snap (BTW, are there reasons? This is something that has not been answered) this is something that Snap's community shouldn't take care of.
Instead, as Snapinator's purpose is to port Scratch projects to Snap, everything that can be done to make the port as similar as possible to the original project should be in my view be investigated and, if possible, solved.
IANJ, but I can tell you about an analogous case: When clones were introduced, Jens chose to delete temporary ones on stop (red button clicked, or all scripts finished) rather than on start. The general principle involved was that the green flag has no magic powers; it just BROADCASTs a special message. WHEN FLAG CLICKED is just a disguised WHEN I RECEIVE.
But after some actual experience with kids, we ended up making green flag also delete temporary clones. I don't think we should change things like this one at a time as people complain, but I can easily imagine that the green flag might do a red stop sign thing, wait until all scripts finished, and then send the green flag message.
No changes to features until Jens finishes the new Morphic, but we'll consider this at that time.
I'm more interested in translating the things that the user explicitly defines, like scripts, costumes, etc., not replicating every minor detail of how Scratch executes projects.
If the main goal of Snapinator was to get projects to run exactly how they do in Scratch without the need for them to be understandable to users, sure, I'd add these green flag and stop sign fixes in a heartbeat.
But since users are going to be looking at the outputted scripts, taking a minor, Scratch-defined feature like this and replicating it in the forefront of the user-defined area—the main scripts pane—just doesn't sit right with me. If I were to fix every small thing like this, I feel like the helper scripts being there would probably be more confusing than any weird behavior they'd fix. In the 5 years since Snapin8r2 was released, it took until now for somebody to complain about the stop sign behavior, but I'm sure I would've gotten questions sooner if I'd included a fix.
Reasonable. If this is something that Snap is not interested in, and snapinator is not taking into consideration not to add too much confusion, I can write a conversion program myself that takes snapinator's output as an input. All the complex stuff has already been done by your excellent tool.
the new Morphic kernel for Snap! v6 reduces memory usage and speeds up loading projects. Much larger projects are possible and Snap! doesn't crash anymore in Chromium. Snap! also runs perfectly in Safari, including mobile Safari and other mobile browsers. Coming up this summer.
