- What browsers show this problem? Chrome
- Please share an example project (if possible): https://snap.berkeley.edu/snap/snap.html#present:Username=s_federici&ProjectName=test%20touch
- Describes the steps to reproduce this issue: click the "is touching" block in the Sprite and Sprite(2) sprites
- What does Snap! currently do? an invisible sprite (called Sprite(2) in the example project) can "touch" a visible sprite (called Sprite in the example project). Is this a planned behaviour? This is different from Scratch and BYOB. Instead a visible sprite (e.g. Sprite in the example project) cannot "touch" an invisible sprite (e.g. Sprite(2) in the example project). This works exactly as in Scratch and BYOB
- What should Snap! do instead? an invisible sprite (e.g. Sprite(2) in the example project) should not be able to "touch" a visible sprite (e.g. Sprite in the example project) as it happens in Scratch and BYOB
I think this is a feature.
If an invisible sprite asks what it's touching, it's because the programmer/user wants to know! I mean, when you write the program, you presumably know that that sprite is invisible, so you would just not ask in the first place if you want not to be thought of as touching. Whereas in the other direction, a sprite that's invisible means to be invisible to other sprites too, not just to the user.
Unfortunately this is not the case for me 
The sprites make themselves invisibles when they are "destroyed", so that they won't need to do anything else as their "touch" conditions are not triggered.
I disagree. I often use touching in combination with ask, and I think that ask x for touching y should be commutative. It isn't too hard a workaround, but it isn't something you expect to have to do.
We argued this out on the forum some time ago. The thing is, if we let invisible sprites check for touching and that isn't what you want, you can just
But if we don't allow it and you want it, you're totally out of luck.
This is certainly true. Even if, I would really love that when importing Scratch projects to Snap everything works as expected, so that you don't need to rework your project. I guess this is something that @djdolphin could take care of?
Yeah. But there are things Scratch got wrong. For instance since the preferred orientation of all the costumes is facing right, direction=0 should mean facing right. (As it is, the default direction is 90.) This is true even apart from all the math teachers wanting positive direction to mean counterclockwise. Someday we'll fix that (after I talk Jens into it).
I'll try to take care of this and the backed up issues this weekend.
0 up is wrong to me too. But my great interest (I understand this can't be yours) is that Scratch and Snap projects are as compatible as possible. I guess I'll have to keep an alternative Snap website where the two tools are more similar. If this must be done, please @jens highlight when and where this differences are introduced. Thanks in advance.
Thanks! Can you please let me know when this is done so that I can test it? Thanks in advance
The only problem about fixing it is that it will break existing projects. And also I won't be able to get used to using the direction blocks differently to how I used to use them
The problems of progress 
Right, we'll have to look at the version number in the project file when loading old projects. That's a solvable problem. But, I remember some software developer giving a talk in which he said that if you're having exponential growth in users, that means the people who remember the old way soon become a tiny sliver of the user base, and catering to them takes tons of resources that could better be used serving the newer users. This was of course in a company that makes money on their software and pays its staff. :~) I think we've been pretty good about not breaking Scratch projects, probably better than at not breaking BYOB projects because of details about object inheritance, for example.
Snapinator has been updated with the 'touching' fix.
Thanks a lot @djdolphin now the project works as expected. Even if I noticed a new difference between Scratch and Snap that requires a new manual update.
In Scratch and Snap you can set the direction of a sprite to whatever you want, but the final value assigned by Scratch is a value between -179 and 180. Instead, Snap's values for directions are values from 0 to 359. So all tests in projects imported from Scratch for values between -179 and -1 will fail in Snap.
In order to solve this problem, all "direction" reporters should be embedded in a "snap equivalent direction to" reporter, that will convert all values from -179 to -1 to values from 181 to 359, just by adding 360.
For point is direction and for turn there is no problem. For the reporter you could use direction > 180 ? direction-360 : direction.
Yes, there are many solutions
I don't have strong feelings either way about the range of DIRECTION, although I think I recall that Cynthia does.
But what I do feel strongly about is not breaking our existing projects for the sake of Scratch compatibility. Maybe you can talk @djdolphin into a hack for the reporter in Snapin8r.
Yes, that is what I thought. Of course, not breaking Snap projects is a much more cogent goal than just allowing to import Scratch projects so that they work.
But even importing Scratch projects that will work once imported is, I guess, a very important goal so that Scratch users will have a stronger impulse to move to Snap not only for its more powerful language, but also as it can remix -thanks to @djdolphin's excellent tool- Scratch projects.
That is why I propose @djdolphin to embed all "direction" reporters inside a custom "snap equivalent direction to" reporter that will convert all values from -179 to -1 to values from 181 to 359.
Maybe after he gets the bignum library updated to 6.0...